Chapter 1. Introduction
Red Hat OpenStack Platform director creates a cloud environment called the Overcloud. As a 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 provides information and a configuration example for using IPv6 in your Overcloud.
1.1. Defining 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 only 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 |
Notice you can also represent IPv6 addresses without leading zeros in each bit group and omit a set of zero bit groups once per IP address. In our 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 our sample IP address (e.g. 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, including:
- 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 with fe80::/64.
- Unique local
- A unique local address is intended for local communication. These addresses use a fc00::/7 prefix.
- Multicast
- 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 director provides a method for mapping OpenStack services to isolated networks. These networks include:
- Internal API
- Storage
- Storage Management
- Tenant Networks (Neutron VLAN mode)
- External
For more information about these network traffic types, see the Director Installation and Usage guide.
Red Hat OpenStack Platform 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 using a high availability solution involving multiple Controller nodes. This helps organizations integrate Red Hat OpenStack Platform with their IPv6 infrastructure.
Use the following table as a guide for what networks support IPv6 in Red Hat OpenStack Platform:
| Network Type | Dual Stack (IPv4/v6) | Single Stack (IPv6) | Single Stack (IPv4) | Notes |
|---|---|---|---|---|
| Internal API | Yes | Yes | ||
| Storage | Yes | Yes | ||
| Storage Management | Yes | Yes | ||
| Tenant Networks | Yes | Yes | Yes | |
| Tenant Network Endpoints | Yes | Yes | Yes | This refers to the IP address of the network hosting the tenant network tunnels, not the tenant networks themselves. IPv6 for network endpoints supports only VXLAN and Geneve. Generic routing encapsulation (GRE) is not yet supported. |
| External - Public API (and Horizon) | Yes | Yes | ||
| External - Floating IPs | Yes | Yes | Yes | Dual stack and single stack (IPv6) only: neutron tenant networks that are assigned Global Unicast Address (GUA) prefixes and addresses do not require NAT on the external gateway port for the neutron router to access the outside world. |
| Provider Networks | Yes | Yes | Yes | IPv6 support is dependent on the tenant operating system. |
| Provisioning (PXE/DHCP) | Yes | Interfaces on this network are IPv4 only. | ||
| IPMI or other BMC | Yes | RHOSP communicates with baseboard management controller (BMC) interfaces over the Provisioning network, which is IPv4. 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 ironic in the overcloud. | |||
| Overcloud Cleaning network | The isolated network used to clean a machine before it is ready for reuse. |
1.3. Setting Requirements
This guide acts as supplementary information for the Director Installation and Usage guide. This means the same requirements specified in Director Installation and Usage also apply to this guide. Implement these requirements as necessary.
This guide also requires the following:
- An Undercloud host with the Red Hat OpenStack Platform director installed. See the Director Installation and Usage guide.
- Your network supports IPv6-native VLANs as well as IPv4-native VLANs. Both will be used in the deployment.
1.4. Defining the Scenario
The scenario for this guide is to create an Overcloud with an isolated network that uses IPv6. The guide aims to achieve this objective through network isolation configured using Heat templates and environment files. 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 in the Director Installation and Usage guide. 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. Make sure to substitute these example addresses for IPv6 addresses from your own network.
