Jump to: navigation, search

NEUTRON-IPV6-MANUAL

The purpose of this wiki is to describe how the features and functionality available in OpenStack (using neutron networking) as of the Kilo release. The functionality describe is based on the in-Tree supported components. It is intended to serve as a guide for how to deploy IPv6 enabled instances. Where appropriate features planned for Liberty or beyond may be described. Special thanks to Rohit Agarwalla whose blog was the source of much of this information.

The Basics

OpenStack Neutron has supported IPv6 tenant subnets for a number of releases, but the Kilo release adds a number of new features, functionality and bug fixes to make it more robust. The focus of the document is to describe:

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

To enable a dual stack network in neutron simply requires creating a subnet with the v6 flag set. In addition the address mode needs to be chosen. This is described more completely below. Finally, the subnets prefix needs to be provided. The guest instance is created normally the procedure is not changed for dual stack versus how it was done for IPv4 only.

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.

Tenant Network Considerations

Dataplane

Both the linuxbridge and the Open vSwitch (OVS) 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.

Address Modes for Subnets

There are four methods for a subnet to gets its prefix in OpenStack:

  1. Direct assignment during subnet creation via command line or Horizon
  2. Referencing a prefix pool during subnet creation
  3. Using the PD client to request a pool from a PD server (Liberty)
  4. Use of an external IPAM module to allocate the subnet (??? Is this only possible in conjunction with option 3?)

Address Modes for Tenant Ports

There are two methods to allocate the full address to guest port after the subnet prefix is assigned.

  1. Using the internal IPAM implementation which uses EUI-64 format as the interface identifier
  2. Using an external IPAM module to assign the /128

Note: An external DHCPv6 server in theory could override the full address OpenStack assigns based on the EUI-64 address, but that would not be wise as it would not be consistent through the system.

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 Neutron directly provides RA, DHCPv6 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, and/or optional information.

For the above two attributes to be effective, enable_dhcp must be set to True in Neutron. With enable_dhcp set to True, if neither attribute is configured, it is considered to be a case of DHCPv6-stateful.

SLAAC

For SLAAC, the possible combinations for the attributes are -

ipv6_ra_mode ipv6_address_mode Result
SLAAC Not specified Address using Neutron router
Not specified SLAAC Address using external router
SLAAC SLAAC Address using Neutron router

Setting SLAAC for ipv6_ra_mode configures Neutron router with radvd agent to send RA. 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 get associated with a SLAAC enabled IPv6 subnet result in all Neutron ports within the network to get an IPv6 address assigned automatically. This is because when RA multicast messages are sent out on a Neutron network, they are received by all IPv6 capable interfaces on the network which then configure the IPv6 address. The IPv6 SLAAC addresses in addition to other IPv4 address on the network port are properly reflected in any command output.

DHCPv6-stateless

For DHCPv6-stateless, the possible combinations are –

ipv6_ra_mode ipv6_address_mode Result
DHCPv6-stateless Not specified Address using Neutron router and optional information using external DHCP service
Not specified DHCPv6-stateless Address using external router and optional information using Neutron DHCP implementation
DHCPv6-stateless DHCPv6-stateless Address and optional information using Neutron router and DHCP implementation respectively

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

We probably want to have placeholders for some of the Liberty work like prefix delegation, etc.   

Router Support

IPv6 Neutron Router

The behavior of the Neutron router for IPv6 is different than IPv4 in a few ways.

Internal router ports, that act as default gateway ports for a network, will share a common port for all IPv6 subnets associated with the network. This implies that there will be an IPv6 internal router interface with multiple IPv6 addresses from each of the IPv6 subnets associated with the network and a separate IPv4 internal router interface for the IPv4 subnet. On the other hand, external router ports are allowed to have a dual-stack configuration with both an IPv4 and an IPv6 address assigned to them.

Neutron tenant networks that are assigned Global Unicast Address (GUA) prefixes and addresses don’t require NAT on the Neutron router external gateway port to access the outside world. As a consequence of the lack of NAT the external router port doesn’t require a GUA to send and receive to the external networks. This implies a GUA IPv6 subnet prefix is not necessarily needed for the Neutron external network. By default, a IPv6 LLA associated with the external gateway port can be used for routing purposes. To handle this scenario, the implementation of router-gateway-set API in Neutron has been modified so that an IPv6 subnet is not required for the external network that is associated with the Neutron router. The LLA address of the upstream router can be learned in two ways.

  1. In the absence of an upstream RA support, ipv6_gateway flag can be set with the external router gateway LLA in the Neutron L3 agent configuration file. This also requires that no subnet is associated with that port.
  2. The upstream router can send an RA and the neutron router will automatically learn the next-hop LLA, provided again that no subnet is assigned and the ipv6_gateway flag is not set.

Effectively the ipv6_gateway flag takes precedence over an RA that is received from the upstream router. If it is desired to use a GUA next hop that is accomplished by allocating a subnet to the external router port and assigning the upstream routers GUA address as the gateway for the subnet.

Note: That it should be possible for tenants to communicate with each other on an isolated network (a network without a router port) using LLA with little to no participation on the part of OpenStack. The authors of this wiki have not proven that to be true for all scenarios.

IPv6 Distributed Virtual Router

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.

Services Consideration

VPNaaS

VPNaaS supports IPv6, but support in Kilo and prior releases will have some bugs that may limit how it can be used. More through 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.

FWaaS

Need help on this. Is it a future?

LBaaS

Need help on this. Is it a future?

NAT & Floating IPs

At the current time OpenStack Neutron 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 over-lap across the tenants.

Security Considerations

Initially this is probably just stating the security group rules relative to IPv6 that are applied.   Need some help for these 

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.

OpenStack Control & Management Network Considerations

As of the Kilo release, considerable effort has gone in to ensuring the tenant network can handle dual stack IPv6 and IPv4 transport across the variety of configurations describe above. This same level of scrutiny has not been apply to running the OpenStack control network in a dual stack configuration. Similarly, little scrutiny has gone into ensuring that the OpenStack API endpoints can be accessed via an IPv6 network. At this time, OVS tunnel types - STT, VXLAN, GRE, only support IPv4 endpoints, not IPv6, so a full IPv6-only deployment is not possible with that technology.

References

The following link provides a great step by step tutorial on setting up the v6 with openstack. http://bit.ly/ipv6-kilo