> Connecting to Google APIs and services using external IPv6 addresses is currently not supported and will result in a destination unreachable ICMP response. Most applications will fallback to IPv4 transparently.

This seems...strange to me. 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.

What makes me wary is that Node.js does not fall back to IPv4 on any of its socket APIs. Currently it also defaults to IPv4 over IPv6 on DNS lookups, but that's apparently being fixed in the next release, so this will make it fairly painful to use any Node.js code that depends on Google APIs on a v6-enabled instance. (I tested this, and this also affects Cloud Run and App Engine-hosted apps.) Makes me wish they would just configure GCE's DNS servers to not return AAAA records for any affected v6 addresses.

This, plus the very limited number of initially supported regions, makes me curious what's going on behind the scenes. It feels kind of unready. I wonder if some large customer demanded this (government?) and this MVP satisfies their requirements.

There is special handling in place for Google APIs/services so they can accessed from private networks, billed differently from external traffic, etc:

https://cloud.google.com/vpc/docs/private-access-options

The "currently" implies that IPv6 support is coming. (Although I don't actually know if or where it's on the roadmap.)

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.

Billing is the lesser reason. It's the networking that's the tricky bit.

Currently their instance-level external IPv6 support does not have any advantages over IPv4. For example, their CDN Interconnect discount does not apply to IPv6 (see https://cloud.google.com/network-connectivity/docs/cdn-inter...).

And it's not clear whether they will charge for external IPv6 addresses.

But in any case, I'm still very happy to see that they finally took this step.

>IPv6 support for subnets and VM instances is available in the following regions:

asia-east1 asia-south1 europe-west2 us-west2

I thought GCP makes a bigger deal about having parity between regions than the other clouds (pushing teams to automate deployment to new regions). TMakes you wonder if other (older) regions are ever going to get IPv6.

Most other GCP products can rely on their SDN to abstract away any differences between colo hardware. But this change is more a vertical through-hole change in the SDN itself — possibly involving, say, third-party network switches and middleboxes in their racks routing encapsulated SDN traffic. If those switches/middleboxes do enough in ASICs, they may have to literally do hardware swaps to execute this rollout.

Maybe a rollout thing, to make sure it's working well and avoid taking down all regions at once?

I wouldn't expect parity between GCP regions, since some of them are in Google data centers and others are in colo facilities. For example, GCP has a region europe-west3 in Frankfurt, but there is not a Google datacenter there. It's rented.

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.

Reminder that news.ycombinator.com still doesn't have an IPv6 address.

Would you notice if it did?

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

And the point of that is...?

Don't get me wrong i see the point of IPv6. What I don't see the point of is vaguely complaining when some random website (that doesn't even sub-host) doesn't support it.

"It'll make my thing green" isn't really a selling point, now, is it?

Well, a more pragmatic reason is that over time, CGNAT will force more users behind shared IPv4 addresses, so websites with IPv6 will be able to do abuse detection more accurately.

Migrating popular traffic from CGNAT to IPv6 can also improve performance for some users, and reduce the long-term costs of CGNAT for ISPs.

Not disagreeing, but I'd like to mention a noticable proportion of IPv6 end users are behind CGNAT too. IPv6 doesn't remove CGNAT for everyone.

I don't understand. There is no CGNAT in IPv6. You can do NPT (network prefix translation) if you really wanted, but why would you let users share the same IPv6 address/prefix as it is too much work (and not needed in any realistic setup).

Faster mobile connections

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

Wow - this has been out on AWS since 2016 maybe? I've used ipv6 on s3 as well sometimes.

Just interesting to see where these providers are on these things

> Just interesting to see where these providers are on these things

Don't look at Azure then, it's not interesting at all. It's just sad.

They NAT IPv6, and hand addresses out in blocks of 16.

No, not /16 address blocks. Sixteen at a time. Six and ten.

I wish I was kidding.

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…

Hey, you just didn't use the correct combination of SKUs and features. That sums up the standard Azure experience.

You can also not use an IPv4 NAT on an IPv6-enabled network.

Or use Virtual WAN with IPv6... at all.

Or...

It's almost like some subcontractor developer was told to tick a checkbox so that they technically speaking provide IPv6. They do. Technically.

> I've used ipv6 on s3 as well sometimes.

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.

There are v6 limitations at AWS though too, right? Can you use a v6 address to reach an RDS instance?

Are they charging for use of external IPv6 addresses? I couldn’t see any differentiation between IP versions on the pricing page.

I think Google actually should gives customers a discount if they go IPv6-only.

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.

Private addresses are free, so there's no cost to keeping them.

Simplicity, for one. One set of routing tables, firewall rules, etc.

And if you don't have any IPv4 then you know that you are not accidentally falling back to IPv4.

For single-VM it doesn't matter, because who would you talk to, but if you have a bigger cloud setup then it would be nice to remove IPv4.

So depends what you mean by "cost".

Neat - real external IPs, no NAT.

Now if only my ISP would support IPv6 properly and hand me a block of static addresses I could use ... until then I guess I'm using IPv4.

Oh I was following https://issuetracker.google.com/issues/35904387?pli=1 for many years and I guess I unsubscribed or something because my last memory was that they were not doing it and now GA!!! yay

Do VPCs or subnets aggregate a larger block that can be used to write a firewall rule? I wouldn't find it quite as useful to have per-VM blocks issued piecemeal. It's not clear from the documentation that I read.

yes. you can use /64 subnets to define your broader level firewall rules.

If only all the ISP in the U.S. had IPv6... We are still really far. Some like RCN don't even have that planned (or they keep that really secret).