Mailing List Archive: 10.0.0

10.0.0

May 30, 1997, 8:53 PM

Post #1 of 13 (478 views)

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 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
- - - - - - - - - - - - - - - - -

Re: 10.0.0 [ In reply to ]

GAVRON at ACES

May 30, 1997, 9:20 PM

Post #2 of 13 (478 views)

Permalink

This does not belong to NANOG. I'm only CCing so you're not
inundated with responses.

1. A host can have multiple addresses. These do not have
to be on the same network. It's a redundancy thing.
Since the host in question is a nameserver, it's even
more reasonable.

2. Reserved addresses can be used anywhere. They are just
not supposed to be leaked into the public internet.

sigh.

Ehud

> 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 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
- - - - - - - - - - - - - - - - -

Re: 10.0.0 [ In reply to ]

doshea at mail

May 30, 1997, 9:43 PM

Post #3 of 13 (477 views)

Permalink

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.
----------
> 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
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
- - - - - - - - - - - - - - - - -

Re: 10.0.0 [ In reply to ]

pjnesser at martigny

May 30, 1997, 11:42 PM

Post #4 of 13 (476 views)

Permalink

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
- - - - - - - - - - - - - - - - -

Re: 10.0.0 [ In reply to ]

jared at puck

May 30, 1997, 11:46 PM

Post #5 of 13 (476 views)

Permalink

Ehud Gavron boldly claimed:
> This does not belong to NANOG. I'm only CCing so you're not
> inundated with responses.
>
> 1. A host can have multiple addresses. These do not have
> to be on the same network. It's a redundancy thing.
> Since the host in question is a nameserver, it's even
> more reasonable.

True.

> 2. Reserved addresses can be used anywhere. They are just
> not supposed to be leaked into the public internet.

Also true, but please re-examine this traceroute:

> >traceroute to ns1.sierra.net (207.135.224.247), 30 hops max, 40 byte packets
> > 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

You can have an internal mesh made up of entireley rfc1918 address
space, and not leak these routes to the rest of the world, I've only
once caught MCI leaking stuff from a test lab, which was kinda annoying,
but not really anything bad, and a polite e-mail message to them got
an immediate fix of the problem.

that next-hop is only relevant to someones local lan, but you
can't traceroute to 10.0.0.2, otherwise someone is doing something naughty.

I ran into this before I realized this could be done in this
fashion, and asked a few questions around and got an answer as to how
it worked.

If your parser is having problems with this message, please ask
me any questions, and I can clarify any questions you have.

- jared

--
jared@CIC.Net - CICNET --------- jared@Nether.Net - Nether Network
"I've got a question" "What is it?" "An interrogative expression often used
to test knowledge, but that's not important right now."
- - - - - - - - - - - - - - - - -

Re: 10.0.0 [ In reply to ]

danny at genuity

May 31, 1997, 1:10 AM

Post #6 of 13 (475 views)

Permalink

> You can have an internal mesh made up of entireley rfc1918 address
> space, and not leak these routes to the rest of the world, I've only
> once caught MCI leaking stuff from a test lab, which was kinda annoying,
> but not really anything bad, and a polite e-mail message to them got
> an immediate fix of the problem.
>

i'd think most providers filter rfc1918 addresses both inbound and outbound at
naps (mci does, i believe), although maybe not to customers...

using reserved address space internally (as long is it remains internal),
seems like a good idea to me - isn't that why it was reserved?

-danny

- - - - - - - - - - - - - - - - -

Re: 10.0.0 [ In reply to ]

pferguso at cisco

May 31, 1997, 4:20 AM

Post #7 of 13 (473 views)

Permalink

Of course, RFC1918 addresses should not appear in the global
routing table. This is a fine example of people not taking
the responsibility to ensure [filter] that if they do use
them, they do not leak.

- paul

At 10:53 PM 05/30/97 -0500, Janet Pippin wrote:

> 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 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
>
>
- - - - - - - - - - - - - - - - -

Re: 10.0.0 [ In reply to ]

bil at zeus

May 31, 1997, 5:07 AM

Post #8 of 13 (474 views)

Permalink

<written about another example>
> Of course, RFC1918 addresses should not appear in the global
> routing table. This is a fine example of people not taking
> the responsibility to ensure [filter] that if they do use
> them, they do not leak.
>

A couple of weeks ago we received a complaint from a customer of a
customer. They could get to some places but not others including us.
This is the traceroute that the dialup customer generated trying to hit
one of my customers.

1 121 ms 124 ms 112 ms wchspawcsap01.bellatlantic.net[192.168.107.173]
2 114 ms 118 ms 161 ms 192.168.107.174
3 126 ms 123 ms 123 ms 206.125.197.69
4 304 ms 292 ms 261 ms ATM5-0-9.dc01.IConNet.NET [204.245.127.157]
5 132 ms 135 ms 126 ms mae-east.netaxs.net [192.41.177.87]
6 159 ms 136 ms 136 ms philly-dc-gw-t3-h3-0.netaxs.net[206.161.90.2]
7 146 ms 136 ms 138 ms 207.106.127.6
8 * * * Request timed out.
9 * * * Request timed out.

A doublecheck of the forward DNS gave me:
Name: wchspawcsap01.bellatlantic.net
Address: 192.168.107.173
Aliases:

It would seem that they not only use the RFC1918 addresses but they have
forward DNS set up for it, and evidently reverse DNS is set up internally for
line one of the traceroute to resolve. Or maybe I am missing something.

Bil

- - - - - - - - - - - - - - - - -

Re: 10.0.0 [ In reply to ]

jhawk at bbnplanet

May 31, 1997, 6:53 AM

Post #9 of 13 (471 views)

Permalink

> 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

Re: 10.0.0 [ In reply to ]

ahp at hilander

May 31, 1997, 7:46 AM

Post #10 of 13 (475 views)

Permalink

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. |
+------------------------------------+--------------------------------------+

Re: 10.0.0 [ In reply to ]

doshea at mail

May 31, 1997, 9:19 AM

Post #11 of 13 (471 views)

Permalink

>> 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.

I meant "services used by normal humans in the course of downloading nude
.gif's", i.e., typical Internet customers. I stand by my statement. :-)

Re: 10.0.0 [ In reply to ]

tli at jnx

May 31, 1997, 10:48 AM

Post #12 of 13 (474 views)

Permalink

doshea@mail.wiltel.net (Dave O'Shea) writes:

> >> 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.
>
> I meant "services used by normal humans in the course of downloading nude
> .gif's", i.e., typical Internet customers. I stand by my statement. :-)

As the "normal human in the course of downloading nude .gif's" should be
using Path MTU Discovery, I think you're agreeing....

Tony

p.s. .gif's are obsolete. Most everything is .jpg's, .mpg's, and .avi now.
;-)

Re: 10.0.0 [ In reply to ]

dts at openroute

May 31, 1997, 11:22 AM

Post #13 of 13 (480 views)

Permalink

At 01:10 AM 5/31/97 -0700, Danny McPherson wrote:
>
>> You can have an internal mesh made up of entireley rfc1918 address
>> space, and not leak these routes to the rest of the world, I've only
>> once caught MCI leaking stuff from a test lab, which was kinda annoying,
>> but not really anything bad, and a polite e-mail message to them got
>> an immediate fix of the problem.
>>
>
>i'd think most providers filter rfc1918 addresses both inbound and
outbound at
>naps (mci does, i believe), although maybe not to customers...

This is unfortunately not the case. I was bombarded by someone with a
172.16.x.x address for several days, at a rate of a significant fraction of
my T1. When I asked, folks said they don't filter the traffic at their
attachment points because the routers they have there couldn't handle doing
any filtering due to limitations in the router architecture, softare or both.

ISPs should at the very least do ingress filtering from customers, but
really should also filter RFC 1918 addresses and ideally not-yet-assigned
addresses from all links. Of course they may have to buy routers which are
capable of performing such work.

>
>using reserved address space internally (as long is it remains internal),
>seems like a good idea to me - isn't that why it was reserved?

Exactly. Their use is an excellent idea.

Daniel Senie mailto:dts@openroute.com
Sr. Staff Engineer http://www.openroute.com/
OpenROUTE Networks, Inc. (a wholly owned subsidiary of
Proteon, Inc.)