filtering long prefixes
nmw at haven.ios.com
Thu Sep 21 19:50:08 UTC 1995
>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, 188.8.131.52/8, where we
> allow prefixes to be up to 24 bits long
> and the two operational IBM prefixes:
> 184.108.40.206/18 and 220.127.116.11/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 18.104.22.168/8 to 22.214.171.124/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 - 126.96.36.199/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 188.8.131.52/8 - 184.108.40.206/8 to something a bit
>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 <smd at sprint.net>
More information about the NANOG