Geolocate much?

RFC9092/RFC9632 gives to the network operator the power to control the geolocation of its IP resources.

It works by linking geofeed files in whois. This allows geolocation databases and content providers to automatically discover the geofeed files and to import them from a format they are already familiar with. It can be used to set the geolocation of entire prefixes or specific IPs.

It works by simply editing a text file. No need to open tickets or send emails.

At the moment there are prefixes with geofeeds.

Adoption

No rows
Name
File format
Auto-discovery v4
Auto-discovery v6
Reactivity
Share

Rows per page:

0–0 of 0

Test your Geofeed

If you type an IP or a prefix, you can check if it is covered by a geofeed file and if the file is correct.

It's easy! Follow this wizard or the steps below.

 

  1. You create a CSV file containing rows in the format:
209.212.224.0/24,TH,TH-10,Bangkok,
209.212.224.3,US,US-CA,,
2001:418:0:5000::1c,US,US-VA,Ashburn,

 

  1. Upload the file somewhere and serve it over HTTPS

 

  1. For each prefix in the file, find the encompassing inetnum in your RIR portal and add a remark in the format:

Geofeed https://url_to_your/file.csv

Note: in ARIN, inetnums are called NetRanges and remarks are called Comments.

 

Example of whois result:

$ whois 209.212.224.1
NetRange:       209.212.224.0 - 209.212.239.255
NetName:        NTTA-209-212-224
NetHandle:      NET-209-212-224-0-1
NetType:        Direct Allocation
Organization:   NTT America, Inc. (NTTAM-1)
Comment:        Geofeed https://geo.ip.gin.ntt.net/geofeeds/geofeeds.csv

 

Remember:

  • You can have multiple prefixes in one file.
  • You can have multiple inetnums pointing to the same file.
  • In the file, you can specify both prefixes and IPs. You can specify nested prefixes, longest prefix match applies.
  • Prefixes which are not encompassed by any inetnum with a remark link to the geofeed file (point 3) are going to be ignored. See image below.
inetnums links

Read more about RFC9092.

The geofeed format is described in (RFC8805) as a string "prefix,country,region,city,zip".

Details below:

 

You can use this service to create a correct geofeed file.

Examples of valid geofeeds:

2001:418:0:5000::1c,US,US-VA,Ashburn, (The IP is in Ashburn, Virginia, United States)

83.231.214.112/30,IT,,Milan, (The prefix is in Milan, Italy)

165.254.21.0/29,BR,,, (The prefix is in Brasil)

203.105.64.248/30,,,, (The prefix should not be geolocated)

The principle is simple.

We periodically place geofeed files in inetnums and we check how much time it takes for the geolocation providers to correct their geolocation.

 

In doing so, we make sure that:

  • The geofeed file did not exist before, in order to avoid cases where the file was discovered in other ways.
  • The inetnum doesn't have any other geographic info like geoloc or country attributes.
  • We verify that initially none of the geolocation providers report the geolocation provided in the geofeed file.

Many RIRs made it clear that they are not responsible for geolocation (e.g., here, here). Despite that, there are geolocation hints in their databases.

 

Among these hints, there are the geoloc and the country attributes.

 

The geoloc attribute is supported by RIPE and APNIC. It allows to associate latitude and longitude coordinates to single inetnums. This is suboptimal at the least. It essentially uses the most accurate and human unfriendly possible geographic information to geolocate resource assignments that could be potentially spread in different continents. If we are not seriously considering the possibility to create many small whois entries (e.g., for /32), there is no way to use this attribute properly.

 

The country attribute in inetnums is supported by APNIC, LACNIC and RIPE. In all the three it has a different or not specified meaning. In APNIC it refers to the geolocation of the inetnum, in LACNIC it refers to the geolocation of the company that owns the inetnum, in RIPE it's not well specified and it can refer to both. Additionally, this approach allows only geolocation at country level and still has the same issue that you cannot be granular enough on geolocating small prefixes or single IPs. Important to notice is that often the country of the organization (and not of the inetnum) is used by geolocation providers.

 

Summary

  • These fields do not work across all RIRs, they do not have the same meaning across RIRs, and they are polluted with stale data (this contributed to a lack of trust in these fields). They are often misinterpreted (e.g., country of the organization) or not imported at all in geolocation datasets.
  • More importantly, they do not provide the needed flexibility.
  • RIRs should refrain from introducing additional geolocation hints directly in their databases, and possibly deprecate attributes for which there was not a clear definition in the past.
  • Users planning to use geofeeds, are better off removing other geographic hints from whois or make sure to don't create contradictions.

 

We need a system that

  • allows to specify geolocation from large or small prefixes, or even single IPs;
  • allows to specify geolocation from none up to city level, in a human friendly format;
  • allows the network team to manage independently the IP geolocation without the need for RIR portal access (and reduce stale data);
  • propagates automatically without the need to contact geolocation providers;
  • is authoritative like whois (linked from whois), but without destroying whois with large amount of small inetnum entries.

One of the key information is that finding the link to the geofeed files from whois is not enough.

You must be sure that when you open the file, you read only the prefixes in the file that are contained by the inetnum in which you discovered the url. Only in this way you will be able to validate the ownership of the prefixes.

 

That being said, to find the links in whois you can download the whois dumps.

 

However, no need to reimplement the wheel.

You can just run geofeed-finder. This utility discovers and retrieves geofeed files from whois data. Additionally, it validates the ownership of the prefixes, manages the cache, and validates the ISO codes. In output you will get a single validated geofeed file, containing the merge of all the found geofeed files. You can safely import this file as is.

 

For your convenience, we run this utility once per day. You can find the link to the result below.

Not all geolocation providers support yet RFC9092 (auto-discovery of geofeed files) while almost all support RFC8805 (geofeed file format).

The step from RFC8805 to RFC9092 is minimal: if you can already import the files, you can easily discover them from whois. This means that a pervasive RFC9092 adoption is probably close. Several geolocation providers are at the moment considering the implementation of this solution.

 

Use this service to check where geolocation providers say your resource is

 

If one of the geolocation providers supporting RFC9092 is not fetching your geolocation:

  • Test your geofeed deployment. This page offers a quick test given a prefix.
  • Check that you are using the correct remark format "Geofeed https://url". Uppercase "G", no semicolon, one space, over https.
  • Check that other whois geographic information (e.g., geoloc or country) are removed or at least not contradicting the geofeed. We have no way to guarantee how diverging data is going to be managed by the single geolocation providers.
  • Geolocation providers can ignore your geolocation if they consider it untruthful, if your prefixes are detected as vpn/proxies, or if you change a prefix too often.
  • Geolocation providers update their datasets periodically. Give them time.

 

Last but not least, if more operators would ask for RFC9092 adoption, geolocation providers would speed up their deployment.

Download all validated feeds at once

https://geolocatemuch.com/geofeeds/validated-all.csv

© 2023 - Massimo Candela, Emanuele Candela, Lorenzo Ariemma

RFC9092/RFC9632 authors: Randy Bush, Massimo Candela, Warren Kumari, Russ Housley