3 ms·

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

by 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.
      - Plasmoid 2y ago
        > 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. OMFG! The hardest part of supporting IPv6 was fixing your address parsing? THAT!? Here's my frustration. Everyone who doesn't understand the why of IPv6 always complains that the address format is such a huge problem and that is why the IPv6 deployment is so slow and hard. It's basically a shibboleth for poor understanding. The reason why this isn't a good take is that IP address parsing is a standard function of every standard library on the planet. You dump in a string and they all figure it out, and spit back an object with everything you need. The reason you had so much trouble with supporting it is that you weren't using the platform libraries. You hacked together some junk, probably a few broken regex's and string concatenation. Your homebrew IP library was broken and I guarantee you didn't handle all the IPv4 parsing rules correctly.
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.

by fargle 2y ago

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.
    - Plasmoid 2y ago
      > 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. OMFG! The hardest part of supporting IPv6 was fixing your address parsing? THAT!? Here's my frustration. Everyone who doesn't understand the why of IPv6 always complains that the address format is such a huge problem and that is why the IPv6 deployment is so slow and hard. It's basically a shibboleth for poor understanding. The reason why this isn't a good take is that IP address parsing is a standard function of every standard library on the planet. You dump in a string and they all figure it out, and spit back an object with everything you need. The reason you had so much trouble with supporting it is that you weren't using the platform libraries. You hacked together some junk, probably a few broken regex's and string concatenation. Your homebrew IP library was broken and I guarantee you didn't handle all the IPv4 parsing rules correctly.

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.