It's not as simple as that. There's no just "extending" the IPv4 stack unless you're going to "extend" every device that supports IPv4 with it. By that point you'd might as well just have IPv6.

IPv6 is perfectly backwards compatible with IPv4 with the IPv4-in-IPv6-address embedding and other technologies. The problem is that IPv4 is not forward-compatible with anything that has a larger address space. Thus a IPv4-only host will never ever be able to communicate with a non-IPv4 host, since there is no way to encode more than 32-bit of information in the IPv4 header.

So you will always end up in this situation where people just won't bother implementing the IPv4-replacement and you cannot simply switch to it.

But why couldn't we just put a middlebox in front of the host which translates a 4-over-6 address to a plain ipv4? The host box still sees only v4 but v6-only devices can still connect to it.

Like I could envision a simple router-like device doing this.

That's not the direction that's the problem - like I mentioned (IPv6 is backwards compatible), NAT64 and so forth boxes exist (but still not great since you have to hold state).

But the problem is that the inverse is not possible. How would a IPv4-only box connect to a non-IPv4 box? How do you encode more than 32-bit of information into the 32-bit destination address field of the IPv4 packet?

> What we needed was an internet protocol with the benefits of IPv6 that runs as an extension to the IPv4 stack.

My understanding is that the reason it's a new version is so existing IPv4 infrastructure would not need to be changed. This "ships in the night" approach has pros and cons, of course, but I'm personally happy to give folks who thought about this problem for many years the benefit of the doubt.

> The current approach to duplicate everything into IPv6 is wasteful and time consuming, proven by the extremely slow adoption rate.

The beauty of the IPv6 approach is that it doesn’t matter how long it takes.

I don't understand how it's "wasteful". Is it wasteful to support 3 versions of HTTP?

HTTP is backwards compatible

It's not. There's a negotiation process, but you can't use HTTP/3 to deliver content to a client that doesn't support it.

"HTTP/3 uses QUIC instead of TCP for the underlying transport protocol. Like HTTP/2, it does not obsolesce previous major versions of the protocol." - https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Would you care to elaborate what "an internet protocol with the benefits of IPv6 that runs as an extension to the IPv4 stack" actually looks like at the technical level that would give the "backward compatibility" that IPv6 you claim is lacking ?

Despite the downvotes you are right. IPv6 replaces IPv4 rather than building on top of it and this really harmed adoption.

I read all of the IPv6-ish proposals at the time, and they all had major problems of one kind or another. The chosen proposal "really harmed adoption" when compared to a pie in the sky, not to the other proposals.