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