The stupidity of trying to "fix" DHCPv6

Ray Soucy rps at
Tue Jun 14 15:12:08 UTC 2011

Wow, I don't recall making it personal?

I have broken networks before by connecting miss-configured devices,
by the way, and I was a moron for doing so.  I don't base my network
design decisions around preventing people with full access to
configure the network breaking it; but rather restrict the level of
access people have and impingement sane policies on when and how
changes are made; like most of the people on this list.

The point was you shouldn't base protocol design around the
possibility that someone might tell it to do something you don't want
it to do; otherwise you'll end up with a one-size-fits-all protocol
that has zero flexibility (and might not even be functional at all).
Similar problems existed in IPv4; but over time networks evolved and
better protection methods became available.

The days of the dumb switch are over; and at the price and performance
of today's switches we should expect features like RA guard and MLD
snooping to be standard.  We threw out Ethernet hubs a decade or two
ago for good reason, and there was resistance then too.

On a side note, if you're going to resort to direct personal attacks,
maybe you shouldn't be doing so while representing your company.
Everything on NANOG is archived and sticks around for a very, very
long time.


On Fri, Jun 10, 2011 at 3:21 PM, Steve Clark <sclark at> wrote:
> On 06/10/2011 09:37 AM, Ray Soucy wrote:
> You really didn't just write an entire post saying that RA is bad
> because if a moron of a network engineer plugs an incorrectly
> configured device into a production network it may cause problems, did
> you?
> You are the moron - this stuff happens and wishing it didn't doesn't stop
> it. Get a clue!
> Honestly.  This whole argument is getting ridiculous.
> On Fri, Jun 10, 2011 at 9:32 AM, Leo Bicknell <bicknell at> wrote:
> 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 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 - CCIE 3440
>        PGP keys at
> --
> Stephen Clark
> NetWolves
> Sr. Software Engineer III
> Phone: 813-579-3200
> Fax: 813-882-0209
> Email: steve.clark at

Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System

More information about the NANOG mailing list