|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: RFC 1918
Actually, when I worked there, the only groups that were using RFC 1918 were some internal test networks at Ohio State University and the internal network of the State of Ohio (both of these organizations used a mix of real and 1918 space). OARnet has never had and will never have control over those organizations and their network policies. At the time of my departure in 1996 we mostly used a couple of /24's out of our 199.18/16 for serial connections. To www.utoledo.edu 13 tlp1-atm1-1-0.toledo.oar.net (199.18.202.51) 43.366 ms 54.371 ms 43.360 ms 14 utoledo-atm2-0s1.toledo.oar.net (199.18.111.90) 44.644 ms 44.263 ms 44.405 ms 15 www.utoledo.edu (131.183.1.7) 44.781 ms 45.440 ms 44.609 ms To www.akron.edu 13 alp1-atm6-0.akron.oar.net (199.18.202.71) 42.051 ms 41.962 ms 42.196 ms 14 uakron1-atm2-0s1.akron.oar.net (199.18.101.42) 42.090 ms 41.844 ms 46.048 ms 15 130.101.18.1 (130.101.18.1) 42.837 ms 45.823 ms 42.534 ms 16 mulder.cc.uakron.edu (130.101.5.50) 46.281 ms 42.777 ms 41.934 ms To www.udayton.edu 13 dlp2-atm2-0.dayton.oar.net (199.18.202.102) 37.537 ms 37.461 ms 50.051 ms 14 udayton-atm2-0s1.dayton.oar.net (199.18.109.14) 55.810 ms 40.436 ms 38.168 ms 15 131.238.11.5 (131.238.11.5) 39.048 ms 38.256 ms 42.208 ms 16 reliant.udayton.edu (131.238.75.30) 52.704 ms 38.672 ms 37.917 ms To www.onu.edu 13 sot1-atm1-0.columbus.oar.net (199.18.202.21) 38.906 ms 43.136 ms 37.208 ms 14 onu-sl0.columbus.oar.net (199.18.103.54) 51.666 ms 53.201 ms 53.414 ms 15 * * * 16 db01.onu.edu (140.228.8.60) 71.364 ms 64.060 ms 58.205 ms I think you get the point. T..S ----- Original Message ----- From: Jamie Rishaw <[email protected]> To: 'Bennett Todd' <[email protected]>; Gary E. Miller <[email protected]> Cc: <[email protected]> Sent: Friday, July 14, 2000 4:18 PM Subject: RE: RFC 1918 > > > > | I claim rather that most routers _never_ have an operational need > | to talk directly to random strangers, i.e. to have their interface > | addresses leak. So sure, honor RFC 1918 strictly and utterly and to > | the letter: put egress filters for the addrs that would guarantee > | that anyone who tried to traceroute through you would see timeouts > | as the replies were blocked. If that makes whingers happier, groove > | on it. If your router doesn't have any different-MTU interfaces that > | it routes between, then there's no harm in using RFC 1918 addresses > | on the endpoints of inter-router links. > > > Exactly. > > I think Vix settled that a few years back when we had this > discussion (I dont remember specifically, but I remember occasions when he > chimes in, he's usually the closing argument) :-) > > - RFC1918 addressing on *endpoint* or leaf links, is fine. > > - RFC1918 addressing on transit links, isn't the best idea, but > except for PMTUD (which arguably shouldn't even be, um, an argument) holds > no technical reasoning(correct me if i'm wrong) to abstain. > > My biggest complaint is that RFC1918 addresses for the most part > don't have in-addr (and if they do, it's generic) and debugging a problem > based on just an IP address is hard when you're talking to cluebies at > someone else's NOC. While I'm not suggesting that in-addr be created for > RFC1918 specific to each provider's arbitrary allocation of IPs (this would > defeat a lot of 1918) I do think that, in a global or public/enterprise > network, 1918 addressing on a transit link is just a bad idea. > > OARnet is doing it for "security" last I talked to them (which was > several years ago), they've been using RFC1918 on transit links for a while > now, CIP ohio-dmz.net. > > -jamie > >
|