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

[Dagger2]

I'm not sure it was ever relevant. All it does is describe the problem, which was already well-known at the time by the people working on v6. It doesn't give a fix for it.

It doesn't give a fix because no fix is possible. Because the problem comes from the design of v4, not from v6.

For some reason djb wasn't able to get his head around that, and people have been pointing to that damn page as if it's some big gotcha ever since. No, it's just the situation we're stuck with, thanks to the people that designed v4.

[mort96]

If it describes problems we're still struggling with, it's still relevant.

[howinteresting]

I mean, v6 is still mostly a failure, so (rightly or not) the situation is going to be blamed on the people that have been pushing v6. That's just the cost of trying to push the entire world towards a new standard.

(I know that v6 has been a success within datacenters and such.)

[ipython]

Actually, aws and the big cloud providers are only now starting to release ipv6 aware services.

If close to half of US traffic to google transits over ipv6 is considered a failure, I would hate to see “success”.

[noipv6]

by what definition would you call ipv6 "mostly a failure"? 30-40% global eyeball network (to the end user) adoption after ~10 years of active deployment, against very vocal opposition seems commendable enough to me.

[commandersaki]

More like 15 years of active deployment, and I'd expect levels at 90%. The world changed after IPv6 with smartphones that are controlled by a select few carriers, so it's easy to deploy IPv6 in which they're in dire need.

But the rest of the networks: enterprises, hosting providers, cloud providers, ISPs really don't give a shit. It's merely a cost centre or a burden.

[cryptonector]

It talks quite a bit about how to tackle migrations. It doesn't specify specific solutions for IPv6, no, but it does talk about what doesn't work and what should be looked into. It's a blog, not an Internet-Draft.

[noipv6]

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

it's irrelevant now because there are smoother approaches to migrating to future-proofed networks than existed at the time. the fact that it persists on the internet, unamended, to be regularly presented (two decades later) as some semblance of current realities of the challenges to ipv6 deployment is a disservice to the internet.

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

i would maintain that "ipv6mess" had a NEGATIVE impact on ipv6 adoption overall, as people who saw djb as a tech god accepted his word as gospel, despite it fundamentally being a crybaby rant, & proliferated the misconceptions & opposition therein.

the fact that he explicitly rejected ipv6 patches to qmail & djbdns (resulting in a fork to at least qmail) should not be understated - he didn't just complain about ipv6, he actively sought to undermine its adoption.

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

[throw0101a]

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

Oh, you mean like this:

> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[61]

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

* https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5

You still need to upgrade bit of networking kit between the source and destination to understand "IPv4+", and this (lack of) upgrading and enabling is what is hampering deployment.

What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6?

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

Backwards compatibile IPv6 was impossible.

IPv4 has 32 bits of address. Anything after IPv4 needed >32 bits of address. How do you fit in >32b in a data structure that is 32b? You cannot.

So you have to go an replace every bit of networking code out there to change the data structures. You know, like was done to deploy IPv6.

[Sesse__]

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

Because it does not help. djb's “idea” was to change everybody's setup _first_ and then have a flag day where the entire world were moved from IPv4 to IPv6 in one big change. Good luck with that. (And only after that flag day, we could start actually using a larger address space to try to get rid of NATs.)

The ipv6mess essay is confused because it somehow thinks _getting addresses_ is the hard problem. It does not solve _any_ other configuration or coding part. You still need to upgrade DNS. You still need to have a different wire protocol. You still need every hop on the path from me to you to understand and route IPv6.

At least now with gradual rollout and dual stack, we're at 40% of endpoints and AFAIK a majority of traffic. With djb's plan, we'd still be at zero.

[mplabelspace]

This is an astoundingly narrow take. They (vendors, practitioners, stodgy luddites) didn't listen because there was nothing on fire and no money to grab at when the conversations began 20 years ago. Networks exist (and have always existed) globally that operate using parallel, incompatible protocols from layer 1 to layer 3. None of this is new, and none of it should be a surprise. The outrage all stems from a lack of awareness of history and increased visibility from armchair experts that fixate on how things work for them, and not from the long-term perspective or the point of view of a large provider, global network, or resource of significant scale / size. IPv4 is the poster child for the sunk cost fallacy; it is an outdated shit pile that has become the outdated shit pile we know, and therefor somehow the option that needs extended in perpetuity. "Good Enough" is subjective. A bicycle is "good enough" for moving a person from point A to point B over short distances. It's not good enough when it is below freezing, raining, or needs to transport large cargo. It's not good enough when there are 3 people that need to travel from point A to point B and there is only one bicycle. A car may be good enough for that. But a car isn't good enough when part of that trip spans an ocean. The fact that a person thinks IPv6 is a stupid idea and that extending or making compatible the pant load of diarrhea that is IPv4 is "good enough" is fine for that one person, or even a group of persons. However, it does not scale globally, and it provides no supportable longevity. Even with the release of every single extra block of IPv4 - 240, 127, all of the unused or dark /8 addresses, 0.0.0.0, 255, and even with the proliferation of carrier NAT - it is still too limited to scale long term or introduces blindingly unnecessary complexity. There is already significant IPv6 deployment globally, and it has grown by a large margin in the last 3 years, prior posts have clearly shown that. As far as IPv4, The goal was never to turn it off like a light switch, it has always been to phase it out, and by and large that has been happening at a fairly accelerated rate.

If we spend half as much time on IPv6 that we do moaning about IPv6, we would have been done with this a decade ago. The point is that IPv4 is functionally legacy. It'll continue to exist until it doesn't, but refusal to learn and implement IPv6 (and contribute to improving it) is truly a disservice. It's well past the point of no return, so learn it. Or don't. It won't really change the direction we are moving.