[dangerlibrary]

Just to address the implication (prevalent in many of the sibling comments as well) that I and everyone else who talks about this are idiots incapable of grasping that 128 is larger than 32:

If 32 bit IPv4 addresses are valid IPv6 addresses without fiddly NAT64/DNS64 shenanigans, then (it seems to me) IPv4-only clients could blithely continue to interact with the IPv4-accessible internet via IPv6-only servers, routers, etc. indefinitely. They can putter along accessing only a subset of available resources forever and everyone can passive-aggressively roll their eyes at them and close support tickets saying "upgrade to IPv6 if you want to see the rest of the internet, it just works."

That's what I mean by backwards compatible. Everyone who says "it can't be done, it has to be this way" is asserting that there's no better alternative to NAT64/DNS64 and running two entirely separate networking stacks in parallel. I don't buy that there was no simpler way to accomplish packing 32 bits into a space that can contain 128 bits. And if "supporting IPv6" simply meant "upgrading your networking software to the latest version, which transparently handles both IPv4 and IPv6 traffic for you" then networking and server teams have no excuse to avoid deploying IPv6 support for 26 years.

I recognize that 128 bit addresses will be truncated and packets misdirected or rejected if handled by a 32 bit networking stack. I recognize that clients upgrading too early will fail and need to fall back. But making it unnecessarily difficult for servers and routers to handle IPv4 traffic in an IPv6-only context led us to where we are today.

To illustrate my point: ascii text works just fine, with no translation layer required, when parsed and transmitted as UTF-8.

[throw0101d]

> If 32 bit IPv4 addresses are valid IPv6 addresses without fiddly NAT64/DNS64 shenanigans, then (it seems to me) IPv4-only clients could blithely continue to interact with the IPv4-accessible internet via IPv6-only servers, routers, etc. indefinitely

If you have an IPv4-only client and an IPv6-only server (i.e., has no IPv4 address), you need a IPv4-IPv6 relay.

Because if the IPv6-only server is truly IPv6-only, it only has addresses that are 128 bits. How would an IPv4-only client, which only knows about 32-bit addresses, deal with a 128-bit address? The only address that the IPv6-only server has is 128 bits: how are you supposed to fit those bits in the 32-bit data structures of the IPv4-only client.

If a the server is IPv6-only, then its DNS records have to be 128-bits as well: how does that work with DNS A records, which are hard-coded to 32-bits? That's why AAAA records were invented: to with 128 bits. Now you're talking about update DNS server for new record types, resolver code to request A and AAAA records. Of course after you do a lookup to get the IP, you have generally want to connect, so you call socket(2) and then connect(7), so the latter has to be re-coded to understand 128-bit addresses.

[dangerlibrary]

You are correct, given the assumption that an IPv6-capable server or host has no IPv4 address. I attempted to acknowledge that such a server would be unreachable from an IPv4 client.

[kstrauser]

Thing is, all interesting Internet services require 2-way communication. Suppose you had an IPv6 client trying to talk to an IPv4 server. With that scheme, the initial packet could get routed to the server by dropping the first 96 bits of the address and treating the rest like an IPv4 address. But where do you put those other 96 bits so that the server can send its reply packet back to the originating client?

You can use NAT64 which does exactly that. If you're doing that anyway, there's not much advantage to adding all the complexity directly into the protocol.

[ianburrell]

How would IPv4 host talk through IPv6 network in your model? Without IPv6 network sees an unsupported IPv4 packet and throws it away. You need something to convert IPv4 to IPv6. We'll call it NAT46, but it is deprecated because dual stack or NAT64 is better.

Or could tunnel IPv4 over IPv6. We'll call this 4in6.

The mistake you are making is thinking that it is hard to have dual stack. IPv4 will be running in tunnels for a long time, just like IPv6 run in tunnels in early days. There are enough IPv4 addresses for servers for a long time. Eventually, IPv6 will be the norm and nobody will care about IPv4 except for running old hardware and software.

Upgrading just networking software is impossible since client software needs to be upgraded to support longer addresses. In particular, they need to support the generic interfaces that work with multiple protocols.

[dangerlibrary]

> Without IPv6 network sees an unsupported IPv4 packet and throws it away. You need something to convert IPv4 to IPv6.

Acknowledging my own ignorance here, assuming this sentence seemingly disregards my point, because this was a choice. The IPv6 standard chose to fix the header length at 40 bytes and operate differently from IPv4, but the standard could easily have said "We're re-using the IPv4 header format, except now addresses are variable-length up to 128 bits."

[Ekaros]

Because they also noticed that IPv4 has some design errors. So if you are anyway making something incompatible you can fix those and bring in new features.

IP packet having checksum that is also calculated on the hops remaining. Well, do you really really need that when most popular protocols TCP and UDP have also a checksum? So getting rid of it entirely is actually a smart move.

And then whole ARP, DHCP etc. Can we do something more sensible instead of that sort of thing. Different mindset, but reasonable attempt.