Some hosts - very dumb ones or very old ones, probably
embedded stacks - may do SLAAC even with a prefix other than 64 bits!
Once a stack is broken, anything is possible, so I'm not sure you win
much here. Zig to avoid one dud, you'll have to zag to avoid thenext,
and before you know it your life is nothing but dodging. Take the high
ground instead.
Better to find and cure/replace/isolate broken hosts than break your
entire network just to accommodate them. If you start doing the "wrong
thing" to accommodate broken hosts, you will never find peace. Zig to
avoid one dud; you'll have to zag to avoid the next and before you know
it your life is nothing but dodging. Take the high ground instead.
Do the advertisements "right", advise sysadmins that hosts should not do
SLAAC, and (if you are really concerned about broken hosts) collect MAC
address information from your switches and do an automated test of
reachability on all SLAAC addresses. You can generate the addresses
yourself easily enough from the prefix and the MAC. None should be
reachable, and any that are - well, you now know where they are and can
take appropriate action.
And then block all SLAAC addresses at your routers or firewalls, that'll
larn 'em 
Regards, K.
Doesn't it tell you something that you're fighting this hard to avoid hosts from doing what comes naturally?
It occurs to me that I haven't met anyone who uses the term "SLAAC" who uses IPv6 in a way that I would consider normal. (Or at all.)
I respectfully disagree. In my opinion there is no future for IPv6
that doesn't involve DHCPv6. DHCPv6 is part of the design of IPv6 as
is clear by the existence of M, O, and A flags in RA.
Without DHCPv6, SLAAC has no way to provide DNS (or other)
configuration information, the fact that IPv6 was designed in a way
where SLAAC could be used for addressing and DHCPv6 for "other"
configuration is an example of how DHCPv6 is an integral component of
IPv6.
SLAAC was designed to make IPv6 work out of the box for ad-hoc
networks (link local scope for example). It's increasingly clear that
the designers never intended for SLAAC to "replace" DHCPv6 or that
DHCPv6 wasn't a necessary part of IPv6, especially once you deploy it
in an enterprise environment.
What we've seen is a community of early adopters who are so eager to
deploy IPv6 that they're willing to make compromises that most would
question.
I think we need to get into the mindset that any implementation of
IPv6 that doesn't include a DHCPv6 client is as incomplete as one that
doesn't support ICMPv6.
Support from vendors will eventually fall into place. If more of the
so-called advocates of IPv6 would stop talking about how DHCPv6 isn't
necessary it would likely happen more quickly.
Both SLAAC and DHCPv6 have their roles to fill; both are required.
As for the use of the term SLAAC... it's usage is pretty widespread.
Didn't RFC 4339 cover most of this?
http://tools.ietf.org/html/rfc4339
> Do the advertisements "right", advise sysadmins that hosts should
> not do SLAAC,
Doesn't it tell you something that you're fighting this hard to avoid
hosts from doing what comes naturally?
Well, I would not personally disable SLAAc except perhaps on specific
machines for specific reasons. If I was using exclusively DHCPv6 I might
disable the appropriate RA flags, and I would then expect my hosts to
not do SLAAC. Any host that did would be broken, IMHO.
It occurs to me that I haven't met anyone who uses the term "SLAAC"
who uses IPv6 in a way that I would consider normal. (Or at all.)
Ah well, it's always the exception that proves the rule.
Sadly the term "stateless autoconfiguration" got overloaded, so now we
have it meaning very different things - a) generating your own address
from RA information; and b) getting only ancillary information from a
DHCPv6 server.
Regards, K.