[multiple response]
Christopher L. Morrow wrote:
I'm going to take a stab at: The next 69.0.0.0/8 release? Certainly there was some lesson learned from this, no?
I don't buy it, Chris. Are you saying that a large backbone provider can't maintain up-to-date bogon filters? In fact, I'd say they would be better at it, and if they were using the filters, then there would be less need for their customers to apply the filters and we'd have less bogon issues in the future.
Owen DeLong wrote:
Source address-based filtering in the backbone is expensive and, in many cases, non-feasible.
Most vendor equipment is easily capable of handling bogon filtering using any number of methods. This is particular true when filtering packets that are not announced bogons (such as most dDOS spoof attacks), even if announced bogon packets are allowed through.
-Jack
Certain backbones _rely_ upon bogons in order for their anti-spoof tracking to work, rather than simply filtering the spoofing to begin with. Backwards logic, but certain backbones seem to be set in their ways and unwilling to change. unwilling to use IRR data to build customer route filters, and instead requiring emailed, manually applied updates (hack spit) unwilling to filter even the most blatant of bogons unwilling to do even loose RPF I've been recommending competing backbones which seem to get at least some of those right.