Sign inMonitor a domain
Network

For ISPs and network admins: publishing an RFC 8805 geofeed

One CSV file, linked from your registry records, fixes the location of every customer in a range at once. It is the most effective thing an operator can do about “wrong location” tickets.

By peekip editorialLast checked 5 Oct 20263 min read5 sources
On this page
Short answer

Write a CSV with one line per prefix: ip_prefix, country code, region code, city, postal code (leave fields empty to be coarser). Serve it over HTTPS, then reference it from each inetnum or NetRange with a geofeed attribute or a “remarks: Geofeed https://…” line. Optionally sign it with RPKI. Databases that read feeds will pick it up on their next refresh.

The file

RFC 8805 defines a geofeed as a CSV file with one entry per line and these fields, in order: ip_prefix,alpha2code,region,city,postal_code.[1] The country is an ISO 3166-1 alpha-2 code and the region an ISO 3166-2 code. Comment lines start with #. An example using documentation ranges:

# Example Networks geofeed, see RFC 8805
192.0.2.0/25,US,US-AL,,
192.0.2.128/25,US,US-TX,Dallas,
198.51.100.0/24,GB,GB-MAN,Manchester,
2001:db8:1000::/36,DE,DE-BE,Berlin,

The fields after the country are optional. RFC 8805 leaves the choice of what to publish to you and notes that fields can be omitted “to further protect privacy”.[1] Most consumer ISPs publish city and leave postal code empty. Real operators show the range of choices: Starlink names a hub city for every block[4], and AWS publishes a geofeed that accounts for its Local Zones.[5]

Where to put it

Geofeed files “MUST be published via and fetched using HTTPS”.[2] Use a stable URL you control (your own domain, or a raw file on a code host as T-Mobile does), served as plain text, with no login and no redirects to HTML.

How databases find it

RFC 9632 defines two ways to point to the file from your registry objects (inetnum, inet6num or NetRange):[2]

  • the native attribute: geofeed: https://example.net/geofeed.csv
  • the remarks form, for registries that don’t support it yet: remarks: Geofeed https://example.net/geofeed.csv, where “Geofeed” is case-sensitive and followed by one URL.

You can see the remarks form in production: ARIN’s RDAP record for T-Mobile’s 172.32.0.0/11 network carries Geofeed https://raw.githubusercontent.com/tmobile/tmus-geofeed/main/tmus-geo-ip.txt in its registration comments.[3]

Only list prefixes covered by the registry object that points to the file; a database checking authority will ignore lines outside it.

Signing (optional)

RFC 9632 adds an optional RPKI signature: a detached CMS signature, base64 and wrapped at 72 characters, appended as comment lines between # RPKI Signature: and # End Signature:.[2] It lets a consumer verify that the publisher holds the address space. It is optional; an unsigned feed is still useful.

Checklist before you announce it

  1. Every line parses: valid prefix, two-letter country, a region code that belongs to that country.
  2. No overlaps that contradict each other; if you publish a /24 inside a /16, the more specific line should be the one you mean.
  3. Gateway-based networks name the gateway city deliberately, not a head office.
  4. The URL answers over HTTPS with a 200 and the CSV, from outside your network.
  5. Each relevant registry object carries the geofeed reference.
  6. Someone owns updates: re-publish when ranges move between regions.
Run it on yours

See what databases say today

Look up one of your customer addresses to compare database locations before and after you publish.

Open the IP lookup

What it will and won’t do

RFC 8805 tells consumers they “MAY treat published feed data as a hint only”.[1] Databases that use feeds refresh them on their own schedules and may weigh your data against their own. Expect gradual improvement over weeks, and a clear answer you can give customers: “our published location for your range is X, and databases are updating.”

Sources

  1. RFC 8805: A Format for Self-Published IP Geolocation Feeds (Aug 2020) · IETF / RFC EditorChecked 5 Oct 2026
  2. RFC 9632: Finding and Using Geofeed Data (Aug 2024) · IETF / RFC EditorChecked 5 Oct 2026
  3. RDAP record NET-172-32-0-0-1 (T-Mobile USA, Inc.) · ARINChecked 5 Oct 2026
  4. Starlink geofeed (RFC 8805 CSV, 4,352 lines on the check date) · StarlinkChecked 5 Oct 2026
  5. AWS IP address ranges · Amazon Web ServicesChecked 5 Oct 2026