nanog mailing list archives
Re: The stupidity of trying to "fix" DHCPv6
From: Ray Soucy <rps () maine edu>
Date: Tue, 14 Jun 2011 14:14:25 -0400
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 () 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/
Current thread:
- Re: The stupidity of trying to "fix" DHCPv6, (continued)
- Re: The stupidity of trying to "fix" DHCPv6 Mohacsi Janos (Jun 10)
- Re: The stupidity of trying to "fix" DHCPv6 Ricky Beam (Jun 10)
- Re: The stupidity of trying to "fix" DHCPv6 Steve Clark (Jun 10)
- Re: The stupidity of trying to "fix" DHCPv6 Josh Hoppes (Jun 10)
- Re: The stupidity of trying to "fix" DHCPv6 Joel Jaeggli (Jun 10)
- Re: The stupidity of trying to "fix" DHCPv6 Ray Soucy (Jun 14)
- Re: The stupidity of trying to "fix" DHCPv6 Nick Hilliard (Jun 14)
- Re: The stupidity of trying to "fix" DHCPv6 Ray Soucy (Jun 14)
- Re: The stupidity of trying to "fix" DHCPv6 Owen DeLong (Jun 14)
- Re: The stupidity of trying to "fix" DHCPv6 Ben Jencks (Jun 14)
- Re: The stupidity of trying to "fix" DHCPv6 Ray Soucy (Jun 14)
- Re: The stupidity of trying to "fix" DHCPv6 Owen DeLong (Jun 14)
- Re: The stupidity of trying to "fix" DHCPv6 Leo Bicknell (Jun 14)
- Re: The stupidity of trying to "fix" DHCPv6 Ben Jencks (Jun 14)
- Re: The stupidity of trying to "fix" DHCPv6 Leo Bicknell (Jun 14)
- Re: The stupidity of trying to "fix" DHCPv6 Jima (Jun 15)
- Re: The stupidity of trying to "fix" DHCPv6 Leo Bicknell (Jun 15)
- Re: The stupidity of trying to "fix" DHCPv6 Iljitsch van Beijnum (Jun 15)
- Re: The stupidity of trying to "fix" DHCPv6 Jima (Jun 15)
- Re: The stupidity of trying to "fix" DHCPv6 Owen DeLong (Jun 16)
- Re: The stupidity of trying to "fix" DHCPv6 Mark Andrews (Jun 16)