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.
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.
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,
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:
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:
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.
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:
Last but not least, if more operators would ask for RFC9092 adoption, geolocation providers would speed up their deployment.
© 2023 - Massimo Candela, Emanuele Candela, Lorenzo Ariemma
RFC9092/RFC9632 authors: Randy Bush, Massimo Candela, Warren Kumari, Russ Housley