[141690] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Ray Soucy)
Fri Jun 10 10:35:19 2011
In-Reply-To: <20110610142802.GA21261@ussenterprise.ufp.org>
Date: Fri, 10 Jun 2011 10:34:57 -0400
From: Ray Soucy <rps@maine.edu>
To: Iljitsch van Beijnum <iljitsch@muada.com>, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
All I'm saying is that it's generally a bad idea to have different
standards for "accidental" and "malicious" traffic.
Say you were using DHCPv6 for routing; a malicious user could still
inject traffic on the network to disrupt service.
People get all uppity about RA because vendors have been painfully
slow to implement RA Guard.
To be fair, RA Guard probably should have been an early RFC as it was
an obvious concern even at the time ICMPv6 was being drafted.
I for one look forward to the day where things like RA Guard and MLD
Snooping are standard on every switch. Just IPv6 growing pains.
Also agree that I want flexibility to use RA or DHCPv6; the
disagreement is that RA needs to be removed or changed from IPv6.
Don't go breaking my IPv6 stack for your own ambitions, please.
On Fri, Jun 10, 2011 at 10:28 AM, Leo Bicknell <bicknell@ufp.org> wrote:
> In a message written on Fri, Jun 10, 2011 at 04:08:06PM +0200, Iljitsch v=
an Beijnum wrote:
>> Ok, so now we've identified the problem.
>>
>> How exactly does adding default gateway information to DHCPv6 solve this=
problem?
>
> Please go back and re-read my original scenario and think about it.
>
> The difference here is that if a client gets a DHCP address it
> generally won't be broken until it tries to renew, and then often
> won't be broken at renewal because it sends a directed request back.
>
> In specific technical terms: DHCP relies on broadcast _ONCE_ at
> boot, and then uses static unicast config to verify that is still
> the correct config. =A0RA's use broadcast every few seconds to broadcast
> new information that everyone is supposed to "trust" instantly.
>
> Turn up a Rogue DHCP server on one of your subnets. =A0It won't affect
> anyone who's already up and running. =A0It may grab newly booted
> machines, depending on a race condition, but it won't break anything
> that is already working.
>
> Turn up rogue RA's, and everyone instantly fails.
>
>
> The behavior of these protocols is different, which leads to different
> failure modes. =A0My assertion is that in every failure mode you can
> come up with RA's lead to more clients being down faster and for
> longer periods of time.
>
> --
> =A0 =A0 =A0 Leo Bicknell - bicknell@ufp.org - CCIE 3440
> =A0 =A0 =A0 =A0PGP keys at http://www.ufp.org/~bicknell/
>
--=20
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
