5 ms·

I wish there were IP successor which would _only_ expand address space and not redo everything network-related. Increasing size of some structs and recompiling

by theamk 3y ago

I wish there were IP successor which would _only_ expand address space and not redo everything network-related. Increasing size of some structs and recompiling software is easy. Re-doing entire address allocation logic, address splitting, and network administration approach is much harder, as it affects millions of customized setups. Oh well, too late for this now. I guess this is the lesson for future network protocol designers: small, backwards-compatible changes will have much higher chances of working. And saying "you must drop old thing entirely and redo everything from scratch" means it'll take more than 30 years for your protocol to be deployed.

_a_a_a_ 3y ago
When you've invented something better you can also invent a time machine, take a trip back half a century and cause everything to be done the right way from the very start.
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...).
- 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.
Dagger2 3y ago
That's pretty much what v6 is. The other proposals were significantly different to v4, but v6 works almost exactly the same as v4 does. It's also backwards compatible with v4 in pretty much every way that you can be backwards compatible with v4. It's not v6's fault that v4 isn't forwards compatible with bigger address sizes. > Increasing size of some structs and recompiling software is easy This turns out to not be so easy. People are STILL writing new code with "struct sockaddr_in" allocations and "socket(AF_INET, ...)" and crap like that. That's the main thing blocking people from moving from dual stack to v6-only today.
- theamk 3y ago
  This could be true in 2000, but its 2023, all major software (and hardware) has IPv6 support. And yet my work's office and DC networks are IPv4 only and have no immediate plans for transition. Why? Some of the reasons: - IPv4 and IPv6 are treated as completely separate things. So tunnels, firewalls, etc.. need to be configured twice if you want both IPv4 and IPv6 support. Any IP-related settings or database fields must be duplicated. (Linux didn't help here with iptables6 being completely separate; neither did FreeBSD by prohibiting combined ipv4/ipv6 sockets). - Best practice in IPv4 is single internet-capable address per machine. Best practice in IPv6 is multiple internet-capable addresses per machine, and sometimes they also dynamically change. This means all the logic which assumes "machine's IP address" need to be rewritten. - Usual practice in IPv4 is NAT + private IP ranges, which completely hides internet provider's IP allocation. Usual practice is IPv6 is "leaking" ISP-provided data to every end station.. if you get a new ISP, you get to renumber all the device and change every hardcoded IP. - Address format is different - all the logic which touches IP address needs to be updated. And .split(":") is no longer going to cut it. ... etc.. there are tons of reasons which are not related to "struct sockaddr_in". (One interesting observation is at lot of it is "best practice" or "implementation details": technically IPv6 is flexible enough to operate in IPv4-like mode... In theory, one can build IPv6 network on fixed addresses allocated by DHCP that uses NAT for internet access, so that existing tooling is preserved. In practice, of course, attempting to create such monstrosity will get you laughed out of the meeting.)
  - allarm 3y ago

by theamk 3y ago

_a_a_a_ 3y ago

When you've invented something better you can also invent a time machine, take a trip back half a century and cause everything to be done the right way from the very start.

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

Dagger2 3y ago

That's pretty much what v6 is. The other proposals were significantly different to v4, but v6 works almost exactly the same as v4 does. It's also backwards compatible with v4 in pretty much every way that you can be backwards compatible with v4. It's not v6's fault that v4 isn't forwards compatible with bigger address sizes. > Increasing size of some structs and recompiling software is easy This turns out to not be so easy. People are STILL writing new code with "struct sockaddr_in" allocations and "socket(AF_INET, ...)" and crap like that. That's the main thing blocking people from moving from dual stack to v6-only today.

theamk 3y ago
This could be true in 2000, but its 2023, all major software (and hardware) has IPv6 support. And yet my work's office and DC networks are IPv4 only and have no immediate plans for transition. Why? Some of the reasons: - IPv4 and IPv6 are treated as completely separate things. So tunnels, firewalls, etc.. need to be configured twice if you want both IPv4 and IPv6 support. Any IP-related settings or database fields must be duplicated. (Linux didn't help here with iptables6 being completely separate; neither did FreeBSD by prohibiting combined ipv4/ipv6 sockets). - Best practice in IPv4 is single internet-capable address per machine. Best practice in IPv6 is multiple internet-capable addresses per machine, and sometimes they also dynamically change. This means all the logic which assumes "machine's IP address" need to be rewritten. - Usual practice in IPv4 is NAT + private IP ranges, which completely hides internet provider's IP allocation. Usual practice is IPv6 is "leaking" ISP-provided data to every end station.. if you get a new ISP, you get to renumber all the device and change every hardcoded IP. - Address format is different - all the logic which touches IP address needs to be updated. And .split(":") is no longer going to cut it. ... etc.. there are tons of reasons which are not related to "struct sockaddr_in". (One interesting observation is at lot of it is "best practice" or "implementation details": technically IPv6 is flexible enough to operate in IPv4-like mode... In theory, one can build IPv6 network on fixed addresses allocated by DHCP that uses NAT for internet access, so that existing tooling is preserved. In practice, of course, attempting to create such monstrosity will get you laughed out of the meeting.)
- allarm 3y ago