nanog mailing list archives

Re: revised ACL 112 ?


From: Philippe Strauss <philippe.strauss () urbanet ch>
Date: Sun, 20 Jun 1999 23:29:56 +0200


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
--



Current thread: