With the exhaustion of IPv4 addresses, IPv6 is no longer a choice but is now a necessity, even more so in case of a cloud environment.

Neutron includes a sub-team focused on bringing parity between IPv4 and IPv6 features and to enhance IPv6 support in OpenStack. The group currently meets every Tuesday at 15:00 UTC in #openstack-meeting-alt with notes available at the following link.

In this post, I would like to share my views on how IPv6 support has evolved in OpenStack with references at appropriate places to where you will be able to find more information.  I will try to first cover what is available in IceHouse, then review what has been merged in Juno and then talk about what is brewing for Kilo.

IceHouse: Limited Support

Support for IPv6 subnets

In order to create IPv6 subnets two new attributes, ipv6-ra-mode and ipv6-address-mode, were added to the Neutron Subnet API. Using these two attributes, you will be able to create subnets which support various IPv6 configuration modes like Stateless Address Autoconfiguration (SLAAC), DHCPv6 Stateful and DHCPv6 Stateless. Not all combinations of these parameters are valid. You can refer to the following link (and also here) which explain the valid/invalid use-cases.

IPv6 SLAAC: It allows an IPv6 compliant node to autonomously generate an IPv6 globally unique address using a combination of locally available information and information advertised by routers.

DHCPv6 Stateless Support: IPv6 addresses are auto discovered from the Router and additional info (like DNS) from DHCPv6 Server.

DHCPv6 Stateful Support: IPv6 addresses along with additional information is discovered from DHCPv6 Server.

IPv6 Upstream Provider Network Support (IceHouse)

With the IceHouse release of OpenStack, only IPv6 Upstream Provider Network support with VLANs is feasible. Some related patch-sets were merged in Juno timeframe and have to be manually backported to realise this feature.

• BluePrint: Provider Networking – Upstream SLAAC Support.
• LibVirt: Disable hairpin when using Neutron
• Calculate stateless IPv6 address
• Pass in certain ICMPv6 types by default
• Permit ICMPv6 RAs only from known routers
• Create new IPv6 attributes for Subnets
• Support Subnets that are configured by external RAs
• Ensure entries in dnsmasq belong to a subnet using DHCP
• Create new IPv6 attributes for Subnets by client

Juno: we’re getting there

RADVD instead of DNSMASQ for RA (Juno)

During the Juno development cycle, some important decisions were taken. I would like to particularly highlight the decision taken to use RADVD over DNSMASQ for serving Router Advertisements (RA). The initial idea was to use DNSMASQ for all the IPv6 modes, but keeping in view of some of the roadmap features of IPv6 and the limitations of DNSMASQ it was decided to use RADVD for serving RAs and DNSMASQ for DHCPv6 Stateless/Stateful modes.

The main reasons behind this decision are mentioned below and are explained in the RADVD Blueprint.

1. In an IPv6 SLAAC network, clients would configure the default gateway to the IP address of the NIC serving RA. Currently DNSMASQ runs in a separate dhcp namespace. So, to address the default gateway use-case, we have to either run another instance of DNSMASQ in the router namespace or change the existing behavior of Neutron to run the DNSMASQ in the router namespace instead of dhcp namespace. This could have implications for IPv4 use-cases as there could be some valid reasons behind running DNSMASQ in a separate dhcp namespace.
2. RADVD has the support for Unicast RA, while DNSMASQ does not support it. Unicast RA would be required for floating IPv6 support and future additions to Neutron. The maintainer of DNSMASQ clearly suggests using RADVD over DNSMASQ for this purpose.

Multiple IPv6 configuration modes (Juno)

In Juno release, all the IPv6 configuration modes like SLAAC, DHCPv6 Stateful and Stateless modes will be supported. Along with this, IPv6 Security Groups support is now matured in OpenStack.

SLAAC Support: IPv6 addresses are auto discovered and assigned.

1. BP Specification: Support Router Advertisement Daemon (radvd) for IPv6.
2. Associated Patch: Radvd Support for IPv6 Router Advertisements.

DHCPv6 Stateless Support: IPv6 addresses auto discovered from the Router and additional info from DHCPv6 Server.

DHCPv6 Stateful: IPv6 addresses along with additional information discovered from DHCPv6 Server.

1. BP Specification: Specification for Dnsmasq DHCPv6
2. Launchpad Links: DHCPv6 Stateful, DHCPv6 Stateless.
3. Associated Patch: Support Stateful and Stateless DHCPv6 by dnsmasq

What about the clients? Yes, the required changes are merged in python-neutronclient as well as Horizon.

Network Connectivity with Neutron

This is a simplified architecture diagram of Network connectivity in OpenStack.

Note: As a platform requirement, we require DNSMASQ 2.63 (or above) and RADVD for IPv6 support.

As IPv6 support was improving in Neutron (Juno), one thing that was completely missing was the support for IPv6 in tempest. eNovance along with Comcast worked towards addressing the parity between IPv4 and IPv6 use-cases. I’m happy to see new patches submitted by various contributors in this regard.

Current limitations for Juno

There are some known limitations and areas where IPv6 impact is yet to be carefully evaluated like (not an exhaustive list)….

1. Metadata is only supported on an IPv4  network. As a temporary measure, config-drive is a recommended solution.
2. Impact on advanced features like FWaaS, VPNaaS etc.
3. Privacy extensions is currently not supported as port-firewalling requires predictable addresses.
4. Floating IPv6 support.
5. Impact of IPv6 on overlay networks like GRE and VxLAN.
6. IPv6 and NFV use-cases.

What about DevStack?

Unfortunately, at this time, DevStack currently does not support IPv6. The following patches are submitted in this regard, hoping that they will be implemented in Kilo.

1. Add IPv6 support for tenant data network
2. Add IPv6 management network support

Kilo: the final frontier?

What is in the Roadmap for Kilo?

In the Kilo Release, the following additional features are being proposed.

1. IPv6 prefix delegation support in Neutron
2. Support Multiple IPv6 Prefixes and Addresses for an IPv6 Network
3. Support for dual-stack (IPv4 and IPv6) on external gateway
4. Support IPv6 DHCPv6 Relay Agent
5. IPv6 Floating IP support
6. …

This is an excellent news for all of us who are interested in OpenStack IPv6 support. While there is still a long way to go before we can say OpenStack is IPv6 production ready, it’s an important milestone as it gives us a platform where we can create IPv6 subnets, try out various use-cases and report issues that are encountered. Click here to see the IPv6 bugs reported in OpenStack.

Thanks to Sean M Collins, Xu Han Peng, Shixiong, HenryG, Baodong Li who implemented the IPv6 blueprints. While I have only mentioned few members who have addressed the blueprints, it was/is a collaborative effort from the Community (including the Neutron cores) who reviewed the patches, addressed issues and shared their knowledge at various stages.