On Mon, 20 Aug 2007, 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>. > > 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. I do concede on the point that almost no one uses it. As a transit provider, we have disabled IPv4 source routing. We have done this to protect our network. We don't want our routers to do expensive software based forwarding decisions. We don't want to allow customers dictating traffic engineering decisions within our network. Unfortunately, our only recourse is to turn off source routing and drop all packets that have any source routing options. It would be better if we had the capabilities to ignore source routing options. This way each network could make its own security decisions instead of the transit ISPs acting like a firewall for the Internet and deciding what traffic is good for the Internet. How would ignoring source routing work? ------------------------------------------------------ Routers could be configured with one of three options: 1. drop all packets with source routing options. Current "no-source-route" or "no ip source-route" 2. ignore source routing. Use standard forwarding if the destination is not the local router. If the destination is the local router discard the packet. 3. honor source routing. This would allow for a given network to protect itself and not be used for source routing, but would not prevent network beyond your network from honoring source routing. For example take customers A, B and C who are connected to ISP1. ISP1 does not want their routers to be used as a source routed node, so they configure ignore-source-route. Customer A and customer B as two consenting adults may decide to support source routing. This could allow customer A to source a packet that will be source routed inside customer B's network. Since the packet does not have a destination of a router in ISP1's network it will just transit ISP1 like any normal traffic. When it reaches customer B, since they support source routing, the traffic will be source routed. Customer C may configure no-source routing. Customer A may send packets that are to be source routed inside customer C's network. In this case the ISP1 will transit the traffic to customer C's network where it will get dropped. Customer A may try to source route a packet in the middle of ISP1's network. In this case ISP1 will carry the traffic to the middle of the network, where the router that is the next hop destination will discard the traffic. __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering [EMAIL PROTECTED] UUNET / Verizon [EMAIL PROTECTED] The good news about having an email address that is twice as long is that it increases traffic on the Internet. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
