...
The diagram below shows how this would work:
A few things are required for this to work:
When a Instance boots it sends out a Router Solicitation and it gets the information from both routers. This is done by the Network Stack of the Instance and is supported by all major Operating Systems.
Using DHCPv6+IA the Instances will obtain their IPv6 address. We can not use SLAAC as certain Operating Systems (like Windows) do not use the MAC address of the network card for calculating their SLAAC address.
CloudStack picks a random IPv6 address out of the /64 and stores that with the Instance.
This address is then programmed into the Security Groups. By default we allow:
...
.
...
ICMP is a essential part of IPv6. Blocking ICMP will break IPv6.
A route table on the Instance might look like this:
2a002001:f10db8:1011::/64 dev eth0 proto kernel metric 256 expires 2591994sec
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::20c:dbff:fef9:cf00 dev eth0 proto ra metric 1024 expires 54sec hoplimit 64
default via fe80::212:f2ff:fe9c:3300 dev eth0 proto ra metric 1024 expires 46sec hoplimit 64
Here it has two default routes via both routers. These routes were obtained by the Router Advertisements.
The Instance now has a single /128 address, but we also want to route a subnet to the Instance.
With IPv4 a client is identified by it's MAC address. With IPv6 the client generates a DUID which is used for identification. Since the client generates this DUID we can not trust it.
On the hypervisor we will run a tagger which inspects outgoing DHCPv6 requests and adds the MAC address of the Instance as option 37 to the DHCPv6 request.
The DHCPv6 server will identify the client based on this option added to the packet.
RFC6939: https://tools.ietf.org/html/rfc6939
This tagger is a small daemon which knows which MAC belongs to which Instance can now use DHCPv6 again to ask for prefix delegationand tag the DHCPv6 packages based on that.
The recommendation is to use ISC Kea as a DHCPv6 server.
In Basic or Direct Attached networking this DHCPv6 server has to run somewhere. It doesn't have to be in the same Layer 2 LAN, as long as the DHCPv6 requests can reach it somewhere.
This could be in a SSVM, but that is not mandatory.
In VPC/Isolated Networks the Kea DHCPv6 server can run inside the SSVM.
IPv6 also need security grouping. It is similar to IPv4:
Afterwards the security groups need additional rules, we have to allow:
ICMP is a essential part of IPv6. Blocking ICMP will break IPv6.
RFC4890 describes the general recommendations for IPv6 firewalling
Using DHCPv6 the client can request one or multiple Prefixes using Prefix Delegation. The client will be identified based on option 37 by a 'tagger' as described above.
An example dhcp6c.conf:
interface eth0 {
send ia-pd 1;
...
The routers see this reply come back and add a route (pseudo) to their routing table:
$ ipv6 route add 2a002001:f10db8:201:fa42:/56 fe80::5054:8fff:fe9f:af61
The reply is now relayed back to the Instance.
In CloudStack we pre-configured a few things:
Under DHCPv4 you could identify a client based on it's MAC Address, but DHCPv6 uses DUUID: Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)
RFC6355: https://tools.ietf.org/html/rfc6355In this case we decide to use DUID-LL, which is identifying a client based on the Link-Layer address (MAC) of a client.
Since CloudStack is under control of generating the MAC address of the Instance we can also calculate the DUID-LL in advance and program that into the DHCPv6 server's database.
It is however up to the client to send the proper DUID! Unknown DUIDs coming it should not get a reply.
When an Instance is deployed we pick a new /56 from the /40 and record that in the database of the DHCPv6 server.
We also allow this /56 in the Security Group of the Instance (ip6tables on the hypervisor).
Now, when the client sends the proper DUID-LL it obtains a reply with a prefix. The prefix is also added to the routing tables of the routers.
The prefix is now usable on the InstanceWe should note that multiple prefixes per Instances should be allowed. DHCPv6 supports this.