...
The goal is Q1 2016 to have a working IPv6 implementation where Instances obtain a /128, but also get a subnet routed. A /56 60 for example.
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 SLAAC the Instances will obtain their IPv6 address. Linux properly uses the MAC Address to generate the IPv6 address. Only Windows has to be configured to not use the random identifier, but the MAC address.
...
The Instance now has a single /128 address, but we also want to route a subnet to the Instance.
CloudStack can calculate which address an Instance will obtain. This is described in RFC4862.
The address of the Instance will not be stored in the database. Using the /64 subnet and the MAC address it can be calulcated when it is required. This saves additional database queries and storage.
This is ONLY for Prefix Delegation purposes. The IPv6 Address for an Instance is generated by the Instance using SLAAC.
With IPv4 a client is identified by it's MAC address. With IPv6 the client generates a DUID which is used for identification at the DHCPv6 server.
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 DHCPv6 has option 37 (remote-id) described in RFC4649. Routers/gateways (outside of CloudStack's control) have to insert the MAC address of the Instance as option 37 to into the DHCPv6 request .so that the
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 and tag the DHCPv6 packages based on that.
can use the MAC Address as a reliable source for identifying the Instance/client.
The recommendation is to use ISC Kea as a DHCPv6 server. This is ONLY for Prefix Delegation purposes. The IPv6 Address for an Instance is generated by the Instance using SLAACIt supports identyfing clients based on their MAC address.
In Basic or Direct Attached networking this DHCPv6 server has to run somewhere. Again, the DHCPv6 server is only required when DHCPv6 prefix delegation is used.
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 mandatoryThis is done by configuring a DHCPv6 Relay Agent on the routers/gateways in the network. This is outside the scope of CloudStack and has to be configuted by the Network Administrator.
In VPC/Isolated Networks the Kea DHCPv6 server can run inside the SSVM.
...
Using libvirt here might be a good solution.
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Afterwards the security groups need additional rules, we have to allow:
...
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' 82 (remote-id) as described above.
An example dhcp6c.conf:
...
In CloudStack we pre-configured a few things:
...
When an Instance is deployed we pick a new /60 from the /40 and record that in the database of the DHCPv6 server .(ISC Kea is recommended)
We also allow this /60 in the Security Group of the Instance (ip6tables on ip6tables/libvirt on the hypervisor).
We should note that multiple prefixes per Instances should be allowed. DHCPv6 supports this.
...