[commandersaki]

Whatever the next IP is, it needs to be interoperable with the Internet aka IPv4.

It’s clear to me that IPv6 won’t reach critical mass (e.g. 80% of connected devices/servers using IPv6 addresses).

I’ll just wait for a new IP with an actual transition plan.

[welterde]

The problem is that IPv4 is not forward-compatible and therefore there cannot be a protocol that is entirely interoperable. There can only be ones that are somewhat interoperable. And IPv6 has plenty of mechanisms that make things interoperable (NAT64, embedding ipv4 addresses in ipv6, etc.).

[commandersaki]

What we need is a pure 4 network to be able to talk to a 6 network - that's what it means to be interoperable. Going 6 to 4 is obviously required or otherwise 6 would be a useless protocol to begin with. Anycast routing plus tunnelling is one way to achieve 4 to 6. But the "ngtrans" team didn't accept this a transition plan, nor did they provide an official transition plan for migrating 4 to 6. Basically 6 has been a disaster since the days of IPng and misstep is ignored because they wanted a "clean slate" architecture with a large IP space that nobody really needs.

I'm holding out for a new protocol/architecture to come along and supplant IP by recognising that it needs to be fully interoperable with 4 before it can supersede it.

[cornholio]

I think this discussion is 20 years too late, the only reasonable way forward is IPv6 or bust. We're reached the end of the IPv4 space and the pressure is mounting; any imaginable backwards-compatible technology would have to run for many years in a limited mode where it's basically just a better way to do NAT traversal and only then, when most endpoints are compatible, you would get to see the address-space relief benefits.

Another nail in the coffin of a graceful upgrade from IPv4 is the widespread filtering of IP options in the backbone, the only practical way I know you could craft an extended IPv4 packet that is still routable by the legacy infrastructure while forwarding and maintaining all the extra header data required for routing in the IPng realms. This was not necessarily true in the early 90s, and many hardware generations would have had the ability to fix it.

So I somewhat disagree with the GP that IPv4 was not forward compatible: it included a mechanism for just that in the form of IP options that seemed like a good idea in 1983, but which proved technically inappropriate for the future needs of the internet. So you can't really fault IETF for wanting to break away from that and earnestly thinking people would just upgrade.

[ianburrell]

Having IPv4 host talk to IPv6 server isn't really necessary since there are enough IPv4 addresses for external servers. IPv6 is most important for client addresses to replace NAT, especially carrier-grade NAT, and simplify networks.

The article mentions NAT64, which works well for IPv6-only computers to talk to IPv4 servers. There is enough space in IPv6 to encode the whole IPv4 connection which makes stateless NAT possible.

The other mechanism is 464XLAT and MAP, where IPv4 isn't tunneled over IPv6 network, but encoded in the IPv6 address. 464XLAT is used heavily on mobile phone and uses software on the device. MAP requires support on gateway. MAP is stateless which is savings over carrier-grade NAT.

[welterde]

How exactly do you propose this 4 to 6 mechanism to work? How do you fit more than 32-bit of information into the 32-bit destination field of IPv4?

Because that's what's required to make it fully interoperable. Anything else and it's not a pure IPv4 network anymore and you are in the exact same situation as we are with IPv6.