- Test - lists.nanog.org

RFC 1918
by Shawn McMahon 14 Jul '00

14 Jul '00

Some naughty person in either BBNPlanet or DeltaCom needs to re-read RFC 1918: traceroute to www.everybuddy.com (209.16.236.3), 30 hops max, 38 byte packets <snip> 12 p1-0.tamqfl1-cr4.bbnplanet.net (4.24.7.186) 50.724 ms 49.658 ms 50.428 ms 13 p0-0.itctampa.bbnplanet.net (4.24.176.6) 44.791 ms 44.299 ms 45.233 ms 14 10.254.0.14 (10.254.0.14) 46.290 ms 45.467 ms 47.701 ms 15 10.52.1.10 (10.52.1.10) 44.798 ms 46.038 ms 48.682 ms 16 1.ATM10-1.IDGAUB7513.TR.deltacom.net (209.192.87.198) 48.998 ms 49.069 ms 49.670 ms <snip>

4 3

Re: Mostly operational content (was Re: piracy on parade)
by Steven M. Bellovin 14 Jul '00

14 Jul '00

In message <000801bfede1$db5ca690$aba4b9d0@PEREGRIN>, "Roeland M.J. Meyer" writ es: > >> Right. Have a look at the IAB statement on the subject of DNS >roots: >> http://www.iab.org/iab/IAB-Technical-Comment.txt > >Yes, pure politics, zero operational content. When was the last >time the IAB released a technical, politically neutral paper? >Ans: a ver long time ago (years). That paper caused me to cast a >negative vote for Brian Carpenter, in the last ISOC elections. >They presented zero technical support for their position. It was >all anecdotal, pure opinion, no substance. I suspect I'm going to regret even responding to this, but... Did you even read that document before posting? It's purely technical -- it outlines the purely-technical reasons why the DNS has to have one root if we're to have effective communication on the net. As for technical papers -- if nothing else, there are the workshops the IAB sponsors; the reports of those workshops are also on the IAB Web page. The report on the Network Layer workshop is about to be released; there are also forthcoming RFCs on QoS and security. > >I submit that the IAB isn't doing its job and until they do, they >should refrain from wasting their resources in the policy arena. > I suspect that the entire IAB wants to spend less time on politics -- I know I'd rather stick to the technical stuff. But external affairs are explicitly our responsibility, per RFC 2580 and its predecessort, RFC 1601. --Steve Bellovin

1 0

Re: Mostly operational content (was Re: piracy on parade)
by Steven M. Bellovin 14 Jul '00

14 Jul '00

In message <20000714130518.J24018(a)mail-abuse.org>, "J.D. Falk" writes: > >On 07/14/00, Valdis.Kletnieks(a)vt.edu wrote: > >> But seriously - there's serious operational considerations involved if >> everybody doesn't have a consistent view of the DNS root - it's called >> Balkanization. > > Very true. There are some who don't care about that, but in > all the years they've been proposing alternate roots (and I, > too, was in favor of the idea for a few months, early on), not > one has ever had more than a handful of real users -- IMHO, > this is due at least in part to the fact that the spokespeople > for these schemes confuse invective with salesmanship. > > If your goal is to provide customers with access to the entire > Internet, and to provide the entire Internet with access to > your customers, then you'd be doing them a disservice if you > encourage them to use non-standard top-level domains. Right. Have a look at the IAB statement on the subject of DNS roots: http://www.iab.org/iab/IAB-Technical-Comment.txt --Steve Bellovin

2 1

RE: piracy on parade
by Jamie Rishaw 14 Jul '00

14 Jul '00

| Joe Baptista will be spamming all of the SLD owners with notices about | the new system, and Bob Allisat will post to | comp.protocols.tcp-ip.domains | with his NNTP client set to wrap at 40 characters. | | It'll happen. I guarantee it. *Dies laughing* Steve. C|N>K. I wonder where Jim Fleming's been. Haven't heard from him in a while. I'm just wondering who will register nic.s0.g0 ??? :-) -jamiE

1 0

RE: piracy on parade
by Roeland M.J. Meyer 14 Jul '00

14 Jul '00

I have a lot of leads for this at www.dnso.net From there you can get to the ORSC sites and a few others. Examples of how to build your own root-zone files are at http://files.dnso.net along with a few papers MHSC has submitted to ICANN/WG-C and other places. Both MHSC and ORSC root-zone files can be found there. <Fair-warning> This is the begining of the trail into the flame-laden domain-policy warz. If you don't want to deal with that then don't travel too deep. </Fair-warning> > -----Original Message----- > From: Brian J. Murrell [mailto:bmurrell@turbolinux.com] > Sent: Friday, July 14, 2000 4:29 AM > To: rmeyer(a)mhsc.com > Cc: jim(a)reptiles.org; vixie(a)mibh.net; nanog(a)merit.edu > Subject: RE: piracy on parade > > > from the quill of "Roeland M.J. Meyer" <rmeyer(a)mhsc.com> on scroll > <000201bfed56$99e475c0$eaaf6cc7@PEREGRIN> > > > > BTW if you really want to get hold of Joe, find him at > > http://www.dot.god > > > > If you need a resolving server to get there, use NS1.MHSC.NET. > > Kinda off the topic a bit, but can somebody point me to a doc > as to how > I can "augment" my root server list in BIND-8 to include an NS record > for GOD. of NS1.MHSC.NET. It does not seem to be as > straightforward as > one would think (by seeding the hints file with an NS and A record). > > The only way I have been able to achieve this sort of thing is with > forwarding zones and forwarders. It's messy and doesn't scale well. > > Thanx, > b. > w > > > > -- > TurboLinux, Inc.

5 6

Re: RFC 1918
by Steven M. Bellovin 14 Jul '00

14 Jul '00

In message <Pine.LNX.4.21.0007141236200.16371-100000(a)ns1.aplatform.com>, "Gary E. Miller" writes: > >Yo Bennet! > >Sounds like circular reasoning: > >Path MTU discovery is broken beacuse poeple use RFC1918 addresses in routers. > >Since Path MTU discovery is broken then there is no need to follow RFC1918. No -- 1918 addresses would only break PMTU if folks did ingress or egress filtering for 1918 addresses. A much bigger cause of the breakage firewalls that block the ICMP message. And most people don't notice or care, because there's been so little need for PMTU in recent years. But that will change, as assorted tunneling technologies become more popular. --Steve Bellovin

3 2

Re: RFC 1918
by Danny McPherson 14 Jul '00

14 Jul '00

> Sounds like circular reasoning: > > Path MTU discovery is broken beacuse poeple use RFC1918 addresses in routers. Actually, PMTU isn't broken just because people use RFC1918 in routers. It's broken because people use RFC1918 in routers and other people (or perhaps the same) filter packets with RFC1918 SAs. -danny

1 0

Re: RFC 1918
by Patrick W. Gilmore 14 Jul '00

14 Jul '00

[SNIP] We had a similar discussion a long while ago (2 years?) on whether having RFC1918 addressed router interface could break Path MTU discovery. The general upshot is that the RFC specifically says that no packets with a reserved address in the header (source or destination) should leave the network in question. Also, the RFC says it is not at all unreasonable (but not required) for a network to filter packets with RFC1918 addresses in the source. (To prevent attacks and things like that.) So it is nearly impossible to stay 100% compliant and address router interfaces with RFC1918 addresses. (Unless you NAT or something.) All IIRC - I did not dig up the thread to double-check. TTFN, patrick P.S. Please do not yell at me about this, I am just summarizing a past thread I thought might be relevant. I got yelled at enough during the last thread where I argued that it was not such a bad thing 'cause it conserved space and stuff. Really, I only need 14 people to point out the sections of the RFC I missed before I get the point. :p

3 3

Re: RFC 1918
by Danny McPherson 14 Jul '00

14 Jul '00

> We had a similar discussion a long while ago (2 years?) on whether having > RFC1918 addressed router interface could break Path MTU discovery. > > The general upshot is that the RFC specifically says that no packets with a > reserved address in the header (source or destination) should leave the > network in question. Also, the RFC says it is not at all unreasonable (but > not required) for a network to filter packets with RFC1918 addresses in the > source. (To prevent attacks and things like that.) > > So it is nearly impossible to stay 100% compliant and address router > interfaces with RFC1918 addresses. (Unless you NAT or something.) Of course, if you use RFC1918 space for internal addressing, then filter all RFC1918 SA both ingress _and egress to your network, you'd in theory be 100% compliant (whatever that means). You'd just be handicapping traceroute, PMTU and the like .. but of course, if folks have a problem with it :-) -danny

1 0

The Cidr Report
by Tony Bates 14 Jul '00

14 Jul '00

This is an auto-generated mail on Fri Jul 14 12:00:00 PDT 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 14Jul00 0) General Status Table History ------------- Date Prefixes 070700 81549 080700 81249 090700 81150 100700 81258 110700 81337 120700 81502 130700 81740 140700 82006 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.56.64.0/21 from AS2941 AS Summary ---------- Number of ASes in routing system: 7900 Number of ASes announcing only one prefix: 4446 (2454 cidr, 1992 classful) Largest number of cidr routes: 960 announced by AS701 Largest number of classful routes: 1078 announced by AS701 1) Gains by aggregating at the origin AS level --- 14Jul00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 435 152 283 65.1% BCnet Backbone AS7046 610 400 210 34.4% COQUI-NET PRTC Internet AS1221 555 397 158 28.5% TELSTRA-AS AS9706 153 26 127 83.0% Pusan Metropolitan City Office of AS2609 128 8 120 93.8% EUnet-TN AS7657 298 190 108 36.2% The Internet Group Limited AS9304 123 17 106 86.2% Hutchcity AS7545 155 57 98 63.2% TPG Internet Pty Ltd AS6429 211 115 96 45.5% RDC-INTERNET AS705 350 259 91 26.0% ALTERNET-AS AS7496 127 39 88 69.3% Power Up AS174 558 470 88 15.8% Performance Systems International AS9269 153 66 87 56.9% Hong Kong CTI AS577 268 181 87 32.5% Bell Backbone AS4293 330 243 87 26.4% Internal ASN for C&W AS724 227 156 71 31.3% DLA-ASNBLOCK-AS AS701 1078 1009 69 6.4% Alternet AS1727 159 92 67 42.1% MRMS-WEST AS3908 261 195 66 25.3% Supernet, Inc. AS5106 93 34 59 63.4% AADS-COLUMBUS AS3749 119 60 59 49.6% TECNET AS6595 108 50 58 53.7% DODDSEUR AS4755 151 93 58 38.4% Videsh Sanchar Nigam Ltd. India AS7568 81 24 57 70.4% C.S. Communications Co., Ltd. AS4740 348 291 57 16.4% Ozemail Pty Ltd (ASN-OZEMAIL) AS3602 299 243 56 18.7% Sprint Canada Inc. AS7018 549 494 55 10.0% AT&T WorldNet Service Backbone AS2764 479 425 54 11.3% connect.com.au pty ltd AS1785 360 311 49 13.6% NYSERNet Backbone AS209 266 218 48 18.0% Qwest Communications For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0