6 ms·

> One key reason for this uneven progress is the extension of IPv4’s lifespan through interim technologies like Network Address Translation (NAT) and IPv4 addre

by fargle 2y ago

> One key reason for this uneven progress is the extension of IPv4’s lifespan through interim technologies like Network Address Translation (NAT) and IPv4 address transfers. they completely ignore the actual problem with IPv6 which is that they didn't just extend IPv4 in a straightforward manner. they could have made the address fields 64 bits and been done with it. but, oh no, they had to make it the protocol for the ages. it's completely analogous to the failed Intel Itanium vs. AMD x64.

Dylan16807 2y ago
I've never seen anyone explain a "straightforward" way to extend the bits without having 90% of the same adoption difficulty. What's your idea, specifically? Also extension mechanisms like that already exist as part of ipv6.
- fargle 2y ago
  not have 128 bit addresses for one thing. 64 bits would have been fine. that was one of the biggest consternations that's a huge hit for small packets. so nat sucks. we needed to have something better. but instead of just extending to 64 bit src/dest addresses, align the fields and drop the checksum or any straightforward extension like that we got an entirely new protocol with new rules, nuances and complexity. so people just said nope. if it had been just a superset of IP with a different packet format and wider fields, it would have been adopted widely 20 years ago. this wasn't intended to be a contentious take, btw: i was genuinely surprised that the article was ignoring this take. it was a very common feeling in the late 90s and 2000s when IPv6 was coming out. "over-engineered"
  - Plasmoid 2y ago
    > What's your idea, specifically? This is the problem. Lots of arm-chair protocol engineers claim it'd be easy if 'They did X'. Of course, these immediately fall apart under the barest of scrutiny but they keep coming up. Here is your challenge. Create a way to add this address space extension in a way that doesn't break backwards compatibility. Remember, you need to be specific how you would add the change and how it would keep backwards compatibility.
    - fargle 2y ago
      > address space extension in a way that doesn't break backwards compatibility. i didn't say it wouldn't break backward compatibility - you're moving the goal posts. what i said was "a superset of IP with a different packet format and wider fields" > arm-chair protocol engineers don't be condescending. i've likely been designing protocols for longer than you think. > Remember, you need to be specific how you would add the change and how it would keep backwards compatibility. if all you had to do to deal with IPv6 was bigger addresses and a slightly different wire format, it wouldn't have had the barrier to adoption. don't design an entirely different protocol. the wire format is the least of the problems.
      - orangeboats 2y ago
        >if all you had to do to deal with IPv6 was bigger addresses and a slightly different wire format, This again. The biggest barrier to IPv6 adoption has always been a different wire format, it doesn't matter the degree of difference.
        magicalhippo 2y ago
        I'm just a casual homelab guy, but all my hardware now supports IPv6 but I'm not really using it precisely because it is just so different from IPv4. How you assign addresses is completely different. How you configure your firewall as a result is completely different. In fact software support for the latter was one of the things I struggled with for years before having to change router software from pfSense to OpenWRT. Last I checked pfSense still didn't have full support. They changed the way you write the addresses, using the port separator as group separator as well, leading to needing special software support for parsing IPv6 addresses. I know because I had to fix this in a few projects where we bothered to add IPv6 support, and that was the biggest PITA by far when adding IPv6 support, the rest was trivial. Out of all the trouble I've had with IPv6, the wire format was the least problematic by far. All the wire format did was cause it to take some time to get IPv6 capable hardware. But I've had that hardware for decades at this point. The thing keeping IPv6 back is all the other things they changed.
  - Dylan16807 2y ago
    A different address size is your main suggestion? Anything that isn't 32 is going to have the same problem. > if it had been just a superset of IP with a different packet format and wider fields It pretty much is... Changes like DHCP are not the deciding factor.
- ooterness 2y ago
  IPv6 changes far more than the address size. Why mandate the use of Neighbor Discovery Protocol instead of the much simpler ARP? Why change the rules for UDP checksums? The checksum field in UDP over IPv4 is optional. The checksum field in UDP over IPv6 is required. This is a major pain for protocols that change fields in transit, such as PTP. I could go on. There are important reasons for each of these decisions, but the fact is that every little change slows adoption. IETF could have stayed focused on solving address scarcity alone, but instead they chose to boil the ocean.
  - acdha 2y ago
    As you noted, there were important reasons for those changes – they even helpfully summarized them in a dedicated section of https://datatracker.ietf.org/doc/html/rfc4861#section-3.1 https://datatracker.ietf.org/doc/html/rfc4861#section-3.1; the checksum benefits are obvious – and none of them were major factors in the rollout delays. The single biggest factor was that changing the header format broke every decoder in existence, and it took a long time both to get all of that old hardware and software aged out of common use since there wasn’t a legal or financial compulsion to do so. Nobody delayed migration because they liked supporting ARP+ICMP more or critically depended on being able to half-ass the implementation of an obscure time sync protocol - if you don’t update checksums, lots of things will stop your traffic even in an IPv4-only world. The main reason was that everyone had to replace their network infrastructure, review firewall rules, etc. and early adopters were only rewarded with more pain. Given how painful that has been, I sympathize with the people who said we should go to 128-bits because we never want to repeat the process.
    - ooterness 2y ago
      As someone who has spent the last several years of my career implementing picosecond-precise time transfer using an "obscure time sync protocol", and holds a few patents in this field, kindly check your dismissive attitude. When you're working on an FPGA or an ASIC, everything about the UDP checksum is a total pain in the ass. It is entirely redundant with the MAC-layer checksum. The field comes before the contents it checks, and depends on the entirety of the message contents, which must be buffered in the meantime while 10+ Gbps of data continue to arrive. The logical thing to do is to disable it, which clients are explicitly required to accept under IPv4. There is no "half-assing" here, only a logical decision to avoid spending 16 kiB of precious SRAM on every network port. That is the reason why the product line in question doesn't support PTP over IPv6 and never will.
- rocqua 2y ago
  The issue isn't that the data sent over the wire changed too much. Instead, the semantics changed too much. Adopting IPv6 would ideally have been as simple as changing a socket definition and your address types. But so much of the semantics changed that it isn't that easy at all. It also prevented backwards capability.

by fargle 2y ago

Dylan16807 2y ago

I've never seen anyone explain a "straightforward" way to extend the bits without having 90% of the same adoption difficulty. What's your idea, specifically? Also extension mechanisms like that already exist as part of ipv6.

fargle 2y ago
not have 128 bit addresses for one thing. 64 bits would have been fine. that was one of the biggest consternations that's a huge hit for small packets. so nat sucks. we needed to have something better. but instead of just extending to 64 bit src/dest addresses, align the fields and drop the checksum or any straightforward extension like that we got an entirely new protocol with new rules, nuances and complexity. so people just said nope. if it had been just a superset of IP with a different packet format and wider fields, it would have been adopted widely 20 years ago. this wasn't intended to be a contentious take, btw: i was genuinely surprised that the article was ignoring this take. it was a very common feeling in the late 90s and 2000s when IPv6 was coming out. "over-engineered"
- Plasmoid 2y ago
  > What's your idea, specifically? This is the problem. Lots of arm-chair protocol engineers claim it'd be easy if 'They did X'. Of course, these immediately fall apart under the barest of scrutiny but they keep coming up. Here is your challenge. Create a way to add this address space extension in a way that doesn't break backwards compatibility. Remember, you need to be specific how you would add the change and how it would keep backwards compatibility.
  - fargle 2y ago
    > address space extension in a way that doesn't break backwards compatibility. i didn't say it wouldn't break backward compatibility - you're moving the goal posts. what i said was "a superset of IP with a different packet format and wider fields" > arm-chair protocol engineers don't be condescending. i've likely been designing protocols for longer than you think. > Remember, you need to be specific how you would add the change and how it would keep backwards compatibility. if all you had to do to deal with IPv6 was bigger addresses and a slightly different wire format, it wouldn't have had the barrier to adoption. don't design an entirely different protocol. the wire format is the least of the problems.
    - orangeboats 2y ago
      >if all you had to do to deal with IPv6 was bigger addresses and a slightly different wire format, This again. The biggest barrier to IPv6 adoption has always been a different wire format, it doesn't matter the degree of difference.
      - magicalhippo 2y ago
        I'm just a casual homelab guy, but all my hardware now supports IPv6 but I'm not really using it precisely because it is just so different from IPv4. How you assign addresses is completely different. How you configure your firewall as a result is completely different. In fact software support for the latter was one of the things I struggled with for years before having to change router software from pfSense to OpenWRT. Last I checked pfSense still didn't have full support. They changed the way you write the addresses, using the port separator as group separator as well, leading to needing special software support for parsing IPv6 addresses. I know because I had to fix this in a few projects where we bothered to add IPv6 support, and that was the biggest PITA by far when adding IPv6 support, the rest was trivial. Out of all the trouble I've had with IPv6, the wire format was the least problematic by far. All the wire format did was cause it to take some time to get IPv6 capable hardware. But I've had that hardware for decades at this point. The thing keeping IPv6 back is all the other things they changed.
- Dylan16807 2y ago
  A different address size is your main suggestion? Anything that isn't 32 is going to have the same problem. > if it had been just a superset of IP with a different packet format and wider fields It pretty much is... Changes like DHCP are not the deciding factor.
ooterness 2y ago
IPv6 changes far more than the address size. Why mandate the use of Neighbor Discovery Protocol instead of the much simpler ARP? Why change the rules for UDP checksums? The checksum field in UDP over IPv4 is optional. The checksum field in UDP over IPv6 is required. This is a major pain for protocols that change fields in transit, such as PTP. I could go on. There are important reasons for each of these decisions, but the fact is that every little change slows adoption. IETF could have stayed focused on solving address scarcity alone, but instead they chose to boil the ocean.
- acdha 2y ago
  As you noted, there were important reasons for those changes – they even helpfully summarized them in a dedicated section of https://datatracker.ietf.org/doc/html/rfc4861#section-3.1 https://datatracker.ietf.org/doc/html/rfc4861#section-3.1; the checksum benefits are obvious – and none of them were major factors in the rollout delays. The single biggest factor was that changing the header format broke every decoder in existence, and it took a long time both to get all of that old hardware and software aged out of common use since there wasn’t a legal or financial compulsion to do so. Nobody delayed migration because they liked supporting ARP+ICMP more or critically depended on being able to half-ass the implementation of an obscure time sync protocol - if you don’t update checksums, lots of things will stop your traffic even in an IPv4-only world. The main reason was that everyone had to replace their network infrastructure, review firewall rules, etc. and early adopters were only rewarded with more pain. Given how painful that has been, I sympathize with the people who said we should go to 128-bits because we never want to repeat the process.
  - ooterness 2y ago
    As someone who has spent the last several years of my career implementing picosecond-precise time transfer using an "obscure time sync protocol", and holds a few patents in this field, kindly check your dismissive attitude. When you're working on an FPGA or an ASIC, everything about the UDP checksum is a total pain in the ass. It is entirely redundant with the MAC-layer checksum. The field comes before the contents it checks, and depends on the entirety of the message contents, which must be buffered in the meantime while 10+ Gbps of data continue to arrive. The logical thing to do is to disable it, which clients are explicitly required to accept under IPv4. There is no "half-assing" here, only a logical decision to avoid spending 16 kiB of precious SRAM on every network port. That is the reason why the product line in question doesn't support PTP over IPv6 and never will.
rocqua 2y ago
The issue isn't that the data sent over the wire changed too much. Instead, the semantics changed too much. Adopting IPv6 would ideally have been as simple as changing a socket definition and your address types. But so much of the semantics changed that it isn't that easy at all. It also prevented backwards capability.