Chapter 1. Introduction to IPv6 for the overcloud
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 (192.168.0.1) looks like this:
| Bits | Representation |
|---|---|
| 11000000 | 192 |
| 10101000 | 168 |
| 00000000 | 0 |
| 00000001 | 1 |
For an IPv6 address (2001:db8:88ec:9fb3::1), the representation looks like this:
| Bits | Representation |
|---|---|
| 0010 0000 0000 0001 | 2001 |
| 0000 1101 1011 1000 | 0db8 |
| 1000 1000 1110 1100 | 88ec |
| 1001 1111 1011 0011 | 9fb3 |
| 0000 0000 0000 0000 | 0000 |
| 0000 0000 0000 0000 | 0000 |
| 0000 0000 0000 0000 | 0000 |
| 0000 0000 0000 0001 | 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:
- Loopback
-
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 withfe80::/64. - Unique local
-
A unique local address is intended for local communication. These addresses use a
fc00::/7prefix. - Multicast
-
Hosts use multicast addresses to join multicast groups. These addresses use a
ff00::/8prefix. For example,FF02::1is a multicast group for all nodes on the network andFF02::2is a multicast group for all routers. - Global Unicast
-
These addresses are usually reserved for public IP address. These addresses use a
2000::/3prefix.
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 Type | Supported Internet Protocol (IP) | Notes |
|---|---|---|
| Internal API |
| |
| Storage |
| |
| Storage Management |
| |
| Project Networks |
| |
| Project Network Endpoints |
| 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) |
| |
| External - Floating IPs |
| 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 |
| IPv6 support is dependent on the project operating system. |
| Provisioning (PXE/DHCP) |
| |
| IPMI or other BMC |
| 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 | IPv6 | The Provisioning network used for Bare Metal Provisioning service in the overcloud. |
| Overcloud Cleaning network | None | 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.
