Several years ago (looking at archive.org it was at the end of 2001) I wrote a database that translated IPs to locations. Very similar to the city-db from maxmind.com. Perhaps someone still remembers the article in the iX about it ?
Anyway, now it is time to release the idea to the public. The idea is a distributed, open-source IP to location translation. Source comes later.
The basic idea
The idea behind IP-to-location translation is pretty old already. For I stumbled over it when I was running traceroute to some IP addresses on IRC. If you are in city-specific channels, you can easy proof if the basic idea works or not.
# traceroute -w 1 -q 1 pD95DE2CD.dip.t-dialin.net
traceroute to pD95DE2CD.dip.t-dialin.net (217.93.226.205), 30 hops max, 40 byte packets
...
2 217.0.72.226 37.472 ms
3 <b>c-eb1.C.net.DTAG.DE (62.154.88.54)</b> 47.532 ms
4 217.0.76.225 47.760 ms
5 *
Coming from another network, we also end up the same way:
...
9 <b>c-eb1.C.net.DTAG.DE (62.154.88.54)</b> 30.622 ms
10 217.0.76.225 (217.0.76.225) 29.864 ms
11 *
So, we can guess that 217.93.226.205 is behind the big router in C. Taking at look at wikipedia we see that C is for Chemnitz.
Proving Networks
Well, scanning each single IP for their last known hop is a but expensive. IP-addresses are 32bit, so 4 billion addresses. It would take ages to scan them all.
The simplify the routing of IP-addresses providers usually assign blocks of 16 or more address to a single dail-in router. For 217.93.226.205 the possible starting addresses are:
- .205 & 0xFC = .204 (/30 or 4 addresses, well 2)
- .205 & 0xF8 = .200 (/29 or 8 addresses)
- .205 & 0xF0 = .192 (/28 or 16 ...)
- .205 & 0xE0 = .192 (/27 or 32 ...)
- .205 & 0xC0 = .192 (/26 or 64 ...)
- .205 & 0x80 = .128 (/25 or 128 ...)
- .205 & 0x00 = .0 (/24 or 256 ...)
Let's probe them:
# traceroute -n -w 1 -q 1 -f 2 217.93.226.204
traceroute to 217.93.226.204 (217.93.226.204), 30 hops max, 40 byte packets
3 62.154.88.54 46.852 ms
4 217.0.76.229 47.101 ms
5 217.93.226.204(N!) 86.009 ms
We already applied 2 minor optimizations:
- no need to resolve IP addresses to names (
-n) - we already know the path to the city-router, no need to probe that again (
-f 2)
Ok, next IPs from the list:
# traceroute -n -w 1 -q 1 -f 2 217.93.226.200
3 217.0.72.226 37.793 ms
4 62.154.88.54 47.864 ms
5 217.0.76.229 47.890 ms
# traceroute -n -w 1 -q 1 -f 2 217.93.226.192
3 217.0.72.226 37.712 ms
4 62.154.88.54 47.685 ms
5 <b>217.0.76.229</b> 48.156 ms
6 217.93.226.192(N!) 85.583 ms
# traceroute -n -w 1 -q 1 -f 2 217.93.226.128
3 217.0.72.226 37.171 ms
4 62.154.88.54 47.205 ms
5 <b>217.0.76.225</b> 47.524 ms
6 217.93.226.128 96.240 ms
Ok, now we are still in the same city (still 62.154.88.54), but already on the next dial-in router (217.0.76.229 vs. 217.0.76.225).
# traceroute -n -w 1 -q 1 -f 2 217.93.226.0 3 217.0.72.230 37.534 ms 4 62.154.88.54 47.821 ms 5 217.0.76.229 47.834 ms # traceroute -n -w 1 -q 1 -f 2 217.93.224.0 3 217.0.72.230 37.972 ms 4 62.154.88.54 48.635 ms 5 217.0.76.229 48.329 ms # traceroute -n -w 1 -q 1 -f 2 217.93.192.0 3 217.0.72.226 37.197 ms 4 62.154.88.54 47.048 ms 5 217.0.76.229 47.069 ms # traceroute -n -w 1 -q 1 -f 2 217.93.128.0 3 217.0.72.230 37.688 ms 4 62.154.88.54 48.311 ms 5 217.0.76.229 48.309 ms # traceroute -n -w 1 -q 1 -f 2 217.93.0.0 3 217.0.72.230 37.723 ms 4 62.154.113.118 53.378 ms 5 217.0.76.209 53.064 ms
There we go. 217.93.128.0 is the start of the network. A simple check against 217.93.255.254 and we know that the 217.93.128.0/17 is behind c-eb1.C.net.DTAG.DE.
Assigning a network to providers
From the domain you can already guess it, but just to be sure we query whois who is the owner of this network block:
$ whois 217.93.226.205
...
inetnum: 217.93.0.0 - 217.94.63.255
netname: DTAG-DIAL19
descr: Deutsche Telekom AG
...
% Information related to '217.80.0.0/12AS3320'
...
origin: AS3320
member-of: AS3320:RS-PA-TELEKOM
mnt-by: DTAG-RR
First of all, the whole 217.80.0.0/12 is managed by the Deutsche Telekom AG. We can assume that they all have the same domain-name pattern. Furthermore we can query the AS number to find out more about the structure of the autonomous zones:
$ whois -i origin -T route AS3320 | grep ^route:
route: 193.103.152.0/22
route: 192.109.195.0/24
route: 194.156.145.0/24
...
route: 217.0.0.0/13
....
From IP to City
We know that 217.93.128.0/17 is behind c-eb1.C.net.DTAG.DE. Let's see how it looks for other IPs for the same provider:
# traceroute -w 1 -q 1 -f 2 217.80.0.1
traceroute to 217.80.0.1 (217.80.0.1), 30 hops max, 40 byte packets
3 217.0.72.230 38.105 ms
4 ke-eb1.KE.DE.net.DTAG.DE (62.154.98.38) 55.057 ms
5 217.0.74.213 55.072 ms
Looks like the DTAG is using naming convention for their routers we can easily match on: the 5th part is the city-key and the 4rd the country-code.
*KE.DE*.net.DTAG.DE
* C.DE*.net.DTAG.DE
Checking wikipedia again, it is Kempten (Allgäu).
Other Naming Conventions
The Deutsche Telekom operates not only in Germany, but worldwide. For outside of Germany they switch to another system. Before we get there let's see how providers are naming their routers:
# traceroute -w 1 -q 1 -f 2 191-196-103-86.dynamic.dsl.tng.de
3 217.0.72.230 37.625 ms
4 62.154.32.230 40.054 ms
5 so-6-0.hsa2.<b>Hamburg</b>1.Level3.net (4.68.127.241) 46.202 ms
6 so-5-0-0.mp2.<b>Hamburg</b>1.Level3.net (4.68.115.242) 46.677 ms
7 ge-5-2.hsa1.<b>Hamburg</b>1.Level3.net (195.122.140.203) 46.891 ms
8 tng2.<b>ham</b>.level3.net (62.67.33.5) 48.588 ms
9 fe1-0.<b>kel</b>6.tng.de (213.178.64.14) 48.775 ms
...
Ok, Hamburg is obvious. HAM for Hamburg and KEL for Kiel. TNG is a regional ISP in Kiel.
City to Location
If you have to city name, it is easy to get the lat and long for it. Well, there is wikipedia, there is yahoo and google ...
- Yahoo and Google with their geocoding interface
- http://de.wikipedia.org/wiki/Kiel see the upper left (Koordinaten: 54° 20′ N, 10° 8′ O) or as XML:
<span class="geo" style="display:none"> <span class="latitude">54.3252777778</span> <span class="longitude">10.1405555556</span> </span>
Wikipedia also gives us ZIP-codes, State and other interesting information.
International
Up to now we only demonstrated it for German IPs, but the it works worldwide:
# traceroute -w 1 -q 1 -f 2 nytimes.com
3 217.0.72.230 37.980 ms
4 f-eb5.<b>F.DE</b>.net.DTAG.DE (62.154.17.62) 51.500 ms
5 62.156.128.98 51.497 ms
6 xe-1-1-0.r21.<b>frnk</b>ge03.<b>de</b>.bb.gin.ntt.net (129.250.2.12) 52.222 ms
7 xe-1-0-0.r20.<b>frnk</b>ge03.<b>de</b>.bb.gin.ntt.net (129.250.2.148) 52.706 ms
8 as-0.r22.<b>lond</b>en03.<b>uk</b>.bb.gin.ntt.net (129.250.4.16) 68.202 ms
9 as-0.r20.<b>nycm</b>ny01.<b>us</b>.bb.gin.ntt.net (129.250.3.254) 134.630 ms
10 po-3.r03.<b>nycm</b>ny01.<b>us</b>.bb.gin.ntt.net (129.250.2.11) 134.875 ms
11 ge-1-2.a00.<b>nycm</b>ny01.<b>us</b>.da.verio.net (129.250.30.193) 140.567 ms
...
From Frankfurt, Germany (DECIX) to London (England) UK and over^Wunder the ocean to New York, NY, US.
Let me pick the IPs of my colleagues and see where they live:
# traceroute ...
6 ge-0-2-0-0.fftcr4.Frankfurt.opentransit.net (193.251.242.233) 50.188 ms
7 so-0-0-0-0.amscr1.Amsterdam.opentransit.net (193.251.242.213) 61.951 ms
8 193.251.247.214 61.249 ms
9 PC11.cr1-asd6.nl.euro.net (194.134.161.80) 61.196 ms
10 10GE1-1.dr3-asd6.nl.euro.net (194.134.161.58) 62.180 ms
11 V538.ar1-<b>Asd</b>-Z.<b>nl</b>.euro.net (194.134.152.50) 66.668 ms
... Amsterdam is the right city
# traceroute ...
5 t2a7-ge5-0.nl-ams2.eu.bt.net (166.49.239.153) 51.006 ms
6 t2c1-prc2.nl-ams2.eu.bt.net (166.49.200.43) 51.223 ms
7 t2c1-p5-0-0.uk-lon2.eu.bt.net (166.49.195.226) 63.025 ms
8 t2c1-p9-0.uk-ilf.eu.bt.net (166.49.195.121) 63.241 ms
9 166-49-168-86.eu.bt.net (166.49.168.86) 62.864 ms
10 core2-pos0-6-4-0.ilford.ukcore.bt.net (62.6.204.62) 64.079 ms
11 core2-pos7-0.<b>birmingham</b>.ukcore.bt.net (62.6.204.61) 67.380 ms
... this is 25miles away
Other Mappings
For some IPs you can simplify the tracing in case they either use the location-encoding for end-points or they use DNS-LOC.
Disclaimer
Doing a massive traceroute against a network of a provider will trigger their Intrusion Detection Systems and they may consider your massive tracerouting as abuse. You were warned.
Summary
To create your very own, accurate IP to location mapping you need:
- a DB of networks and their providers
- a patterns to map domain-names to cities and countries
- a DB for geocoding
With that in hand you can do something like:
Prior Art
These aren't my ideas. Most is documented and talked about at http://www.caida.org/ like http://www.caida.org/publications/papers/2000/inet_netgeo/inet_netgeo.html.
Comments