RFC 1918 address on open internet?

Question

In trying to diagnose a failover problem with my Cisco ASA 5520 firewalls, I ran a traceroute to www.btfl.com and, much to my surprise, some of the hops came back as RFC 1918 addresses.

Just to be clear, this host is not behind my firewall and there is no VPN involved. I have to connect across the open internet to get there.

How/why is this possible?

asa# traceroute www.btfl.com

Tracing the route to 157.56.176.94

 1  <redacted>
 2  <redacted>
 3  <redacted>
 4  <redacted>
 5  nap-edge-04.inet.qwest.net (67.14.29.170) 0 msec 10 msec 10 msec
 6  65.122.166.30 0 msec 0 msec 10 msec
 7  207.46.34.23 10 msec 0 msec 10 msec
 8   *  *  *
 9  207.46.37.235 30 msec 30 msec 50 msec
 10 10.22.112.221 30 msec
    10.22.112.219 30 msec
    10.22.112.223 30 msec
 11 10.175.9.193 30 msec 30 msec
    10.175.9.67 30 msec
 12 100.94.68.79 40 msec
    100.94.70.79 30 msec
    100.94.71.73 30 msec
 13 100.94.80.39 30 msec
    100.94.80.205 40 msec
    100.94.80.137 40 msec
 14 10.215.80.2 30 msec
    10.215.68.16 30 msec
    10.175.244.2 30 msec
 15  *  *  *
 16  *  *  *
 17  *  *  *

and it does the same thing from my FiOS connection at home:

C:\>tracert www.btfl.com

Tracing route to www.btfl.com [157.56.176.94]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  myrouter.home [192.168.1.1]
  2     8 ms     7 ms     8 ms  <redacted>
  3    10 ms    13 ms    11 ms  <redacted>
  4    12 ms    10 ms    10 ms  ae2-0.TPA01-BB-RTR2.verizon-gni.net [130.81.199.82]
  5    16 ms    16 ms    15 ms  0.ae4.XL2.MIA19.ALTER.NET [152.63.8.117]
  6    14 ms    16 ms    16 ms  0.xe-11-0-0.GW1.MIA19.ALTER.NET [152.63.85.94]
  7    19 ms    16 ms    16 ms  microsoft-gw.customer.alter.net [63.65.188.170]
  8    27 ms    33 ms     *     ge-5-3-0-0.ash-64cb-1a.ntwk.msn.net [207.46.46.177]
  9     *        *        *     Request timed out.
 10    44 ms    43 ms    43 ms  207.46.37.235
 11    42 ms    41 ms    40 ms  10.22.112.225
 12    42 ms    43 ms    43 ms  10.175.9.1
 13    42 ms    41 ms    42 ms  100.94.68.79
 14    40 ms    40 ms    41 ms  100.94.80.193
 15     *        *        *     Request timed out.

score 16 · Answer 1 · edited Oct 07 '21 at 06:47

Not just RFC 1918...also RFC 6598, i.e. 100.64.0.0/10 CGN space. Both of those are private networks, but the latter is more recently standardized and less known.

This isn't unusual from a traceroute standpoint. You aren't actually talking to those 10space and 100space hosts directly, you're sending packets with incrementally larger TTLs to your next hop router. To keep the answer from getting overly long, this Wikipedia link summarizes the process.

What is unusual is that that this packet traverses public IP space, and is then tunneled through private IP space to reach a "public" net yet again. 157.56.176.94 is owned by Microsoft, and the packet traverses MS owned networks before hitting the private net...so it's simply what Microsoft is choosing to do with their network space at both ends of the private space. They advertise the routes; the other routers just do what they're told.

As a general rule, no, network operators generally do not expose their private nets along a route to public IP space from outside of their network. That's why this is so unusual.

(it could be a missing route somewhere on their border, causing the packets to traverse a non-optimal path that eventually reaches its destination, but I'm not a networking guy and someone can probably take a better stab at it)

Most traceroute implementations rely on UDP+ICMP as your article goes on to state. — dmourati, Jun 25 '13 at 02:13
@dmourati As a Unix admin, I'm forced to blush. Duh. Thank you. — Andrew B, Jun 25 '13 at 02:15
In my experience, this isn't unusual at all. Many carriers use 10.0.0.0/8 inside their network, and expose a disturbing amount of it. — Paul Gear, Jun 26 '13 at 22:37

Falcon Momot · Accepted Answer · 2013-06-25T07:27:31.373

It is permissible for routers to connect to each other using RFC1918 or other private addresses, and in fact this is very common for things like point-to-point links, and any routing that takes place inside an AS.

Only the border gateways on a network actually need publicly routeable IP addresses for routing to work. If a router's interface doesn't connect to any other ASes (or any other service providers, more simply), there is no need to advertise the route on the internet, and only equipment belonging to the same entity will need to directly connect to the interface.

That the packets return to you this way in traceroute is a slight violation of RFC1918, but it isn't actually necessary to use NAT for these devices as they don't connect to arbitrary things on the internet themselves; they just pass along traffic.

That the traffic takes the (possibly circuitous) route through several organizations that it does is merely a consequence of the operation of exterior gateway routing protocols. It seems perfectly reasonable that Microsoft has some backbone and some people have peered with it; you don't have to be a wholesale ISP to route traffic.

That the traffic has gone through multiple series of routers with private IPs, transiting through ones with public IPs in between, is not especially strange - it simply indicates (in this case) two different networks along the path have routed the traffic through their own routers which they have chosen to number in this way.

RFC 1918 address on open internet?

2 Answers2