4 ms·

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

by 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.
p_l 2y ago
Because even in 2000-2004, when people starting more seriously talking about adding IPv6 support, BSD Sockets stupid legacy of having every user deal with gory details of used protocol made people write new software using gethostbyname(3) and connect()/listen() calls that used hand-written IPv4 parsers and artisanal sockaddr structs. And there's a lot of software that never got corrected, that explodes when it reads an address that isn't IPv4 even if uses a more modern API. Meanwhile IPv4 was supposed to be sunsetted in 1990, had been actively pushed to be migrated off in 1990-1995, but the cost of updating software that used the popular BSD Sockets API, introduction of NAT to remove major pain point, and certain major client (read: government and military) giving waivers on upgrading deadlines to vendors[1] meant that nothing really moved. And everytime people try to push things forward, some big chunk of infrastructure becomes a blocker - like cloud providers[2] - or we get inundated with "why in 1995 they didn't decide to go with something backwards compatible?". Newsflash - it was impossible for BSD Sockets software to be forward-compatible. If your software was build with XTI or similar interface (like Plan9's dial(), which is present in Go), you got IPv6, IPv7, and IPv9 support back in 1996, along with X.25 and who knows what else. In fact, IPv9 aka TUBA was actually implemented in network hardware around 1992 - the original RFC pointed to experiments using nearly unmodified Sun and Cisco hardware. [1] US government finally learnt though, and if you're selling to them you now have to support v6 or wrap your product in a black-box that will handle v6. No deferrals for products/vendors. [2] I'd argue AWS, GCP and Azure had significantly hampered global IPv6 migration

by theamk 2y ago

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.

p_l 2y ago

Because even in 2000-2004, when people starting more seriously talking about adding IPv6 support, BSD Sockets stupid legacy of having every user deal with gory details of used protocol made people write new software using gethostbyname(3) and connect()/listen() calls that used hand-written IPv4 parsers and artisanal sockaddr structs. And there's a lot of software that never got corrected, that explodes when it reads an address that isn't IPv4 even if uses a more modern API. Meanwhile IPv4 was supposed to be sunsetted in 1990, had been actively pushed to be migrated off in 1990-1995, but the cost of updating software that used the popular BSD Sockets API, introduction of NAT to remove major pain point, and certain major client (read: government and military) giving waivers on upgrading deadlines to vendors[1] meant that nothing really moved. And everytime people try to push things forward, some big chunk of infrastructure becomes a blocker - like cloud providers[2] - or we get inundated with "why in 1995 they didn't decide to go with something backwards compatible?". Newsflash - it was impossible for BSD Sockets software to be forward-compatible. If your software was build with XTI or similar interface (like Plan9's dial(), which is present in Go), you got IPv6, IPv7, and IPv9 support back in 1996, along with X.25 and who knows what else. In fact, IPv9 aka TUBA was actually implemented in network hardware around 1992 - the original RFC pointed to experiments using nearly unmodified Sun and Cisco hardware. [1] US government finally learnt though, and if you're selling to them you now have to support v6 or wrap your product in a black-box that will handle v6. No deferrals for products/vendors. [2] I'd argue AWS, GCP and Azure had significantly hampered global IPv6 migration