I shall post the text of the filter here tomorrowishly so that everyone can look at how gross it is, comments-and-all. Meanwhile, however, it seems correctly to implement this policy, which is now many months old:
reject BGP announcements which:
-- are an old-style classful A network with a mask longer than 8 bits except for exp39, 39.0.0.0/8, where we allow prefixes to be up to 24 bits long and the two operational IBM prefixes: 9.20.0.0/18 and 9.2.0.0/16.
Class A network addresses are large, too large. That's why the Class A subnetting experiment was run, so that Class A's can be used when Class C and Class B space runs out; when Class A subnets start being delegated to different ASes a different policy will have to be used for filtering routes in Class A space. Why not allow prefixes upto /12 (or maybe even /14) in Class A space now? What length prefixes does Sprint plan to allow in Class A space in the future? What about others? Is it too early to talk about this? Knowing this could help the NICs allocate better. Also, I suspect a number of providers are ready to start using Class A subnets now, at least for internal purposes (such as dialup SLIP/PPP), probably for some customers with CIDR-capable equipment, and probably for single-homed customers with CIDR-incapable equipment who just default. I wasn't able to be at the Pittsburg NANOG meeting; was the use of Class A subnets talked about?
-- are an old-style classful B network with a mask longer than 16 bits -- are in the range of 206.0.0.0/8 to 239.0.0.0/8 with a mask longer than 18 bits -- has a mask longer than 24 bits
[RSN we will also reject RFC1597 prefixes in this list; currently another mechanism is used to avoid hearing RFC1597 prefixes.]
Note that we accept prefixes in the range of 192.0.0.0/8 - 205.0.0.0/8 (known cordially as The Swamp) as long as the prefix is at least 24 bits long. ^^^^^ Perhaps you meant most. I'm not being pedantic; it would be bad if you really meant "least."
There has also been some talk about relaxing the maximum mask length on 1.0.0.0/8 - 126.0.0.0/8 to something a bit longer.
See above.
I suspect all of this will be revisited at intervals, however, I believe that the consensus at the NANOG in Pittsburgh was that it'd be a good idea to post things like this here.
Penultimately, this filter is currently deployed at all of SprintLink's edges, but not within ICM AS 1800. This is principally to allow for differential comparisons between what long prefixes the two networks see over the next short while. That makes it easier to see what we're filtering out on the SprintLink side, in hopes of catching botches and spending a couple of days firing off email to people responsible for announcing long prefixes, explaining why they should stop.
Perhaps manufacturers of the sort of routers you use could add a feature whereby incoming announcements rejected by filters are logged, perhaps by forwarding the announcements in question to a log host via BGP itself (IBGP probably) or else via syslog.
Sean. - -- Sean Doran <smd@sprint.net>
Nick