turning on comcast v6

Leo Bicknell bicknell at ufp.org
Tue Dec 31 19:08:49 UTC 2013


On Dec 31, 2013, at 12:36 PM, Tony Hain <alh-ietf at tndh.net> wrote:

> likely pointless. Do you really believe that dhcp messages picked up by the
> rogue router wouldn't end up answering with the wrong values and breaking
> both IPv4 & IPv6? Next, do you really believe that DHCP Guard for an IPv4
> aware switch will do anything when an IPv6 DHCP message goes by? Don't you
> have to replace every switch and reconfigure anyway? Or is rogue DHCP
> service a problem that goes away with IPv4? Why do people continue to insist
> that a cornerstone of their network security model is tied to an inherently
> insecure protocol that was never intended to be used as a security tool? ...
> but I digress …

In the scenario I described, which I suggest is extremely common, the 
rogue router will not provide any DHCPv4 client with an address, ever.
It is configured to forward to a DHCP sever, and based on the steps I
suggested it has no route to reach it.  It will forward the packet out
its down uplink, and never get a reply.  It is in fact 100% benign.

Let me repeat, it's 100% benign, and will not affect any users, ever.

Yes, if the router has a local DHCP server there would be an issue.  But
that's not actually very common, most of the people running DHCP want a
central server and the logging that goes along with it.

I'll admit my scenario was contrived, constructed to specifically show
ONE aspect of the problem.  It is not the only operational issue, but
it is one that is easy for engineers to understand and replicate.  However,
it's also common.  I know multiple people who shot themselves in the foot
in this very way, with operational networks.  It's not a theoretical
problem, it's one that happens every day.

Here's another problem that happens every day in data centers and offices.
Someone accidentally bridges two VLAN's together for a few minutes by
plugging in a cable to the wrong port, realizing it and then unplugging
it.  In an IPv4+DHCPv4 world the majority of the time the impact is,
well, NONE.  No hosts notice.  Some switches compute a new spanning tree
adjacency and some broadcast traffic goes where it shouldn't, but everything
remains operational.  Do the same with IPv6 and all of the hosts on one of
the two VLAN's will instantly stop working.

There are controlled environments, like a single tenant data center
where a rogue DHCP server is simply not a security concern, but where
a tech accidentally bridging VLAN's is a very real possibility.

The fact of the matter is that the scale, scope, and impact from a rogue
DHCP server is entirely different from a rogue RA server.  IPv4+DHCP
is operationally much more robust in the face of various scenarios,
where as IPv6+RA pretty much always results in near instantaneous 100%
failure.

> Unfortunately there have been too many voices demanding a 'one size fits
> all' approach within the IETF, and we have gotten to the current situation
> where you need to deploy parts of both models to have a functional network.
> RFC 6106 is a half-baked concession from the 'dhcp is the only true way'
> crowd to allow home networks to be functional, but if you want anything more
> than DNS you have to return to the one-true-way, simply because getting
> consensus for a more generic dhcp-options container in the RA was not going
> to happen. The Routing Information DHCP option has been held hostage by
> those that might be described as a 'dhcp is broken by design' crowd, because
> many saw that as a bargaining point for consensus around a more feature rich
> RA. Both hard line positions preventing utility in the other model are
> wrong, but in the presence of a leadership mantra of one-size-fits-all,
> neither side was willing to allow complete independent functionality to the
> other. 

I think you describe the IETF situation reasonably well.  The internal 
bickering between the "RA camp" and the "DHCP camp" have largely prevented
either one from producing something robust.

> Making progress on the Routing Information option requires a clear scenario
> to justify it, because vast swamp of dhcp options that have ever been used
> in IPv4 are not brought forward without some current usage case. Lee was
> asking for that input, and while the scenario you paint below might be
> helped by that option, it presumes that every device on the network has
> additional configuration to ignore an errant RA sent from the router being
> configured simply because the network is supposed to using DHCP.

This is some extremely circular logic.

We can't have DHCP until there are options in devices to ignore RA's.

We can't have an option to ignore RA's in devices, because at the moment RA's
are the only way to get a default route so it doesn't make sense.

Someone has to go first, the other side will follow.  I suggest it makes
a lot more sense to get working DHCP, before pressuring end-user boxes
to have an option or even default to ignoring RA's.

-- 
       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/20131231/bc7d75c3/attachment-0001.bin>


More information about the NANOG mailing list