Two scenarios that are much less harmful are when there is only 1 address in only one RH0: 1) when the intermediate destination address and the final destination address are addresses of the same node. 2) when the final destination address is equal to the source address.
In both cases, the intermediate destination isn't being used as transit between two other nodes. A sample use case of the second scenario is for a round-trip traceroute. -Dave -----Original Message----- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 10:44 AM To: [EMAIL PROTECTED] Cc: Brian Carpenter; IETF IPv6 Mailing List Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues] > 1) Deprecate all usage of RH0 > 2) Recommend that RH0 support be off by default in hosts and routers > 3) Recommend that RH0 support be off by default in hosts > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number > of addresses in one RH0. My preference is 2 or alternatively 1. I am currently not aware of any real use case for Type 0 header (but please educate me if there is some). It has been known to be dangerous for a long time and without a use case, it seems waste of energy to work on 4 or other more detailed limitations to make it safe. In particular I would very much like to see us publishing the RFC deprecating/turning this off soon. Developing the rules for 4 is possible, but it will take time. More fundamentally, I believe functions like this need to be tailored to a specific need before they can be made restricted enough to be safe and useful at the same. This is what was done with Type 2, for instance. If we will see a future need for something like this, I suspect that it may need a new Type number anyway. Alternative 3 is an interesting one. It would actually align IPv6 with current IPv4 specifications. RFC 1812 calls for a configuration option to turn off source routes, but requires the default to be that the source routes are processed. I'm not sure this is right, however... perhaps we should update corresponding IPv4 specifications at the same time, too. Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
