[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The stupidity of trying to "fix" DHCPv6
- Subject: The stupidity of trying to "fix" DHCPv6
- From: nick at foobar.org (Nick Hilliard)
- Date: Tue, 14 Jun 2011 17:15:34 +0100
- In-reply-to: <BANLkTi=tDa4_T4_u0_Fg5fQUA_zOJHL5cQa8H=dTrw28AhH+Aw@mail.gmail.com>
- References: <BANLkTimGPh3TxmE2LO2dJ2F8YWkM5g5raxa3dPzbTbOv=Sxa5Q@mail.gmail.com> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <BANLkTi=8C4MRPJsF+6AMSp5aRVbCGw8bNvSC5Gcnp8TE9yVp-Q@mail.gmail.com> <[email protected]> <BANLkTi=tDa4_T4_u0_Fg5fQUA_zOJHL5cQa8H=dTrw28AhH+Aw@mail.gmail.com>
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