[HN Gopher] External IPv6 addresses for VM instances is now in G...
___________________________________________________________________
External IPv6 addresses for VM instances is now in General
Availability
Author : fulafel
Score : 181 points
Date : 2021-07-28 11:04 UTC (7 hours ago)
(HTM) web link (cloud.google.com)
(TXT) w3m dump (cloud.google.com)
| profmonocle wrote:
| > 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 wrote:
| 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.)
| profmonocle wrote:
| 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?
| parhamn wrote:
| > 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 wrote:
| Billing is the lesser reason. It's the networking that's
| the tricky bit.
| fdr wrote:
| 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.
| whoknowswhat11 wrote:
| 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
| profmonocle wrote:
| > 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.
| whoknowswhat11 wrote:
| 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 )
| profmonocle wrote:
| > 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.
| whoknowswhat11 wrote:
| 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.
| tptacek wrote:
| There are v6 limitations at AWS though too, right? Can you use
| a v6 address to reach an RDS instance?
| jiggawatts wrote:
| > 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.
| deathanatos wrote:
| Recently1 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.
|
| 1okay, apparently April, and even just the request to get the
| limitation added to their documentation of the limitations of
| IPv6 is still pending...
| EE84M3i wrote:
| >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.
| jeffbee wrote:
| 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.
| corty wrote:
| 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.
| derefr wrote:
| 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.
| ehsankia wrote:
| Maybe a rollout thing, to make sure it's working well and avoid
| taking down all regions at once?
| [deleted]
| jl6 wrote:
| Are they charging for use of external IPv6 addresses? I couldn't
| see any differentiation between IP versions on the pricing page.
| ericyan wrote:
| I think Google actually should gives customers a discount if
| they go IPv6-only.
| profmonocle wrote:
| 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.
| Clewza313 wrote:
| Private addresses are free, so there's no cost to keeping
| them.
| knorker wrote:
| 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".
| lima wrote:
| Neat - real external IPs, no NAT.
| DanAtC wrote:
| Reminder that news.ycombinator.com still doesn't have an IPv6
| address.
| scrollaway wrote:
| Would you notice if it did?
| p1mrx wrote:
| Yes, the IPvFoo icon would change from 4 (red) to 6 (green).
| scrollaway wrote:
| 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?
| p1mrx wrote:
| 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.
| ithkuil wrote:
| 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
| dheera wrote:
| 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.
| aofeisheng wrote:
| 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.
___________________________________________________________________
(page generated 2021-07-28 19:01 UTC)