IPv6 Deployment for the LAN

Thu Oct 22 12:11:39 UTC 2009

Just to clear things up, I'm not advocating the use of 80-bit
prefixes.  I was asking if they were a legitimate way to prevent SLAAC
in environments with hardware that don't support disabling the
autonomous flag for a prefix, or hosts that don't respect the
autonomous flag.  I've since done some testing in the lab, and have
found that the majority of operating systems that are still in use
respect the autonomous flag when deciding whether or not to run SLAAC
if IPv6 is implemented, so this becomes a non-issue.  I agree,
sticking with a 64-bit prefix for every network is a good thing.

SLAAC itself is also a good thing and I'm not advocating that it go
away.  I think its rather elegant and provides a lot of flexibility.
That said, DHCPv6 is also a key part of IPv6.  The fact that we have M
and O flags in RA, and the A flag in advertised prefixes is a pretty
strong signal that both stateless and stateful configuration are valid
choices for IPv6 deployment.

Adding DNS information to RA would generally be a bad idea.  There is
more to host configuration than just DNS, though DNS is the most
common.  I think that RA knows its role and archives it rather nicely.
 When you want to provide hosts with other configuration, like DNS,
you can do so making use of a lightweight implementation of DHCPv6.
In fact, most routers already support this.  The argument that
implementing DHCPv6 in the client is somehow too much work is
ridiculous.  DHCPv6 is as essential to IPv6 as ICMPv6 and MLD.  You
really shouldn't consider an implementation of IPv6 without a
functional DHCPv6 client complete.

At the same time, adding gateway information to DHCPv6 is also a bad
idea.  This is already accomplished by RA in an elegant and thoughtful
way.  This whole line of thinking is a result of the mindset that
SLAAC and DHCPv6 are mutually exclusive; they're not.  RA, SLAAC, and
DHCPv6 compliment one another.  They are all important components of
the IPv6 addressing architecture.

What we have now generally works well.  Getting vendors to work
together and actually implement things the same way is sometimes a
challenge.  Perhaps we need to update the language on RFCs from MAY
and SHOULD to MUST and eliminate the ambiguity of what needs to be
implemented with IPv6.

In an enterprise environment, SLAAC has no place.  It makes perfect
sense to not run SLAAC on prefixes you advertised in this case.  Just
because SLAAC is the default doesn't mean it's the only method of
deployment.  There are still some challenges to work out with DHCPv6
implementations, and it may help dual-stack environments if DHCPv6 is
amended to include a MAC address in requests when running on a
dual-stack network so associations can be made between IP and IPv6
addresses on a host, but the use of DUID is generally a good thing.
Once we start seeing more IPAM solutions include support for IPv6 and
DHCPv6 I think a lot of the hostility towards DHCPv6 will go away.

We've been implementing DHCPv6 support in our home-grown IPAM solution
and have found that it all works rather nicely.  Mac OS X is a
challenge since it doesn't provide a DHCPv6 client, but our position
has become that of saying we don't roll out IPv6 to clients with
incomplete implementations and to leave it at that.

IPv6 isn't quite necessary for all clients just yet.  There is very
little that is reachable by IPv6 only.  Until that changes, we're
willing to ignore certain groups of clients in an effort to pressure
vendors to come into the fold and support DHCPv6 by default.  If we
have a case where there is a legitimate need for IPv6, we still have
the ability to manually assign an IPv6 address on the host, but this
would be on a very limited basis.

If you're an ISP and deploying IPv6 for your residential customers, by
all means run SLAAC.  It's easy and it works.  If you manage an
enterprise IT environment and need control over your network, disable
SLAAC and run DHCPv6.  This will allow you to roll out IPv6 at your
own pace, giving you time to make sure that hosts and users are
prepared for it, all while maintaining the benefits of DHCPv6 in your
architecture.

That's all I'm trying to say.

-- 

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/