I want to do something a little bit different. Never before have I mulled over a situation for so long, incurring so many rewrites/rehashes as I have over this topic, namely IPv6's rollout and how SLAAC misses the boat on a crucial use case. I'm going to use the opportunity to nevertheless state it as quickly as possible, subsequently filling in info later on. The situation is basically that SLAAC misses how network edge operators favor address ranges which are static, singly-homed and centrally controlled MORE than they favor that said endpoints be publicly reachable. That is it, the most succinct, terse forumation for the problem with IPv6 migration, a migration which is by no means endeared though it should be. Its something that we should all be jumping on but rather due to the fact that SLAAC, the uncle that no one asked to come along for the migration, is here, and the options and RFCs are numerous, stagnation ensues. Its why ultimately DHCPv6+NATv6 will eventually come to the rescue as it is the only way to address theese network operator's use cases. One cannot ensure network space will never change (at the edge) for machines which are not on ARIN allocations. This couldn't be more true for last-mile ISP allocated ranges, and if any annecdotes are to be believed, end users will routinely see thier prefixes (and thusly thier entire network) change just as often as thier IPv4 singletons, because despite ISPs not needing to do so they have no financial obligation to ensure it remain static. Its as if one of the cornerstones of IP networking (which has materialized behind NAT for decades) was thrown away, as if nobobdy needed it. But hey, there are now way more public addresses.

So here we are at the juncture, something which we've grown near and dear to has run its course, and the replacement will exceed our expectations in terms of expandability. Yet, part of the way its being offered (by default) misses the exact way in which we've come to depend on our network to operate. Oh, and what's this? No NAT needed you say? Sounds too good to be true. Well, we'd like our addresses to stay put thank you very much. No, multihoming is not a reasonable solution, yes we're aware of RFC6724, and we'll be giddy someday when THAT'll introduce the next security event! The single greatest way to minimize unanticipated network interactions is via a SINGLE, unchanging address. Despite the work put into said RFC, which will make its way to getaddrinfo(), you can't beat an algorithm which can only choose ONE source address. Its pretty hard to fail there. In the meantime, source address selection will have no less than 8 rules which must be assesed before connection initialization. Again, its not that theese are inherently incapable of delivering deterministic results, rather its from the viewpoint of an experienced developer who has seen the myriad ways in which large systems grow over time, caches are introduced, best practices are skirted, even publicly well-known ways of initializing something are ignored. Its hard for me to trust such moons won't align to cause interesting and totally unforseen failure modes which wouldn't even be considered on a singly-homed system. This isn't even taking into account the ways I've seen IPv4 multihoming act up, albeit without such logic as described in the RFC.

Now, I can already hear the retorts as to what people should expect to happen when you don't read the docs, or that no one is stopping us from using DHCPv6+NATv6 for the singly-homed approach. The main problem I have is that in a sea of vendors and interaction points, some may and even have choosen to implement IPv6-SLAAC and call it done. THIS is the problem, and IT is the largest impediment which hinders moving forward. The standard must contain both methods and furthermore if need arises to only allow one I'd opt for the one which is most functioanlly similar to what we have already, that being DHCPv6+NATv6.

Pushing SLAAC as the only way forward (sans NAT) for IPv6 is, in effect shortsighted. It is illustrative of a humanistic tendancy wherein anything run by humans which becomes more widely proliferated incurrs schisms when common elements are endeared by subgroups for different reasons. Things which we had no idea our neighbor loved about our commonalities cause strife when one group decides to change said elements, and so too with technology and protocols. The severe lack of advocacy for edge network admins will only be detrimental in the end and as it stands even at the time of this writing it is just those kinds of networks which adoption lags on.