Re: filtering long prefixes

[Nick Williams <nmw () haven ios com>]

> 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