4 ms·

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

> 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.

Clewza313 5y ago
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 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.)
- parhamn 5y ago
  > 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.
  - Clewza313 5y ago
    Billing is the lesser reason. It's the networking that's the tricky bit.
- profmonocle 5y ago
  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?

Clewza313 5y ago

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 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.)

parhamn 5y ago
> 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.
- Clewza313 5y ago
  Billing is the lesser reason. It's the networking that's the tricky bit.
profmonocle 5y ago
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?