External IPv6 addresses for VM instances is now in General Availability

Actually, I just thought of something I noticed when Google Cloud Run launched. When I accessed a Google Cloud Run URL from a VM with no public IP (using their private Google access function), the X-Forwarded-For header sent to the container was a private IPv6 address that included the instance's private IPv4 address embedded in it.

So I wonder if the Private Google Access mechanism uses some sort of IPv4 to IPv6 translation in their internal network in order to route the request, and maybe some detail of that implementation makes it difficult to route request from public v6 addresses to Google v6 addresses on GCE.

I just tried this again, and it looks like the X-Forwarded-For header now returns 0.0.0.0 when accessed from a VM without a public IP. Could be a sign that a fix is in the works?

> Why would services hosted by Google be different than other IPs? Sure those ranges are billed differently, but they must already handle billing differentiation for different v6 ranges in order to support different intra-zone/inter-zone/inter-region/internet bandwidth pricing.

They mention your reason.

Rented or not doesn't matter. If you rent a rack or more in colo, you get your uplink fibres and starting there can use your own network equipment. And for big enough customers, the uplink fibres aren't necessarily ethernet but optionally MPLS, some patched dark fibre somewhere or whatever you like and want to pay for. So I don't see how not owning the building would make any difference.

Yes, the IPvFoo icon would change from 4 (red) to 6 (green).

For the "News" portion no, for the "Hacker" portion absolutely.

Recently¹ tried to bring up a "Flexible" Postgres server (Azure's managed PG offering) on an IPv4 (four) only subnet. The request hung, for two hours, before finally failing with a generic "internal error". Retried, same result. Contact support. Flexible PG doesn't support being brought up on a vnet with IPv6, even if it is on an IPv4-only subnet, even if you have no intention of connecting to it over v6. Want that service? No IPv6 for you, I guess.

¹okay, apparently April, and even just the request to get the limitation added to their documentation of the limitations of IPv6 is still pending…

There are two reasons you could give for this that I'm aware of:

1. Most Google services are behind a single frontend, and supporting IPv6 is easy because that frontend already supports v6 and you have to do specifically stupid things in order to not get support (backends hardly care what kind of address the request originally came in over). Cluster networking is not like that; the network is the product, not just the delivery mechanism you happen to run HTTP over, and you have to do real extra work to support both. 2. Google's IPv6 SWE team was largely wound down (most of the interesting things were “done”) a bit before GCE became a thing; at that point, IPv6 was generally expected to be done by each team and not a merry band of renegades, and GCE had more than enough other things to worry about.

(I worked in the IPv6 deployment team at the time, part of it in 20% time.)

Can you really talk to their stuff on ipv6 from GCP?

The dual stack names for AWS I like because your old stuff keeps working. Networks can do weird things if not expecting dual stack and not everyone is smart enough to predict it (at least not me).

I have native IPv6 at home and not great experience with gcp on it (Google.com is great though oddly )

Assuming they aren't charging for external IPv6 (I imagine they aren't), then there effectively is a discount for going v6-only - you just need to choose to disable external v4, and not enable v4 NAT. That'll save you a few $ per month per VM. (Public IPv4s are $0.004 per hour.)

It looks like there's currently no way to go literally v6-only, i.e. not even having a private v4 address on the VM. The instance metadata server as well as the default DNS and NTP servers are still v4-only.