3 ms·

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 (

by 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.

by growse 3y ago

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.