On 16-mei-2007, at 16:51, Tim Enos 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.
I don't think forbidding people from implementing RH0 is warranted. And having two RFCs, one that says you MUST implement it and another that you MUST NOT, is BAD. The proper way to do this is to write a new IPv6 specification where RH0 is absent.
Since the draft (if approved) would officially deprecate the use of RH0, that is what compliant implementations would do.
No. Do we have an official IETF definition of "deprecate"? In my book, this means that a feature is considered not useful and should not be implemented or used. That's a different thing than saying all complying implementations are prohibited from implementing or using something.
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,
There are countries in this world where (almost) any idiot can go into a store and buy a gun. There are dangers associated with that. Having RH0 enabled the way it is currently is an inconvenience; this feature in and of itself poses no danger.
The firewall issue is immaterial: firewalls should filter properly. The DNS anycast issue is immaterial: there is no danger in being able to send packets to an unexpected anycast instance. The only real issue is the DoS amplification issue.
However, it seems that few people realize that this can only happen in badly configured networks: in order for the amplification to happen, a packet must ping-pong between two nodes without source address validation (ingress filtering) on the intermediate links, or if there is a source address validation, the source address is valid in each direction. With proper ingress filtering, a source address can never be valid in both directions. So either the A and B nodes that the packet flows between are both in the same AS, or at least one of them doesn't implement proper ingress filters. In the former case, they should disable source routing. In the latter case, they should enable ingress filtering. In both cases, that's something that can be implemented within the AS that suffers from the abusive traffic, so whenever this problem occurs, it will be dealt with swiftly. The argument that ingress filtering isn't possible doesn't apply, because no equipment is both old enough that it can't perform simple filtering and new enough that it can run IPv6.
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.
If you disable source routing, there won't be any source routing. How does this leave the problem unsolved???
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
Right. So disable it by default, let people enable it if they want to.
Respectfully, I don't think I've seen a convincing enough case for RH0 use.
Yes, and as soon as you are elected the first president of the world you get to make decisions about what's good for the entire world's population.
People are old and wise to make their own decisions.
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.
Changing the IP specification is something we should think long and hard about, and we tend to do that every time we do. Taking a few weeks to decide to forbid people from using a feature that has been available for a decade is not good standards making. Brian and Bob made the right call, let's do what they suggest and not stumble over our own feet for the sake of being seen addressing "security" issues.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
