On Fri, Jun 18, 1999 at 12:55:16AM -0700, I Am Not An Isp wrote:
At 11:37 PM 6/16/99 +0200, Philippe Strauss wrote:
The exact access list is the one Sean described on this list in 1995, available at http://www.ianai.net/filters/Sprint-ACL112
Something I had forgotten was pointed out to me by a friend. THAT LIST CONTAINS ERRORS - YOU ARE DENYING VALID ROUTES. And I do not mean just those with masks longer than 19 bits.
Specifically, from http://www.cctec.com/maillists/nanog/historical/9509/msg00107.html, we see:
! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *) ! (allow mask bits in first 18 bits) ! 1100111x == {206,207} ! 1110xxxx == {208-239} ! access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 239.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0
Which *should* be:
! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *) ! (allow mask bits in first 18 bits) ! 1100111x == {206,207} ! 1101xxxx == {208,224} ! 1110xxxx == {224-239} ! access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 208.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 224.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0
Oh ok, quiet a nice chunk of adresse space left on the floor there :-)
(Ignoring the fact that /19s were just allowed in 206/8 in the line before. :)
This was a very early rev of 112, posted by Sean here on NANOG. (The earliest I could find, in fact.) First of all, you are blocking even /19s in all but 206/8, allowing /18s. But you are *completely* blocking 208-224, as there is no permit statement for them.
I am sorry, I never intended that page to be USED by anyone, it was strictly there for historical/reference purposes.
Yes, I've used it because it was the only version of Sean's ACL112 I've found. My goal was just to experiment about how isp's desaggregate ip space relative to how assigning authorities distribute it. I've deployed this ACL on a stub AS, with a default route pointing to one of my transit provider.
Philippe, if you are going to use something like a modern ACL112, please check out Sean's later posts in the NANOG archive.
OK, thanks for the advice. Will look the archive. But for production, I stick to your ACL190. Anyone having references about how assigning authorities claim to aggregate address space? (I know that RIPE never allocater longer than /20 in 195.0.0.0/8) ACL112 take various assumption, were are the reference information about that?
I shall update the page soon with a correct version of 112, and a corrected/updated version of my filter from the merit page. Sorry if anyone else has used this filter.
Philippe Strauss, ingenieur reseau/systemes, Urbanet SA
TTFN, patrick
P.S. I am no way implying this is Sean's fault. The web page is an early, untested version and I really never meant for anyone to actually USE it. In fact, there is no link to the list anywhere on any of my other pages or anything like that. Philippe must have attended one of my classes or something, where I specifically stated it was an early, broken version.
Altavista found it for me :-) Try ACL112 and look the result. Time to write a robot.txt :-)) Thanks for you time.
-- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (No, I still don't have enable. ;-)
-- Philippe Strauss, ingenieur reseau/systemes, Urbanet SA philippe.strauss@urbanet.ch tel +41 21 623 30 20 --