[141920] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Ray Soucy)
Tue Jun 14 11:12:19 2011
In-Reply-To: <4DF26EB7.70502@netwolves.com>
Date: Tue, 14 Jun 2011 11:12:08 -0400
From: Ray Soucy <rps@maine.edu>
To: Steve Clark <sclark@netwolves.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
Ray
On Fri, Jun 10, 2011 at 3:21 PM, Steve Clark <sclark@netwolves.com> 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@ufp.org> 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@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. =A0It'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 n=
ew
> technology.
>
> The problem in this case is that the failure modes are significantly
> different. =A0Some folks have learned this the hard way.
>
> It's a very easy scenario to reconstruct. =A0Consider the "branch
> office router" in a typical corporate enviornment. =A0We're talking
> a device with one WAN port, and one LAN port. =A0Configure 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. =A0In IPv6, configure it with RA's, the
> supposed "better" way.
>
> Now, take the 100% working branch router and have it sent back to
> corporate. =A0Maybe 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. =A0IPv4 keeps working fine.
>
> Oops.
>
> What happened? =A0Well, the router sent IPv6 RA's as soon as it came
> up, and every workstation instantly started using them. =A0In 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. =A0This "rogue device" will
> =A0never disrupt the IPv4 configuration. =A0DHCP snooping isn't even need=
ed
> =A0in your switches, since it never returns a response.
>
> - IPv6 "failed immediately" with the RA configuration. =A0What's worse is
> =A0if you simply turn the device off after you realized you took down the
> =A0entire network devices will continue to be broken for 2-4 hours until
> =A0the RA's time out. =A0The only method to mitigate is to deploy RA guar=
d
> =A0on all of your switches, which probably means replacing 100% of your
> =A0hardware with new stuff that can do that, and then deploying new
> =A0features.
>
> The fact of the matter is that the failure modes of these two
> protocols are vastly different operationally. =A0The DHCP failure
> semantics are not only better understood, but cause less disruption
> to the network. =A0Even a properly rouge DHCP server will only damage
> _new_ clients coming up on a network, existing folks will work just
> fine. =A0Contrast 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. =A0If I don't my boxes don't have
> DNS servers, NTP servers, know where to tftpboot, etc. =A0It'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. =A0My 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.
>
> --
> =A0 =A0 =A0 Leo Bicknell - bicknell@ufp.org - CCIE 3440
> =A0 =A0 =A0 =A0PGP keys at http://www.ufp.org/~bicknell/
>
>
>
>
>
> --
> Stephen=A0Clark
> NetWolves
> Sr.=A0Software=A0Engineer=A0III
> Phone:=A0813-579-3200
> Fax:=A0813-882-0209
> Email:=A0steve.clark@netwolves.com
> http://www.netwolves.com
>
--=20
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
