> > 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>.
> >
> > 2) Revising the draft to restrict the usage of RH0. This would
> > continue to require RH0 to be implemented but would restrict the
> > functionality of RH0. For example, require nodes to have support for
> > RH0 turned off by default, limit the number of RH0 headers in a
> > packet to one, limit the number of addresses in the RH0 to a smaller
> > number (e.g., 6), and and a requirement that addresses can only be in
> > the header once.
> >
> I am in favor of option 2.
>
> With regard to RH0 and source routing in general I do not believe the best
> approach is to deprecate this functionality.
>
> Feature parity between IPv4 and IPv6 is important to ease transition and
> transition concerns. I wonder how much support there would be to
> deprecate IPv4 source routing.
>
> Also, if source routing in some sort of new and limited form turns out to
> be useful, RHx could be specified and implemented in new extension header,
> but the same is not true for IPv4.
see the text carefully. (1) says "deprecate *RH0*", (2) says
"restrict the usage of *RH0*". it is not about RHx. will your
choice change because of this?
and for what it's worth, IPv4 options entirely deprecated in reality.
packets with any IPv4 options could not go through JP-US link at least
since 1992 or so. therefore, IPv4 equivalent of RH0 has been dead
for 15 years.
i'm, of course, in favor of (1), and the document has to be shipped
as soon as possible. there are huge vendors which holding up the
release of security advisory until RFC gets published!
itojun
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
