This is by no means the authoritative answer, but it's from my experience
as a network engineer for an ISP that's been default-free since 1994.
Here's an email from Sean Doren from Sprint who was either the person,
or a significant part of the group who determined Sprint's BGP prefix
filtering policy in 1995 (implemented because they had a significant number
of cisco 7000's that maxxed out at 64Mb of RAM and had to limit their
table size. (further commentary after the included mail here so keep
on a-readin')
---- begin included mail-------------------------------------------------
http://www.cctec.com/maillists/nanog/historical/9509/msg00107.html
This is probably ugly and difficult to read.
It also can be trimmed, but has been left overly-long and
overly-paranoid for readability when using "show access-list
112" and because the IOS 10.3 distribute-list caching
doesn't seem to mind the extra deny clauses all that much.
Sean.
- --
! list 112 - deny more specifics of some prefixes
!
! IMPORTANT-TO-REMEMBER SYNTAX FOR BGP distribute-list!
! access-list ip
!
! clear old list
!
no access-list 112
!
! this was originally ordered A, B, C and side-effects, but
! what we really want to do is put the permit clauses up front
! starting with the swamp, as this will match the most prefixes
!
!!!!! START
!
!!!! PERMITs
!
!!! C space
!! permit /24s in 192/8-205/8.
! (192==1100 0000, 205==1100 1101)
!
! allow M = /24 below and we did /17-/23 for 0/8-191/8 above,
! so we only need to worry about 19-23 for 207/8-239/8
!
! first, in 1100 111x (206/8, 207/8)
! (if mask has 1 bits in third octet (bits 18-23), deny)
!
access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255
access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255
access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255
access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255
access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255
access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255
!
! next in 1101 xxxx (208/8-239/8)
! (if mask has 1 bits in third octet (bits 18-23), deny)
!
access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255
access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255
access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255
access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255
access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255
access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255
!
!!! all UNICAST space
!! deny ANY/24, ANY/(25-32)
! now we block the final octet for 0/8-239/8
! (because we specifically allowed /24s in 192/8-205/8, we can
! just block everything in xxxx xxxx * that has any 1 bits in 4th
octet)
!
access-list 112 deny ip 0.0.0.0 255.255.255.255 255.255.255.0 0.0.0.0
access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.128 255.255.255.127
access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.64 255.255.255.191
access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.32 255.255.255.223
access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.16 255.255.255.239
access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.8 255.255.255.247
access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.4 255.255.255.251
access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.2 255.255.255.253
access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.1 255.255.255.252
!
!!! all IP space
!! deny 240/(4-32), 0/(8-32)
! finally, we get rid of any announcements that are bogons
! 240/8-255/8 and 0/8
! 1111 xxxx * and 0000 0000 * (any mask)
! we can leave this last as it's likely almost never to happen
!
access-list 112 deny ip 255.0.0.0 15.255.255.255 0.0.0.0 255.255.255.255
access-list 112 deny ip 0.0.0.0 0.255.255.255 0.0.0.0 255.255.255.255
!
!!!!! END
end
----end included archive (btw, if you can understand every line-----
----on the above access list, you are doing very well in "getting"--
----bitmasked logic and shortcuts you can make with it--------------
On 07-May-2001, Chuck Larrieu wrote:
> I respectfully disagree. A brief look through route-server.cerf.net shows
an
> awful lot of /24's in class A space, particularly in the 24.0.0.0,
64.0.0.0,
> 65.0.0.0, and 66.0.0.0 space. Not to mention a lot in class B space. My
hand
> hurts from scrolling through the routing table there. Granted, everything
is
> relative. What cerf.net shows is not necessarily what any other provider
> shows. But I suggest that CIDR is broken and there are lots of prefixes
> longer than /19, no matter what the classful block. :->
>
> Chuck
24.0.0.0/8 was partitioned up directly by the IANA and large chunks
(possibly all of it, but I haven't dug deep enough and it's just a minor
point and not the gist of my note) given to Time Warner/@Home/Roadrunner.
63.0.0.0/8 was given to either ARIN, or if this decision was made before
ARIN, to the Internic to divide up to give to ISP's to head off the
exhaustion of class B and class C space. The key to this working was an
experiment by the IETF/ISI?? (I remember Bill Manning talking about it's
success) with 39.0.0.0/8. The issue was seeing whether IP stacks on the
net, and particularly if the IP stack vendors (especially cisco) could
support true classless routing. Ie ... would one AS who was assigned
39.64.0.0/18 be able to talk to the rest of 39.0.0.0/8 without blackholing
it because 39.64.0.0/18 is part of the classful 39.0.0.0/8 block. In
other words, the registries needed to know if the Internet would still
work (or adapt quickly enough) when they allocated SUBNETS instead of
SUPERNETS (speaking in a purely classful sense, which a good part of the
IP stacks still assumed in the early-mid nineties). The examples that you
list Chuck, are specifically blocks partitioned (or in the case of
24.0.0.0/8, assigned with the understanding that it would be announced in
a fragmented way) for registries to dole out to ISP's.
The above listed access-list 112 didn't make exceptions for 24/8, 63/8,
and the others that followed. That specific access-list was applied to
a very large number of ISP's that followed NANOG, including the one I
work for. On a side note, part of the motivation was that SPRINT was
applying this filter only on the inbound side. They allowed their customers
to announce more specific prefixes outbound and it provided them with
a bit of a competitive advantage because, if you had to announce greater
than a /19 from non-swamp space, you had to have a Sprint connection, or
you couldn't talk to them. Everyone else adopting the same policy evened
the playing field and made it so that if you didn't fit in that policy,
it didn't matter who you connected through, you were broken with regards
to communication with some part of the net.
You can find the "others that followed" at:
http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space
64/8, 65/8, and others are part of that space that followed and are
assigned by ARIN on classless prefixes. RIPE and APNIC have other /8's.
Now, pre-1995, there were parts of the class C space that were doled out
in allocations as long as /24's (note that this still means classful
allocations). The range is 192/8-205/8. Up until about 3 years ago,
these were the only /24's that could be counted on to be globally
routable (accepted by the vast majority of the bgp input filters).
There were some huge problems with the Internic allocating on /20
block sizes in the 206/8 space (in their slow-start method) while
Sprint, and others, were still filtering on a /19 or greater in
swamp space. This specific issue was why an ISP customer of mine
sold his /20 and renumbered into a /19 that I allocated to him.
After the IANA allocated 24/8 to the cable companies for subnetting
and 63/8 came out, we all had to modify our filters to make exceptions
for those prefixes. The early recipients of those blocks had to do a
lot of tracking down connectivity problems and convince the filtering
ISP's to make these changes. Finally, many ISP's went to generic filters
that allowed all /24's and shorter except for martians (no RFC1918,
multicast, etc netblocks) as the carving up of traditional class A space
became more common, routers with 128Mb+ RAM capacity took over their
infrastructure, and the fragmenting of the routing registries made
management of these filters less neccessary and less needed. I myself
made that change after the UPS fragmented their 153.2/16 block and
we had customers who couldn't reach their tracking website.
Still, even today, if you were to take 206.109.0.0/16 (one of my blocks)
and announce it as specific /24's, there will be networks out there who
won't be able to communicate with me because of legacy filters. It's
definately not as common, nor is it considered "common practice" just
in that last couple of years, but it's still an annoying reality.
> From: Brian [mailto:[EMAIL PROTECTED]]
>
> many providers filter based on the classful origin of the space. If the
> block is out of what was once class a or b space, the likelihood of a /24
> getting filtered out is fairly high. My previous employer did that.
"fairly high" is fairly low nowdays and is shrinking, but yes, it still
exists a lot more than we wish it did.
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> > Murphy, Brennan
> >
> > Cisco told me today that a /24 drawn from Class C space
> > has a better chance of being propogated throughout the Internet
> > than a /24 taken from Class B space. Anyone disagree with that?
> > Can anyone recommend a good source of info on this. Ive checked
> > Halabi.
That someone from cisco is probably passing on the net folklore about
swamp space being "more likely to pass filters" than "classful subnets"
will. Again, it's likely, but it will affect ever shrinking parts of
the net. To this day, we discourage people from depending on more
specific announcements making it through (especially when people want
to announce their /24 out of UUNet space, etc), but depending on the
application and tolerence to a specific person not being able to reach
it, it can be acceptable.
---------------------------------------------------------------------------
** Andrew W. Smith ** [EMAIL PROTECTED] ** Chief Network Engineer **
** http://www.neosoft.com/neosoft/staff/andrew ** 1-888-NEOSOFT **
** NeoSoft, Inc. An Internet America Company 1-800-BE-A-GEEK **
** "Opportunities multiply as they are seized" - Sun Tzu **
---------------------------------------------------------------------------
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=3556&t=3506
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
