Happy 10-year 10-year World IPv6 Launch Anniversary! I am incredibly pleased to be able to write about Google Cloud Platform’s new IPv6 support inside its Virtual Private Cloud (VPC) offerings. There are a bunch of caveats, but bottom-line this is a huge first step and great progress moving the ball forward where only a small capability existed previously. While I will point out a few of the lingering issues below which prevent full IPv6 parity, this is still a remarkable achievement and Google should be proud of this work!
Previous IPv6 Support
Previously, Google Cloud’s (like Amazon Web Services) first step in their IPv6 journey was to provide IPv6 on its external load balancers. These were similar to AWS’s Elastic Load Balancers. They are the external IP address used for load balancing and Web Application Firewall (WAF) protection. This was a great first step as it provided cloud instances with external, inbound IPv6 reachability – which was not possible in GCP until then. There are obvious downsides to this as it is nothing more than a IPv6 to IPv4 NAT to the IPv4 only server. So, the compute instance could not: route to other IPv6 nodes inside its VPC, route via IPv6 to other peered VPCs, route to other IPv6 nodes in a VPN, etc. It effectively just terminated IPv6 on an application front end.
New VPC IPv6 Support
Now in 2022 – GCP has added some remarkably interesting capabilities that I will outline below. The capabilities are split into (2) types of support: internal and external IPv6. I have some issues with both however, they are still great first steps in enabling the capability.
External IPv6
As the name states, this enables full IPv6 reachability externally from end to end over IPv6. When you enable a subnet for IPv6 external you need to remember it must be set as dual-stack (IPv6-only not supported yet). When you set the VPC as external IPv6 here are several options:
The notation when you first configure the dual-stack subnet in GCP cannot be changed after it is initially configured. Then you must select whether the IPv6 access type is external or internal. Once external is selected Google will allocate a /64 prefix after creating the subnet. Here is an example of the subnet after creation:
Now here are the caveats. Yes, it is a fully reachable IPv6 subnet. Meaning internet-to-instance over IPv6 is reachable. The subnet even has IPv6 firewall rules/access-lists that can be managed. However, it is an externally facing address. So, if you wanted to use GCP services like Cloud WAF or Load Balancing it is practically impossible as the address is routed outside the VPC. If using WAF or external load balancing does not affect your use case, then this provides exactly what you need to have a fully IPv6-enabled cloud network. You have:
- end-to-end IPv6 reachability
- DNS PTR records for IPv4 and IPv6
- inter-VPC routing but not configured through VPC peering. The routing for external IPv6 is outside the VPC. There is no capability to add IPv6 subnets in exported or imported route configuration
- Full IPv6 firewalling support
- NO SUPPORT: WAF/external Load Balancing
- NO SUPPORT: inter-VPC IPv6 routing
- UNKNOW SUPPORT: VPN routing with IPv6 subnets
It will look something like this after it is enabled – as it is using DHPCv6 to gain its IPv6 address:
ens4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
inet 172.30.5.2 netmask 255.255.255.255 broadcast 172.30.5.2
inet6 fe80::4001:acff:fe1e:502 prefixlen 64 scopeid 0x20<link>
inet6 2600:1900:4090:ab00:: prefixlen 128 scopeid 0x0<global>
ether 42:01:ac:1e:05:02 txqueuelen 1000 (Ethernet)
RX packets 6736 bytes 22297385 (21.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5571 bytes 814605 (795.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
The route table looks like this, but I will explain the interesting use of a /65 prefix later in the blog:
root@v6-test-e:~# route -n6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::1/128 :: U 256 2 0 lo
2600:1900:4090:ab00::/128 :: U 256 1 0 ens4
2600:1900:4090:ab00::/65 fe80::4001:acff:fe1e:501 UGAe 1024 3 0 ens4
fe80::/64 :: U 256 3 0 ens4
::/0 fe80::4001:acff:fe1e:501 UGDAe 1024 3 0 ens4
::1/128 :: Un 0 5 0 lo
2600:1900:4090:ab00::/128 :: Un 0 4 0 ens4
fe80::4001:acff:fe1e:502/128 :: Un 0 4 0 ens4
ff00::/8 :: U 256 4 0 ens4
::/0 :: !n -1 1 0 lo
Internal IPv6
As the name says, this is internal IPv6, in the most internal sense it uses the Unique Local Unicast (ULA) addressing scope. Other than giving IPv6 address to subnets inside a VPC, you really get no other functionality apart from external IPv6 load balancing/WAF. It is an IPv6 address but there is not much in additional capabilities.
- Full IPv6 firewalling support
- IPv6 to IPv4 external load balancing
- NO SUPPORT: end-to-end IPv6 reachability
- NO SUPPORT: DNS PTR records for and IPv6
- NO SUPPORT: inter-VPC IPv6 routing
- UNKNOW SUPPORT: VPN routing with IPv6 subnets
This walkthrough of VPC configuration can be followed to get started with IPv6 enabled VPC in GCP. You must first enable the VPC to have IPv6 ULA subnets and it cannot be removed once enabled:
It will look something like this after it is enabled – which it seemly follows the RFC 4193 procedures for ULA assignments:
Configure the subnet as a dual stack:
Which will then look something like this:
On a compute instance the instance looks like this when getting it is address from DHCPv6:
ens4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460
inet 172.30.4.2 netmask 255.255.255.255 broadcast 172.30.4.2
inet6 fd20:514:8b1f:1800:: prefixlen 128 scopeid 0x0<global>
inet6 fe80::4001:acff:fe1e:402 prefixlen 64 scopeid 0x20<link>
ether 42:01:ac:1e:04:02 txqueuelen 1000 (Ethernet)
RX packets 9532 bytes 22685035 (21.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7544 bytes 832777 (813.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
The route table looks like this – as you see there is a difference in the IPv6 route-option give the host on an internal IPv6 VPC network. For the internal ULA subnet, it is given the /64 and not /65 prefix route:
root@v6-test-ula:~# route -n6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::1/128 :: U 256 1 0 lo
fd20:514:8b1f:1800::/128 :: U 256 1 0 ens4
fd20:514:8b1f:1800::/64 fe80::4001:acff:fe1e:401 UGAe 1024 1 0 ens4
fe80::/64 :: U 256 4 0 ens4
::/0 fe80::4001:acff:fe1e:401 UGDAe 1024 3 0 ens4
::1/128 :: Un 0 4 0 lo
fd20:514:8b1f:1800::/128 :: Un 0 2 0 ens4
fe80::4001:acff:fe1e:402/128 :: Un 0 4 0 ens4
ff00::/8 :: U 256 5 0 ens4
::/0 :: !n -1 1 0 lo
Odd IPv6 Route Prefix Options for External IPv6
As you may have noticed the external IPv6 host receives a /65 route. That seems like it is messing with the broadly implemented /64 subnet prefix that is needed for local Neighbor Discovery Protocol (NDP). Which may or may not cause some interoperability or functionality issues. Since DHCPv6 is being used and not IPv6 Stateless Address Autoconfiguration (SLAAC) that uses On-Link flags, there may not be any lingering technical issues. In other words, it may seem off, it will function so long as SLAAC is not also deployed in GCP.
The router advertisement gives the end host a /65 in its RA packet as shown here:
After a few discussions with folks like Scott Hogg and Ed Horley they theorized this could be a way that GCP uses “spilt scopes” or “Split prefix ranges,” with DHCPv6. In other words, using a High Available (HA) DHCPv6 solution, the subnet RAs are advertised as /65s depending upon zone. Infoblox had a good write up on this type of capability for DHCPv6. However, this is a just us giving Google the benefit of the doubt that the /65 route information option was configured correctly because this was not done with the internal/ULA IPv6 subnet.
In Summary
This is a great first step, Google has risen to the challenge in providing some better IPv6 capability to its GCP customers. It is not complete given the caveats explained above, but you can be assured there is more capability that previously supported. If you have any questions about how Tachyon Dynamics can help you implement IPv6 in your cloud services, please reach out and let us know!