Google Cloud Storage has been dual-stack since my company started using it, which was 2015 or so. And unlike S3 it's just the default, you don't need to use a special hostname. Same is true of all other Google Cloud APIs, AFAIK.
I always found it strange that Google Cloud was lagging behind the other providers so badly in terms of providing IPv6 to instances, when Google has fully embraced v6 on all of their public APIs and web sites.
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 )
> Can you really talk to their stuff on ipv6 from GCP?
Nope. Until now it was impossible because you couldn't get v6 on GCP, so it was only useful for communicating with GCP APIs externally. Strangely, even now you can't talk to their stuff over IPv6 from GCE, because of this: "Connecting to Google APIs and services using external IPv6 addresses is currently not supported and will result in a destination unreachable ICMP response."
IIRC, S3 also got v6 support some time before EC2 instances could get v6 addresses, but I don't recall this kind of weird internally connectivity breakage on AWS when EC2 rolled out v6. Google must be doing something weird with their internal routing.
I think you are right - weird or so cool it doesn't play well with ipv6?
Yeah, AWS ALSO had the issue of ipv6 on various services long before EC2 which was frustrating (I think you could terminate IPv6 at load balancer before they had IPv6 on instances?).
They tend to support services much longer so I think did the dual stack endpoints as separate endpoints in case someone had built something where if an intermediate or base DNS got updated and started providing IPv6 customer apps wouldn't break.
Google used to be much more get out of our way in terms of closing down / depreciation systems - so your stuff was always breaking - but on the upside they could do cleaner approaches (one set of endpoints etc). I've heard they've gotten some feedback that doesn't work so well on enterprise side so are dialing it back.
Google Cloud Storage has been dual-stack since my company started using it, which was 2015 or so. And unlike S3 it's just the default, you don't need to use a special hostname. Same is true of all other Google Cloud APIs, AFAIK.
I always found it strange that Google Cloud was lagging behind the other providers so badly in terms of providing IPv6 to instances, when Google has fully embraced v6 on all of their public APIs and web sites.