On Tue, 28 Aug 2007, Jun-ichiro itojun Hagino wrote: > > > 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?
I am quite aware that choice 1 is Deprecate RH0 and choice 2 is restrict usage of RH0, and neither relates to RHx. I think maybe you are missing my point. It relates to a more general discussion of source routing and feature parity in IPv4 and IPv6. If you are going to deprecate IPv6 source routing, then you should also deprecate IPv4 source routing. If you think that maybe IPv6 source routing is useful, especially in a more limited fashion, then that can easily be defined in another IPv6 RHx extension header. But the problem is much more complicated if you want feature parity with IPv4 as you would need to modify the IPv4 header. For this reason I would prefer greater control over how to deal with source routed packets (IPv4 and IPv6). I am not opposed to changing the defaults (in both IPv4 and IPv6) to prevent source routing. I think it would be good to require all vendors to support a single config bit to prevent source routing. But if we are going to re-think source routing, I think there are better options then either supporting source routing, or discarding all packets with a source routing option. > > 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. Again, some people seem to think source routing is useful, other are afraid of the security risks. Each network operator will act in their own best interest. Currently the only options are either allow your devices to perform source routing, or drop all packets that are transiting the network with source routing options. There is middle ground here. Allow routers to be configured such that they can ignore source routed packets that are not destined to the local router. This will allow routers to forward source routed packets in the normal way without an impact on software based forwarding. This will allow an operator to secure their own network and not allow their network to be used for source routing, while not preventing networks that are reached through them to use source routing if they so desire. This way everyone can decide for themselves if they want to support source routing unlike currently where all of the transit providers have made the decesion on behalf of their customers. > > 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 I am still in favor of choice 2. I would be curious how people feel about these choices if they also apply to (as they should) IPv4 source routing. __Jason -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
