On 29 Sep 2001, Paul Vixie wrote:
there has to be a limit.
A limit is needed, but the filtering method in question to me essentially says this: if you have 64.x.x.x/15, slice it into as many /20's as you can and bloat as much as you want.. we feel this is an acceptable practice. Yet, if you're a legitimately multihomed customer wants to push out a single /24 (1 AS, 1 prefix) that is not considered acceptable. The only kind of prefix filtering I would want to implement is something that can accomplish: 1. Define threshold, say /20 or /18 or hell even /8. 3. all prefixes longer than threshold get held until entire tables are loaded 3. start looking at the longer prefixes across the entire ipv4 space starting with the longest and finishing at threshold+1 4. if prefixes longer than threshold appear as part of a larger aggregate block that *originate* from the same AS, drop. 5. if prefixes longer than threshold originate from a different AS than the aggregate, accept. This way I could get rid of redundant information yet at the same time not cause any trouble to smaller multihomed customers. I'm not saying that we should allow /32's to be pushed everywhere either. As you said there has to be a limit, and /24 seems to be a pretty good one if something along the lines of the above mentioned filtering algorithm could be used. I'm sure in reality there's many reasons this would not be able to be implemented (CPU load perhaps) but it would atleast do something more than a "gross hack" that nails some offenders, not all by any means, and impacts multihomed customers who are only a portion of the problem that the current prefix filtering solution does not solve. paul