---------- firstname.lastname@example.org wrote: ------------
As a general rule, most clients are following the "If we gave them static
IPv4 addresses we will give them static IPv6 addresses" (infrastructure,
servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit
related) conversation ...
Seeing Howard's quick response saying "To try to stay operational
about this..." makes me realize I may have inadvertently invited a
religious flame fest.
I guess that rules me out.
Please! Operational content and hands-on experiences only to the
best of your ability. I want to learn from this, not delete the
The short and simple "Where we are Today" is that the only DHCPv6
clients you are likely to encounter in your networks are either DOCSIS
modems or Windows Vista.
So if you are going to deploy IPv6 to customers, you are generally
going to use SLAAC today, and all the headaches that entails.
Although there's now an option for domain name servers and search
paths in router advertisements, you'll have an even worse time finding
So the current state of the art is to run dual stack so that DHCPv4
can reliably provide IPv4 nameservers, which you can use to find
AAAA records, enabling SLAAC'd IPv6 access. For extra credit you
can supply IPv6 nameserver information statelessly, but then you're
only complicating things even more.
One of the little talked about issues is the potential support
cost when a customer wants to resolve some issue. "My web isn't
working." "Are you using v4 or v6?" "Netscape."
And of course it's a non-starter for anyone who needs to assign and
approve the client's configuration, let us imagine because of
differing product levels, rather than letting them pick whatever they
I think the above can reasonably be said to be an accurate, if brief,
depiction of current IPv6 operations. If you wanted to gaze into the
future, I think that isn't precisely possible without welcoming the
related philosophical (not religious) debates.