When people talk about the IPv4 Address exhaustion problem, it’s usually in the context of the public IPv4 space. When IPv6 was introduced, the primary goal was to fix the address exhaustion problem by allocating internet-accessible addresses to every device. However, IP exhaustion issues in large enterprises are often related to the private RFC1918 address space. Large enterprises use the RFC1918 address space for their internal networks. And lately, technological advancements such as 5G, internet of things, mobile applications, connected devices, serverless and container-based services have expedited the exhaustion of the IPv4 private address space.
One particularly interesting IPv6 capability you’ll find in Google Cloud is support for ULA (Unique Local Addresses), an IPv6 address space defined in RFC4193 that is analogous to the private IP space used in IPv4 defined in RFC 1918.
Even though the IPv6 address space is gigantic compared to the IPv4 address space, enterprises require a private network that is not exposed to threats that you might find on the public internet. Like IPv4, IPv6 retains the notion of private addressing as a separate private address space that will not conflict with the public address space. IPv6 ULA addresses are routable within the scope of private networks, but not publicly routable on the global IPv6 internet, thus providing isolation for private workloads from the internet and other cloud customers. Further, you can allocate and use these addresses without arbitration by a central registration authority.
Google Cloud allows you to create internal IPv6 ULA subnets for private communication within a VPC. Any workloads with IPv6 ULA addresses allocated from these subnets are meant to be used for private communication within your network. Any workload that is meant to be publicly available can leverage external IPv6 with GUA (Globally Unique Addresses). Additionally, multi-nic VM instances may be dual-homed with both ULA (internal) and GUA (external) addresses.
Using ULA addressing for private communication in Google Cloud provides the following advantages over the traditional IPv4 RFC 1918 address space.
1. VPCs with billions and billions of IPv6 addresses
A /48 ULA range is allocated to each VPC and each subnet in the VPC will be allocated a /64 IPv6 address range from this /48 ULA range. Each VPC with a /48 ULA range can accommodate 65,536 /64 subnets. A dual-stack subnet is assigned both IPv4 and IPv6 address ranges. Each /64 subnet can accommodate 4 billion unique VM interfaces. Each IPv6-enabled VM will be assigned a /96 address range from the subnet, which provides you with 4 billion unique IPv6 addresses for each VM interface.
2. Non-overlapping private IPv6 address space
When you create a ULA-enabled VPC, you are assigned a /48 range for your VPC, which can be used across all Google Cloud regions. You can use this aggregate range to simplify specification of ACLs, firewalls, and access controls in your on-prem or cross-cloud deployments.
Unlike RFC1918 addresses, which are meant to be reused across multiple networks, ULA addresses are meant to be unique. RFC4193 includes a description for a pseudo-random IP generator to help avoid overlaps. Google Cloud assigns all ULA addresses from the fd20::/20 range and ensures that each VPC network is assigned a unique /48 ULA prefix to avoid overlaps with other VPCs. This is beneficial when using VPC peering, which requires non-overlapping IPv6 address ranges for subnets in the peering VPCs. Ensuring uniqueness also eliminates the need for NAT to communicate between private networks. Google Cloud provides you the flexibility to choose a ULA range for your VPC that does not overlap with your on-prem/cross-cloud ULA ranges.
Support for IPv6 ULA addressing opens up a world of possibilities for enterprises with large, complex systems, like those based on containers and microservices. To learn more about how to get started with IPv6 in Google Cloud, check out the documentation. We can’t wait for all the interesting things you will build using IPv6 ULA address space.
By: Ujjwal Jain (Software Engineer) and Rohit Dalal (Product Manager)
Source: Google Cloud Blog
Our humans need coffee too! Your support is highly appreciated, thank you!
