...

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:

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 (SLAAC) enabled. 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. They have to use the /64 subnet plus their MAC to generate the address. The subnet used here has to be a /64 exactly.

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

• The Link-Local Address
• The IPv6 address handed out by DHCPv6.
• ICMPv6

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.

netsh interface ipv6 set privacy state=disabled store=persistent

netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

 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.

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.

DHCPv6

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.

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 into the DHCPv6 request so that the

DHCPv6 server 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. It supports identyfing clients based on their MAC address.

Basic Networking

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

Advanced Networking

In VPC/Isolated Networks the Kea DHCPv6 server can run inside the SSVM.

SECURITY GROUPS

IPv6 also need security grouping. It is similar to IPv4:

• ebtables to prevent MAC spoofing
• Do source IP-address checking to prevent source address spoofing
  
  • The Addresses of the Instance
  • Any delegated prefixes

Using libvirt here might be a good solution.

Afterwards the security groups need additional rules, we have to allow:

• The Link-Local Address with specific ICMPv6:
  • Duplicate Address Detection
  • Echo Request
  • MLD
  • Router Sollicitation
  • Neighbor Sollicitation
• On Link Local no UDP or TCP is allowed
• The IPv6 address handed out by DHCPv6.
• ICMPv6
• User specified rules

ICMP is a essential part of IPv6. Blocking ICMP will break IPv6.

RFC4890 describes the general recommendations for IPv6 firewalling

DHCPv6+Prefix Delegation

Using DHCPv6 the client can request one or multiple Prefixes using Prefix Delegation. The client will be identified based on option 82 (remote-id) as described above.

can now use DHCPv6 again to ask for prefix delegation.An example dhcp6c.conf:

interface eth0 {
 send ia-pd 1;

 send ia-na 10;

 request domain-name-servers;
 request domain-name;
};

...

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.

ADDRESS GENERATION

In CloudStack we pre-configured a few things:

• The /64 used in the Layer 2 network. Using a /64 is mandatory to use SLAAC.
• The /40 we use for Prefix Delegation Assigments
• The size of the prefixes we want to delegate: /56

...

• 60

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

In 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 60 from the /40 and record that in the database of the DHCPv6 server .(ISC Kea is recommended)

We also allow this /56 60 in the Security Group of the Instance (ip6tables on ip6tables/libvirt 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.