31–40 of 74 posts
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?)
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?)
> NAT devices are detected by observing a difference in the expected and actual checksum of the UDP packet that is returned as the part of the Original Datagram in the ICMP Time Exceeded message. If they differ then it indicates that a NAT device has modified the packet. This happens because the NAT device must recalculate the UDP checksum after modifying the packet (i.e. translating the source port) and so the checksum in the UDP packet that is nested in the ICMP error may not, depending on the device, match the original checksum.
[1] https://github.com/fujiapple852/trippy/releases/tag/0.11.0
Earlier quoted context omitted.
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 p…
> 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 i…
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.
I work for a major open source network software company, we support IPv6 natively and in the past 2 years I've been asked about IPv6 by my customers exactly...zero times.
Earlier quoted context omitted.
> 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 i…
> 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…
This again. The biggest barrier to IPv6 adoption has always been a different wire format, it doesn't matter the degree of difference.
Earlier quoted context omitted.
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.
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 p…
> 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.
As usual with English, the British master it, and they have a term for bureaucratic friction: "The Blob"
Earlier quoted context omitted.
> There's nothing wrong with having RFC1918 addresses and globally-routable IPv6 addresses assigned to your VPC. It's a pretty backwards way to build your network. You pay all the costs and gain none of the benefits.
I'm afraid I don't follow. The way to express the design in a pure-IPv6 world would be that you use ULA addresses to reach the AWS services that you use and globally-routable addresses to reach the outside world. Given that the cost that we're avoiding paying with the mechanism I described in my previous post is the ongoing cost for globally-routable IPv4 addresses, I'm not sure what cost you're talking about paying.…
> 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.
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.
I work for a major open source network software company, we support IPv6 natively and in the past 2 years I've been asked about IPv6 by my customers exactly...zero times.
But granted, Sonic is favored by enthusiasts, so they likely have a higher share of customers caring about such technicalities. And even then the ratio of users actively asking for it may have been tiny.