North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: 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, 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
|