Earlier quoted context omitted.
GCP will support IPv6 in 2021.
Imagine someone saying, in 2001 that they're adding IPv4 support. Laughable, right? IPv6 was available in Windows 2000. Just saying.
More than 1/3 of all access to Google is now over IPv6
101–110 of 237 posts
Re: More than 1/3 of all access to Google is now over IPv6
#102Earlier quoted context omitted.
Google definitely uses IPv6 internally (ie office WiFi is now using IPv6 only (with the router doing translations to IPv4 if the site doesn’t support IPv6) and afaik most of the servers in the datacenter/clusters are IPv6 only now as they ran out of IPv4 LAN IPs for their clusters. I just think that there’s little demand on cloud (and tons of other high prior work)
There's little demand for half-baked support. There would be a lot of demand if IPv6 wasn't an "also ran", a "tack on", some checkbox to tick. Think about how much network complexity would simply vanish if everything used only public routable IPv6 ranges. No more split DNS. No more NAT gateways. No need for a separate "public IP" and "private IP". No need to carefully "carve up" the 10.x.x.x range to carefully avoid…
(They still could do IPv6 proper - no argument there)
Re: More than 1/3 of all access to Google is now over IPv6
#103Earlier quoted context omitted.
That's scaremongering and simply false. Cgnat servers are not necessarily congested. I've been to several isps with cgnat and none of them suffered from congestion. On a more personal note, if ipv6 were so great, their fans wouldn't have to make up things to badmouth ipv4.
> I've been to several isps with cgnat and none of them suffered from congestion. And I've been on several residential ISPs where IPv4 was unusable during peak netflix hours, likely because people were blindly disabling IPv6 on their devices.
Re: More than 1/3 of all access to Google is now over IPv6
#104Earlier quoted context omitted.
My ISP in the Netherlands (Ziggo) provides me with native IPv6 if I use their supplied router, but forces me onto IPv4 when I use theirs in bridge mode in conjunction with my own router. Still not sure why they do that.
These ISPs are using DS-Lite, Dual-Stack Lite. https://www.juniper.net/documentation/en_US/junos/topics/top... (this isn't a purely Juniper thing, but they have nice diagrams on their documentation) It's a kind of carrier grade NAT with 4over6 baked in. Depending on the version of this they are relying on your modem to perform encap/decap of 4to6, hence when you switch to modem mode or your own router you fall back t…
Hyperoptic will give you a globally unique IPv4 address for an extra £5/month, and otherwise will stick you behind their CGN.
Re: More than 1/3 of all access to Google is now over IPv6
#105Earlier quoted context omitted.
GCP will support IPv6 in 2021.
Imagine someone saying, in 2001 that they're adding IPv4 support. Laughable, right? IPv6 was available in Windows 2000. Just saying.
Re: More than 1/3 of all access to Google is now over IPv6
#106Earlier quoted context omitted.
You've had a few replies so I guess mine will be lost to the aether. NAT vs Direct addressing is an interesting topic, because we've gotten so used to working around the issues inherent in NAT that we take them as a sort of given. I'll lay them out here: 1) The actual NAT state table in your router is much slower than a simple bit-map firewall lookup. This will show up as a bit of latency on every new connection. 2)…
> The state table can get full. When that happens some connection needs to be evicted. This would be so much more convincing with some numbers to show it actually does happen in reality, especially at a rate that's comparable to other random connection drop-outs.
This is hard for individuals to see, but put a fair bit of load on a home consumer 'router' and, presuming you can get enough access to it to watch resources, you'll see it run out.
This is one of the things that better home network devices do: have sufficient RAM to handle a big state table, and manage it well.
IPv6 completely sidesteps this by not even needing a state table because no NAT.
Re: More than 1/3 of all access to Google is now over IPv6
#107Earlier quoted context omitted.
> The state table can get full. When that happens some connection needs to be evicted. This would be so much more convincing with some numbers to show it actually does happen in reality, especially at a rate that's comparable to other random connection drop-outs.
The most common symptom of this is someone mentioning that their home 'router' regularly needs reboots to keep working well. Excluding memory leaks, it's frequently the state table running out of space and connections going sideways as a result. This is hard for individuals to see, but put a fair bit of load on a home consumer 'router' and, presuming you can get enough access to it to watch resources, you'll see it r…
You may have forgotten that a stateful firewall that tracks inbound and outbound connections still needs memory to store a state table still applies in IPv6.
Now it also needs 8x more memory per entry, as the addresses have gone from 2x 32bit to 2x 128bit.
Re: More than 1/3 of all access to Google is now over IPv6
#108Earlier quoted context omitted.
That's scaremongering and simply false. Cgnat servers are not necessarily congested. I've been to several isps with cgnat and none of them suffered from congestion. On a more personal note, if ipv6 were so great, their fans wouldn't have to make up things to badmouth ipv4.
NAT is fundamentally a limited technology that has massive scaling problems that simply do not exist in non-nat networking situations. The larger the network behind the NAT, the more problems you get. This is also before considerations like the fact NAT breaks 2 way connectivity that is the cornerstone of the design of the internet. >if ipv6 were so great, their fans wouldn't have to make up things to badmouth ipv4.…
Re: More than 1/3 of all access to Google is now over IPv6
#109And yet, when I beg my google cloud rep for IPv6 addresses on instances (or on anything that isn’t the load balancer) I get told that it is not on the immediate roadmap. The cloud providers have pushed back ipv6 adoption so hard imo. At least native ipv6 access. I know they’ve thrown in some token support and you /can/ make something work; but compared to VPS providers which consistently deliver machines with IPv6 ad…
Azure's IPv6 "support" saddens me. It's just painful how minimal their support is. For one, they NAT all IPv6 traffic. Let that sink in. Let it percolate. Mull over the fact that the entire purpose of IPv6 is to eliminate NAT, and that it's practically impossible to get an IPv6 NAT-ing network device. Microsoft must have had to write their own, custom network load balancers to NAT IPv6. It's madness . Oh, if that's n…
That’s why adoption is slow.
NAT isn’t such a huge problem that the industry thinks it’s urgent enough to push hard to solve.
Re: More than 1/3 of all access to Google is now over IPv6
#110Earlier quoted context omitted.
There's little demand for half-baked support. There would be a lot of demand if IPv6 wasn't an "also ran", a "tack on", some checkbox to tick. Think about how much network complexity would simply vanish if everything used only public routable IPv6 ranges. No more split DNS. No more NAT gateways. No need for a separate "public IP" and "private IP". No need to carefully "carve up" the 10.x.x.x range to carefully avoid…
Looking at the number of unprotected databases (see i.e. https://news.ycombinator.com/item?id=23957510 ) I think it's good that cloud providers push for gateways etc. in order to restrict access on network level. (They still could do IPv6 proper - no argument there)
If the default security group for IPv6 only allows SSH and ICMPv6 to an instance/host, what difference does it make?
* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-secu...
It's not the NATing that gives (internal) networks security, it's the stateful packet inspection at the gateway and--more and more--at the host level.