> so a direct connection is obviously impossible. (Are you even asking seriously, or is this just snark?)
I am asking seriously, both because I've seen proposals where the proposer does seem to sincerely believe it to be possible to somehow fit more than 32 bits in a 32-bit field (that was a truly baffling one), and because it is possible with stateful hacks similar to NAT64/DNS64 (that is: when the host at 198.51.100.1 tries to look up the address of the host at 459.256.369.257, it receives a fake but valid address, and a router in the path knows to map the fake address to the real address while doing all the necessary NAT shenanigans).
> The wide-address host would have to have an additional IPv4-compatible address bound to its network interface.
Then you gain nothing other than extra complexity, since the total number of hosts is still limited by the 32-bit IPv4 address.
> Or else some other host would have to have such an IPv4-compatible address on its behalf and do NAT or proxying.
Then not only you gain nothing by making your "new" addresses a superset of IPv4 addresses, but also you start looking like IPv6 ended up being, with all its transition mechanisms.
> I've seen proposals where the proposer does seem to sincerely believe it to be possible to somehow fit more than 32 bits in a 32-bit field.
Ah, well, that's obviously not a computer programmer with more than 2 or 3 years of experience. :)
> Then you gain nothing other than extra complexity, since the total number of hosts is still limited by the 32-bit IPv4 address.
Have we gained nothing?
Consider that the majority of the IP addresses in the network are individual subscriber IP addresses, not servers. So we can have a transitional situation in which major service providers use the old 32 bit address space (so they are reachable by every client, 32 or 64 bit), while we put new subscribers into the 64 bit address space.
The users who remain in the 32 bit space will increasingly find that they can't connect to some servers that are in the beyond-32 parts of 64 space, so they will have to upgrade their systems.
Users in 32 space cannot do peer-to-peer with 64 users outside of that space, of course.
> Consider that the majority of the IP addresses in the network are individual subscriber IP addresses, not servers. So we can have a transitional situation in which major service providers use the old 32 bit address space (so they are reachable by every client, 32 or 64 bit), while we put new subscribers into the 64 bit address space.
> The users who remain in the 32 bit space will increasingly find that they can't connect to some servers that are in the beyond-32 parts of 64 space, so they will have to upgrade their systems.
> Users in 32 space cannot do peer-to-peer with 64 users outside of that space, of course.
i.e. exactly the same situation that we currently have, only it would be less visible whether you've upgraded, and harder to debug when you had?
The hard part of deploying IPv6 isn't that the protocol is different (indeed the protocol is significantly simpler e.g. removing fragmentation). The hard part is that it's necessarily a new global routing table, that you necessarily can't use it between two hosts unless every router in between them supports it and has the routes set up. A more IPv4-like packet format would not change that at all.
You might not have identified the really hard part.
Which is this: reams of application code is hard-coded to the AF_INET address family, and its binary sockaddr_in structure, and related data types and functions.
But that's a problem facing any proposed or actual IP facelift.
> I've seen proposals where the proposer does seem to sincerely believe it to be possible to somehow fit more than 32 bits in a 32-bit field.
If someone seriously brings that to me, I'm gonna try and come up with something witty...
"The thing people forget is that the periods in an IPv4 address take up space, too. If you know anything about data octets, you'd realize that were we're wasting adding 8 bits for EACH period just to make those addresses human readable. Periods are the junk DNA if IP addresses.
Fun fact: the reason Comcast is able to charge more for their Internet is because they got Congress to allow them to charge extra for the dots. You know how some people pay $40 for their Internet and you are paying $70? While they are talking to 32 bit addresses at $10 per 8 bits, you are paying the same $10 per 8 bits, and another $30 for IP addess 'junk DNA'! Pull out your cable bill and look for through the fine print. There's a reason the fine print is so small. That's how they obfuscate how they you charge you 75% and get away with it."
I wish I could remember where I saw it so I could share it with you all, but the argument was something like using more voltage levels to fit more values in each bit of the IP address. (It was probably in one of the ietf mailing lists, this sort of crankery seems to get posted there often for some reason.)
I am asking seriously, both because I've seen proposals where the proposer does seem to sincerely believe it to be possible to somehow fit more than 32 bits in a 32-bit field (that was a truly baffling one), and because it is possible with stateful hacks similar to NAT64/DNS64 (that is: when the host at 198.51.100.1 tries to look up the address of the host at 459.256.369.257, it receives a fake but valid address, and a router in the path knows to map the fake address to the real address while doing all the necessary NAT shenanigans).
> The wide-address host would have to have an additional IPv4-compatible address bound to its network interface.
Then you gain nothing other than extra complexity, since the total number of hosts is still limited by the 32-bit IPv4 address.
> Or else some other host would have to have such an IPv4-compatible address on its behalf and do NAT or proxying.
Then not only you gain nothing by making your "new" addresses a superset of IPv4 addresses, but also you start looking like IPv6 ended up being, with all its transition mechanisms.