Planning an IPv6 network on Google Cloud

Google Cloud supports a wide range of IPv6 capabilities. When using IPv6 addressing, Google Cloud gives you the choice of using Global Unicast Addresses (GUA) for external connectivity or Unique Local Addresses (ULA) for private connectivity. In a previous blog, we discussed when and how to use ULA addressing for private communication in Google Cloud. In this blog, we discuss how to use Google Cloud’s GUA and ULA address space within your VPC network and customize it for your environment in a variety of interesting ways, with 4 billion IPv6 addresses available for each VM instance.

First, some context. Google Cloud reserves the fd20::/20 range for ULA address allocation and 2600:1900::/28 range for GUA address allocation (if you’re new to IPv6, here’s an overview of IPv6 addresses). Each Google Cloud VPC network consists of one or more subnets, which are regional resources that have IP address ranges associated with them. A dual-stack subnet is a resource that has both IPv4 and IPv6 address ranges associated with it. The IPv6 subnet size is /64 (e.g., fd20:a:b:c::/64). Each IPv6-enabled VM will be assigned a /96 address range from the subnet, providing 4 billion unique IPv6 addresses for each VM interface.

Please note that you can only configure a VPC network with dual-stack subnets only if the subnet mode is set to custom; IPv6 addressing is not available if the subnet mode is set to automatic. You can create a custom mode VPC network as follows:

If you choose to use ULA addressing for your VPC network, Google Cloud allows you a choice between:

An automated allocation of a /48 address range for your VPC from the fd20::/20 range

• A /48 address range of your choice from the fd20::/20 range

Each /48 address range is automatically allocated across all GCP regions with portions of the /48 reserved for each region (e.g., /54 for us-central1, /55 for europe-west1, /56 for asia-south1). Subnets with a /64 prefix length are allocated from each of these regional reservations. This lets you create:

up to 256 subnets in a region where a /56 is automatically reserved

up to 512 subnets in a region where a /55 is automatically reserved

and up to 1024 subnets in a region where a /54 is automatically reserved.

The entire /48 is only available for your network, and is guaranteed not to overlap with any other network in GCP.

You can create a subnet with a ULA range associated with it:

You can create a VM with a ULA address for internal connectivity by associating it with a ULA subnet. A /96 is allocated to the VM on creation:

If you choose to use GUA addressing for your subnet, then a /64 is allocated for each subnet you create. GUA subnets are allocated from the 2600:1900::/28 address range:

You can also create a VM with a GUA address for external connectivity by associating it with a GUA subnet. A /96 is allocated to the VM on creation:

By default, Google Cloud uses DHCPv6 to assign the first /128 address to the VM interface and creates Auto-DNS AAAA record for this first /128. However, Google Cloud provides you with the flexibility to use the 4 billion IPv6 addresses allocated to each VM interface by modifying the default configuration. Here are a few interesting things you can do with this capability:

Create containers and embed their unique 32-bit container ids in the VM address range. For example: <VM 96-bit IPv6 range> <32-bit container id>. This allows the receiver of the traffic to recognize the sender by its container id.

If you are building an application on Google Cloud, you can pass some metadata through network layers opaquely. 

For obfuscation purposes, use any random /128 IPv6 address from the /96 address range assigned. 

You can also encode information relevant to your environment such as location ID, using random bits from the last 32 bits.

Finally, use suffix-based programming by using a well-known suffix to identify certain types of workloads.

Example

Here’s an example of assigning unique IPv6 addresses to containers using network namespaces:

Consider a case where you have containers for your dev and prod environments running on a VM. If each environment is assigned an unique ID (lets say, the dev environment has ID=1 and the prod environment has ID=2), then the lower 32 bits of a VM can encode these IDs. You can then enforce ACLs such that the prod database can only accept connections with addresses whose lower 32 bits are ‘2’. This adds another level of security by providing environment isolation at the network layer.

And with that, we hope that you now understand how to utilize the /96 address allocation to each VM in unique ways and customize it for your environment. To learn more about how to get started with IPv6 in Google Cloud, check out the documentation.