> …a bunch of lazy network admins in NA and the EU that don't want to learn the new tech…
That’s a cheap shot, and it’s not called for.
Network admins are paid to make the networks run. Anything else is less important. If your IPv6 network experiences some small problems, well, you’re going to hold on to IPv4 because small network problems can mean big inefficiencies or lost sales.
Just a few weeks ago I was on the phone with my WiFi router’s vendor for a couple hours or more because IPv6 traffic wasn’t working through it. I had narrowed the problem down to the router itself. It’s not necessarily that IPv6 is poorly tested or has technical problems, it’s that there’s a long tail of devices/configurations/software out there which screw it up, and it’s often cheaper to just use IPv4 rather than suffer even the minor inconveniences and troubleshooting sessions necessary to run IPv6.
It’s moving forward but it’s slow progress, and it’s not because network admins are lazy or stupid. It’s because there’s a lot of work to be done and not everyone has much of an incentive to do it at all.
We had to return stacks of Cisco equipment, because despite being brand new it had no IPv6 support. We should have checked of cause, but we just didn't imagine that you could buy IPv4 only equipment in 2020.
Software is even worse, we have had software that advertised IPv6 support, so we build an IPv6 only solution, only to find out that the manufacturer has NEVER had a customer using their software on IPv6. They tested it six years ago and never followed up, meaning that IPv6 does actually work in the latest versions.
Docker is another example, who in their right mind designed Docker to be a IPv4 only solution and then attempts to bolt on IPv6 later. It should have been IPv6 and then if you really needed it you could add an IPv4 ingress. Most of the issues we have experience using Docker could have been avoided by using IPv6 and dropping IPv4 all together.
Indeed. Even stuff like pfSense has only rudimentary IPv6 support.
And I guess software support is poor because they're still figuring out how to actually deploy IPv6, churning out new RFC's[1].
[1]: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing... (random example)
We discovered this due to operating an IPv6-only network and having to deploy NAT64/DNS64* on the edge specifically for reaching hub.docker.com
* NAT64/DNS64 was trivial to set up (Tayga + bind9) - took 2 hours for a networking apprentice
Google is seeing 43% IPv6 traffic in the US, 50% in Germany, 35% in Japan, and 17% in Gabon (the most of any African country).
The data seems to support the exact opposite of your assessment.
Not one of our enterprise customers has IPv6 enabled.
Not one of the public clouds we manage have IPv6 addresses on their virtual networks.
Meanwhile, putting a CDN in front of an otherwise 100% IPv4 web server will add an IPv6 address whether you like it or not, and that traffic will contribute to those stats you mentioned.
This article is about public cloud providers hoarding IPv4, which applies to things like the PaaS and SaaS services, internal APIs, etc... which are nearly 100% IPv4 in all three of the big public cloud providers.
[1] https://www.datacenterknowledge.com/sites/datacenterknowledg...
It hasn’t even been that long that Amazon EC2 has had v6 support, which is where a huge chunk of the Internet is hosted.
The network admins at ISPs are just providing connectivity the customers demand. It’s hosting providers and sys admins that don’t bother setting up anything interesting on v6 in the first place.
Second: Ever since IPv6 has been a thing, I've offered to customers the option to turn it on for free. No added charge. We'll just flip the switches and it's there. Not one customer, ever, has said "yes". They've all actively refused to turn it on, for any purpose.
Third: The few times IPv6 has been forced upon our customers, mostly due to Microsoft Windows DirectAccess, it was the network administrators frothing at the mouth, ranting and raving about how they don't want to do it, that DirectAccess should use IPv4 (I'll call Redmond and I'm sure they'll get right on it!), etc...
Fourth: As you've mentioned, AWS, Azure, and GCP had practically zero IPv6 support until very recently. Now, they have broken IPv6 support which is worse than useless, because it gives the impression that the problem is with IPv6, not with the people holding on to an appreciating asset of IPv4 addresses that they intend to use to lock out the competition.
TL;DR: IPv6 is held back by a combination of bad ISPs, lazy network admins, and monopoly seeking public cloud providers.
As such a customer, I’m worried that my ISP would eventually bait-and-switch me from routable IPv4 + optional IPv6 to CGNAT IPv4 + IPv6 when convenient to them. Sorry, but I’m not risking going behind a 1:n NAT layer that I don’t manage.
Does this strategy work? Maybe, when I upgraded my plan they wanted to switch modems, the new one didn’t have working bridge support, and I said to them it was a requirement for me. No bridging, revert everything. The field tech escalated to engineering and they approved a business-class modem. I expect the same with IPv4, even if I have to pay extra.
For example Aussie Broadband had a nice writup of their CGNAT setup: https://www.aussiebroadband.com.au/wp-content/uploads/2019/0...