3 ms·

IPv6 and Python 3 are case studies in How to Not Upgrade Something. They basically created entirely different products that provided a marginal immediate benef

IPv6 and Python 3 are case studies in How to Not Upgrade Something. They basically created entirely different products that provided a marginal immediate benefit to the users and then said "upgrade whenever you get around to it". They are both now in the 2nd decade of their upgrade cycle. PowerPC->Intel, Xbox/PlayStation emulation, x86 32-bit>64-bit, and Java are all technologies that had successful upgrade strategies that were centered around replacing the original product rather than indefinitely providing an alternative.

JohnFen 2y ago
I think this describes very well what's happened. I haven't moved my systems to IPv6, and have no current plans to do so, because it's a pretty major change (meaning a ton of hassle) that brings me no benefits that I care about. If/when IPv6 becomes mandatory to connect to the internet, I'll go to the trouble of shifting my systems.
throw0101a 2y ago
> IPv6 and Python 3 are case studies in How to Not Upgrade Something. There was no other way to do it with IPv6: IPv4 has 32-bits of address space and >32 was needed for more addresses. That 32-bits is hard-coded in data structures, APIs, and even DNS formats (e.g., A records). So regardless of anything else related to IPv6 (ARP vs ND), you would have still needed to release a bunch of code that had to be installed on every router, L3 switch, firewall, DNS server, and end device. It was also recognized that, given the size of the Internet even in the 1990s, that a flag day like was done for the NCP->IP transition would not be possible: 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. * https://datatracker.ietf.org/doc/html/rfc1726#section-5.5 https://datatracker.ietf.org/doc/html/rfc1726#section-5.5 So you were always going to have to have a 'rolling upgrade' to get a larger address space. You were always going to have translation systems. It was also recognized that the 'legacy' may never go away: 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. * Ibid
- ryandvm 2y ago
  I won't be so brazen as to suggest I could have done any better, but the claim that never actually completing the upgrade was the only way is a bit too hand wavy I think.
  - throw0101a 2y ago
    > […] but the claim that never actually completing the upgrade was the only way is a bit too hand wavy I think. Is it accurate to think of it as an "upgrade" versus "addition"? It's not like HTTP 1.1 went away just because HTTP 3/QUIC came around. HTTP 3 may have certain useful features, but lots of folks do need/care about them and so may never activate it (at least on purpose, unless Apache/Nginx have them default-on). This thinking may not add much burden to the rest of the Internet for that protocol. Whereas not supporting IPv6 can add burdens to others: > Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic. > We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices. * 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... * Discussion: https://news.ycombinator.com/item?id=35047624 https://news.ycombinator.com/item?id=35047624 Getting people to follow new standards and follow best practices can be more difficult than herding cats.

JohnFen 2y ago

I think this describes very well what's happened. I haven't moved my systems to IPv6, and have no current plans to do so, because it's a pretty major change (meaning a ton of hassle) that brings me no benefits that I care about. If/when IPv6 becomes mandatory to connect to the internet, I'll go to the trouble of shifting my systems.

throw0101a 2y ago

> IPv6 and Python 3 are case studies in How to Not Upgrade Something. There was no other way to do it with IPv6: IPv4 has 32-bits of address space and >32 was needed for more addresses. That 32-bits is hard-coded in data structures, APIs, and even DNS formats (e.g., A records). So regardless of anything else related to IPv6 (ARP vs ND), you would have still needed to release a bunch of code that had to be installed on every router, L3 switch, firewall, DNS server, and end device. It was also recognized that, given the size of the Internet even in the 1990s, that a flag day like was done for the NCP->IP transition would not be possible: 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. * https://datatracker.ietf.org/doc/html/rfc1726#section-5.5 https://datatracker.ietf.org/doc/html/rfc1726#section-5.5 So you were always going to have to have a 'rolling upgrade' to get a larger address space. You were always going to have translation systems. It was also recognized that the 'legacy' may never go away: 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. * Ibid

ryandvm 2y ago
I won't be so brazen as to suggest I could have done any better, but the claim that never actually completing the upgrade was the only way is a bit too hand wavy I think.
- throw0101a 2y ago
  > […] but the claim that never actually completing the upgrade was the only way is a bit too hand wavy I think. Is it accurate to think of it as an "upgrade" versus "addition"? It's not like HTTP 1.1 went away just because HTTP 3/QUIC came around. HTTP 3 may have certain useful features, but lots of folks do need/care about them and so may never activate it (at least on purpose, unless Apache/Nginx have them default-on). This thinking may not add much burden to the rest of the Internet for that protocol. Whereas not supporting IPv6 can add burdens to others: > Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic. > We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices. * 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... * Discussion: https://news.ycombinator.com/item?id=35047624 https://news.ycombinator.com/item?id=35047624 Getting people to follow new standards and follow best practices can be more difficult than herding cats.