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