3 ms·

> 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 hos

> 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
I am not sure why you keep mentioning gethostbyname(3), socket calls, and so on. As I said, this has been fixed - python's IPv6 support back in 2004 (20+ years ago!) had it all figured out and implemented. Bind 9.2 (released 2001) had AAAA support. You cannot explain difficulties in IPv6 adoption by need to rewrite in 2024. And yes, maybe IPv7 in particular is not the best solution, but it's hard to imagine how it could be worse than IPv6.. 20 years since support has been added to all core software and it's _still_ not adopted by end users? I think the problem with IPv6 is a decision to redo all the management methodology. Your RFC 1726 illustrates it well: there is only one brief mention of backward compatibility in 5.5, listed as "optional" feature, and whole sections about changing the protocol in incompatible way, including 5.8 which starts with: People complain that IP is hard to manage. We cannot plug and play. We must fix that problem. They fixed it indeed! Today, for home networks, IPv6 is even harder to manage than IPv4 was, just try to keep your small office LAN functioning while handling ISP address changes. Certainly possible, but nowhere close to "plug device in and it gets stable IPv4 address which is unlikely to ever change".
- throw0101b 2y ago
  > You cannot explain difficulties in IPv6 adoption by need to rewrite in 2024. The difficulties encountered with IPv6 would have been the same even if another proposal would have been chosen for IPng because the exact same thing would have needed to be done: new address type for syscalls, new data structures, new surrounding infrastructure. When your original standards do not allow for address length changes/flexibility, you have to write a new standard with the new address size, and there's no way to stuff >32 bits of data (addresses) into a 32-bit field. IPng would always have been a breaking change, regardless of proposed candidate chosen. And if you're not going to have a flag day (à la NCP-IP changeover), then you'll need transition mechanisms with tunnels for sparse dispersal between IPng islands in a sea of IPv4. > And yes, maybe IPv7 in particular is not the best solution, but it's hard to imagine how it could be worse than IPv6.. 20 years since support has been added to all core software and it's _still_ not adopted by end users? All the proposals for IPng needed to have the same things done. "Technical Criteria for Choosing IP The Next Generation (IPng)": * https://datatracker.ietf.org/doc/html/rfc1726 https://datatracker.ietf.org/doc/html/rfc1726 New packet type/header, new API options, new records and data structures for DNS, transition mechanisms (tunnelling). All this needs to be rolled out to hosts, routers, firewalls, ASICs, etc. All the while IPv4 would continued to be used, so what incentive would business and IT departments have had to move to TUBA or TP/IX-CATNIP? ("Our (IPv4) network works, why do we need IPv7?") > Today, for home networks, IPv6 is even harder to manage than IPv4 was, just try to keep your small office LAN functioning while handling ISP address changes. Before recently moving ISPs (to go from DSL to GPON) I had IPv6 for several years on the old one and all my hosts (cabled, Wifi), phones, printers, etc, had IPv6 addresses given out by RA by my Asus, and I had no issues. In fact IPv6 worked "too well" for me at one point: a while ago I was web surfing I had all those little Facebook icons show up that were served from their web site, probably dropping cookies on my system. I didn't want that so I put FB's domain in my hosts(5) file so that it go to "0.0.0.0": the little icons went away. Then suddenly they appeared. And I checked hosts to make sure things were still there, and I did web browser debugging to see if things changed in the HTML. And then I remembered that my ISP had activated IPv6, and so the icons were coming from FB's IPv6 address. Once I added "::1" for FB in my hosts file the icons disappeared again. The IPX/SPX and DECnet folks managed to learn IPv4, so I'm not sure why the IPv4 folks have such a hard time with IPv6. IPv6 is no more difficult a Layer 3 protocol than IPv4.

theamk 2y ago

I am not sure why you keep mentioning gethostbyname(3), socket calls, and so on. As I said, this has been fixed - python's IPv6 support back in 2004 (20+ years ago!) had it all figured out and implemented. Bind 9.2 (released 2001) had AAAA support. You cannot explain difficulties in IPv6 adoption by need to rewrite in 2024. And yes, maybe IPv7 in particular is not the best solution, but it's hard to imagine how it could be worse than IPv6.. 20 years since support has been added to all core software and it's _still_ not adopted by end users? I think the problem with IPv6 is a decision to redo all the management methodology. Your RFC 1726 illustrates it well: there is only one brief mention of backward compatibility in 5.5, listed as "optional" feature, and whole sections about changing the protocol in incompatible way, including 5.8 which starts with: People complain that IP is hard to manage. We cannot plug and play. We must fix that problem. They fixed it indeed! Today, for home networks, IPv6 is even harder to manage than IPv4 was, just try to keep your small office LAN functioning while handling ISP address changes. Certainly possible, but nowhere close to "plug device in and it gets stable IPv4 address which is unlikely to ever change".

throw0101b 2y ago
> You cannot explain difficulties in IPv6 adoption by need to rewrite in 2024. The difficulties encountered with IPv6 would have been the same even if another proposal would have been chosen for IPng because the exact same thing would have needed to be done: new address type for syscalls, new data structures, new surrounding infrastructure. When your original standards do not allow for address length changes/flexibility, you have to write a new standard with the new address size, and there's no way to stuff >32 bits of data (addresses) into a 32-bit field. IPng would always have been a breaking change, regardless of proposed candidate chosen. And if you're not going to have a flag day (à la NCP-IP changeover), then you'll need transition mechanisms with tunnels for sparse dispersal between IPng islands in a sea of IPv4. > And yes, maybe IPv7 in particular is not the best solution, but it's hard to imagine how it could be worse than IPv6.. 20 years since support has been added to all core software and it's _still_ not adopted by end users? All the proposals for IPng needed to have the same things done. "Technical Criteria for Choosing IP The Next Generation (IPng)": * https://datatracker.ietf.org/doc/html/rfc1726 https://datatracker.ietf.org/doc/html/rfc1726 New packet type/header, new API options, new records and data structures for DNS, transition mechanisms (tunnelling). All this needs to be rolled out to hosts, routers, firewalls, ASICs, etc. All the while IPv4 would continued to be used, so what incentive would business and IT departments have had to move to TUBA or TP/IX-CATNIP? ("Our (IPv4) network works, why do we need IPv7?") > Today, for home networks, IPv6 is even harder to manage than IPv4 was, just try to keep your small office LAN functioning while handling ISP address changes. Before recently moving ISPs (to go from DSL to GPON) I had IPv6 for several years on the old one and all my hosts (cabled, Wifi), phones, printers, etc, had IPv6 addresses given out by RA by my Asus, and I had no issues. In fact IPv6 worked "too well" for me at one point: a while ago I was web surfing I had all those little Facebook icons show up that were served from their web site, probably dropping cookies on my system. I didn't want that so I put FB's domain in my hosts(5) file so that it go to "0.0.0.0": the little icons went away. Then suddenly they appeared. And I checked hosts to make sure things were still there, and I did web browser debugging to see if things changed in the HTML. And then I remembered that my ISP had activated IPv6, and so the icons were coming from FB's IPv6 address. Once I added "::1" for FB in my hosts file the icons disappeared again. The IPX/SPX and DECnet folks managed to learn IPv4, so I'm not sure why the IPv4 folks have such a hard time with IPv6. IPv6 is no more difficult a Layer 3 protocol than IPv4.