Here is a traceoute from BBN Planet to my machine... (sorry D, couldn't
resist...
traceroute to 24.112.43.xx (24.112.43.xx), 30 hops max, 40 byte packets
1 netgwb (205.227.188.1) 196 ms 611 ms 9 ms
2 oakland-cr2.bbnplanet.net (4.0.68.77) 20 ms 15 ms 19 ms
3 oakland-br2.bbnplanet.net (4.0.16.17) 16 ms 15 ms 22 ms
4 sanjose1-br1.bbnplanet.net (4.0.1.74) 25 ms 16 ms 15 ms
5 bb.mae-w.home.net (198.32.136.70) 19 ms 17 ms 21 ms
6 172.16.2.174 (172.16.2.174) 110 ms 108 ms 107 ms
7 r3-fe0-0-100bt.rdc1.on.wave.home.net (24.2.9.4) 121 ms 108 ms 112 ms
8 10.0.184.34 (10.0.184.34) 153 ms 109 ms 106 ms
9 pc-30xxx.on.rogers.wave.ca (24.112.43.xx) 110 ms 111 ms 110 ms
Nice 10.x.x.x.
I don't see a problem here ?
According to RFC 1918 the Net 10 and Net 172.16/12 and 192.168/16 addresses are
for use privately or internally such as when :
" - Interfaces of routers on an internal network usually do not
need to be directly accessible from outside the enterprise."
These addresses are however not advertised to the outside world and should thus
cause no problem here.
We are simply seeing those net 10 addresses as a source address for those
packets returned by the traceroute, but that address should not be reacheable
or advertised from outside the internal network.
See http://www.cis.ohio-state.edu/htbin/rfc/rfc1918.html for more details.
Thanks
Pat
@Home Network Operations
Once upon a time, Marc Hurst arranged the electrons in @Home's private
scaleable, ATM, OC3 BackBone to write:
In article <Pine.BSD/.3.91.980313185428.24020A-100000@fastlane.ca>,
Not unless you have a larger MTU on the "outside" interface than
the "inside" interface, then you lose bigtime.
I would check to see if this is the case in this situation, but
those addresses don't come into my network so I can't.
Offhand, I can't think of any other problems but I really discourage
people from using internal address space for this purpose because it:
- breaks stuff like path MTU discovery, etc. when filtered.
- prevents easy identification of links, whose they are, etc.
because you can't have reverse DNS and the addresses don't
belong to you.
- causes confusion when multiple networks that are using such
addresses are merged or interconnected in the wrong (right)
way.
I like the idea behind why you would do it, but... can't justify it.
IMHO, the decision to use private IP space for hosts/routers/interfaces in
a network is really a matter of necessity or security. I am familiar with
a few corporate networks with nationwide WANs (as well as a major ISP or
two) that use 10.0.0.0/8 and other private networks for all their backbone
equipment, simply because they lack the public address space to do
otherwise. Others do it for the very reason that their equipment is
unreachable from the outside world. Whatever the reason, as long as you
keep it within your own AS and don't announce or listen to it from
anywhere else, there is nothing wrong with setting a network up this way.
That was the whole point of 1918. The RFC was published because large
chunks of public address space were being allocated to networks that
weren't connected to the internet (case in point: one of our federal
customers has a /14, a /15, and a /16 in class B space, and has had them
for several years. We just added them to the RA and started announcing
them last month. There were several interesting reactions around here
when people noticed the RADIUS entry for his <modem> connection with those
netmasks!) Of course, if your company gets bought by another company that
also uses private space, you're going to have to invest in some shiny new
hardware that can do NAT between your two networks when it comes time to
merge.....
No. The assumption that life is as simple as that is the biggest
problem with most uses of private IP space.
It _does_ break things if not done with very careful attention. Most of
the people using it have no clue about how it can break things and are
bewildered when it is explained to them.
For example? A router with one ATM interface going to the world with a
high MTU with an ethernet on the other side. Say you use private IP space
for links on that router. Say someone on the Internet filters traffic
from private netblocks; lots of people do. There _can_ be machines that
are completely unable to transfer data (eg. download a web page) from
another because you just broken path MTU discovery. This is not a made up
situation, this is a real example that I have had to deal with of how
using private IP space for
network interfaces used for public traffic does break things in some
situations.
Now, you can avoid this problem by being careful to ensure that there is
no MTU change on any router using private address space for the relevant
interface, or that all systems downstream of it don't have a MTU larger
than the MTU on the low MTU interface, etc. But that is just hacks to get
around the basic problem; while they may be acceptable in your situation,
and I am not trying to claim it is never appropriate, most people that I
have seen with problems like this never had a chance to decide that
because they don't have the faintest understanding of issues like this.
Pinging ? [10.0.184.34] with 48 data bytes
Statistics for 10.0.184.34
12 packets transmitted, 6 packets received, 50% packet loss
round-trip (ms) min/avg/max = 117/123/141
This is wrong....
I should not be able to do this!
M.
Well, obviously I can see it coming from an outside network can't I!
TraceRoute: 48 data bytes to pc-30857.on.rogers.wave.ca [24.112.43.19]
1:Rcvd pkt type 11: [207.112.4.14] tor4.pm.passport.ca in 134 msec.
2:Rcvd pkt type 11: [207.112.4.1] P50.emporium.on.ca in 131 msec.
3:Rcvd pkt type 11: [205.150.206.157] ? in 194 msec.
4:Rcvd pkt type 11: [205.150.242.65] h4.bb1.tor2.h4.bb1.tor1.uunet.ca in
123 msec.
5:Rcvd pkt type 11: [205.150.221.62] ? in 174 msec.
6:Rcvd pkt type 11: [24.112.32.190] ? in 165 msec.
7:Rcvd pkt type 11: [24.2.9.4] r3-fe0-0-100bt.rdc1.on.wave.home.net in
201 msec.
8:Rcvd pkt type 11: [10.0.184.34] ? in 160 msec.
9:Rcvd pkt type 0: [24.112.43.19] pc-30857.on.rogers.wave.ca, 48 bytes
in 180 msec.
You only run into this situation if:
1) The packets have DONT_FRAG flag set on them
2) The ATM interface is in fact set with a small MTU.
1 is very possible nowadays, but 2 is prolly not. Yeah, ATM has a small
cell size, but most IP over ATM interfaces I've ever seen have an MTU of
something like 4470. Yes, they cheat and do break down the packet into
cells, but can you imagine trying to put a TCP download into 48 bytes?
You'd use most if not all of that for the IP header.
It is still an open debate about whether or not RFC1918 space is wise to
use, but I'd say it's a sign of a commendable effort on @Home's part that
they are trying to conserve IP space, even though they do have lots of
routable addresses.
Alec
Another problem is mergers. If you ever merge with another company, hope
they dont use the same private IP space.
Stb
) Pinging ? [10.0.184.34] with 48 data bytes
) Statistics for 10.0.184.34
) 12 packets transmitted, 6 packets received, 50% packet loss
) round-trip (ms) min/avg/max = 117/123/141
Are you sure you aren't using 10.0.0.0 in your local network?
(11:05)root@narnia:~# traceroute 10.0.184.34
traceroute to 10.0.184.34 (10.0.184.34), 30 hops max, 40 byte packets
1 annex1.mhv.net (199.0.0.10) 441.71 ms 447.504 ms 474.262 ms
2 router.mhv.net (199.0.0.1) 728.385 ms 693.522 ms 930.113 ms
3 sl-gw8-pen-3-4-T1.sprintlink.net (144.228.160.41) 907.624 ms 1132.57 ms 938.952 ms
4 * sl-gw8-pen-3-4-T1.sprintlink.net (144.228.160.41) 1710.79 ms !H 1932.13 ms !H
(11:06)root@narnia:~#
No, you should definetly not be able to ping it. Where are you in
respect to home.net? If you are not directly connected to home.net and if
you can ping that IP, then @home is trying to advertise 10.0.184.0 to
their upstreams and they are accepting those advertisments. If you are
on home.net then you will be able to see them. That is definetly wrong
though! I can see if you use 10.x net for un-advertised touch-down nets
between two routers, but you should definetly not be able to ping them
from afar.
No, I'm definitely not part of the @home net. I'm coming in off a dial-up
of an independant ISP in Toronto (UUnet/Sprint feeds I believe...).
M.
All 10.x.x.x networks should be filtered by all competent upstreams.
The same goes for 127 and 224 
is NAT that hard to configure?
Alex
>
>For example? A router with one ATM interface going to the world with a
>high MTU with an ethernet on the other side. Say you use private IP space
>for links on that router. Say someone on the Internet filters traffic
>from private netblocks; lots of people do. There _can_ be machines that
>are completely unable to transfer data (eg. download a web page) from
>another because you just broken path MTU discovery. This is not a made up
>situation, this is a real example that I have had to deal with of how
>using private IP space for
>network interfaces used for public traffic does break things in some
>situations.
You only run into this situation if:
1) The packets have DONT_FRAG flag set on them
As I said, path MTU discovery. That imples DF.
2) The ATM interface is in fact set with a small MTU.
1 is very possible nowadays, but 2 is prolly not. Yeah, ATM has a small
cell size, but most IP over ATM interfaces I've ever seen have an MTU of
something like 4470. Yes, they cheat and do break down the packet into
cells, but can you imagine trying to put a TCP download into 48 bytes?
You'd use most if not all of that for the IP header.
No, the whole point is the ATM interface has a large MTU and the ethernet
has a small MTU, which means that large segments coming from the "outside"
to the "inside" don't fit. This is just a simple example from my life;
there are many situations that can cause this which aren't always obvious.
It is still an open debate about whether or not RFC1918 space is wise to
use, but I'd say it's a sign of a commendable effort on @Home's part that
they are trying to conserve IP space, even though they do have lots of
routable addresses.
You can call it an open debate until you actually try using it. Of
course, most people don't notice the things that break when they do.
Another problem is mergers. If you ever merge with another company, hope
they dont use the same private IP space.
I think it depends greatly on how you glue the merged nets together. This
really shouldn't be much of a problem, compared to the other issues of
merging.
OTOH, I think there is a saying that when climbing a ladder, don't put both
feet on the same rung at the time. So perhaps its not such a bad idea to
pick some random and obscure part of 1918 space, when necessary.
--Dean
I have used it myself, actually (I do on some less-visible links). No
problems really. I did a comparison between running with 1918 space and
without it. I know what problems I am _supposed_ to see, but I can't say I
did. Guess I'm special.
The people who work on the @home network are _not_ stupid, in fact quite to
the contrary they have some of the best network talent on the planet.
They would not be using RFC1918 space if it broke their network.
Alec
The upstreams should certainly be filtering this. I am truly surprised
someone is still leaking a ten/8 network to the world.
Alex