Hi Iljitsch/all, >On 16-mei-2007, at 10:05, Ebalard, Arnaud wrote: > >> Should (can) something like the following be added to the draft ?: >> "Conformant implementations of IPv6 hosts and routers MUST not >> provide a way to activate RH0 processing on the system." > >This is a very bad idea for two reasons: > >1. The IPv6 spec says that you MUST implement it, then having >something else say you MUST NOT actually use it is just bad standards >making
That a spec says something which (upon further reflection of working group members and others) is bad is not seemingly a valid reason to keep saying it. That said, the point of the two extant drafts on the RH0 subject (to be combined as one) is to update the IPv6 spec. Since the draft (if approved) would officially deprecate the use of RH0, that is what compliant implementations would do. The MUST in the base spec would (for lack of a better term) be superseded by the "MUST NOT" in the draft. > >2. Maybe someone has a legitimate use for this, they should be able >to do so if they want Given the dangers associated with RH0, the possibility that there would be a "legitimate use" of it seems to be precluded. > >This whole issue is blown WAY out of proportion: the BSD guys should >not forward when forwarding is disabled, the router guys should >disable source routing by default (for IPv4, too, please). Problem >solved, bring on the next one. Not really solved by simply disabling. Implicit in disabling something by default is: *that there is something sufficiently bad about it which precludes its use (at least in the general case) *that there could be a legitimate (corner?) use case for which its use is valid *that it therefore can be subsequently enabled Respectfully, I don't think I've seen a convincing enough case for RH0 use. It seems at most to be a "nice-to-have", yet in no case IMO is it a "got-to-have" (especially given the dangers associated with it). > >If, at some later date, it turns out nobody uses this feature, rip it >out of the next iteration of the IPv6 spec. It seems there is both a sufficient lack of use of this feature and sufficient evidence and consensus that it ought not be used to justify its (de facto) removal via approval of the draft. I would think the next iteration of the IPv6 spec would reflect this. But please, let's not >overreact. Compared to what we had to go through with directed >broadcast amplification (smurf attack), this isn't much of an issue >at all, even if you ignore that IPv6 uptake isn't above 0 in a >statistically significant way yet. > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >[email protected] >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- Best Regards, Tim Enos Rom 8:28 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
