The stupidity of trying to "fix" DHCPv6

Leo Bicknell bicknell at ufp.org
Fri Jun 10 08:32:43 CDT 2011


In a message written on Fri, Jun 10, 2011 at 01:03:01PM +0000, Bjoern A. Zeeb wrote:
> On Jun 10, 2011, at 10:10 AM, sthaug at nethelp.no wrote:
> > Several large operators have said, repeatedly, that they want to use
> > DHCPv6 without RA. I disagree that this is stupid.
> 
> I wonder if it's just a "violation" of rule #1: stop thinking legacy!
> 
> People are used to what they have done for a decade or two.  It's hard to
> see the change and results in "why is this all so different and complicated?".
> It's hard to open ones mind for the new, but it is essential to do with new
> technology.

The problem in this case is that the failure modes are significantly
different.  Some folks have learned this the hard way.

It's a very easy scenario to reconstruct.  Consider the "branch
office router" in a typical corporate enviornment.  We're talking
a device with one WAN port, and one LAN port.  Configure it for
dual stack, speaking IPv4, and in IPv4 configure it the typical
corporate way with a "DHCP Helper" forwarding requests over the WAN
to a central DHCP server.  In IPv6, configure it with RA's, the
supposed "better" way.

Now, take the 100% working branch router and have it sent back to
corporate.  Maybe they got a bigger router, maybe the office closed.
A network engineer gets the router and is tasked with making it
ready to redeploy.

The network engineer plugs it into the switch on his desktop, plugs in a
serial cable, turns it on and steps out to get a coffee while it boots.
He's planning to erase the configuration and then load new software over
the network.

As soon as the router boots the IPv6 network fails for all the users on
his subnet.  IPv4 keeps working fine.

Oops.

What happened?  Well, the router sent IPv6 RA's as soon as it came
up, and every workstation instantly started using them.  In IPv4,
the router received DHCPv4 requests and forwarded them per the
helper address, except that its WAN port is down, and thus it in
fact didn't send them anywhere.

The important points:

- IPv4 "failed safe" with the DHCP config.  This "rogue device" will
  never disrupt the IPv4 configuration.  DHCP snooping isn't even needed
  in your switches, since it never returns a response.

- IPv6 "failed immediately" with the RA configuration.  What's worse is
  if you simply turn the device off after you realized you took down the
  entire network devices will continue to be broken for 2-4 hours until
  the RA's time out.  The only method to mitigate is to deploy RA guard
  on all of your switches, which probably means replacing 100% of your
  hardware with new stuff that can do that, and then deploying new
  features.

The fact of the matter is that the failure modes of these two
protocols are vastly different operationally.  The DHCP failure
semantics are not only better understood, but cause less disruption
to the network.  Even a properly rouge DHCP server will only damage
_new_ clients coming up on a network, existing folks will work just
fine.  Contrast with RA's which instantly break 100% of the users.

Even more annoying is that if I use RA's for the default gateway,
I still have to run DHCPv6 anyway.  If I don't my boxes don't have
DNS servers, NTP servers, know where to tftpboot, etc.  It's not a
choice of one or the other, it's I always run DHCPv6, do I need
RA's or not.

Given the failure modes I would much prefer to run with RA's turned off
completely, and have DHCPv6 able to provide a default gateway just as it
works in IPv4.

My opinion comes not from "thinking legacy", indeed my employer has been
fully dual stacked since 2003.  My opinion comes from the fact that in
the 8 years of operational experience we have RA's are significantly
more fragile, and IMHO not ready for widespread IPv6 deployment.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110610/e9fd23fb/attachment.bin>


More information about the NANOG mailing list