Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. The Layer 3 routers/gateways of the CloudStack POD get a /40 IPv6 subnet routed to them using OSPF/BGP/Static routes. This assigment is static. Outside the control/scope of CloudStack.
  2. In the routers the DHCPv6 Relay is configured which forwards all DHCPv6 requests towards a DHCPv6 server under control of CloudStack
  3. In the Layer 2 network a /64 (POD) IPv6 is configured with Router Advertisements enabled with the managed flag. This /64 is NOT in the /40 routed to the routers. CloudStack has to know which subnet is being used here.
  4. Instances use SLAAC (without Privacy Extensions) to obtain a IPv6 Address using DHCPv6+IAaddress. They have to use the /64 subnet plus their MAC to generate the address.

OBTAINING ADDRESS

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 SLAAC the Instances will obtain their IPv6 address. Linux properly uses the MAC Address to generate the 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.Only Windows has to be configured to not use the random identifier, but the MAC address.

 

netsh interface ipv6 set privacy state=disabled store=persistent
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

 CloudStack picks a random IPv6 address out of the /64 and stores that with the Instance.

A route table on the Instance might look like this:

...

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.

DHCPv6

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.

...

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 SLAAC.

Basic Networking

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.

...

interface eth0 {
send ia-pd 1;
 send ia-na 10;
 request domain-name-servers;
request domain-name;
};

...

  • The /64 used in the Layer 2 network
  • The /40 we use for Prefix Delegation Assigments
  • The size of the prefixes we want to delegate: /5660

RFC6355: https://tools.ietf.org/html/rfc6355

When an Instance is deployed we pick a new /56 60 from the /40 and record that in the database of the DHCPv6 server.

We also allow this /56 60 in the Security Group of the Instance (ip6tables on the hypervisor).

...