The stupidity of trying to "fix" DHCPv6

Tue Jun 14 22:08:30 UTC 2011

On Jun 14, 2011, at 11:14 AM, Ray Soucy wrote:

>> 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.

That's the current broken behavior. The goal is to correct that problem.

> 
> 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.
> 

That would also likely be good, but, I don't think that requires IETF effort.

> 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.
> 

No, that is not the only place it comes from. There are real world networks
that don't have a good solution with RA because RA assumes that link==subnet
and that simply isn't true in all cases.

> 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.
> 

Believe me, I've done both.

Owen

> -- 
> Ray Soucy
> 
> Epic Communications Specialist
> 
> Phone: +1 (207) 561-3526
> 
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/