[RijilV]

It's been a quarter of a century since IPv6 launch.

There's some really good lessons learned here. IPv6 requires everyone, everywhere, needs to change their configuration to add IPv6 addresses and network connectivity to every node/endpoint. The madness of course is that all the underlying infrastructure software (routers, OS, standard libraries) all support IPv6. It would seem, at a large enough scale, that software is the easy part, configuration is the hard part.

DJB wrote this up two decades ago[0] and it remains relevant. In particular the comparison between IPv6 and MX records. It took me a little while to wrap my brain around just extending existing software to support sometimes 32bit and sometimes 128. Ultimately it wasn't hard to dream up a few solutions for how that would work.

The other thing, FWIW, which has been slowing IPv6 adoption is business owners not asking for it as a high priority item from their providers. I've seen this happen way more often that I would like where provider asks a customer what they want and the customer never mentions IPv6, and when prompted shrugs it off because they don't see it as a business critical (and in fairness, it hasn't been). Yes provider isn't asking the 'nerds' at their customer's businesses, but those folks also aren't the ones paying the bills so...

0: https://cr.yp.to/djbdns/ipv6mess.html

[connicpu]

I got a brand new router recently, IPv6 was still disabled by default! I honestly can't understand the reasoning, I don't even buy the internet visibility argument because the default incoming connection rules for IPv6 after I enabled it were deny-all. We really have a long way to go still in getting equipment everywhere enabled on it.

[Gigachad]

Some ISPs have v6 enabled but it's just broken or sub optimal. I imagine the logic is that v4 always works and the user could only see a benefit from having v6 off by default.

[otabdeveloper4]

IPv6 is a security liability and provides no benefit to the user.

[xattt]

If we take a chapter on fixing broken implementations from the USB Forum, the clear solution is to come up with an IPv6 Rev. e^76.

[solarkraft]

If it was easy to set up, the providers would just include it (or the price would be low enough to shrug it on).

But it's not really trivial and IPv4 works well enough for most people to bother. Remember the typical workaround for network issues being disabling IPv6?

[noipv6]

anyone who thinks "ipv6mess" is still relevant in 2022, doesn't understand the problem space it describes.

part 1, interoperability failure/incompatibility: nat64+dns64 has been viable since 2008

part 2, incoherence: dual-stack was the transition plan, & was clearly communicated from the start (to anyone who listened). that turned out to not be so effective since so many ppl ignored the realities of legacy ip depletion. at this juncture ipv6-only (w/ nat64) is becoming a more preferable approach, since you only need to maintain a single protocol in the majority of your environment (as evidenced by org's like tmobile us, facebook, etc).

part 3, distractions: one could argue that rants like "ipv6mess" are the biggest distractions to ipv6 deployment.

"no one is asking for ipv6" is a lie writ large in the provider space; i've seen plenty of examples where a provider has told multiple customers "you're the first person to ask for ipv6 support!" - the problem being is that most org's don't actually keep track of such requests in a unified place, & so every customer is pushing for it alone, so far as the provider is concerned.

[cryptonector]

> anyone who thinks "ipv6mess" is still relevant in 2022, doesn't understand the problem space it describes.

It was relevant then -and it is relevant now- because there are good lessons in how to migrate from thing A to thing B, even if some of the then-missing necessary bits are in place now.

Still, it's almost certainly the case that DJB's rant had no real effect, and that the necessary steps were bound to be taken as the cost of sticking with IPv4 rose. Also, a significant period of time was always going to be necessary for software and tooling to catch up -- perhaps there wasn't much to be done about improving the transition 20 years ago. Yet DJB's rant isn't wrong or devoid of value -- it's mostly right and entertaining (still!), even if there just wasn't enough IETF and dev oomph to do better at the time.

[MisterTea]

> part 1, interoperability failure/incompatibility: nat64+dns64 has been viable since 2008

Why are we stuck with nat in 2022 again? Why did we not map the 32 bits of ipv4 to ipv6?

> part 2, incoherence: dual-stack was the transition plan, & was clearly communicated from the start (to anyone who listened).

Perhaps they didn't listen because dual stack means investing in building another incompatible internet on ipv6 in parallel with the ALREADY WORKING ipv4 internet. Reminds me of a great quote: "the most dangerous enemy of a better solution is an existing codebase that is just good enough." - Eric S Raymond

> part 3, distractions: one could argue that rants like "ipv6mess" are the biggest distractions to ipv6 deployment.

Because it is a mess. Stop denying that. If ipv6 was designed to be easily deployed via backwards compatibility then we would be using ipv6 already.