Any ideas how (or why) the following traceroutes are leaking private RFC1918 addresses back to me when I do a traceroute?
Maybe try from your side of the internet and see if you get the same types of responses.
It’s really strange to see 10/8’s and 192.168/16 addresses coming from the public internet. Has this phenomenon been documented anywhere? Connectivity to the end-sites is fine, it’s just the traceroutes that are strange.
(initial few hops sanitized)
[brian@testbox1 /]# traceroute www.ibm.com
traceroute: Warning: www.ibm.com has multiple addresses; using 129.42.17.99
traceroute to www.ibm.com (129.42.17.99), 30 hops max, 38 byte packets
1 (—.---.—.---) 2.481 ms 2.444 ms 2.379 ms
2 (—.---.—.---) 17.964 ms 17.529 ms 17.632 ms
3 so-1-2.core1.Chicago1.Level3.net (209.0.225.1) 17.891 ms 17.985 ms 18.026 ms
4 so-11-0.core2.chicago1.level3.net (4.68.112.194) 18.272 ms 18.109 ms 17.795 ms
5 so-4-1-0.bbr2.chicago1.level3.net (4.68.112.197) 17.851 ms 17.859 ms 18.094 ms
6 so-3-0-0.mp1.stlouis1.level3.net (64.159.0.49) 23.095 ms 22.975 ms 22.998 ms
7 ge-7-1.hsa2.stlouis1.level3.net (64.159.4.130) 23.106 ms 23.237 ms 22.977 ms
8 unknown.level3.net (63.20.48.6) 24.264 ms 24.099 ms 24.154 ms
9 10.16.255.10 (10.16.255.10) 24.164 ms 24.108 ms 24.105 ms
10 * * *
[brian@testbox1 /]# traceroute www.att.net
traceroute: Warning: www.att.net has multiple addresses; using 204.127.166.135
traceroute to www.att.net (204.127.166.135), 30 hops max, 38 byte packets
1 (—.---.—.---) 2.404 ms 2.576 ms 2.389 ms
2 (—.---.—.---) 17.953 ms 18.170 ms 17.435 ms
3 500.pos2-1.gw10.chi2.alter.net (63.84.96.9) 18.077 ms * 18.628 ms
4 0.so-6-2-0.xl1.chi2.alter.net (152.63.69.170) 18.238 ms 18.321 ms 18.213 ms
5 0.so-6-1-0.BR6.CHI2.ALTER.NET (152.63.64.49) 18.269 ms 18.396 ms 18.329 ms
6 204.255.169.146 (204.255.169.146) 19.231 ms 19.042 ms 18.982 ms
7 tbr2-p012702.cgcil.ip.att.net (12.122.11.209) 20.530 ms 20.542 ms 23.033 ms
8 tbr2-cl7.sl9mo.ip.att.net (12.122.10.46) 26.904 ms 27.378 ms 27.320 ms
9 tbr1-cl2.sl9mo.ip.att.net (12.122.9.141) 27.194 ms 27.673 ms 26.677 ms
10 gbr1-p10.bgtmo.ip.att.net (12.122.4.69) 26.606 ms 28.026 ms 26.246 ms
11 12.122.248.250 (12.122.248.250) 27.296 ms 28.321 ms 28.997 ms
12 192.168.254.46 (192.168.254.46) 28.522 ms 30.111 ms 27.439 ms
13 * * *
14 * * *
This is quite often used. You cant (d)DoS the routers this way, nor try
to do any harm to them as you cant reach them.
Regards,
Jonas
Search the archives, Comcast and other cable/DSL providers use the 10/8 for their infrastructure. The Internet itself doesn't need to be Internet routable. Only the edges need to be routable. It is common practice to use RFC1918 address space inside the network. Companies like Sprint and Verio use 'real' IPs but don't announce them to their peers on customer edge routes.
-Matt
Sure you can, easy, attack a router 1 hop past your real target and spoof your target as the source. The resulting ICMP responses will hammer the target. If the Internet edge actually protected itself against spoofing it would be harder but it is still very do-able now.
Matthew Crocker wrote:
Search the archives, Comcast and other cable/DSL providers use the 10/8 for their infrastructure. The Internet itself doesn't need to be Internet routable. Only the edges need to be routable. It is common practice to use RFC1918 address space inside the network. Companies like Sprint and Verio use 'real' IPs but don't announce them to their peers on customer edge routes.
Which (as discussed previously) breaks things like Path MTU Discovery, traceroute, and other things that depend on the router sending back ICMP packets to the sender if any ISP along the return path (properly) filters RFC1918 address space as being bogus. You can use RFC1918 space on any device that really has no need to communicate with the outside world, but generally, un-NAT'ed routers don't qualify for this, at least on their transit interfaces.
I believe Comcast (and I'm going only on my experience as a customer) is or has moved from RFC1918 space to routable IP space for their routers, at least on interfaces I've been doing traceroutes through.
Bob
Using real but announced IPs for routers will make their packets fail
unicast-RPF checks, dropping traceroute and PMTUD responses as happens with
RFC1918 addresses.
Rubens
I guess you meant "unannounced".
This is the case for those who run uRPF towards their upstream (or
transit ISPs peering with them who'd run uRPF on the peering links).
I don't think too many folks do that.
But I see very little point in not announcing them. Equally well you
could just set up an acl at the edge which drops or rate-limits the
traffic. Well, you might not be able to if you're using a vendor
the implementation of which doesn't allow you to do that.. 
matthew@crocker.com disait :
Search the archives, Comcast and other cable/DSL providers use the
10/8 for their infrastructure. The Internet itself doesn't need to be
Internet routable. Only the edges need to be routable. It is common
practice to use RFC1918 address space inside the network. Companies
like Sprint and Verio use 'real' IPs but don't announce them to their
peers on customer edge routes.
Are you sure about Sprint ?
I was told that Sprint DOES announce edge blocks to peers/custom (For URPF
i guess) but blackholes this block at the edge.
Thus you can still traceroute the IP up to Sprint edge, but cannot get
into Sprint network.
This is a hot issue for Opentransit since we are considering not
announcing some infrastructure blocks.
I think that Sprint way is rather smart :
. It prevent/mitigate infrastructure DDOS
. It keeps working with URPF enable peers.
Vincent, Opentransit - France Telecom