Chapter 1. Introduction to IPv6 for the overcloud

download PDF

Red Hat OpenStack Platform director creates a cloud environment called the overcloud. By default, the overcloud uses Internet Protocol version 4 (IPv4) to configure the service endpoints. However, the overcloud also supports Internet Protocol version 6 (IPv6) endpoints, which is useful for organizations that support IPv6 infrastructure.

This guide acts as supplementary information for the Director Installation and Usage guide. The same requirements specified in Director Installation and Usage also apply to this guide. Implement these requirements as necessary.

1.1. Introduction to IPv6 networking

IPv6 is the latest version of the Internet Protocol standard. Internet Engineering Task Force (IETF) developed IPv6 as a means to combat the exhaustion of IP address from the current common IPv4 standard. IPv6 has various differences from IPv4 including:

Large IP Address Range
The IPv6 range is much larger than the IPv4 range.
Better End-to-End Connectivity
The larger IP range provides better end-to-end connectivity due to less reliance on network address translation.
No Broadcasting
IPv6 does not support traditional IP broadcasting. Instead, IPv6 uses multicasting to send packets to applicable hosts in a hierarchical manner.
Stateless Address Autoconfiguration (SLAAC)
IPv6 provides features for automatically configuring IP addresses and detecting duplicate addresses on a network. This reduces the reliance on a DHCP server to assign addresses.

IPv6 uses 128 bits (represented with 4 hexadecimals using groups of 16 bits) to define addresses while IPv4 uses only 32 bits (represented with decimal digits using groups of 8 bits). For example, a representation of an IPv4 address ( looks like this:










For an IPv6 address (2001:db8:88ec:9fb3::1), the representation looks like this:


0010 0000 0000 0001


0000 1101 1011 1000


1000 1000 1110 1100


1001 1111 1011 0011


0000 0000 0000 0000


0000 0000 0000 0000


0000 0000 0000 0000


0000 0000 0000 0001


You can also represent IPv6 addresses without leading zeros in each bit group and omit a set of zero bit groups once for each IP address. In this example, you can represent the 0db8 bit grouping as just db8 and omit the three sets of 0000 bit groups, which shortens the representation from 2001:0db8:88ec:9fb3:0000:0000:0000:0001 to 2001:db8:88ec:9fb3::1. For more information, see "RFC 5952: A Recommendation for IPv6 Address Text Representation"

Subnetting in IPv6

Similar to IPv4, an IPv6 address uses a bit mask to define the address prefix as its network. For example, if you include a /64 bit mask to the sample IP address 2001:db8:88ec:9fb3::1/64, the bit mask acts as a prefix that defines the first 64 bits (2001:db8:88ec:9fb3) as the network. The remaining bits (0000:0000:0000:0001) define the host.

IPv6 also uses some special address types:

The loopback device uses an IPv6 for the internal communication within the host. This device is always ::1/128.
Link Local
A link local address is an IP address valid within a particular network segment. IPv6 requires each network device to have a link local address and use the prefix fe80::/10. However, most of the time, these addresses are prefixed with fe80::/64.
Unique local
A unique local address is intended for local communication. These addresses use a fc00::/7 prefix.
Hosts use multicast addresses to join multicast groups. These addresses use a ff00::/8 prefix. For example, FF02::1 is a multicast group for all nodes on the network and FF02::2 is a multicast group for all routers.
Global Unicast
These addresses are usually reserved for public IP address. These addresses use a 2000::/3 prefix.

1.2. Using IPv6 in Red Hat OpenStack Platform

Red Hat OpenStack Platform (RHOSP) director maps OpenStack services to isolated networks. These networks include:

  • Internal API
  • Storage
  • Storage Management
  • Project(tenant) Networks (Neutron VLAN mode)
  • External

For more information about these network traffic types, see the Director Installation and Usage guide.

Director also provides methods to use IPv6 communication for these networks. This means the required OpenStack services, databases, and other related services use IPv6 addresses to communicate. This also applies to environments that use a high availability solution involving multiple Controller nodes. This helps organizations integrate RHOSP with their IPv6 infrastructure.

Use the following table as a guide for which RHOSP networks support IPv6:

Network TypeSupported Internet Protocol (IP)Notes

Internal API

  • IPv6
  • IPv4


  • IPv6
  • IPv4

Storage Management

  • IPv6
  • IPv4

Project Networks

  • Dual-stack (IPv4/v6)
  • IPv6
  • IPv4

Project Network Endpoints

  • Dual stack (IPv4/v6)
  • IPv6
  • IPv4

This refers to the IP address of the network hosting the project network tunnels, not the project networks themselves.

IPv6 for network endpoints supports only VXLAN and Geneve. Generic routing encapsulation (GRE) is not yet supported.

External - Public API (and Horizon)

  • IPv6
  • IPv4

External - Floating IPs

  • Dual stack (IPv4/v6)
  • IPv4

IPv6 uses Global Unicast Addresses (GUAs) instead of NAT and floating IP addresses. The Networking (neutron) service expects the IPv6 addressing between project networks to use GUAs, with no overlap in GUAs across the project networks, and therefore can be routed without NAT.

With dual stack (IPv4/v6), you can use floating IP addresses to only reach the IP addresses on IPv4 subnets.

Provider Networks

  • Dual stack (IPv4/v6)
  • IPv6
  • IPv4

IPv6 support is dependent on the project operating system.

Provisioning (PXE/DHCP)

  • IPv6
  • IPv4

IPMI or other BMC

  • IPv6
  • IPv4

RHOSP communicates with baseboard management controller (BMC) interfaces over the Provisioning network.

If BMC interfaces support dual stack IPv4 or IPv6, tools that are not part of RHOSP can use IPv6 to communicate with the BMCs.

Overcloud Provisioning network


The Provisioning network used for Bare Metal Provisioning service in the overcloud.

Overcloud Cleaning network


The isolated network used to clean a machine before it is ready for reuse.

Defining the scenario

The scenario for this guide is to create an overcloud with an isolated network that uses IPv6. Use heat templates and environment files to configure network isolation. This scenario also provides certain variants to these heat templates and environment files to demonstrate specific differences in configuration.


In this scenario, the undercloud still uses IPv4 connectivity for PXE boot, introspection, deployment, and other services.

This guide uses a scenario similar to the advanced overcloud scenario. The main difference is the omission of the Ceph Storage nodes.

For more information about this scenario, see the Director Installation and Usage guide.


This guide uses the 2001:DB8::/32 IPv6 prefix for documentation purposes as defined in RFC 3849. Ensure that you substitute these example addresses for IPv6 addresses from your own network.

Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.