Calgary ... Texas?

Laws are forcing more and more services, like social networks, to change their behavior based on the user's region.

This week, I've been in Calgary, Canada, and Bluesky wants me to verify my age because it thinks I'm in ... Texas???

This seems like a good time to talk about how IP geolocation works, and as a treat, we can also talk about mobile networks and roaming!

One way that apps and websites can tell where you are is for your phone to tell them based on your GPS or other location clues like the set of visible Wi-Fi networks. This post is not about that.

When you connect to a service over the Internet, it sees an IP address as the source of your connection. (Yep, VPNs, I know; also not about that, though similar things are going to apply.)

It's fairly common to try to guess your location from that IP address. This doesn't get you street- or building-level accuracy, but it's often good enough to get country, state/province/etc, or even city-level locations.

The first thing to understand is that there is nothing inherently geographical about an IP address. It's just a 32-bit (or 128-bit) number. So, you have to use a collection of heuristics to make an educated guess. There are a number of databases and services that exist to do this mapping. An app or website doing geo-based compliance, content customization, etc. will use one of these.

So where do locations in these databases come from?

The answer is a lot of guessing, and I'll go through some of the ways these guesses work. All have downsides, so they are usually used together.

Every IP address is controlled by an Autonomous System (AS) for routing purposes, and you can sometimes (not always!) make broad location guesses based on these records. For example, if the IP address belongs to AS17055, the University of Utah, you can guess it's likely in Utah (and therefore in the USA.) It's maybe in Salt Lake City, where the University is located, and it might be on or near the campus. But the University of Utah does run networks that are off-campus and enter other states, so.... not super accurate.

Sometimes, networks themselves give you clues about where devices are by how they are named, especially in backbones and large corporate networks. If I use reverse DNS to look up the name of the address 199.212.24.66, for example, I can see that it's named clgr2rtr3.network.canarie.ca . From that .ca , I can guess it may be a Canadian network, and therefore maybe it's in Canada; that 'clgr' at the front is a stronger clue, likely indicating that it's in Calgary. These kinds of signals aren't always present, are not always accurate, and can be hard to get (e.g. the intermediary IP hops are often gathered with traceroute, which is not possible and/or accurate in every network). But, still, hey, this is information we can use to strengthen our guesses.

Another way to guess is using latency. If you can measure the latency from a probe with a known location to the destination (ie. with ping), you get an upper bound on how far away the destination is: if it takes 1 millisecond for network traffic to get there and back, the speed of light (in fiber) tells us that the destination cannot possibly be more than about 100 km (62 miles) away. It could be closer, though, for a lot of reasons. So the latency measurement gets you a circle, centered at the probe point, that probably contains the destination IP address. What you do, then, is you measure latency from a lot of different sources in a lot of different places; this gives you a bunch of circles, and your destination is probably inside the region where they overlap. For this to work, you need a lot of probe locations, and if you want this to work worldwide, you need them, well, worldwide. For example, IPinfo, one of the commercial geolocation providers, advertises that they have 1,377 locations in 169 countries that they probe from.

You can't get information on every single IP address using the reverse-DNS method (not every address has a reverse DNS record, or one with name info in it) or the latency method (not every device responds to ping), so you end up using a lot of heuristics to make assumptions about which IP addresses are probably geographically close to each other, and you use your inferred location for one to stand in for the others that you think are near.

As you can see, there are lots of ways for this to go wrong. It can be pretty accurate, but it can also fail subtly or badly; different geolocation providers don't always agree, either. It's all (educated) guesses. And it's quite a bit of work, which is why the high-quality providers tend to charge for this data.

OK. So now let's talk about mobile (AKA cellular) networks.

They are extremely complex, but the main thing you need to understand for this purpose is that traffic doesn't flow straight from the cell tower you're connected to into the Internet. The mobile provider connects with the Internet at a far smaller number of places. In 5G the device/software that does this is called a UPF, and this is where the IP address seen by other services "lives," so this is what someone looking up your location by IP address is going to see. (It's more complicated than this, but you are already a champ for reading this far and I'm not going to make this even harder for you.)

You can see the problem here, right?

No matter where you actually are, IP geolocation is going to think you are at one of these relatively scarce UPF locations. The UPF you're going through might be close, or it might not. It might not be in the same city or state where you really are, especially if you're somewhere rural or otherwise far from the major Internet exchange points.

So, mobile networks are one of the cases where IP-based geolocation can be particularly inaccurate.

But how did I end up getting mislocated by 2,500 km and to the entirely wrong country?

These screenshots contain a hint.

Notice that the geolocation information thinks I'm on T-Mobile's network. But then notice that the other screenshot thinks I'm on the Rogers network.

I'm roaming.

Rogers and T-Mobile have (directly or indirectly, again, it's complicated) an agreement such that when T-Mobile's customers are in Rogers' service area, they can connect to Rogers towers.

(Actually, it's even more complicated than this, I'm on Google Fi which is not even it's own network, it's a virtual one that runs on T-Mobile plus other providers and ... well you can see why I'm not going to get into it.)

There are multiple ways to connection roaming customers' data traffic with the Internet. The simplest one is called "local breakout": my data traffic goes over the air to the Rogers tower, enters the Rogers core network, goes to a Rogers UPF, and exits somewhere locally, almost certainly in Canada, maybe even in Calgary.

That's not what's happening here.

They are using another strategy here, specifically it appears that they are using Home Routing: my traffic is going into the Rogers network, getting routed back to my "home" network, then using a UPF there to connect to the Internet. Carriers often do this because, even though it's a pretty inefficient way to route packets, they want to maintain policy and charging control over their customers' traffic. But that's a subject for another post.

Why Texas, and not someplace else in T-Mobile's service area? No idea. It might not actually even be in Texas, could be a wrong guess by the geolocation provider. But, that's why I'm an honorary Texan this week.

Yeehaw. (Or maybe Yahoo!?)