On 20-Aug-2007, at 16:43, Bob Hinden wrote:
We would like to get your comments on the following two choices:
1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-
rh0-01.txt>.
I support this option since:
1. I think it is the clearest solution to the problem (as in, easiest
to understand). I believe clarity is important here, since ambiguity
seems like a path to "let's block all routing headers, just to be on
the safe side".
2. It facilitates identification of "dangerous" source-routing in a
way that is already available on several platforms (checking the RH
type) without requiring devices to distinguish between old and new
semantics (as would be needed in the case of a shared codepoint
between the original and new specification).
3. Architecturally, choosing a new codepoint for functionality which
is different, even if it is similar, seems like the right thing.
4. It is congruent with the approach several significant
implementations have taken (e.g. Linux, *BSD, Mac OS X).
5. Nobody has come forward with an indication that functionality
requiring RH0 in its current form is widely deployed or required. It
seems at least plausible that we might expect to have heard of such a
use case given the publicity surrounding the CanSecWest presentation,
regardless of whether you choose to classify that publicity as
"hysteria" or "journalism" :-).
6. It seems likely that some IPv6 operators have taken the precaution
of dropping datagrams carrying RH0, and hence the zero type might be
considered effectively poisoned for use on the public Internet. Re-
use of type zero would hence only be of reliable use within
controlled networks; to be of general use, a benign source routing
option would need a new codepoint.
Joe
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
