Provider uses IP addresses for their internal network tunnels that correspond to a DOD ARIN allocation.
> Aha! The IP is assigned to my phone’s GSM interface, so it looks like it’s benign after all.
> That did the tip, Amatus!
If so, I could buy that, but my question is "why?" That is, why not use an actual RFC1918 private address?
Or is your point actually something different, and I'm just missing it?
Ok, I get that in principle... but that particular combination sounds awfully suspicious. The DoD just happens to have extra IP space, and they just happen to lease it to cell phone carriers? Hmmmmmmmmm....
I mean, yeah, it could all be totally innocuous, but I'm still suspicious that there might be something else going on. I'm not exactly a card carrying member of the tinfoil-hat brigade, but I trust our government about as far as I can throw it... :-)
Do a control-f for "DOD". These guys have so much IP4 space its not even funny. Being the government, they'll never give it up. So a total of 200 million IP4 addresses:
So, when the country that starts the internet is also the country with the largest, by far, military and has obscene military spending, well, this is what happens.
Back before the commercialization of the Internet these things were relatively free.
(omitted the 0.0.0/8 from all but the first for brevity)
a904guy is using addresses that are not in the RFC 1918 block for his personal network. While this is discouraged, there isn't anything preventing it. It can cause problems if someone decides to later use 220.127.116.11/24 since he wouldn't be able to use those addresses locally AND talk to external sites on that same netblock without doing some creative NAT.
Secondly, yes, the provider should use RFC 1918 and RFC 4193 blocks. While this can cause problems when provider A uses 10.0.0.0/24 and provider B uses 10.0.0.0/24 and Provider A later buys Provider B, the private address blocks are there and are not supposed to be routed or announced outside local networks. In this case, it appears that Time Warner (or whomever), used 18.104.22.168/8 internally. This probably dates back to the @home network when the providers shared responsibility and grabbed the 22.214.171.124/8 block, then, later split and renumbered. TWC may have just swapped 24 for 28 on their network to eliminate re-engineering. No way to know for sure without someone knowing some history.
shareme: There is a difference between DNS registered (which this block is not), and assigned and registered by ARIN. ARIN delegates blocks to particular entities and maintains that directory. That doesn't mean I can't use those IP addresses locally (I wouldn't be able to announce them to the global internet - well, you could if you had upstream providers willing or negligent in their best practices).
The government is not leasing IP addresses to Sprint. How do we know this? Because the IP addresses are not being announced by anyone:
HE.inet.0: 42 destinations, 42 routes (41 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 28w4d 15:04:18
> to x.x.x.x via ge-0/3/0.0
Internap.inet.0: 42 destinations, 42 routes (41 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 28w4d 15:03:57
> to x.x.x.x via ge-0/1/0.0
route-views>show ip bgp 126.96.36.199
BGP routing table entry for 0.0.0.0/0, version 338718131
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Not advertised to any peer
2905 65524 16637
188.8.131.52 from 184.108.40.206 (220.127.116.11)
Origin IGP, metric 0, localpref 100, valid, external, best
As most networks don't run defaultless - they have a default path just in case they receive a packet for an IP address that isn't in their routing table. This happens when you have a client of a provider that may not have their filters set properly, or, are have odd confederations or community settings that you don't see their announcement. Rather than blackhole those organizations, one normally has a default route pointed to a provider. A backbone provider would more likely run defaultless, a host or Internet Service Provider would normally run with a default route.
So, you run a traceroute on a network that has a default route, and it gets to the border to a provider that doesn't run defaults and the packet is dropped. The DoD isn't filtering these packets or making them disappear - the Internet doesn't know where they should go, and, since there is no default route, the packets are dropped at the first router that doesn't know how to route it.
Actually, no. But the OP is a friend, and this showed up in my G+ feed earlier. I thought some HN people might either A. find it interesting and/or B. have an explanation.
Due to responses to multiple threads, I figure a single explanation should suffice, referenced to related portions.
That all sounds reasonable... but you'd think if somebody was going to squat on some IP address space, they'd pick somebody other than the DoD to mess with. :-)
RFC 4913 suggests using the current timestamp + the mac address of your machine, sha1 hashed and then taking the lower 40 bits to generate your Unique Local Address (ULA). An RFC that is specific about generating an arbitrary number.
I doubt much thought went into it - it was an unused, unannounced block that didn't conflict with their existing 10.0.0.0/8 network.
If you look inside the SDP's (usually in the INVITE and 200 OK, potentially 183/180 or ACK) it will tell you where the actual RTP traffic is going. If those RTP ports and addresses are changed something is certainly foul. My guess is they are not.
If you see a Record Route header it means some proxy has inserted itself into the signaling traffic. Or again, if the SDP inside SIP header is changed.
For reference, an SDP looks like this:
o=- 1996782469 1996782469 IN IP4 18.104.22.168
c=IN IP4 22.214.171.124
m=audio 57076 RTP/AVP 0 101
Actually I do that quite often as the DoD's IP allocations are fixed and well known. I figure that since nothing on my networks should ever be talking to the DoD anyway, the worst that will happen is that DoD spyware can no longer phone home. No big loss :)
Wait, maybe I shouldn't have said that on a public forum...
The DoD handed the block back to IANA in 1998, and in 2010 it was allocated for use.
Of course, that might just be what they WANT us to think.
<dawns tinfoil hat>
The DOD IP is in the 28/8 range which is not in the global routing table. So the packets never reach DOD.
Thanks to the help of a few folks who commented on my blog, I was able to learn that the 28.x.x.x IP was assigned to my phone's interface. Thus it appears Sprint has "borrowed" addresses from the DoD. Because SIP packets contain the source IP (unlike the other traffic from my phone) the internal IP was leaking through Sprint's NATting, causing my confusion. It's all harmless, though a good argument for moving to IPv6!
In other words, there are missing pieces that make all explanations difficult to confirm or not.
"That’s what hackers do, you know."
"I have my own VoIP system (remember, I’m a hacker)"
To be fair, Mark probably had no idea this would show up on HN. I was the one who posted it here, not him. He probably thought his audience for this would be the same regular audience for his blog, which includes a lot of RTP locals who know him in person and know his background. In that context, those statements make perfect sense.
because he bought a VoIP system and installed Google Voice on his smartphone.
Nah, Mark's been hacking on Linux and Asterisk stuff a long time; and he's a sharp guy who definitely deserves the "hacker" appellation.
In this case, I added those comments to my post so that a non-technical audience would better understand the mindset. Believe it or not, not everyone thinks the way we geeks do. :)