North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: filtering long prefixes

  • From: Nick Williams
  • Date: Thu Sep 21 15:51:22 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, 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 <[email protected]>


Nick