Hi Jason, Hi *, Jason Schiller <[EMAIL PROTECTED]> writes:
> 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 1 for all the reasons provided by Joe in a previous post. > 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. And even better if we had the insurance that all devices do not process RH0 at all. > instead of the transit ISPs acting like a firewall for the Internet and > deciding what traffic is good for the Internet. IPv6 without RH0 is good for the Internet (ISP, networks and users). It has no specific additional prerequisites for users and operators as it follows their expectations, i.e. it flows End-to-End. Furthermore, its associated operational cost is null and it does not remove any _useful_ functionality (as already discussed on the list). Trying to secure RH0 use in the Internet has a cost (implementation, education, configuration) and an already proven null ROI (even negative given the time lost in past decade to specify it, implement it and ... deactivate it). Having a rock solid infrastructure for IP communications (simple, reliable and efficient) is certainly preferable to a pick-up-sticks structure that will collapse if one of the hypothesis on which it is built does not hold anymore. Regards, a+ -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
