The stupidity of trying to "fix" DHCPv6

Leo Bicknell bicknell at ufp.org
Fri Jun 10 09:28:02 CDT 2011


In a message written on Fri, Jun 10, 2011 at 04:08:06PM +0200, Iljitsch van 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.  RA'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.  It won't affect
anyone who's already up and running.  It 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.  My 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.

-- 
       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/8920272a/attachment.bin>


More information about the NANOG mailing list