Comment by neilalexander | Hacker News Reader

Comment by neilalexander | Hacker News Reader

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.

> 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?

Yes, 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.

I'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.

You 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.)

Maybe have a look at http://he.net/ and quick links on the right side...

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

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

> but what you need here is an ISP that handles IPv6 prefixes properly

It's hard to get ISPs to do things properly in general; if it's for IPv6, it's even more difficult. I think the intent of IPv6 designers was for hosts to manage to be prefix fluid; you might set up ULAs for local traffic, and use whatever prefixes are advertised for non-local traffic. Of course, that's harder to do than to write an RFC about, so I can understand resorting to prefix translation to get things done in the way desired. Prefix translation has the potential to be stateless which is nice for resource management on the translation element, though.

> Prefix translation has the potential to be stateless which is nice for resource management on the translation element, though.

It really messes with protocols where you need to tell another host how to contact you, though, since you don't know your "real" IP address without asking some other server. This gets worse if there is more than one level of translation involved. You also need hacks like "hairpin NAT" (wastefully passing local traffic through the router) since local hosts trying to connect to the public IP of a local server don't realize that they can reach it directly via the ULA.

> … you might set up ULAs for local traffic, and use whatever prefixes are advertised for non-local traffic.

This is the way.

That sounds like a surveillance nightmare...

Nope! 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

Reply on news.ycombinator.com