The stupidity of trying to "fix" DHCPv6

Ray Soucy rps at maine.edu
Tue Jun 14 18:14:25 UTC 2011


> On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote:
> What is needed is:
>
>        -       Native RA Guard in switches
>        -       Native DHCPv6 Snooping in switches
>        -       Native RA Guard in WAPs
>        -       Native DHCPv6 Snooping in WAPs
>        -       Additional options to DHCPv6 for Routing Information
>        -       Eventual changes to host DHCPv6 Client behavior so that
>                DHCP does occur when RA not present.

Agree 100%

Especially with the last one; DHCPv6 clients shouldn't even be started
unless they see the M flag set; but that's an implementation
challenge.

Would probably include something analogous to ARP inspection for
neighbor discovery; and that router implementations are modified so
that once full, the neighbor table won't throw out known associations
in favor of unknown associations to mitigate the denial of service
attack vector present when using 64-bit prefixes.  Perhaps DAD
flooding protection too.  It's a "new" protocol, so it will take a
while for all these things to be worked out and become standard.

On Tue, Jun 14, 2011 at 2:00 PM, Ben Jencks <ben at bjencks.net> wrote:

> This has always confused me. What aspect of host configuration is the router providing that's so
> problematic? The prefix, which has to match on the router and host in order for anything to work
> anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to
> configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to
> know it all anyway, that I'm having trouble understanding what environment would find this so
> horrifying.

And This.

Really, people make way too big a deal about RA, and I think most of
it comes from the lack of vendor support for filtering of rouge RA and
the fact that Windows ICS happily sends them out.

I still blame vendors; this design has been known for a long time now
and they still haven't come up to speed, in part because people spend
their time complaining on NANOG instead of to their sales rep.

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/




More information about the NANOG mailing list