Comment by throw0101a
5 days ago
If we have IPv4 address 1.2.3.4, and the hypothetical IPv4+ adds 1.2.3.4.1.2.3.4 (or longer), how would a IPv4-only router handle 1.2.3.4.1.2.3.4? If an IPv4-only host or application gets a DNS response with 1.2.3.4.1.2.3.4, how is it supposed to use it?
As I see it, the transition mechanism for some IPv4+ that 'only' has longer addresses is exactly the same as for IPv6: new code paths that use new data structures, with a gradual rollout with tech refreshes and code updates where hosts slowly go from IPv4-only to IPv4-and-IPv4+ at different rates in different organizations.
If you think it's somehow different, can you explain how it is so? What proposal available (especially when IPng was being decided on in the 1990s) would have allowed for a transition that is different than the one described above (gradual, uncoördinated rollout)?
The proposal is that IPv4+ would be interpretable as an IPv4 packet. Either the IP header is extended, or we add another protocol layer for the IPv4+ bits (IPv4+ is another envelope for the user payload).
DNS is like today: A and AAAA records for IPv4 and IPv4+ respectively.
Core routers do not need to know about IPv4+, and might never know.
The transition is similar to 6to4. The edge router does translation to allow IPv4+ hosts to connect to IPv4 hosts. IPv4 hosts are unable to connect to IPv4+ directly (only via NAT). So it has the similar problem to IPv6 that you ideally want all servers to have a full IPv4 address.
What you don't have is a completely parallel addressing system, requirements to upgrade all routers (only edge routers for 4+ networks), requirements to have your ISP cooperate (they can just give you an IPv4 and you handle IPv4+ with your own router), and no need that the clients have two stacks operating at once.
It's essentially a better NAT, one where the clients behind other NATs can directly connect, and where the NAT gradually disappears completely.