IPv6 Deployment for the LAN

Mon Oct 19 16:15:10 UTC 2009

It wasn't my intention to turn this into a debate of SLAAC vs DHCPv6
but that seems to be what it has become...

I agree, SLAAC is the easy way out.  I once drank the Kool-Aid and was
a "SLAACer" as well.

My attitude is that if there is a problem with DHCPv6 support let's
fix it, not abandon it.

Ultimately, DHCPv6 has a valid role to fill, and creating elaborate
systems to monitor IPv6 traffic and populate DNS, or adding extensions
to RA to provide DNS server configuration in an effort to turn SLAAC
into a DHCPv6 replacement is a little ridiculous.

If DHCPv6 worked properly on every system are you trying to argue that
you wouldn't want to make use of it over SLAAC for large environments?
 Or are you just basing your argument on the fact that vendors are
lagging behind on support for DHCPv6.

Rather than rolling out IPv6 at all costs and making sacrifices to do
so, we should be actively involved in engaging vendors and developers
to fix their systems so that we don't have to make these compromises.
We still have time, and as a group we have the ability to ignite such
change.

SLAAC does have a place byond residential networks, and perhaps in the
future we'll be at a point where we can run SLAAC and DHCPv6 side by
side to provide support for legacy systems, but at this point I think
that giving up on DHCPv6 in favor of SLAAC is the wrong path to take.

On Mon, Oct 19, 2009 at 10:04 AM, Ron Broersma <ron at spawar.navy.mil> wrote:
>
> On Oct 18, 2009, at 2:38 PM, Ray Soucy wrote:
>
> 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?
>
> As I read this whole thread, I had similar questions coming to mind.
>
> 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.
>
> I do not understand the big concern here, but that is probably because my
> own perspective and approach is
> somewhat different than yours.  In my humble opinion, those of us that are network operators need to provide robust IPv6 connectivity and services to our customers today, and customers with IPv6-enabled devices should automatically have IPv6 connectivity (i.e. automatically get an address and default route) with minimal hassle and configuration effort on their side.
>  If they decide they don't want IPv6, it is up to them to disable it,
> because they are the exception, not the rule.  Besides, systems
> administrators are probably the wrong ones to ask, because they will most
> often opt for "don't change anything that might break something or make me
> do more work".
> I just don't see how SLAAC is holding back deployment.  In my experience,
> SLAAC is your friend, given that DHCPv6 is not yet available for most of the
> client world (i.e. Windows XP, Mac OSX).  I've seen only one case out of
> thousands of customers where enabling IPv6 on the client broke access to a
> single remote web site, but that was because of a flaw in the DNS
> implementation for that remote site.  Wait, there was one other case where
> the problem turned out to be a bad NIC.  I think you are overly concerned
> about breaking someone by enabling SLAAC on all your nets.  Rather, focus on
> making sure that you have robust IPv6 connectivity and infrastructure and
> peering/transit.  If you do find situations where something breaks, then put
> your energies into resolving those situations, which benefits the whole
> community.  Our philosophy has been "aggressive IPv6-enablement is the right
> thing to do, and don't be afraid to break some glass".
>
> 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.
>
> Those cases are increasingly rare, and
> can be fixed.  Don't let such concerns stop you from IPv6-enabling your nets.  As a network operator, you are doing the right thing by enabling IPv6 on all your nets, and it is not your fault if sys admins aren't keeping their systems patched.
>
> 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).
>
> When I started rolling out IPv6 to my nets many years ago, I was of the same
> mindset.  I wanted the same mechanisms for managing addresses and DNS as I
> had in place for IPv4, and do dynamic DNS updates out of DHCP.  But, I
> quickly changed my approach after seeing the huge lack of client side
> support for DHCPv6, and serious interoperability issues where it did exist.
>  What we did find is a fairly simple means to use SLAAC and still keep DNS
> updated automatically for IPv6 addresses by polling the routers and doing
> the mapping to clone the IPv4 DNS entries for IPv6.  That works very well
> for us.
>
> 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.
>
> I would be more concerned with deviating from the mainstream of /64, and the
> potential problems you will encounter when doing so, than I would be for the
> few machines that might break when encountering SLAAC.
>
> 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).
>
> Using SLAAC for servers has not been a problem for us at all.  Many server
> admins also want to use manual IPv6 addressing, and that is perfectly fine
> with us if that is their choice.  I just don't see a problem with this.
>
> 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?
>
> Until every network device has a built-in DHCPv6 client, I need SLAAC.  Even
> then, I have a number of special case networks where DHCP is overkill if I
> have SLAAC available to me.  But on the other hand, for some network
> situations (like if you are using IVI as a transition mechanism for your
> net) then DHCPv6 is mandatory.  So I argue that we need both.
>
> 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 agree that this is a huge shortcoming on the part of Apple.  Everyone
> needs to file appropriate bug reports with Apple and complain about lack of
> DHCPv6 support.
> Good luck on your IPv6 deployment efforts.
> Regards,
> --Ron
>

-- 

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

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