turning on comcast v6

Leo Bicknell bicknell at ufp.org
Tue Dec 31 01:16:04 UTC 2013

On Dec 30, 2013, at 6:56 PM, Owen DeLong <owen at delong.com> wrote:

> You can accomplish the same thing in IPv4….
> Plug in Sally’s PC with Internet Connection Sharing turned on and watch as her
> DHCP server takes over your network.

No, the failure mode is still different.

With IPv6 RA's, the rouge router breaks all hosts on the LAN with a single broadcast.

With a rogue DHCP server no currently working clients will stop working.  In fact many will do directed renews, and never notice said rogue server.  It is only a freshly booted host that might be captured by a rogue DHCP server.

In a corporate environment the difference between one user getting a rogue DHCP server, being down, and asking for troubleshooting, and taking out an entire department/floor/office is enormous.

> Yes, you have to pay attention when you plug in a router just like you’d have to pay attention if you plugged in a DHCP server you were getting ready to recycle.
> Incompetence in execution really isn’t the protocol’s fault.

We can't work around incompetent admins.  Even the best humans goof from time to time.

What we can do is design protocols that are robust, or not in the face of stupidity and accident.

I should tell you about the time rogue RA's took down a data center network because in the middle of the night the tech I was talking to couldn't tell if I said port "fifteen" or port "fifty" over the phone, and thus plugged the router into the wrong network taking down several hundred hosts.  The IPv4 side was fine for the 30 seconds or so until we straightened it out.

There's a reason why there's huge efforts to put RA guard in switches, and do cryptographic RA's.  These are two admissions that the status quo does not work for many folks, but for some reason these two solutions get pushed over a simple DHCP router assignment option.

       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: signature.asc
Type: application/pgp-signature
Size: 793 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131230/76376047/attachment.bin>

More information about the NANOG mailing list