On May 17, 2007, at 4:18 AM, Brian Haberman wrote:
I don't think that is the case at all. What this draft does is
deprecates a *form* of source routing that is open to attack. It does
not ban all source routing (e.g. MIPv6 can still use Type 2 source
routing) and it does not preclude someone from defining a new type
that
addresses a need that they have.
Thanks, Brian / all.
I guess what I'm trying to understand is how to strike the right
balance between preventing undesirable behavior and allowing
flexibility for innovation. One approach is to provide a general
source-routing capability that can be used in a variety of ways - in
other words, allow for experiment and innovation within the context
of the operational network. A different approach is to incrementally
add specific functionality only to meet specific goals - essentially
moving much of the process of innovation off the operational network.
As currently specified, the RH0 is pretty far in the direction of the
former (i.e. provide flexibility). If an adjustment to RH0 is needed
to address the concern at hand, perhaps we should not make a single
and complete move to the latter model. (this is how I interpreted
your above comment, but maybe I got that wrong). One reason is the
(potential) interplay between source routing and inter-domain routing
policy may well require the innovation to occur within the
operational environment.
I think it's true that the IPv6 spec and any related RH docs will
provide the upper bound on flexibility, which can then be reduced
through configuration, filtering, outside mechanisms, etc. The
inverse does not seem to be true - in other words, if the inherent
flexibility of the current spec is reduced said flexibility could not
be recovered through configuration, outside mechanisms, etc. I could
more easily support deprecation of RH0 if there were an accompanying
action to add (return) a general source-routing mechanism to the IPv6
spec.
I'm still thinking through this, but the fact that the RH0 is so
widely implemented seems to be a desirable property for fostering
innovation. If we took RN0 out, and then added something similar
back in, it would take some time to recover that property. It may be
easier to simply disable-by-default, improve the fidelity of
filtering (RH0 vs RH2), etc. Of course, if one is not interested in
supporting a general and flexible mechanism, then taking RH0 out
makes a lot more sense.
R,
Dow
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
