5 ms·

It's impossible to implement a backwards-compatible successor to IP without breaking the principle that every node can address other node. Old nodes will have

by growse 3y ago

It's impossible to implement a backwards-compatible successor to IP without breaking the principle that every node can address other node. Old nodes will have no idea how to address "new" ones, and if you want actual communication to happen, then addressability needs to function in both directions. (You've also glossed over the fact that so much hardware assumed that an IP address was an int32. Swapping that out was always going to take a long time).

ok123456 3y ago
If it was just a simple expansion you could have had a deadline for a switch over date. For example, on 1999-1-1 00:00:0.000Z stop using 32 bit address, and roll over to a 64 bit address. This is what happened when the internet switched from NCP to TCP. But, since it's not just a simple expansion of the address space and it fundamentally does things differently, this is impossible. And we've been stuck in limbo for about 28 years now.
- growse 3y ago
  Things that break when you do "just a simple expansion" of the address length because they assume a 32 bit address: * ARP (goodbye all your switches) * DHCP (goodbye all your CPE routers) * DNS (A records don't work any more) * BGP (goodbye internet backbone routers) * ICMP (good luck without this) * etc. It is impossible to change the length of the address without fundamentally changing how the internet works.
  - theamk 3y ago
    It has been more almost 30 years now, multiple generations of devices (and OS'es) have happened. If the only problem was low-level network stack support, it would have been fixed. There is nothing impossible about designing compatible system, if the compatibility is your goal. Let's think about "simple address expansion" - there is a "IP-long" ethertype which is used with IP addresses longer than 32 bits; and all code is structured such that if IP address fits in 32 bits, then old IPv4 packets are used. All apps are hardcoded to use a single address family (IP-long), but as if you are running in IPv4-compat mode, only last 32 bits of address would be nonzero. ARP has PTYPE field, and arbitrary address length already. It could have worked with "IP-long" schema with minor changes (for example to send parallel requests for compatibility). We could have IP-long capable devices operating in IPv4 compat mode for years.. until one day the assigned address changes to be longer than 32 bits and now the new protocol is in effect. Since majority of kernel code would be the same for IPv4 and IP-long packets, there was a good chance it would "just work". Sadly, this cannot happen with IPv6, because they made an explicit decision to break compatibility, and so they got rid if ARP. Note there was nothing "fundamental" that required they did so, they just didn't like it. For DHCP, we could have an all-new option, "client supports IP-long". Old DCHP servers would ignore it and return regular IPv4 address. New DHCP servers would return IP-long allocation to supported clients, and could optionally return "compat" record to IPv4-only clients (possibly with packet-translating gateway). We could have a network where you can mix and match clients, and enabling longer address would be as simple as creating a new private IP pool in the DHCP config with longer IP addresses. Sadly, this cannot happen with IPv6, because they made an explicit decision to break compatibility, and so they made a different IP allocation mechanism. And also NATs are heavily deprecated so "create a new private IP pool" makes no sense either. Note there was nothing "fundamental" that required new addressing mechanism, IPv6 designers just wanted to start from scratch. DNS actually works pretty well, obviously you'd want another record type for IP-long addresses but adding new record type is a known process. The only reason DNS is hard under IPv6 is because of "happy eyeballs" and all the non-working IPv6 deployments. ICMP could use the same treatment as ARP, that is has IPv4-comaptible versions and "long" versions for long addresses. We could have a single ICMP stack in the kernel and all the tools, with the only long-aware changes being in network packet decoding code. Sadly, this cannot happen with IPv6, because they made an explicit decision to break compatibility, and so they stuffed all sorts of things into ICMP protocol (ARP, IGMP, etc...).
    - allarm 3y ago
      I mean it’s all probably true, but how would it be easier to migrate to long ipv4 than to ipv6? Looks like there’s basically the same struggle, no? I think the major part of the migration problem is the global routing - the new protocol should be implemented in hardware, in ASICs and route processors. The LAN part of the migration is likely the easiest. And if it’s true, breaking compatibility and introducing a completely different protocol was probably well justified. IPv6 solves some other problems aside of the address space exhaustion - see SLAAC, easier route summarization, simplified packet header. That would not have been resolved by simply increasing the address space for v4.
      - theamk 3y ago
        Is global routing really the problem in 2023? Anecdotally, its the end user's service which is hardest to migrate, and specifically all If end user wants IPv6 in the office, but their ISP does not support it, enable HE (or some other one) tunnel on router and you done, here is a few dozens more IPv6 hosts generating traffic and increasing IPv6 fraction. If ISP wants everyone to use IPv6, but end users do not support it... well, ISP can do whatever but the traffic should eventually emerge as IPv4 and there would be no forward motion. I know a few places which still use IPv4 and have no plans for IPv6 -- my work's DC network, my work's office network, my home network, etc.. The reason they are are still on IPv4 have nothing to do with global routing or hardware support (everything is on a fairly new software), but rather all the unrelated changes IPv6 has bundled with longer addressees such as SLAAC. Do you know of any networks which are still on IPv4? What is their sysadmin's motivation?
        allarm 3y ago
        > Is global routing really the problem in 2023? I don't think so, why? I was talking about migrating from v4 on the day 0, when every single ip-speaking device used v4 only. My point was that on day 0 the main problem was global routing, because the new protocol should have got hardware support and all the network equipment should have been replaced. Local networks migration is much easier to do. > Do you know of any networks which are still on IPv4? I managed networks for around 15 years, up until 2018 and I've never managed an IPv6 network in my whole career. My current company (a well-known company from SF) runs v4 only network. I think the question should be different: what is the motivation for sysadmins and the business to migrate to v6, if v4 runs perfectly fine? And the answer is - there's basically none.
theamk 3y ago
Re hardware: Maybe it was the case in 2000, but how all virtually all hardware have a capability to support IPv6. Even $3 ESP32 microcontrollers do so. They just don't enable that capability.. why? see below. Re backwards-compatible: we have no problems upgrading other protocols (like TLS or SSH) while keeping some amount of backward compatibility. The procedure is known: (1) create software which talks both old and new versions, auto-selecting right one (2) start deploying, initially in compatibility mode (3) once a very high fraction of devices are upgraded, start cutting off old versions. IPv6 could have been the same. Make it use IPv4-like IP address formatting, and change network stack to emit IPv4 packets for ::ffff: addresses - this'd allow changing application software painlessly: the packets are IPv4 on the wire, but apps already use IPv6 code. Next, recommend that every router has some sort of SIIT translator by default: now you can mix and match IPv4 and IPv6 devices on same network (the performance might suffer but at least things work). Eventually you could go full IPv6, and then finally drop that NAT in the router. But no. One of the large goals of IPv6 was to "simplify everything" so such solutions would be unacceptable. Everything that could be used to ease IPv4 transition was extra complexity, so this information is hidden and left for special circumstances only. IPv6 is a shining example what happens when people want to design nice, clean system without backwards compatibility. Take your post for example -- you are outright saying "it is impossible [...] without breaking the principle that every node can address other node." and it is correct.. but how often do you have full node-to-node communication? Things like NAT64 can help you transition, but try finding it in a beginners example.
- growse 3y ago
  > Re backwards-compatible: we have no problems upgrading other protocols (like TLS or SSH) while keeping some amount of backward compatibility. The procedure is known: (1) create software which talks both old and new versions, auto-selecting right one (2) start deploying, initially in compatibility mode (3) once a very high fraction of devices are upgraded, start cutting off old versions. The IP stack is nothing like TLS or SSH. Besides, step (2) in what you're describing is what we have today, and is called dual-stack. Pretty much all software today can communicate on sockets with v4 or v6 addressing, and the vast majority doesn't actually care. > Next, recommend that every router has some sort of SIIT translator by default ... "Simply draw the rest of the owl". I have a sibling comment where I explain why it's not as simple as just "translating the packets in the router". You need a solution to how most of the protocols that underpin the internet are going to work (ARP, DNS etc.) because they historically were all very tightly coupled to IPv4. > But no. One of the large goals of IPv6 was to "simplify everything" so such solutions would be unacceptable. Everything that could be used to ease IPv4 transition was extra complexity, so this information is hidden and left for special circumstances only. IPv6 is a shining example what happens when people want to design nice, clean system without backwards compatibility. Simplifying things is a laudable goal. If you're designing a replacement for something, once you realise that backwards compatibility is impossible, then you then have an opportunity to fix some things to make them better (e.g. neighbour discovery, routing). IPv6 is not perfect by any means, but given the enormous task, complexity and competing constraints, I think they did an ok job. Pace of adoption is entirely an economic issue, not a technological one. There's no change without incentive: the carrot was never particularly big and until recently the stick was non-existent. > but how often do you have full node-to-node communication? Things like NAT64 can help you transition, but try finding it in a beginners example. I use full node-to-node communication every day. It's the bedrock on which the internet functions. Also, I managed to get NAT64 working by fiddling with my DNS server (unbound) and installing jool on my router. Took me about half an hour.

by growse 3y ago

ok123456 3y ago

If it was just a simple expansion you could have had a deadline for a switch over date. For example, on 1999-1-1 00:00:0.000Z stop using 32 bit address, and roll over to a 64 bit address. This is what happened when the internet switched from NCP to TCP. But, since it's not just a simple expansion of the address space and it fundamentally does things differently, this is impossible. And we've been stuck in limbo for about 28 years now.

growse 3y ago
Things that break when you do "just a simple expansion" of the address length because they assume a 32 bit address: * ARP (goodbye all your switches) * DHCP (goodbye all your CPE routers) * DNS (A records don't work any more) * BGP (goodbye internet backbone routers) * ICMP (good luck without this) * etc. It is impossible to change the length of the address without fundamentally changing how the internet works.
- theamk 3y ago
  It has been more almost 30 years now, multiple generations of devices (and OS'es) have happened. If the only problem was low-level network stack support, it would have been fixed. There is nothing impossible about designing compatible system, if the compatibility is your goal. Let's think about "simple address expansion" - there is a "IP-long" ethertype which is used with IP addresses longer than 32 bits; and all code is structured such that if IP address fits in 32 bits, then old IPv4 packets are used. All apps are hardcoded to use a single address family (IP-long), but as if you are running in IPv4-compat mode, only last 32 bits of address would be nonzero. ARP has PTYPE field, and arbitrary address length already. It could have worked with "IP-long" schema with minor changes (for example to send parallel requests for compatibility). We could have IP-long capable devices operating in IPv4 compat mode for years.. until one day the assigned address changes to be longer than 32 bits and now the new protocol is in effect. Since majority of kernel code would be the same for IPv4 and IP-long packets, there was a good chance it would "just work". Sadly, this cannot happen with IPv6, because they made an explicit decision to break compatibility, and so they got rid if ARP. Note there was nothing "fundamental" that required they did so, they just didn't like it. For DHCP, we could have an all-new option, "client supports IP-long". Old DCHP servers would ignore it and return regular IPv4 address. New DHCP servers would return IP-long allocation to supported clients, and could optionally return "compat" record to IPv4-only clients (possibly with packet-translating gateway). We could have a network where you can mix and match clients, and enabling longer address would be as simple as creating a new private IP pool in the DHCP config with longer IP addresses. Sadly, this cannot happen with IPv6, because they made an explicit decision to break compatibility, and so they made a different IP allocation mechanism. And also NATs are heavily deprecated so "create a new private IP pool" makes no sense either. Note there was nothing "fundamental" that required new addressing mechanism, IPv6 designers just wanted to start from scratch. DNS actually works pretty well, obviously you'd want another record type for IP-long addresses but adding new record type is a known process. The only reason DNS is hard under IPv6 is because of "happy eyeballs" and all the non-working IPv6 deployments. ICMP could use the same treatment as ARP, that is has IPv4-comaptible versions and "long" versions for long addresses. We could have a single ICMP stack in the kernel and all the tools, with the only long-aware changes being in network packet decoding code. Sadly, this cannot happen with IPv6, because they made an explicit decision to break compatibility, and so they stuffed all sorts of things into ICMP protocol (ARP, IGMP, etc...).
  - allarm 3y ago
    I mean it’s all probably true, but how would it be easier to migrate to long ipv4 than to ipv6? Looks like there’s basically the same struggle, no? I think the major part of the migration problem is the global routing - the new protocol should be implemented in hardware, in ASICs and route processors. The LAN part of the migration is likely the easiest. And if it’s true, breaking compatibility and introducing a completely different protocol was probably well justified. IPv6 solves some other problems aside of the address space exhaustion - see SLAAC, easier route summarization, simplified packet header. That would not have been resolved by simply increasing the address space for v4.
    - theamk 3y ago
      Is global routing really the problem in 2023? Anecdotally, its the end user's service which is hardest to migrate, and specifically all If end user wants IPv6 in the office, but their ISP does not support it, enable HE (or some other one) tunnel on router and you done, here is a few dozens more IPv6 hosts generating traffic and increasing IPv6 fraction. If ISP wants everyone to use IPv6, but end users do not support it... well, ISP can do whatever but the traffic should eventually emerge as IPv4 and there would be no forward motion. I know a few places which still use IPv4 and have no plans for IPv6 -- my work's DC network, my work's office network, my home network, etc.. The reason they are are still on IPv4 have nothing to do with global routing or hardware support (everything is on a fairly new software), but rather all the unrelated changes IPv6 has bundled with longer addressees such as SLAAC. Do you know of any networks which are still on IPv4? What is their sysadmin's motivation?
      - allarm 3y ago
        > Is global routing really the problem in 2023? I don't think so, why? I was talking about migrating from v4 on the day 0, when every single ip-speaking device used v4 only. My point was that on day 0 the main problem was global routing, because the new protocol should have got hardware support and all the network equipment should have been replaced. Local networks migration is much easier to do. > Do you know of any networks which are still on IPv4? I managed networks for around 15 years, up until 2018 and I've never managed an IPv6 network in my whole career. My current company (a well-known company from SF) runs v4 only network. I think the question should be different: what is the motivation for sysadmins and the business to migrate to v6, if v4 runs perfectly fine? And the answer is - there's basically none.

theamk 3y ago

Re hardware: Maybe it was the case in 2000, but how all virtually all hardware have a capability to support IPv6. Even $3 ESP32 microcontrollers do so. They just don't enable that capability.. why? see below. Re backwards-compatible: we have no problems upgrading other protocols (like TLS or SSH) while keeping some amount of backward compatibility. The procedure is known: (1) create software which talks both old and new versions, auto-selecting right one (2) start deploying, initially in compatibility mode (3) once a very high fraction of devices are upgraded, start cutting off old versions. IPv6 could have been the same. Make it use IPv4-like IP address formatting, and change network stack to emit IPv4 packets for ::ffff: addresses - this'd allow changing application software painlessly: the packets are IPv4 on the wire, but apps already use IPv6 code. Next, recommend that every router has some sort of SIIT translator by default: now you can mix and match IPv4 and IPv6 devices on same network (the performance might suffer but at least things work). Eventually you could go full IPv6, and then finally drop that NAT in the router. But no. One of the large goals of IPv6 was to "simplify everything" so such solutions would be unacceptable. Everything that could be used to ease IPv4 transition was extra complexity, so this information is hidden and left for special circumstances only. IPv6 is a shining example what happens when people want to design nice, clean system without backwards compatibility. Take your post for example -- you are outright saying "it is impossible [...] without breaking the principle that every node can address other node." and it is correct.. but how often do you have full node-to-node communication? Things like NAT64 can help you transition, but try finding it in a beginners example.

growse 3y ago
> Re backwards-compatible: we have no problems upgrading other protocols (like TLS or SSH) while keeping some amount of backward compatibility. The procedure is known: (1) create software which talks both old and new versions, auto-selecting right one (2) start deploying, initially in compatibility mode (3) once a very high fraction of devices are upgraded, start cutting off old versions. The IP stack is nothing like TLS or SSH. Besides, step (2) in what you're describing is what we have today, and is called dual-stack. Pretty much all software today can communicate on sockets with v4 or v6 addressing, and the vast majority doesn't actually care. > Next, recommend that every router has some sort of SIIT translator by default ... "Simply draw the rest of the owl". I have a sibling comment where I explain why it's not as simple as just "translating the packets in the router". You need a solution to how most of the protocols that underpin the internet are going to work (ARP, DNS etc.) because they historically were all very tightly coupled to IPv4. > But no. One of the large goals of IPv6 was to "simplify everything" so such solutions would be unacceptable. Everything that could be used to ease IPv4 transition was extra complexity, so this information is hidden and left for special circumstances only. IPv6 is a shining example what happens when people want to design nice, clean system without backwards compatibility. Simplifying things is a laudable goal. If you're designing a replacement for something, once you realise that backwards compatibility is impossible, then you then have an opportunity to fix some things to make them better (e.g. neighbour discovery, routing). IPv6 is not perfect by any means, but given the enormous task, complexity and competing constraints, I think they did an ok job. Pace of adoption is entirely an economic issue, not a technological one. There's no change without incentive: the carrot was never particularly big and until recently the stick was non-existent. > but how often do you have full node-to-node communication? Things like NAT64 can help you transition, but try finding it in a beginners example. I use full node-to-node communication every day. It's the bedrock on which the internet functions. Also, I managed to get NAT64 working by fiddling with my DNS server (unbound) and installing jool on my router. Took me about half an hour.