- NANOG - lists.nanog.org

Re: RFC 1918
by Michael Shields 15 Jul '00

15 Jul '00

In article <20000714194722.AD3EA35DC2(a)smb.research.att.com>, "Steven M. Bellovin" <smb(a)research.att.com> wrote: > No -- 1918 addresses would only break PMTU if folks did ingress or > egress filtering for 1918 addresses. It is easy to argue that using interface 1918 addresses and PMTUD are incompatible with connecting to the Internet, for PMTUD requires sending an ICMP message with the source address of the interface, and using 1918 space on the Internet is not allowed. RFC 1918 section 3: "In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. [...] However, they cannot have IP connectivity to any host outside of the enterprise." "Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage." -- Shields.

3 2

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