alt Hacker NewsWhat problem is this actually solving? I've deployed DHCP countless times in all sorts of environments and its "statefulness" was never an issue. Heck, even with SLAAC there's now DAD making it mildly stateful.
Don't get me wrong, SLAAC also works fine, but is it solving anything important enough to justify sacrificing 64 entire address bits for?
Replies
SEND secures NDP by putting a public key into those 64 bits, and also having big sparse networks renders network scanning rather useless at finding vulnerable hosts, so there are reasons to make subnets /64 other than SLAAC.
Also we can always reduce the standard subnet size in 4000::/3 if we ever somehow run out of space in 2000::/3 (and if we don't then we didn't sacrifice anything to use /64s).
DHCP requires explicit configuration; it needs a range that hopefully doesn't conflict with any VPN you use; it needs changes if your range ever gets too small; and it's just another moving part really.
With SLAAC, it's just another implementation detail of the protocol that you usually don't have to even think about, because it just works. That is a clear benefit to me.
* privacy addresses are great
* deriving additional addresses for specific functions is great (e.g. XLAT464/CLAT)
* you don't get collisions when you lose your DHCP lease database
* as Brian says, DHCP wasn't quite there yet when IPv6 was designed
* ability to proactively change things by sending different RAs (e.g. router or prefix failover, though these don't work as well as one would hope)
* ability to encode mnemonic information into those 64 bits (when configuring addresses statically)
* optimization for the routing layers in assuming prefixes mostly won't be longer than /64
… and probably 20 others that don't come to mind immediately. I didn't even spend seconds thinking about the ones I listed here.