I recently got an Android phone. After downloading the Android SDK I noticed that my cellular provider (T-Mobile) was doing something odd. According to the netcfg command they’re using 25.0.0.0/8 on their GPRS/EDGE network:
$ netcfg
lo UP 127.0.0.1 255.0.0.0 0x00000049
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
rmnet0 UP 25.130.205.212 255.255.255.252 0x00001043
rmnet1 DOWN 0.0.0.0 0.0.0.0 0x00001002
rmnet2 DOWN 0.0.0.0 0.0.0.0 0x00001002
sit0 DOWN 0.0.0.0 0.0.0.0 0x00000080
ip6tnl0 DOWN 0.0.0.0 0.0.0.0 0x00000080
T-Mobile doesn’t own that netblock. The UK Ministry of Defence does. Why would they do such a thing? After all, RFC 1918 gives you three whole blocks (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) to do with as you please. Straying from those on your private will damn you to an eternity of network flakiness and give your twisted pair cabling scurvy, right?
Why this is clever 🔗
According to several BGP looking glasses and figure 5 of Geoff Huston’s IPv4 Address Report the Ministry of Defence doesn’t advertise any routes for 25.0.0.0/8. That means that none of the 25.x.x.x addresses are being used on the public Internet. If you’re on a private network they’re effectively free for the taking. But still, why aren’t they using the officially-sanctioned RFC 1918 address?
My phone also has an 802.11 interface. Let’s take a look at netcfg’s output when I’m connected to T-Mobile’s network and my home network:
$ netcfg
lo UP 127.0.0.1 255.0.0.0 0x00000049
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
rmnet0 DOWN 25.130.205.212 255.255.255.252 0x00001002
rmnet1 DOWN 0.0.0.0 0.0.0.0 0x00001002
rmnet2 DOWN 0.0.0.0 0.0.0.0 0x00001002
sit0 DOWN 0.0.0.0 0.0.0.0 0x00000080
ip6tnl0 DOWN 0.0.0.0 0.0.0.0 0x00000080
eth0 UP 192.168.25.4 255.255.255.0 0x00001043
See the 192.168.25.4? That could just as easily be 10.0.0.4, 172.18.34.4, or any other RFC 1918 address. On many networks (particularly universities) it could even be a public address. T-Mobile has no way of predicting or controlling what happens on that interface. The 25.0.0.0/8 netblock has the following advantages:
- It doesn’t overlap with any other network, public or private. Therefore you won’t get any routing confusion when the phone is connected on GPRS/EDGE and WiFi at the same time.
- It’s not in public use. The next Facebook or Lolcats isn’t going to show up with a 25.x.x.x address, thereby causing routing confusion for your users.
- Even if the UK MoD is handing out 25.x.x.x address over 802.11 they’re way over in the UK. It’s unlikely that my phone will be connected to the MoD and T-Mobile networks at the same time.
Why this is insane 🔗
IPv4 addresses are getting scarce. Who says the MoD won’t turn the 25.0.0.0/8 netblock over to RIPE or IANA next week? Even then my phone has to go through a proxy server on T-Mobile’s network so it’s probably not a huge deal.
Update 🔗
Just before publishing this I ran netcfg and my phone was using 14.64.186.160. The 14.0.0.0/8 netblock used to be reserved for public data networks but was allocated to APNIC earlier this month. I wonder what other questionable netblocks they’re using.
Comments 🔗
Comment by Stephen Fisher on 2010-04-11 02:15:40 +0000 🔗
Maybe they should start using that strange “new” thing called IPv6 🙂
Comment by Gerald Combs on 2010-04-12 09:19:00 +0000 🔗
You’re absolutely right. This would be a non-issue with IPv6. To be fair, I’m not sure what else T-Mobile can do in this situation. They probably have a lot of customer handsets that are v4-only. Luckily none of the mail or SSH servers I use have 25/8 or 14/8 addresses.
Comment by Julio De Leon on 2010-04-12 12:52:24 +0000 🔗
Let’s see if I understood well, if I were to point to your address 25.130.205.212/8 from my computer, it will route me to your phone? Instead of correctly route me to anywhere in the UK MoD network?
Comment by Gerald Combs on 2010-04-13 09:54:27 +0000 🔗
@Julio The 25/8 block isn’t publicly routed at all, so you should see a timeout or network unreachable error if you try to connect to 25.130.205.212. T-Mobile’s GPRS/EDGE uses a proxy server for HTTP connections and NAT for everything else so the 25/8 and 14/8 addresses are invisible to the outside world. The problem is when I’m connected via GPRS/EDGE and need to connect to a 25/8 or 14/8 address *outside* of T-Mobile’s network. Right now this isn’t a problem. As the IPv4 address space nears exhaustion it could easily become one.
Comment by Old T-Mo Employee on 2010-05-13 10:15:57 +0000 🔗
Actually, T-Mobile has many “illegal” IP ranges, depending on what network you connect through. In fact, there is a management network which also uses stolen public space. It is a risk, but was done because of the scarcity of RFC1918 space. Believe it or not, there just are not addresses in that range to handle all the network devices and phones.
Comment by Rollo on 2010-05-15 08:25:15 +0000 🔗
Here in Germany t-mobile uses IP-Adresses like 1.2.3.4 for example, APNIC-adress-space. Should work fine, they are not only “way over”, but “down under” 😉
Comment by brn0vrflw on 2010-05-18 10:13:48 +0000 🔗
Why extrapolate ? Just contact them !
Comment by olivia on 2010-05-25 13:38:50 +0000 🔗
i found exactly the same issue with our business “orange” mobiles however T-mobile and orange have now merged. Surely Its obvious UK.gov are turning a blind eye to the misuse of what essentially is a public network.
Comment by Will on 2010-05-25 14:44:10 +0000 🔗
@olivia: It’s not a misuse of a public network… in a worst-case scenario, let’s say you work for the UK Government and need to connect to 25.1.1.1 from your T-Mobile phone– you’ll likely be unable to, as T-Mobile is using that address for their INTERNAL network. However, if you connect from anything else besides your T-Mobile phone, it’ll work fine.
So this isn’t a misuse, it’s just risky since T-Mobile customers could potentially be angry that they can’t reach a certain website.
Currently, however, it’s a smart move on T-Mobile’s part because they can avoid even worse problems if you connected your phone to a wifi network that happened to use the same internal IP range as T-Mobile.
IPv6 will solve all of this, and it should solve it soon as most new devices are IPv6 enabled and strategies for routing between IPv6 and IPv4 networks are already well-known.
Comment by Jodrik on 2010-05-30 23:46:17 +0000 🔗
Versatel also has a hand in this using 1.0.0.0/8 for their GPRS in the Netherlands for instance. I personally think it’s -extremely- annoying that major companies like ISPs just go out and set “bad examples” with work-arounds like this. Yes IPv4 is limited, but how long has IPv6 been in the making? Shouldn’t ISPs be the one pushing phones manufacturers to implement IPv6 instead of just waiting for it to happen and basically abusing privately owned networks.
In my opinion if they should have seen this limitation comming way back when GPRS etc started catching on and should have just implemented IPv6 on it by default.
Comment by Michael Patterson on 2010-06-06 18:20:42 +0000 🔗
Hello Gerald,
We are testing IPFIX in our next release due out later this month. We are finally receiving the data from procflow correctly. What are your intentions with this tool? We noticed it hasn’t been updated for about a year.
See you at sharkfest.
Mike [at] plixer.com