5 ms·

IPv6 and Python3 are case studies in how not to roll out a new version unless you're cool with multi-decade upgrade windows.

paulgb 3y ago
Is there an alternative, though? Both Python3 and IPv6 both solve problems that would have been at least as painful to do incrementally, IMHO.
- danpalmer 3y ago
  Agreed, while I recognise that both look bad, I'm skeptical as to how bad they actually are. Some comparisons against good examples of these sorts of transitions would be good.
- JoshTriplett 3y ago
  IPv6 provided some features people needed (larger addresses), made some changes born from experience (removing IP-level header checksums in favor of packet checksums like those in UDP and TCP, removing fragmentation), and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec). If IPv6 had left out the mandatory added complexity, and just focused on the larger addresses and cleanups, it would have been easier to adopt. The other changes could have happened via other standards, rather than bundling them all into "IPv6".
  - throw0101b 3y ago
    > […] and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec). SLAAC and RA reduce complexity as you no longer need 'extra' infrastructure (DHCP) to get going: plug in and the router sends the information and you're done. You also get rid of the complexity of STUN/ICE/etc as you no longer need NAT, so you just need hole punching for SPI firewall (also needed with NAT for port forwarding, so no change there).
    - marcinzm 3y ago
      Except you still need all that complexity as you need to support IPv4 as well.
      - betaby 3y ago
        There is NAT64 for that https://en.wikipedia.org/wiki/NAT64 https://en.wikipedia.org/wiki/NAT64 Many mobile operators use that, in USA that is Sprint/T-mobile, Bell in Canada. All modern OSes support that pretty well.
    - rescbr 3y ago
      Once you add up the real world factor of half-assed implementations and bad business/tech decisions, you end up with DHCP and NAT (or its IPv6 cousin, NPT) to solve issues.
    - JoshTriplett 3y ago
      > plug in and the router sends the information and you're done. If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server. (With added bonus "this could happen asynchronously at any time and you never reliably know when your network is actually done being configured".) If those standards are so valuable, they should have stood on their own, as optional things people could have adopted if they wanted to do things completely differently from IPv4. Meanwhile, people already have DHCP servers, and could have just told those DHCP servers to start giving out IPv6 addresses too. The reaction I have every time I interact with IPv6 is that it seems incredibly hard to make a system just use the configuration you tell it to use and never ever listen to any configuration from the network.
      - throw0101b 3y ago
        > If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server. I've had to fight with ip-helper issues and DHCP scopes enough times to not wish to have to deal with it if possible. I have to configure the router (or the VLAN on a Layer 3 switch) anyway, so a few extra lines for /64 scopes that are sent out via RAs on the same device I have to touch anyway is easier. > The reaction I have every time I interact with IPv6 is that it seems incredibly hard to make a system just use the configuration you tell it to use and never ever listen to any configuration from the network. On Debian with interfaces(5): auto eth0 iface eth0 inet6 static address 2001:db8:aaa:bbbb:cccc::dead:beef netmask 64 gateway 2001:db8:aaa:bbbb:cccc::1 accept_ra 0 For Netplan-based stuff, this looks similar: * https://github.com/canonical/netplan/blob/main/examples/direct_connect_gateway_ipv6.yaml https://github.com/canonical/netplan/blob/main/examples/dire... I recently had to switch ISPs to one that doesn't do IPv6 for FTTH (but their smart offerings are (AFAICT) IPv6-only), but my previous IPv6 did, and activating it for my home network was a couple clicks on my Asus router: all my devices (including a networked printer) picked it up without issue.
  - magicalhippo 3y ago
    Indeed. IPv6 is something very different from IPv4. And due to the large number of significant changes it's still a work in progress as a standard, with important RFCs coming out "as we speak"[1]. [1]: https://packetpushers.net/podcast/ipv6-buzz-134-revisiting-unique-local-addressing-at-the-ietf/ https://packetpushers.net/podcast/ipv6-buzz-134-revisiting-u...
  - hot_gril 3y ago
    Yes but you've left out the biggest and most disruptive change in v6: all pre-existing v4 addresses and routing are not carried over to it. This alone makes it a conceptually separate network from ipv4.
- gray_-_wolf 3y ago
  I think that if IPv6 would just be IPv4 with bigger addresses, the rollout would be much easier. Sure, you would still need new hardware, but the basic operations would still be the same as IPv4. Currently, it is far from that.
  - oarsinsync 3y ago
    Are there recommendations that result in IPv6 looking like something more than just IPv4 with bigger addresses? Yes. Is there anything stopping you from effectively running IPv6 networks the same way as you run IPv4 networks, but with larger address pools? No. You can do NAT66, you can do DHCPv6, you can run every network as a /120 (IPv6 equivalent of a /24 - 256 addresses) if you want to as well. You can even (outside of whatever prefix is delegated to you) only use numbers for the host addressing portion if you want to, and not bother with letters. Just because the recommendations and standards say you SHOULD do things a particular way, it doesn’t mean you MUST.
    - gray_-_wolf 3y ago
      Sure, I don't have to, but everything in the stack assumes I would run it in the recommended way. I gave up trying to setup my LAN to support IPv6 after I wasted more than 2 hours on convincing my router, and devices behind it, to somehow work with the /128 address I got from my ISP. Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it? No, there is not, everything is reachable on IPv4 anyway. This would not be a problem if it would be just bigger IPv4 and there still was NAT, DHCP and everything. But that is not the way you are expected to be doing IPv6...
      - oarsinsync 3y ago
        > Sure, I don't have to, but everything in the stack assumes I would run it in the recommended way. > This would not be a problem if it would be just bigger IPv4 and there still was NAT, DHCP and everything. Irony, I remember life before DHCP/NAT44 defaults, and having to struggle so much to do it myself. Mind, this was 1997, and IPv6 was already a defined standard, which then never got any traction because NAT44 ended up being “good enough” for most people who didn’t think about what they lost in the process. > Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it? There was a lot of value in me spending a lot of time and effort on setting up DHCP and NAT in my home environment in the 90s. Nobody else I knew thought it was worthwhile though, and thought I was insane. There was a lot of value in me spending a lot of time and effort on dual stacking my LAN too. I see a parallel here that’s amusing to me :-)
- throw0101b 3y ago
  > Is there an alternative, though? Certainly some people didn't like the changes of ND vs ARP and such, but once you're changing the address length, you have to alter the data structure on every bit of networking code, and any transition is going to be a slog. IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+. And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere. But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection. And of course as long as IPv4 works there's little inherent motivation to go to any kind of IPng. See "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993): * https://datatracker.ietf.org/doc/html/rfc1347 https://datatracker.ietf.org/doc/html/rfc1347
  - oneshtein 3y ago
    In practice, port number is used as part of address, or, VPN, with tagging, are used. We can make convention that top 4 bits of port number are part of the host address. It will increase number of available addresses by up to 16x. For example, we have router at 1.2.3.4/192.168.0.254, and 15 hosts behind it, then, by convention, we can access 192.168.0.1 from public internet as 1.2.3.4:32848 (port 32767+1+80), host 192.168.0.3 as 1.2.3.4:32849, and so on.
- devit 3y ago
  A much simpler and compatible solution would be to assign a single IPv4 address per AS and then use IP options to pass additional address bits to identify the specific host within the AS.
  - Dagger2 3y ago
    That wouldn't be simple or compatible, but also... v6 basically already has what you're suggesting here, except forget every AS: every single v4 address already has a /48 of v6 space tunnelled to it.
candiddevmike 3y ago
They're more a case study on institutional inertia and not providing a good justification for businesses to upgrade. Gotta sell the benefits. I think cloud providers charging for IPv4 is a great stick, since the initial carrots (easier subnetting, huge networks, multiple IPs per host, encryption, etc) didn't work. I do wish they provided NAT64 services though.
deleted 3y ago
[deleted]
noirscape 3y ago
At least with Python3, there was eventually Python 2.7 to permit a compatibility layer to move over. It took ages, but there was at least a "best effort" to help people write code that could be easily moved between 2 and 3. (In spite of apparent behavior from the Python developers at the time). IPv6's hard break with IPv4 means that the switchover likely won't happen anytime soon.
- cesarb 3y ago
  > At least with Python3, there was eventually Python 2.7 to permit a compatibility layer to move over. [...] IPv6's hard break with IPv4 means that the switchover likely won't happen anytime soon. There was no hard break. The same way you have compatibility layers between Python 3.x and Python 2.7, we have compatibility layers between IPv4 and IPv6. For instance, 6to4 meant that anyone with an IPv4 address automatically had an IPv6 network, and could talk to IPv6 hosts; I used it for a while, and it worked nicely. Another one was Teredo, which worked even if your IPv4 host was behind an IPv4 NAT. Nowadays, the preference is for newer transition mechanisms, like NAT64/DNS64 and 464XLAT. On the software side, IPv4-mapped IPv6 addresses allow software written for IPv6 to transparently use the host's IPv4 stack to connect to an IPv4 address; this last one is very similar to the preferred approach of writing Python 3 code and using a compatibility layer to make it run on Python 2.7.
- hot_gril 3y ago
  IMO they should've just conceded and added a `print` syntax to Py3 similar to Py2. Stupid as it sounds, that was often the only reason someone's script was Py2-only. That and the integer division should've stayed the same.

paulgb 3y ago

Is there an alternative, though? Both Python3 and IPv6 both solve problems that would have been at least as painful to do incrementally, IMHO.

danpalmer 3y ago
Agreed, while I recognise that both look bad, I'm skeptical as to how bad they actually are. Some comparisons against good examples of these sorts of transitions would be good.
JoshTriplett 3y ago
IPv6 provided some features people needed (larger addresses), made some changes born from experience (removing IP-level header checksums in favor of packet checksums like those in UDP and TCP, removing fragmentation), and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec). If IPv6 had left out the mandatory added complexity, and just focused on the larger addresses and cleanups, it would have been easier to adopt. The other changes could have happened via other standards, rather than bundling them all into "IPv6".
- throw0101b 3y ago
  > […] and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec). SLAAC and RA reduce complexity as you no longer need 'extra' infrastructure (DHCP) to get going: plug in and the router sends the information and you're done. You also get rid of the complexity of STUN/ICE/etc as you no longer need NAT, so you just need hole punching for SPI firewall (also needed with NAT for port forwarding, so no change there).
  - marcinzm 3y ago
    Except you still need all that complexity as you need to support IPv4 as well.
    - betaby 3y ago
      There is NAT64 for that https://en.wikipedia.org/wiki/NAT64 https://en.wikipedia.org/wiki/NAT64 Many mobile operators use that, in USA that is Sprint/T-mobile, Bell in Canada. All modern OSes support that pretty well.
  - rescbr 3y ago
    Once you add up the real world factor of half-assed implementations and bad business/tech decisions, you end up with DHCP and NAT (or its IPv6 cousin, NPT) to solve issues.
  - JoshTriplett 3y ago
    > plug in and the router sends the information and you're done. If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server. (With added bonus "this could happen asynchronously at any time and you never reliably know when your network is actually done being configured".) If those standards are so valuable, they should have stood on their own, as optional things people could have adopted if they wanted to do things completely differently from IPv4. Meanwhile, people already have DHCP servers, and could have just told those DHCP servers to start giving out IPv6 addresses too. The reaction I have every time I interact with IPv6 is that it seems incredibly hard to make a system just use the configuration you tell it to use and never ever listen to any configuration from the network.
    - throw0101b 3y ago
      > If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server. I've had to fight with ip-helper issues and DHCP scopes enough times to not wish to have to deal with it if possible. I have to configure the router (or the VLAN on a Layer 3 switch) anyway, so a few extra lines for /64 scopes that are sent out via RAs on the same device I have to touch anyway is easier. > The reaction I have every time I interact with IPv6 is that it seems incredibly hard to make a system just use the configuration you tell it to use and never ever listen to any configuration from the network. On Debian with interfaces(5): auto eth0 iface eth0 inet6 static address 2001:db8:aaa:bbbb:cccc::dead:beef netmask 64 gateway 2001:db8:aaa:bbbb:cccc::1 accept_ra 0 For Netplan-based stuff, this looks similar: * https://github.com/canonical/netplan/blob/main/examples/direct_connect_gateway_ipv6.yaml https://github.com/canonical/netplan/blob/main/examples/dire... I recently had to switch ISPs to one that doesn't do IPv6 for FTTH (but their smart offerings are (AFAICT) IPv6-only), but my previous IPv6 did, and activating it for my home network was a couple clicks on my Asus router: all my devices (including a networked printer) picked it up without issue.
- magicalhippo 3y ago
  Indeed. IPv6 is something very different from IPv4. And due to the large number of significant changes it's still a work in progress as a standard, with important RFCs coming out "as we speak"[1]. [1]: https://packetpushers.net/podcast/ipv6-buzz-134-revisiting-unique-local-addressing-at-the-ietf/ https://packetpushers.net/podcast/ipv6-buzz-134-revisiting-u...
- hot_gril 3y ago
  Yes but you've left out the biggest and most disruptive change in v6: all pre-existing v4 addresses and routing are not carried over to it. This alone makes it a conceptually separate network from ipv4.
gray_-_wolf 3y ago
I think that if IPv6 would just be IPv4 with bigger addresses, the rollout would be much easier. Sure, you would still need new hardware, but the basic operations would still be the same as IPv4. Currently, it is far from that.
- oarsinsync 3y ago
  Are there recommendations that result in IPv6 looking like something more than just IPv4 with bigger addresses? Yes. Is there anything stopping you from effectively running IPv6 networks the same way as you run IPv4 networks, but with larger address pools? No. You can do NAT66, you can do DHCPv6, you can run every network as a /120 (IPv6 equivalent of a /24 - 256 addresses) if you want to as well. You can even (outside of whatever prefix is delegated to you) only use numbers for the host addressing portion if you want to, and not bother with letters. Just because the recommendations and standards say you SHOULD do things a particular way, it doesn’t mean you MUST.
  - gray_-_wolf 3y ago
    Sure, I don't have to, but everything in the stack assumes I would run it in the recommended way. I gave up trying to setup my LAN to support IPv6 after I wasted more than 2 hours on convincing my router, and devices behind it, to somehow work with the /128 address I got from my ISP. Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it? No, there is not, everything is reachable on IPv4 anyway. This would not be a problem if it would be just bigger IPv4 and there still was NAT, DHCP and everything. But that is not the way you are expected to be doing IPv6...
    - oarsinsync 3y ago
      > Sure, I don't have to, but everything in the stack assumes I would run it in the recommended way. > This would not be a problem if it would be just bigger IPv4 and there still was NAT, DHCP and everything. Irony, I remember life before DHCP/NAT44 defaults, and having to struggle so much to do it myself. Mind, this was 1997, and IPv6 was already a defined standard, which then never got any traction because NAT44 ended up being “good enough” for most people who didn’t think about what they lost in the process. > Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it? There was a lot of value in me spending a lot of time and effort on setting up DHCP and NAT in my home environment in the 90s. Nobody else I knew thought it was worthwhile though, and thought I was insane. There was a lot of value in me spending a lot of time and effort on dual stacking my LAN too. I see a parallel here that’s amusing to me :-)
throw0101b 3y ago
> Is there an alternative, though? Certainly some people didn't like the changes of ND vs ARP and such, but once you're changing the address length, you have to alter the data structure on every bit of networking code, and any transition is going to be a slog. IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+. And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere. But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection. And of course as long as IPv4 works there's little inherent motivation to go to any kind of IPng. See "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993): * https://datatracker.ietf.org/doc/html/rfc1347 https://datatracker.ietf.org/doc/html/rfc1347
- oneshtein 3y ago
  In practice, port number is used as part of address, or, VPN, with tagging, are used. We can make convention that top 4 bits of port number are part of the host address. It will increase number of available addresses by up to 16x. For example, we have router at 1.2.3.4/192.168.0.254, and 15 hosts behind it, then, by convention, we can access 192.168.0.1 from public internet as 1.2.3.4:32848 (port 32767+1+80), host 192.168.0.3 as 1.2.3.4:32849, and so on.
devit 3y ago
A much simpler and compatible solution would be to assign a single IPv4 address per AS and then use IP options to pass additional address bits to identify the specific host within the AS.
- Dagger2 3y ago
  That wouldn't be simple or compatible, but also... v6 basically already has what you're suggesting here, except forget every AS: every single v4 address already has a /48 of v6 space tunnelled to it.

candiddevmike 3y ago

They're more a case study on institutional inertia and not providing a good justification for businesses to upgrade. Gotta sell the benefits. I think cloud providers charging for IPv4 is a great stick, since the initial carrots (easier subnetting, huge networks, multiple IPs per host, encryption, etc) didn't work. I do wish they provided NAT64 services though.

deleted 3y ago

[deleted]

noirscape 3y ago

At least with Python3, there was eventually Python 2.7 to permit a compatibility layer to move over. It took ages, but there was at least a "best effort" to help people write code that could be easily moved between 2 and 3. (In spite of apparent behavior from the Python developers at the time). IPv6's hard break with IPv4 means that the switchover likely won't happen anytime soon.

cesarb 3y ago
> At least with Python3, there was eventually Python 2.7 to permit a compatibility layer to move over. [...] IPv6's hard break with IPv4 means that the switchover likely won't happen anytime soon. There was no hard break. The same way you have compatibility layers between Python 3.x and Python 2.7, we have compatibility layers between IPv4 and IPv6. For instance, 6to4 meant that anyone with an IPv4 address automatically had an IPv6 network, and could talk to IPv6 hosts; I used it for a while, and it worked nicely. Another one was Teredo, which worked even if your IPv4 host was behind an IPv4 NAT. Nowadays, the preference is for newer transition mechanisms, like NAT64/DNS64 and 464XLAT. On the software side, IPv4-mapped IPv6 addresses allow software written for IPv6 to transparently use the host's IPv4 stack to connect to an IPv4 address; this last one is very similar to the preferred approach of writing Python 3 code and using a compatibility layer to make it run on Python 2.7.
hot_gril 3y ago
IMO they should've just conceded and added a `print` syntax to Py3 similar to Py2. Stupid as it sounds, that was often the only reason someone's script was Py2-only. That and the integer division should've stayed the same.