Re: Someones being naughty again...
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:
Subject: Someones being naughty again... (Mar 13, 6:56pm) 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. End of included message written by Marc Hurst on Mar 13, 6:56pm,
On Fri, 13 Mar 1998, Pat Darisme wrote:
I don't see a problem here ?
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..... --------------------------------------------------------------------------- Blake Willis Network Engineer, New Customers blakew@cais.net CAIS Internet, a CGX Communications Company --------------------------------------------------------------------------- On Fri, 13 Mar 1998, Marc Slemko wrote:
On Fri, 13 Mar 1998, Pat Darisme wrote:
I don't see a problem here ?
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.
On Sat, 14 Mar 1998, Blake Willis wrote:
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.
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.
At 02:36 3/14/98 , Marc Slemko wrote:
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 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 -- +----------------------------------+----------------------------------+ |Alec Peterson - ahp@hilander.com | Erols Internet, INC. | |Network Engineer | Springfield, VA. | +----------------------------------+----------------------------------+
On Sat, 14 Mar 1998, Alec H. Peterson wrote:
At 02:36 3/14/98 , Marc Slemko wrote:
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.
At 17:58 3/14/98 , Marc Slemko wrote:
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.
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 -- +----------------------------------+----------------------------------+ |Alec Peterson - ahp@hilander.com | Erols Internet, INC. | |Network Engineer | Springfield, VA. | +----------------------------------+----------------------------------+
On Sat, 14 Mar 1998, Marc Slemko wrote:
On Sat, 14 Mar 1998, Blake Willis wrote:
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.
No. The assumption that life is as simple as that is the biggest problem with most uses of private IP space.
Another problem is mergers. If you ever merge with another company, hope they dont use the same private IP space. Stb
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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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.
You also discourage people from filtering the ICMP packets this uses. Right?
- prevents easy identification of links, whose they are, etc. because you can't have reverse DNS and the addresses don't belong to you.
Not a problem if it is entirely inside an enterprise, as valid addresses before and after it would be the same enterprise. But as links between I would see a problem.
- causes confusion when multiple networks that are using such addresses are merged or interconnected in the wrong (right) way.
Private addressing is not the ideal solution, but when networks are built with lots of links to lots of places, address allocating authorities prefer you to use private addresses where feasible. It maybe be a gray and fuzzy line determining that, but many cases clear work fine with such addresses (for example having a consisent MTU).
I like the idea behind why you would do it, but... can't justify it.
I don't have so many links that I can't get them all in a /24. But much beyond that and I will be using private addresses. I do run some private address LANs, but they end in private addresses and you should never see them (but if you are my customer you will be able to). -- Phil Howard | stop8810@spammer6.net stop6589@spammer3.net no1way64@no3where.edu phil | no3spam1@noplace4.edu no3spam5@anywhere.com crash431@s8p1a7m3.com at | blow2me8@no83ads9.org stop7363@dumb7ads.edu suck6it9@no1place.net milepost | end8it30@noplace0.com no2spam5@anyplace.org a1b5c1d8@s3p3a5m0.edu dot | no52ads8@no97ads7.com die9spam@noplace0.org end0it22@spam9mer.edu com | stop3424@no2place.net eat38me1@lame9ads.org end2ads8@nowhere8.org
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.
On Sat, 14 Mar 1998, Marc Hurst wrote: ) 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:~# -- Daniel Reed <n@narnia.n.ml.org> (3CE060DD) System administrator at large... I never deny, I never contradict. I sometimes forget. -- Benjamin Disraeli
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. On Sat, 14 Mar 1998, Marc Hurst wrote: :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. : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca System Administrator [L5] jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 ext 18 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
On Sat, 14 Mar 1998 jlixfeld@idirect.ca wrote:
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 On Sat, 14 Mar 1998, Marc Hurst wrote:
On Sat, 14 Mar 1998 jlixfeld@idirect.ca wrote:
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.
The upstreams should certainly be filtering this. I am truly surprised someone is still leaking a ten/8 network to the world. Alex On Sat, 14 Mar 1998 jlixfeld@idirect.ca wrote:
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.
On Sat, 14 Mar 1998, Marc Hurst wrote:
: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. :
-- Regards,
Jason A. Lixfeld jlixfeld@idirect.ca System Administrator [L5] jlixfeld@torontointernetxchange.net
--------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 ext 18 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
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.
participants (11)
-
Alec H. Peterson -
Blake Willis -
Daniel Reed -
Dean Anderson -
Fancy Feast -
jlixfeld＠idirect.ca -
Marc Hurst -
Marc Slemko -
Pat Darisme -
Phil Howard -
S.T.Balbach