IPv6 Support

Calico supports connectivity over IPv6, between compute hosts, and between compute hosts and their VMs. This means that, subject to security configuration, a VM can initiate an IPv6 connection to another VM, or to an IPv6 destination outside the data center; and that a VM can terminate an IPv6 connection from outside.

Requirements for containers

Containers have no specific requirements for utilising IPv6 connectivity.

Requirements for guest VM images

When using Calico with a VM platform (e.g. OpenStack), obtaining IPv6 connectivity requires certain configuration in the guest VM image:

  • When it boots up, the VM should issue a DHCPv6 request for each of its interfaces, so that it can learn the IPv6 addresses that OpenStack has allocated for it.
  • The VM must be configured to accept Router Advertisements.
  • If it uses the widely deployed DHCP client from ISC, the VM must have a fix or workaround for this known issue.

These requirements are not yet all met in common cloud images - but it is easy to remedy that by launching an image, making appropriate changes to its configuration files, taking a snapshot, and then using that snapshot thereafter instead of the original image.

For example, starting from the Ubuntu 14.04 cloud image, the following changes will suffice to meet the requirements just listed.

  • In /etc/network/interfaces.d/eth0.cfg, add:

    iface eth0 inet6 dhcp
        accept_ra 1

  • In /sbin/dhclient-script, add at the start of the script:

    new_ip6_prefixlen=128

  • In /etc/sysctl.d, create a file named 30-eth0-rs-delay.conf with contents:

    net.ipv6.conf.eth0.router_solicitation_delay = 10

Implementation details

Following are the key points of how IPv6 connectivity is currently implemented in Calico.

  • IPv6 forwarding is globally enabled on each compute host.
  • Felix (the Calico agent):
    • does ip -6 neigh add lladdr dev, instead of IPv4 case arp -s, for each endpoint that is created with an IPv6 address
    • adds a static route for the endpoint’s IPv6 address, via its tap or veth device, just as for IPv4.
  • Dnsmasq provides both Router Advertisements and DHCPv6 service (neither of which are required for container environments).
    • Router Advertisements, without SLAAC or on-link flags, cause each VM to create a default route to the link-local address of the VM’s TAP device on the compute host.
    • DHCPv6 allows VMs to get their orchestrator-allocated IPv6 address.
  • For container environments, we don’t Dnsmasq:
    • rather than using Router Advertisements to create the default route, we Proxy NDP to ensure that routes to all machines go via the compute host.
    • rather than using DHCPv6 to allocate IPv6 addresses, we allocate the IPv6 address directly to the container interface before we move it into the container.
  • BIRD6 runs between the compute hosts to distribute routes.

OpenStack Specific Details

In OpenStack, IPv6 connectivity requires defining an IPv6 subnet, in each Neutron network, with:

  • the IPv6 address range that you want your VMs to use
  • DHCP enabled
  • (from Juno onwards) IPv6 address mode set to DHCPv6 stateful.

We suggest initially configuring both IPv4 and IPv6 subnets in each network. This allows handling VM images that support only IPv4 alongside those that support both IPv4 and IPv6, and allows a VM to be accessed over IPv4 in case this is needed to troubleshoot any issues with its IPv6 configuration.

In principle, though, we are not aware of any problems with configuring and using IPv6-only networks in OpenStack.