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 information is supplementary to 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 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 (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 IPv6 IPv4 Storage 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 IPv6 The Provisioning network used for ironic 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. Note 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. Important 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.

Commands: