Using OpenStack Networking with IPv6¶

The basics¶

OpenStack Networking has supported IPv6 tenant subnets in certain configurations since Juno, but the Kilo release adds a number of new features, functionality and bug fixes to make it more robust. The focus of this page will be:

• How to enable dual-stack (IPv4 and IPv6 enabled) instances.
• How those instances receive an IPv6 address.
• How those instances communicate across a router to other subnets or the internet.
• How those instances interact with other OpenStack services.

To enable a dual-stack network in OpenStack Networking simply requires creating a subnet with the ip_version field set to 6, then the IPv6 attributes (ipv6_ra_mode and ipv6_address_mode) set. The ipv6_ra_mode and ipv6_address_mode will be described in detail in the next section. Finally, the subnets cidr needs to be provided.

Not in scope¶

Things not in the scope of this document include:

• Single stack IPv6 tenant networking
• OpenStack control communication between servers and services over an IPv6 network.
• Connection to the OpenStack APIs via an IPv6 transport network
• IPv6 multicast
• IPv6 support in conjunction with any out of tree routers, switches, services or agents whether in physical or virtual form factors.

Neutron subnets and the IPv6 API attributes¶

As of Juno, the OpenStack Networking service (neutron) provides two new attributes to the subnet object, which allows users of the API to configure IPv6 subnets.

There are two IPv6 attributes:

• ipv6_ra_mode
• ipv6_address_mode

These attributes can be set to the following values:

• slaac
• dhcpv6-stateful
• dhcpv6-stateless

The attributes can also be left unset.

IPv6 addressing¶

The ipv6_address_mode attribute is used to control how addressing is handled by OpenStack. There are a number of different ways that guest instances can obtain an IPv6 address, and this attribute exposes these choices to users of the Networking API.

Router advertisements¶

The ipv6_ra_mode attribute is used to control router advertisements for a subnet.

The IPv6 Protocol uses Internet Control Message Protocol packets (ICMPv6) as a way to distribute information about networking. ICMPv6 packets with the type flag set to 134 are called “Router Advertisement” packets, which broadcasts information about the router and the route that can be used by guest instances to send network traffic.

The ipv6_ra_mode is used to specify if the Networking service should transmit ICMPv6 packets, for a subnet.

Dataplane¶

Both the Linux bridge and the Open vSwitch dataplane modules support forwarding IPv6 packets amongst the guests and router ports. Similar to IPv4, there is no special configuration or setup required to enable the dataplane to properly forward packets from the source to the destination using IPv6. Note that these dataplanes will forward Link-local Address (LLA) packets between hosts on the same network just fine without any participation or setup by OpenStack components after the ports are all connected and MAC addresses learned.

Addresses for subnets¶

There are four methods for a subnet to get its cidr in OpenStack:

1. Direct assignment during subnet creation via command line or Horizon
2. Referencing a subnet pool during subnet creation

In the future, different techniques could be used to allocate subnets to tenants:

1. Using a PD client to request a prefix for a subnet from a PD server
2. Use of an external IPAM module to allocate the subnet

Address modes for ports¶

IPv6 supports three different addressing schemes for address configuration and for providing optional network information.

Stateless Address Auto Configuration (SLAAC)

Address configuration using Router Advertisement (RA).

DHCPv6-stateless

Address configuration using RA and optional information using DHCPv6.

DHCPv6-stateful

Address configuration and optional information using DHCPv6.

OpenStack can be setup such that OpenStack Networking directly provides RA, DHCP relay and DHCPv6 address and optional information for their networks or this can be delegated to external routers and services based on the drivers that are in use. There are two neutron subnet attributes - ipv6_ra_mode and ipv6_address_mode – that determine how IPv6 addressing and network information is provided to tenant instances:

• ipv6_ra_mode: Determines who sends RA.
• ipv6_address_mode: Determines how instances obtain IPv6 address, default gateway, or optional information.

For the above two attributes to be effective, enable_dhcp must be set to True in file neutron.conf.

Using SLAAC for addressing¶

When using SLAAC, the currently supported combinations for ipv6_ra_mode and ipv6_address_mode are as follows.

Setting ipv6_ra_mode to slaac will result in OpenStack Networking routers being configured to send RA packets, when they are created. This results in the following values set for the address configuration flags in the RA messages:

• Auto Configuration Flag = 1 Managed
• Configuration Flag = 0
• Other Configuration Flag = 0 New or existing

Neutron networks that contain a SLAAC enabled IPv6 subnet will result in all neutron ports attached to the network receiving IPv6 addresses. This is because when RA broadcast messages are sent out on a neutron network, they are received by all IPv6 capable ports on the network, and each port will then configure an IPv6 address based on the information contained in the RA packet. In some cases, an IPv6 SLAAC address will be added to a port, in addition to other IPv4 and IPv6 addresses that the port already has been assigned.

DHCPv6¶

For DHCPv6-stateless, the currently supported combinations are as follows:

Setting DHCPv6-stateless for ipv6_ra_mode configures the neutron router with radvd agent to send RAs. The table below captures the values set for the address configuration flags in the RA packet in this scenario. Similarly, setting DHCPv6-stateless for ipv6_address_mode configures neutron DHCP implementation to provide the additional network information.

• Auto Configuration Flag = 1
• Managed Configuration Flag = 0
• Other Configuration Flag = 1

Neutron’s Distributed Router feature and IPv6¶

IPv6 does work when the Distributed Virtual Router functionality is enabled, but all ingress/egress traffic is via the centralized router (hence, not distributed). More work is required to fully enable this functionality.

VPNaaS¶

VPNaaS supports IPv6, but support in Kilo and prior releases will have some bugs that may limit how it can be used. More thorough and complete testing and bug fixing is being done as part of the Liberty release. IPv6-based VPN as a service is configured similar to the IPv4 configuration. Either or both the peer_address and the peer_cidr can specified as an IPv6 address. The choice of addressing modes and router modes described above should not impact support.

LBaaS¶

TODO

FWaaS¶

FWaaS allows creation of IPv6 based rules.

NAT & Floating IPs¶

At the current time OpenStack Networking does not provide any facility to support any flavor of NAT with IPv6. Unlike IPv4 there is no current embedded support for floating IPs with IPv6. It is assumed that the IPv6 addressing amongst the tenants are using GUAs with no overlap across the tenants.

Configuring interfaces of the guest¶

OpenStack currently doesn’t support the privacy extensions defined by RFC 4941. The interface identifier and DUID used must be directly derived from the MAC as described in RFC 2373. The compute hosts must not be setup to utilize the privacy extensions when generating their interface identifier.

There is no provisions for an IPv6-based metadata service similar to what is provided for IPv4. In the case of dual stack Guests though it is always possible to use the IPv4 metadata service instead.

Unlike IPv4 the MTU of a given network can be conveyed in the RA messages sent by the router and not in the DHCP messages. In Kilo the MTU sent by RADVD is always 1500, but in Liberty changes are planned to allow the RA to send the proper MTU of the network.

Prefix delegation¶

From the Liberty release onwards, OpenStack Networking supports IPv6 prefix delegation. This section describes the configuration and workflow steps necessary to use IPv6 prefix delegation to provide automatic allocation of subnet CIDRs. This allows you as the OpenStack administrator to rely on an external (to the OpenStack Networking service) DHCPv6 server to manage your tenant network prefixes.

default_ipv6_subnet_pool = prefix_delegation

pd_dhcp_driver = <class path to driver>

script "/var/lib/dibbler/pd-server.sh"

iface "br-ex" {
    pd-class {
        pd-pool 2222:2222:2222::/48
        pd-length 64
    }
}

if [ "$PREFIX1" != "" ]; then
    if [ "$1" == "add" ]; then
        sudo ip -6 route add ${PREFIX1}/64 via $REMOTE_ADDR dev $IFACE
    fi
    if [ "$1" == "delete" ]; then
        sudo ip -6 route del ${PREFIX1}/64 via $REMOTE_ADDR dev $IFACE
    fi
fi

# dibbler-server run

# dibbler-server start

$ neutron net-create ipv6-pd
Created a new network:
+-----------------+--------------------------------------+
| Field           | Value                                |
+-----------------+--------------------------------------+
| admin_state_up  | True                                 |
| id              | 31ef3e85-111f-4772-8172-8e4a404a7476 |
| mtu             | 0                                    |
| name            | ipv6-pd                              |
| router:external | False                                |
| shared          | False                                |
| status          | ACTIVE                               |
| subnets         |                                      |
| tenant_id       | 28b39bcce66e4a648f82e2362b958b60     |
+-----------------+--------------------------------------+

$ neutron subnet-create ipv6-pd --name ipv6-pd-1 --ip_version 6 \
  --ipv6_ra_mode slaac --ipv6_address_mode slaac
Created a new subnet:
+-------------------+--------------------------------------------------+
| Field             | Value                                            |
+-------------------+--------------------------------------------------+
| allocation_pools  | {"start": "::2", "end": "::ffff:ffff:ffff:fffe"} |
| cidr              | ::/64                                            |
| dns_nameservers   |                                                  |
| enable_dhcp       | True                                             |
| gateway_ip        | ::1                                              |
| host_routes       |                                                  |
| id                | ea139dcd-17a3-4f0a-8cca-dff8b4e03f8a             |
| ip_version        | 6                                                |
| ipv6_address_mode | slaac                                            |
| ipv6_ra_mode      | slaac                                            |
| name              | ipv6-pd-1                                        |
| network_id        | 31ef3e85-111f-4772-8172-8e4a404a7476             |
| subnetpool_id     | prefix_delegation                                |
| tenant_id         | 28b39bcce66e4a648f82e2362b958b60                 |
+-------------------+--------------------------------------------------+

$ neutron router-interface-add cb9b7a2c-0ffa-412f-989a-1e6c60e1c02f \
  ea139dcd-17a3-4f0a-8cca-dff8b4e03f8a
Added interface a7e4d663-e3fc-4b8f-909f-865c397a930e to router
cb9b7a2c-0ffa-412f-989a-1e6c60e1c02f.

$ neutron subnet-show ipv6-pd-1
+-------------------+-------------------------------------------------+
| Field             | Value                                           |
+-------------------+-------------------------------------------------+
| allocation_pools  | {"start": "2222:2222:2222:6977::2",             |
|                   | "end":"2222:2222:2222:6977:ffff:ffff:ffff:fffe"}|
| cidr              | 2222:2222:2222:6977::/64                        |
| dns_nameservers   |                                                 |
| enable_dhcp       | True                                            |
| gateway_ip        | 2222:2222:2222:6977::1                          |
| host_routes       |                                                 |
| id                | ea139dcd-17a3-4f0a-8cca-dff8b4e03f8a            |
| ip_version        | 6                                               |
| ipv6_address_mode | slaac                                           |
| ipv6_ra_mode      | slaac                                           |
| name              | ipv6-pd-1                                       |
| network_id        | 31ef3e85-111f-4772-8172-8e4a404a7476            |
| subnetpool_id     | prefix_delegation                               |
| tenant_id         | 28b39bcce66e4a648f82e2362b958b60                |
+-------------------+-------------------------------------------------+

pd_dhcp_driver = neutron_pd_agent

pd_interface = br-ex

neutron-pd-agent --config-file /etc/neutron/neutron.conf