[throw0101b]

> SLACC is something that sounded good on paper but doesn't adequately capture the entire problem domain.

Good news! Nothing in SLACC (sic) prevents you from using DHCPv6.

But now, since we have SLAAC as well, you get auto-magic working with simple link-layer connectivity without having to bother with extra infrastructure. If you need extra functionality, you have the option (not necessity).

[cynicalkane]

Standard SLAAC only uses 64-bit prefixes. This is a problem if you want subnets and have an uncooperative ISP handing out 64-bit prefixes. Or maybe you have a /48 or /56 but want a nice readable hierarchy of subnets.

You don't even need 64 bits. IIRC with SLAAC you send NDP messages to the entire broadcast domain. So you need broadcast-domain-sized (i.e., small) device counts on every data-link-layer subnet. So why assign /64? But because some devices won't give up if SLAAC routers aren't there and and some mysteriously default to SLAAC when they shouldn't and in fact some devices only use it, now every bottom level subnet has to be /64. Blech.

This is just one of many IPv6 annoyances that don't even need to exist.

[zamadatix]

/64 is about a lot more than SLAAC, that's just one easily seen place it shows up. Even without SLAAC the /64iveness of IPv6 would still be there. End client subnets being /64 (with the exception of host routes and p2p networks) allow hardware route scaling to be roughly twice as high, allow network operators to never worry about what the client subnet size is (it's /64 and that's big enough for anything, if it's bigger it's an aggregate route, the address is always split in the half for routed part and client part), and allow various tricks like SLAAC assignment methods to work reliably. A /56 gives 256 subnets (and a /48 65,536), if a house needs more than that for hierarchy then something besides the base /64 is wonky.

Uncooperative ISPs will always exist. If the minimum size was /96 they'd hand that out instead of a /64. If there was no minimum size then they'd hand out a /124 or something equally as stupid. For all of the corporatize ISPs and well planned uses, starting at a /64 makes the rest of life easier.

It's the same logic, though often more accepted in this case, as the minimum advertiseable prefix on the internet being a /48. That also has nothing to do with how many theoretical end clients could fit in that and everything to do with what that actually means to equipment, scaling, and implementation planning.

[zamadatix]

The practical issues are unrelated to whether or not the two are mutually exclusive. In practice, the lack of RDNSS support from the get-go was quite the nuisance. Especially when combined with clients that refused to support the optional DHCPv6 method (e.g. Android/ChromeOS). Even with RDNSS, the feature set is quite limited compared to DHCPv6 but you may have to end up implementing both since there weren't enough incentives for all clients to go the extra mile and support it even if some of your other clients do.

Overall these days, beyond Google products, I think the ecosystem is in a healthy spot now and I think IPv6 chose the right path. It can still be a bit more hassle to manage in the enterprise space though and that's the one that needs to most convincing to migrate at this point.

[cyberax]

Can you guess which of the popular OSes doesn't support stateful DHCPv6?

Answer: Android.

This makes DHCPv6 pretty much useless in practice, when 30% of the clients simply can't use it.