[muvlon]

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

[eqvinox]

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

[cbolton]

Privacy addresses... Isn't it silly to talk of privacy if the prefix doesn't change?

[ButlerianJihad]

Absolutely schizo.

"I wish to participate in a global telecommunications network and I wish to connect immediately to all my friends and be available to them 24/7 and I wish to play games with strangers across the country and I wish to receive all my email within 300ms with no spam and I wish to watch the latest news from Iran in 4K streaming Dolby"... but priiiiivacy!

[Dagger2]

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

[9dev]

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.

[j16sdiz]

When it fail, you find there is no option to tune its behaviour.

Plug in a rough router and see quickly you can find it.

[9dev]

What kind of failure are you referring to? What would you want to tune? You can still easily locate all devices on your network.