undefined | Better HN

0 pointsooterness1y ago0 comments

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.

0 comments

acdha1y 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; 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.

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

acdha1y ago

First, I’m not saying that it’s obscure to be dismissive but simply recognizing that the number of people who need to have picosecond precision is not a significant factor in global IPv6 adoption.

Second, while it’s certainly true that having to buffer packets to calculate the checksum is more expensive that doesn’t mean that the best option is to ignore concerns about data integrity which was a far more frequent source of problems. If they hadn’t developed an encapsulation mechanism, using an alternate protocol like UDP-Lite would avoid the issue and anyone needing extremely high-precision already has to have tight enough control over their network to deploy it since they’d need to avoid having random middleboxes interfering with timing.

1 more reply

Dylan168071y ago

If you're running at 10Gbps and you don't spare the memory to buffer a single packet, that's desire not need.

Your expertise does not make you automatically right about every tradeoff.

Also why does on-the-fly editing for PTP packets in particular require your buffer to be bigger than a PTP packet? Aren't those small?

1 more reply

j / k navigate · click thread line to collapse

0 comments

acdha1y ago

ooternessOP1y ago

acdha1y ago

1 more reply

Dylan168071y ago

If you're running at 10Gbps and you don't spare the memory to buffer a single packet, that's desire not need.

Your expertise does not make you automatically right about every tradeoff.

Also why does on-the-fly editing for PTP packets in particular require your buffer to be bigger than a PTP packet? Aren't those small?

1 more reply

j / k navigate · click thread line to collapse