[perennialmind]

There's no viable alternative to dual stack with NAT now. We're stuck with it.

But when IPv6 was standardized, a pure upgrade to IPv4 was still feasible. IPv4 allows for extensions headers and middleboxes hadn't yet imposed protocol ossification. If instead of the encapsulation the article supposes, the upgrade embraced translation, we could have had an IPv4+ with NAT fallback. A node on a network behind a IPv4+ router would send out a packet with the RFC1918 interior address encoded as the address extension. Either the server (which would have a proper IPV4 address) responds without the extension header, at which point the IPv4+ router at the edge has to do NAT-style connection tracking, or the response packet can be forwarded as-is.

All the pain of upgrading software to a new protocol still applies, with the added headache of variable length addresses (4 bytes, 8 bytes, potentially more). But no ISP has to make the investments or take the risk of the parallel infrastructure. The IPv4 core carries on, with incremental improvements but zero mandatory upgrades.

[Dagger2]

Sure there is: use single-stack v6 with NAT64.

What you're describing there is just an approach to store NAT state inside every packet instead of on the router. I'm not sure that's even an improvement on v4, but in any case it wouldn't increase the size of the address space so it wouldn't help with the one thing driving the need for IPv6.

[perennialmind]

IPv4 will be with us for a long, long time. My point is that we're stuck with the combination in some form or another and it didn't have to be that way.

Embedding the address extension using the extension mechanism built into IPv4 would have allowed for a true upgrade and a single IP address space. Two nodes with eight-byte IP addresses would exchange packets without any rewriting. That's an address-space expansion, not just a weird way to do NAT. With perfect foresight, I have no doubt the IETF could have embraced NAT as a transition technology quickly obsoleted by broad adoption.

[Dagger2]

There is no extension mechanism built into v4 for longer addresses.

Of course v4 is going to be with us for a long time. We can't make existing v4-only devices go away because we have no way to enforce a flag day on the Internet, so there was never any way around that. But you can run networks without v4 just fine if you want to (including the ability to connect to v4-only hosts, or let them connect to you), so you can in fact turn v4 off on your network.

> That's an address-space expansion, not just a weird way to do NAT

You said the server would have a proper v4 address and the client would put its RFC1918 address into an extension header. You don't get any extra address space that way. But if you do try to give nodes 8-byte addresses... you immediately get the same situation we have in v6, because nodes and software that only know how to deal with 4-byte addresses won't know how to deal with your 8-byte addresses. You'll end up having to use the same approaches v6 uses to deal with the same problem.

> I have no doubt the IETF could have embraced NAT as a transition technology quickly obsoleted by broad adoption

What do you think RFC 2765/2766 are about? Or RFCs 6144~6147?