Re: RFC 1918

["Todd R. Stroup" <tstroup () tomahawk dartas com>]

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 <jamie.rishaw () mypotential com>
To: 'Bennett Todd' <bet () rahul net>; Gary E. Miller <gem () rellim com>
Cc: <nanog () merit edu>
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