5 ms·

From §8.3: Each TCP/IP v7 system, whether host or router, must be able to recognize adjacent systems in the topology that are (only) v4, and call t

From §8.3: Each TCP/IP v7 system, whether host or router, must be able to recognize adjacent systems in the topology that are (only) v4, and call the appropriate conversion routine just before sending the datagram. […] On networks where ARP is not normally used, the method is to assume that a remote system is v7. If an IPv7 datagram is received from it, the assumption is confirmed. If, after a short time, no IPv7 datagram is received, a v7 ICMP echo is sent. If a reply is received (in either version) the assumption is confirmed. If no reply is recieved, the remote system is assumed not to understand IPv7, and datagrams are converted to IPv4 just before transmitting them. So basically very close to what's done now in the IPv4-IPv6 world with Happy Eyeballs (do a DNS lookup, and try both A and AAAA responses, and see who answers first): * https://en.wikipedia.org/wiki/Happy_Eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs And let's not forget about all the function and system calls that need to be updated (§2.4) because various structs are of a fixed sized: There is a non-trivial amount of software that assumes that an "int" is the same size and shape as an IP address, and does things like "ipaddr = *(int *)ptr". This usage has always been incorrect, but does occur with disturbing frequency. As IPv7 8 byte addresses appear in the application layers, this software will find those addresses unreachable; this is preferable to interacting with a random host. Just like with IPv6, the IPv7 described in RFC 1475 would have needed libraries and data structures to be created. Also DNS A records were fixed sizes, and so a new record type would have needed to be created for IPv7 (like AAAA was for IPv6). IPv7 would have had the exact same issues that IPv6 had with rollout. There is no "just" when trying to expand a fixed-size data structure across the entire planet.

theamk 2y ago
No they would not. Linux is IPv6 compatible since 1996. Apache since 2002. Python since 2004. The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet? Because IPv6 refused to be IPv4-with-extensions and instead decided to be completely incompatible - so all the admin scripts, all the best practices, all the configuration needs to be rewritten. Instead of fixing a single apache codebase, one needs to fix millions of adhoc network configurations. IPv7 on the other side, had absolutely different philosophy: The objective of conversion is to be able to upgrade systems, both hosts and routers, in whatever order desired by their owners. Organizations must be able to upgrade any given system without reconfiguration or modification of any other; and IPv4 hosts must be able to interoperate essentially forever. (IPv4 routers will probably be effectively eliminated at some point, except where they exist in their own remote or isolated corners.) this would get things converted much faster.
- throw0101b 2y ago
  > No they would not. Linux is IPv6 compatible since 1996. Apache since 2002. Python since 2004. Okay: so given that gethostbyname(3) only dealt with struct hostent with type of AF_INET: * https://pubs.opengroup.org/onlinepubs/000095399/functions/gethostbyname.html https://pubs.opengroup.org/onlinepubs/000095399/functions/ge... * https://www.akkadia.org/drepper/userapi-ipv6.html https://www.akkadia.org/drepper/userapi-ipv6.html Those had to be rewritten to support AF_INET6 and use use that new address type. See also changing all socket(2) calls. * https://datatracker.ietf.org/doc/html/rfc3493 https://datatracker.ietf.org/doc/html/rfc3493 * https://datatracker.ietf.org/doc/html/rfc4038 https://datatracker.ietf.org/doc/html/rfc4038 Regardless of what was chosen to be IPng, there would have been a whole bunch of rewriting necessary. If "IPv7" (TP/IX) was chosen as IPng (instead of SIPP(-16) becoming "IPv6") then we would have to add "AF_INET7" everywhere. And the supporting infrastructure (e.g., new DNS record types) would also have needed to be done for AF_INET7, just like it had to be done for AF_INET6. > The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet? Because most programs are written in Western, industrialized countries. And those countries have plenty of IPv4 address to go around since they got to the Internet first. And so there is no (perceived) shortage for the people writing and and running the largest Internet services they feel no pressing need to. ("Address shortage? What address shortage?") IPv6 has not taken off not because it's "bad" or "worse" than IPv4, or because IPv4 is "better" than IPv6: it has not taken off because of inertia: IPv4 works well enough and its short-coming (e.g., NAT) are known quantities with known workarounds. Meanwhile those folks that weren't fortunate enough to around for the early IPv4 address land grab are struggling with shortages: * https://community.roku.com/t5/Features-settings-updates/It-s-2022-and-still-no-IPv6/m-p/854673/highlight/true#M35732 https://community.roku.com/t5/Features-settings-updates/It-s... * https://news.ycombinator.com/item?id=35047624 https://news.ycombinator.com/item?id=35047624 > IPv7 on the other side, had absolutely different philosophy: All IPng had the same criteria, including gradual upgrades ("Technical Criteria for Choosing IP The Next Generation (IPng)" § 5.5 Transition): We believe that it is not possible to have a "flag-day" form of transition in which all hosts and routers must change over at once. The size, complexity, and distributed administration of the Internet make such a cutover impossible. Rather, IPng will need to co-exist with IPv4 for some period of time. There are a number of ways to achieve this co-existence such as requiring hosts to support two stacks, converting between protocols, or using backward compatible extensions to IPv4. Each scheme has its strengths and weaknesses, which have to be weighed. Furthermore, we note that, in all probability, there will be IPv4 hosts on the Internet effectively forever. IPng must provide mechanisms 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 https://datatracker.ietf.org/doc/html/rfc1726#section-5.5 The authors of RFC 1475 themselves 'abandoned' / changed TP/IX and put forward CATNIP: * https://datatracker.ietf.org/doc/html/rfc1707 https://datatracker.ietf.org/doc/html/rfc1707 You are putting forward an idea (RFC 1475: TP/IX) which the authors themselves did not put forward for evaluation.

theamk 2y ago

No they would not. Linux is IPv6 compatible since 1996. Apache since 2002. Python since 2004. The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet? Because IPv6 refused to be IPv4-with-extensions and instead decided to be completely incompatible - so all the admin scripts, all the best practices, all the configuration needs to be rewritten. Instead of fixing a single apache codebase, one needs to fix millions of adhoc network configurations. IPv7 on the other side, had absolutely different philosophy: The objective of conversion is to be able to upgrade systems, both hosts and routers, in whatever order desired by their owners. Organizations must be able to upgrade any given system without reconfiguration or modification of any other; and IPv4 hosts must be able to interoperate essentially forever. (IPv4 routers will probably be effectively eliminated at some point, except where they exist in their own remote or isolated corners.) this would get things converted much faster.

throw0101b 2y ago
> No they would not. Linux is IPv6 compatible since 1996. Apache since 2002. Python since 2004. Okay: so given that gethostbyname(3) only dealt with struct hostent with type of AF_INET: * https://pubs.opengroup.org/onlinepubs/000095399/functions/gethostbyname.html https://pubs.opengroup.org/onlinepubs/000095399/functions/ge... * https://www.akkadia.org/drepper/userapi-ipv6.html https://www.akkadia.org/drepper/userapi-ipv6.html Those had to be rewritten to support AF_INET6 and use use that new address type. See also changing all socket(2) calls. * https://datatracker.ietf.org/doc/html/rfc3493 https://datatracker.ietf.org/doc/html/rfc3493 * https://datatracker.ietf.org/doc/html/rfc4038 https://datatracker.ietf.org/doc/html/rfc4038 Regardless of what was chosen to be IPng, there would have been a whole bunch of rewriting necessary. If "IPv7" (TP/IX) was chosen as IPng (instead of SIPP(-16) becoming "IPv6") then we would have to add "AF_INET7" everywhere. And the supporting infrastructure (e.g., new DNS record types) would also have needed to be done for AF_INET7, just like it had to be done for AF_INET6. > The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet? Because most programs are written in Western, industrialized countries. And those countries have plenty of IPv4 address to go around since they got to the Internet first. And so there is no (perceived) shortage for the people writing and and running the largest Internet services they feel no pressing need to. ("Address shortage? What address shortage?") IPv6 has not taken off not because it's "bad" or "worse" than IPv4, or because IPv4 is "better" than IPv6: it has not taken off because of inertia: IPv4 works well enough and its short-coming (e.g., NAT) are known quantities with known workarounds. Meanwhile those folks that weren't fortunate enough to around for the early IPv4 address land grab are struggling with shortages: * https://community.roku.com/t5/Features-settings-updates/It-s-2022-and-still-no-IPv6/m-p/854673/highlight/true#M35732 https://community.roku.com/t5/Features-settings-updates/It-s... * https://news.ycombinator.com/item?id=35047624 https://news.ycombinator.com/item?id=35047624 > IPv7 on the other side, had absolutely different philosophy: All IPng had the same criteria, including gradual upgrades ("Technical Criteria for Choosing IP The Next Generation (IPng)" § 5.5 Transition): We believe that it is not possible to have a "flag-day" form of transition in which all hosts and routers must change over at once. The size, complexity, and distributed administration of the Internet make such a cutover impossible. Rather, IPng will need to co-exist with IPv4 for some period of time. There are a number of ways to achieve this co-existence such as requiring hosts to support two stacks, converting between protocols, or using backward compatible extensions to IPv4. Each scheme has its strengths and weaknesses, which have to be weighed. Furthermore, we note that, in all probability, there will be IPv4 hosts on the Internet effectively forever. IPng must provide mechanisms 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 https://datatracker.ietf.org/doc/html/rfc1726#section-5.5 The authors of RFC 1475 themselves 'abandoned' / changed TP/IX and put forward CATNIP: * https://datatracker.ietf.org/doc/html/rfc1707 https://datatracker.ietf.org/doc/html/rfc1707 You are putting forward an idea (RFC 1475: TP/IX) which the authors themselves did not put forward for evaluation.