misc

dating DNS libraries and user land. There is no way to expand address space without going through all the same issues as what we call "IPv6" (originally SIPP) has gone through. * https://github.com/becarpenter/misc/blob/main/why6why.md

col. (3B) Translation, in which something translates addresses between the old and new protocols. * https://github.com/becarpenter/misc/blob/main/why6why.md * https://datatracker.ietf.org/doc/html/rfc1671

(3B) Translation, in which something translates addresses between the old and new protocols. * https://github.com/becarpenter/misc/blob/main/why6why.md * https://datatracker.ietf.org/doc/html/rfc1671 You also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.) In any 'address extension' plan the legacy code cannot use the new address space; you have to: * update the IP stack (like with IPv6) * tell applications about new DNS records (like IPv6) * set up translation layers for legacy-only code that cannot be update to reach extended-address-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)

the old (IPv4) and new (IPng) protocol. (3B) Translation, in which something translates addresses between the old and new protocols. * https://github.com/becarpenter/misc/blob/main/why6why.md * https://datatracker.ietf.org/doc/html/rfc1671 > Keeps all the nice parts of IPv4, doesn’t require everyone to switch to an entirely new system, backwards compatible with existing hardware/software. Problem solved. You have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6. You also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.) You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to: * update the IP stack (like with IPv6) * tell applications about new DNS records (like IPv6) * set up translation layers for legacy-only code that cannot be update to reach IPv4+-only destination (like IPv6 with DNS64/NAT64, CLAT, etc) You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space. "Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.

ething translates addresses between the old and new protocols. * https://github.com/becarpenter/misc/blob/main/why6why.md * https://datatracker.ietf.org/doc/html/rfc1671 For anyone curious as to the decision-making process, here are the criteria for what the IETF was looking for in an IPng: * https://datatracker.ietf.org/doc/html/rfc1726 Here are the candidates that were floating around at the time, and the reason why the winner was chosen: * https://datatracker.ietf.org/doc/html/rfc1752

anisms to allow these hosts to communicate, even after IPng has become the dominant network layer protocol in the Internet. * https://datatracker.ietf.org/doc/html/rfc1726#section-5.5 Creating an IPng was always going to be complicated: So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means [three] things immediately: You have to change the version number. You have to add new code to handle the new version. […] You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions: (3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol. (3B) Translation, in which something translates addresses between the old and new protocols. * https://github.com/becarpenter/misc/blob/main/why6why.md * https://datatracker.ietf.org/doc/html/rfc1671