4 ms·
In many ways, IPv6 stacks are simpler than their IPv4 counterparts. The fixed packet headers are simpler and faster to parse, ICMPv6 includes both router and ne
by neilalexander 4y ago
In many ways, IPv6 stacks are simpler than their IPv4 counterparts. The fixed packet headers are simpler and faster to parse, ICMPv6 includes both router and neighbour solicitation (as opposed to being separate protocols like ARP in IPv4), routers generally won’t fragment large packets in transit (instead giving way to Path MTU Discovery) and NAT is not so widely needed as it is in IPv4.
That said, the fixed packet headers being slightly longer means there’s actually slightly less room for the payload in an IPv6 packet compared to IPv4 on an otherwise equivalent link MTU.
I’m not entirely sure what to make of the results in the article though and the title really should be leading with asking why in order to be less sensational. The only explanation I can think of right now is that many routers have historically deprioritised ICMP traffic or even dropped it when under heavy load, but given that ICMPv6 is much more core to the functioning of IPv6 in general, it is perhaps not as feasible to do so for ICMPv6.
- Genbox 4y ago> NAT is not so widely needed as it is in IPv4. If every device had a globally unique address, is there really a need for NAT?
- rescbr 4y agoYes, because not every entity is an ASN with their own allocation, nor their ISPs will announce their addresses on a residential service, for instance. I have to resort to NPTv6 in my setup, as my ISP allocates IPv6 prefixes dynamically, breaking down IPv6 routing when they have some issue and drop/change the prefixes previously allocated to me.
- nybble41 4y agoI'm not sure incompetence on the part of the ISP really translates into a need for NAT. It's a useful workaround, to be sure, but what you need here is an ISP that handles IPv6 prefixes properly. There is no reason for the prefix delegated to a customer to change, ever. They should just assign it statically when they create the account.
- adrianmonk 4y agoYou might not have exactly one ISP. Imagine you use an RV as a nomadic home office. You have a small LAN with a private server (file server, HTTP server for testing web sites, etc.), and you want that server to have a static IP. Since you might be on RV park WiFi at one moment, cell data at another, etc., you can't use a static IP from an ISP. But you can use the IPv6 private address range, and then you need NAT. (Technically I guess you could do without NAT if you gave every host on your LAN two addresses: a private address and a publicly-routable one. But that might be more cumbersome.)
- LargoLasskhyfv 4y agoMaybe have a look at http://he.net/ http://he.net/ and quick links on the right side...
- ArchOversight 4y ago> (Technically I guess you could do without NAT if you gave every host on your LAN two addresses: a private address and a publicly-routable one. But that might be more cumbersome.) Except that the IPv6 standard explicitly allows for two on-link prefixes for SLAAC. So in my home I have a ULA address range that is static, and all my devices get a SLAAC random IP from my ISP. If my prefix changes, that doesn't change my ULA prefix and all DNS records will continue to function. My ULA is also advertised over BGP using Wireguard, so its automatically routable from VPN when I am on the road but I still want to reach internal resources.
- craftkiller 4y ago> (Technically I guess you could do without NAT if you gave every host on your LAN two addresses: a private address and a publicly-routable one. But that might be more cumbersome.) For any IPv6 setup, you already have multiple addresses per host. You start with your mandatory link-local unicast address from the `fe80::/10` range and then you add a global address after getting a prefix from your router. I don't see how adding a third address, particularly a static one, would be cumbersome.
- toast0 4y ago
- craftkiller 4y agoNope! There's even an RFC that enumerates all the purposes for NAT and explains why they are no longer needed in IPv6: https://datatracker.ietf.org/doc/html/rfc4864 https://datatracker.ietf.org/doc/html/rfc4864