From: Janet Pippin <jdp@cyberramp.net> To: nanog@merit.edu Cc: Larry Rosenman-CyberRamp System Administration <ler@cyberramp.net> Subject: 10.0.0 Date: Friday, May 30, 1997 10:53 PM
ALL: Upon trying to discover an abuse site's network location, I happened upon this:
Now, first it goes to sierra.. Then right after the trace finishes, I ran the second one..
traceroute to ns1.sierra.net (207.135.224.247), 30 hops max, 40 byte
I've noted several providers, including a couple of better-known ones, using RFC1597 addresses internally. While not a Really Optimal Solution, it does work, and if you find yourself with only a couple of class C's to work with.. I'd probably rather preserve them for my customers, and go with whatever I had to internally, as long as packets still got from A to B. The only services that should be affected by the use of such "bogus" addresses will be traceroute and any routing information passed by the device. Much more interesting is when you have to connect to several different customers, many of whom have chosen 10/8, 172.16/16, or 192.168.1/24 as their core network addresses. Looks like Sierra is a customer of Phoenix Fiberlink, who is likely dual-homed, since he's got a Sprint netblock transiting UUnet. Hope that helps. ---------- packets
1 cisco.cyberramp.net (207.158.64.1) 2 ms 1 ms 1 ms 2 166.48.80.9 (166.48.80.9) 6 ms 8 ms 13 ms 3 core3.Dallas.mci.net (204.70.4.13) 5 ms 7 ms 16 ms 4 uunet-hssi.Dallas.mci.net (206.157.77.130) 26 ms 7 ms 56 ms 5 Fddi0-0.CR1.DFW1.Alter.Net (137.39.37.35) 103 ms 13 ms 15 ms 6 108.Hssi5-0.CR1.SFO1.Alter.Net (137.39.70.221) 135 ms 312 ms 348 ms 7 133.Hssi4-0.GW1.SLT1.Alter.Net (137.39.68.10) 104 ms 121 ms 122 ms 8 pfi-gw.customer.ALTER.NET (137.39.167.18) 108 ms 171 ms 106 ms 9 207.49.13.50 (207.49.13.50) 114 ms 117 ms 112 ms 10 207.14.235.22 (207.14.235.22) 112 ms 116 ms 113 ms 11 10.0.0.2 (10.0.0.2) 116 ms 108 ms 114 ms 12 rock.sierra.net (207.135.224.247) 116 ms 112 ms 113 ms
jdp@mailhost 18 ~ > wi 10.0.0 IANA (RESERVED-6)
Netname: RESERVED-10 Netnumber: 10.0.0.0
hrmm... and the second one:
jdp@mailhost 17 ~ > t ns1.sierra.net traceroute to ns1.sierra.net (198.60.22.2), 30 hops max, 40 byte packets 1 cisco.cyberramp.net (207.158.64.1) 2 ms 1 ms 1 ms 2 166.48.80.9 (166.48.80.9) 29 ms * 5 ms 3 bordercore1-loopback.Denver.mci.net (166.48.92.1) 210 ms 252 ms 281 ms 4 electric-light.Denver.mci.net (166.48.93.254) 274 ms 273 ms 260 ms 5 F0-0.slkcib01.eli.net (207.0.56.18) 59 ms 59 ms 62 ms 6 XMISSION-DOM.slkcib01.eli.net (207.49.20.86) 64 ms 67 ms 69 ms 7 xmission.xmission.com (198.60.22.2) 60 ms * 88 ms jdp@mailhost 18 ~ >
enlighten me, someone... :(
-janet
Janet Pippin * CyberRamp Internet Services Network Administrator *** 11350 Hillguard Road jdp@cyberramp.net * Dallas, Texas 75243-8311 http://www.cyberramp.net * (214) 340-2020 (817) 226-2020
Dave O'Shea supposedly said:
I've noted several providers, including a couple of better-known ones, using RFC1597 addresses internally. While not a Really Optimal Solution, it does work, and if you find yourself with only a couple of class C's to work with.. I'd probably rather preserve them for my customers, and go with whatever I had to internally, as long as packets still got from A to B.
I would like to contidict your statement of "not a Really Optimal Solution" and state that it is a really good solution. The value of a uniques address is its routability. For purely transit links what does it matter? Using an RFC 1918 net for your internal network is a good move for providers to provide transit. It provides great flexibilty in your numbering options and as long as you don't leak your IGRP routes your AS the only thing it effects is traceroutes.
Much more interesting is when you have to connect to several different customers, many of whom have chosen 10/8, 172.16/16, or 192.168.1/24 as their core network addresses.
It shouldn't make a bit of difference since the routes should not be visable outside the individual AS. ---> Phil
On Sat, May 31, 1997 at 02:42:16AM -0400, Philip J. Nesser II wrote:
I would like to contidict your statement of "not a Really Optimal Solution" and state that it is a really good solution. The value of a uniques address is its routability. For purely transit links what does it matter? Using an RFC 1918 net for your internal network is a good move for providers to provide transit. It provides great flexibilty in your numbering options and as long as you don't leak your IGRP routes your AS the only thing it effects is traceroutes.
On top of that, it makes the InterNIC (or insert your favorite address space allocation body here) very happy to know that you are trying to stretch your existing address space as far as possible when going to ask for more. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - ahp@hilander.com | Erols Internet Services, INC. | |Network Engineer | Springfield, VA. | +------------------------------------+--------------------------------------+
I've noted several providers, including a couple of better-known ones, using RFC1597 addresses internally. While not a Really Optimal Solution, it does work, and if you find yourself with only a couple of class C's to work with.. I'd probably rather preserve them for my customers, and go with whatever I had to internally, as long as packets still got from A to B.
The only services that should be affected by the use of such "bogus" addresses will be traceroute and any routing information passed by the device.
Unfortunately that's not quite true. There are a variety of services which rely on messages received from intermediate hops that would break if the the sending host happened to filter out RFC1918 addresses and a part of the network were using them. Probably the best example is Path MTU Discovery. --jhawk
participants (4)
-
Alec H. Peterson -
Dave O'Shea -
John Hawkinson -
Philip J. Nesser II