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:

geographical access distribution

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

Enable javascript to load comments.