Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong <owen () delong com>]

On Jun 14, 2011, at 9:41 AM, Ray Soucy wrote:

> The energy in this thread should be focused on switch vendors to
> actually implement L2 security features for IPv6, which is usually an
> easy upgrade; rather than calling for all host implementations of IPv6
> to work differently; which will take a decade to implement and be a
> band-aid at best; not a good long-term design for the protocol.

No, the energy in this thread needs to be directed to both of those
issues. However, your characterization of the needed behavior
and the time to deploy it is not entirely accurate.

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.

> I think that was the original spirit of this thread.

No, the original spirit of the thread revolved around the last 2
items in the above list. The first 4 have been discussed and already
resolved at the IETF level and are merely awaiting vendor implementation.

> Full static assignment is always an option if you don't want to use RA
> or DHCPv6.

Sure, but, the issue is people that don't want to use RA, but, want to use
DHCPv6.

> If you get a bad DHCP server on the network it can take hours to undo
> the damage thanks to lease times; if you get bad RA you can usually
> fix the problem as soon as you find it.  Apples and Oranges, really.
> If connecting the rogue DHCP server doesn't obviously break things
> when connected, you might not even notice it until it's too late.

There's actually no reason this couldn't be done with DHCPv6, too, but,
it's not there currently.

> More responsive to change is better in my opinion.  I hate having to
> wait hours or days for changes to propagate; it feels like the 1990s,
> or the days of mainframes and batch jobs.

Then use RA and move on. However, please understand that yours
is not the only environment and that there are real-world scenarios
where having the router-guys dictate the host configuration is considered
unacceptable at best.

Owen

> On Tue, Jun 14, 2011 at 12:15 PM, Nick Hilliard <nick () foobar org> wrote:
> > On 14/06/2011 16:12, Ray Soucy wrote:
> > > The point was you shouldn't base protocol design around the
> > > possibility that someone might tell it to do something you don't want
> > > it to do; otherwise you'll end up with a one-size-fits-all protocol
> > > that has zero flexibility (and might not even be functional at all).
> >
> > sensible engineering dictates that design should aim to be fail-safe.  I.e.
> > not "failsafe" in the common usage of the term (= doesn't fail), but rather
> > cogniscent of the fact that all systems fail from time to time, and when
> > they do, they ought to fail in such a way that the collateral damage is
> > minimised.  This principal is recodified in various ways ("be liberal in
> > what you accept", etc), but the underlying idea is the same.
> >
> > In IPv6-land, we appear not to have learned the lessons from ipv4 history,
> > and our vendors aren't yet shipping switches with native RA- and DHCPv6-
> > guard (yes, there are some exceptions to the former).
> >
> > Nick
>
>
>
> -- 
> Ray Soucy
>
> Epic Communications Specialist
>
> Phone: +1 (207) 561-3526
>
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/