The stupidity of trying to "fix" DHCPv6
rps at maine.edu
Tue Jun 14 16:41:46 UTC 2011
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.
I think that was the original spirit of this thread.
Full static assignment is always an option if you don't want to use RA
Presenting suggestions in the form of an RFC draft would be more
useful than ranting about it for the 100th time on-list. At least
then you could point to something that can actually be worked on
constructively; rather than a lot of straw-man arguments because you
don't personally like the way things are currently done.
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.
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.
On Tue, Jun 14, 2011 at 12:15 PM, Nick Hilliard <nick at 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).
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
More information about the NANOG