Re: IPv6 Deployment for the LAN

[Ron Broersma <ron () spawar navy mil>]

On Oct 18, 2009, at 2:38 PM, Ray Soucy wrote:

> On Sun, Oct 18, 2009 at 4:28 PM, Steven Bellovin  
> <smb () 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