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