Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Schrödinger's IPv6 Cat

labs.ripe.net

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Schrödinger's IPv6 Cat

#51

Post by acdha »

asynchronous wrote: post #43

Here’s the real reason we won’t move to IPv6: NAT is used as a security feature in IPv4. World isn’t willing to do the work to make that transition.

This talking point has been debunked since the 90s. Any device capable of doing NAT can perform the even easier task of filtering packets.

Even if you do decide to toss your router and connect directly to the internet it’s a lot less risky than it was in 1998 when Windows 95 didn’t have a firewall. I doubt IPv6 is going to make many people decide they want dumber gateway devices, however, since the cost differential hasn’t been meaningful for ages.

Re: Schrödinger's IPv6 Cat

#52

Post by ooterness »

acdha wrote: post #48
ooterness wrote: post #39

Earlier quoted context omitted.

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, bu…

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 t…

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.

Re: Schrödinger's IPv6 Cat

#53

Post by Dylan16807 »

ooterness wrote: post #52
acdha wrote: post #48

Earlier quoted context omitted.

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 t…

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 i…

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?

Re: Schrödinger's IPv6 Cat

#54

Post by Arnavion »

ironhaven wrote: post #49
UI_at_80x24 wrote: post #28

Quasi related; how does one find out if your ISP is using CGNAT? I'm rather lucky in that my ISP recently started offering IPv6 (and somehow my workstation appears to be using it by as the default), but none of the other PC's on my network do. (Win11 change perhaps?)

I don't know of any ISP that will give you a public ipv4 address for free. More interesting is windows 11 auto configuring ipv6. Does you pc have a public ipv6 address starting with 2:: or fe80:: link local address? Quick ipv6 crash course. Instead of DHCPv4 (there is DHCPv6 but it's optional) being required for address configuations, ipv6 uses somting called Stateless address Autoconfiguration (SLAAC). Normaly your…

>I don't know of any ISP that will give you a public ipv4 address for free.

There probably isn't an ISP that gives out *static* public IPv4 addresses for free, but any ISP that supports IPv4 without CGNAT will give out public IPv4 addresses by definition. The two I've used in the US (Frontier, now Ziply) certainly do.

Re: Schrödinger's IPv6 Cat

#55

Post by acdha »

ooterness wrote: post #52
acdha wrote: post #48

Earlier quoted context omitted.

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 t…

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 i…

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.

Re: Schrödinger's IPv6 Cat

#56

Post by ooterness »

Dylan16807 wrote: post #53
ooterness wrote: post #52

Earlier quoted context omitted.

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 i…

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?

It's very much "need" in this case. This was considered at length.

To be clear, we are talking about exotic custom hardware that has little in common with the average x86/x64 desktop.

For something like a 24-port 10 GbE switch, the platform might have a gigabyte of off-chip DRAM, but only a megabyte of on-chip SRAM. An ask of 16 kiB SRAM per port is 37% of that capacity, which is badly needed for other things.

The other complicating factor is that the PTP egress timestamp and update pipeline needs to be predictable down to the clock cycle, so DRAM isn't an option.

Most PTP packets are small, yes, but others have a lot of tags and metadata. They may also be tucked between other packets. To be fully compliant, we have to handle the worst case, which means a full-size buffer for a jumbo frame.

And yes, we did consider RFC1141 and RFC1624. We use those when we can, but unfortunately not possible in this case.

Say what you will about the rest of IPv6, but I am particularly salty about the UDP checksum requirement.

Re: Schrödinger's IPv6 Cat

#57

Post by rocqua »

Dylan16807 wrote: post #21
fargle wrote: post #14

> 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 th…

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.

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.

Re: Schrödinger's IPv6 Cat

#58

Post by ooterness »

acdha wrote: post #55
ooterness wrote: post #52

Earlier quoted context omitted.

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 i…

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 sou…

Data integrity is ensured by the MAC layer. Ethernet's CRC32 is substantially stronger than the weak and unnecessary 16-bit IP-checksum in the UDP header. It is also infinitely easier to calculate in hardware, because it is placed where it belongs (i.e., after the end of protected data).

I acknowledge that PTP is not that widespread, but this isoteric issue is emblematic of broader overreach with the IPv6 design. This decision is one of dozens (hundreds?) that are nice-to-have for many users, but catastrophically disruptive for others.

Such concerns are individually minor, but I assert that they collectively represent a significant barrier to adoption.

Re: Schrödinger's IPv6 Cat

#59

Post by Dylan16807 »

ooterness wrote: post #56
Dylan16807 wrote: post #53

Earlier quoted context omitted.

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?

It's very much "need" in this case. This was considered at length. To be clear, we are talking about exotic custom hardware that has little in common with the average x86/x64 desktop. For something like a 24-port 10 GbE switch, the platform might have a gigabyte of off-chip DRAM, but only a megabyte of on-chip SRAM. An ask of 16 kiB SRAM per port is 37% of that capacity, which is badly needed for other things. The ot…

> To be fully compliant, we have to handle the worst case, which means a full-size buffer for a jumbo frame.

Well, fully compliant except for IPv6. If you said no jumbo frames for PTP, or no jumbo frames for specifically IPv6 PTP, then the extra buffer for PTP checksums only needs 4% of your SRAM.

> They may also be tucked between other packets.

Does that matter? Let's say a particular PTP packet is 500 bytes. If there's a packet immediately after it, I would expect it to flow through the extra buffer like it's a 500 byte shift register.

Re: Schrödinger's IPv6 Cat

#60

Post by spystath »

meragrin_ wrote: post #47
asynchronous wrote: post #43

Here’s the real reason we won’t move to IPv6: NAT is used as a security feature in IPv4. World isn’t willing to do the work to make that transition.

Wrong. It's more about money. People who run ISPs have said they don't support IPv6 because they won't see any return on the cost. These ISPs use CGNAT and like to solve customer "issues" by selling them a static IP. They would sell far fewer static IPs and actually have to look into issues rather than dilly dally around a bit so the static IP "fixes" the issue. They like to blame issues on other nefarious customers…

In a lot of cases on a residential line you can't even pay for a public and/or static v4. The option simply doesn't exist. Many ISPs just force you to buy a "business" package for 3x the cost with a bunch of other features you may not need.
Post reply on HN