filtering long prefixes

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,, where we
  allow prefixes to be up to 24 bits long
  and the two operational IBM prefixes: and

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 to
   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 -
(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 - to something a bit

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 Doran <>