IPv6 Deployment for the LAN

trejrco at gmail.com trejrco at gmail.com
Mon Oct 19 12:19:57 UTC 2009


IPv6 is an opportunity/excuse to make networks make sense - think about what you really want your architecture to be, plan it and start migrating to that.  

IF that means adding something to v6, great - do it, solve problems.

I am not saying "the way we do it know" is always just a bad excuse, but when it is _just_ that maybe the situation needs another look :) ...

(Specifically - on an enterprise side - Align "life cycle refresh" and IPv6 deployment; once the "IPv4 only things" are identified they will simply not be migrated to new dual-stack segments ... Easy!)

(Oh - As for SLAAC, you can just do the default gateway part and still use DHCPv6 for the rest ... I have yet to see implementations that ignore A=0, and have never tried of using ~/80s to force non-autoconf.(My gut says the odds of hosts mis-handling a /80 are far greater than ignoring A=0 :) ))

In the end - I agree that SLAAC and DHCPv6 both fulfill valid roles ...


/TJ ... Not (just) an idealist :)
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Ray Soucy <rps at maine.edu>
Date: Sun, 18 Oct 2009 17:38:26 
To: Steven Bellovin<smb at cs.columbia.edu>
Cc: <nanog at nanog.org>
Subject: Re: IPv6 Deployment for the LAN

Thanks for the response, if only to force me put my thoughts down into words.

On Sun, Oct 18, 2009 at 4:28 PM, Steven Bellovin <smb at cs.columbia.edu> wrote:

> ...
>
> My question is this: what are your goals?  What are you trying to achieve?
>  Force all authorized machines to register?  If so, why?  We'll leave out
> for now whether or not there's even much point to that.  My university --
> and I'm just a user of campus computing facilities; I don't run them -- has
> concluded that there's no particular benefit to requiring registration or
> permission; it's one more server complex to run, one more database to
> maintain, and one more thing to break, and the benefits don't seem to be
> worth the cost.  And given that we've had incidents of IP and MAC address
> spoofing, where it took the switch logs to figure out what was going on, I'm
> very far from convinced that registration is of any benefit anyway.  In
> other words -- yes, I agree with the campus policy -- but that's not the
> question I'm asking.

Not my place to implement policy; I'm not a lawyer.  We already have
monitoring in place for accountability that maps each address used on
a network (regardless of IP or IPv6) to a device and interface for
incident response.

The greater concern is that SLAAC makes IPv6 available to hosts that
may not be prepared for it.  If administrators are asked if they would
like IPv6 enabled, having been explained the implications of such if
SLAAC is used for configuration, the majority of the time they come
back and say "thanks, but no thanks."  In this situation, SLAAC is
holding back deployment of IPv6.  I suspect other have seen this as
well.

Part of the problem here is that IPv6 isn't new; it's old.
Implementations have been in place for years on certain systems
without proper testing as they have gone largely unused.  We've seen
cases where older versions of Linux can be crashed by enabling SLAAC
on a network being one example.

By using DHCPv6 we gain some advantages: We can automatically update
DNS for hosts so that IPv4 records and IPv6 records match; We have the
ability to roll out DHCPv6 on a per-host basis without causing
problems on the production IP network; and we can roll it in to our
existing [home grown] tools for network management in a way that is
easy for users of the system to understand (keep in mind, we provide
tools to delegate network control to hundreds of sub-administrators
throughout the State).

The original question here wasn't SLAAC vs. DHCPv6.  I think many
network operators here who are tasked with managing anything of scale
will agree that SLAAC doesn't quite cut it and is often a step
backwards.  The overhead of implementing and administering such a
system at this scale generally wins out over not doing so.

The question I was mainly concerned with was if anyone has encountered
issues with the use of an 80-bit prefix to prevent SLAAC from being
active.  While the prefix advertisement does have the autonomous flag
which can be set to false, the underlying problem of IPv6
implementations not being consistent across hosts operating systems
yet doesn't change.  I'm not convinced that there aren't
implementations out there that will enable SLAAC regardless of what
the prefix flag is set to, so using a prefix other than a 64 provides
an easy way to [attempt to] avoid this, all the while allowing for us
to eventually migrate to a 64-bit prefix when host support improves.

Another concern is that we certainly don't want to use SLAAC for
servers, and I'm hesitant to promote the use of manual IP
configuration as it can quickly become a nightmare if you need to move
networks (admittedly there should be less need for network moves, but
all the same).

DHCP has long solved many of these issues in the IP world, and it is
perfectly reasonable, and desirable, to apply them to IPv6 though the
use of DHCPv6.  Perhaps in the future, as we see less legacy hosts
online we'll be in a position to make use of both SLAAC and DHCPv6 for
host configuration, but in all honesty, once DHCPv6 is in place, why
would you want to use SLAAC?

My other question was DHCPv6 support from Apple (who seems to be one
of the few in resistance of DHCPv6).  This list managed to point me in
the right direction to nag them about it.

> I ask because there may be other ways to achieve your actual goal, but
> without knowing that it's hard to make recommendations.  The most obvious
> answer is accountability, but physical port number may be a better approach
> there, depending on how the campus network is run.
>
>
>                --Steve Bellovin, http://www.cs.columbia.edu/~smb



-- 

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

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



More information about the NANOG mailing list