Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.
Anyone who has had a new address block mislocated knows the symptoms: a website shows content in the wrong language, a streaming service refuses access, or a fraud check flags a user because the address "is in" another country. IP geolocation is not a property of the network; it is an inference made by commercial and open datasets from many signals. Because they are inferences, they can lag behind changes and be plain wrong, especially for new prefixes, moved prefixes, and IPv6, where address space is large and measurement signals are sparse. This article explains where location data comes from, what a geofeed (RFC 8805) is, and how to maintain accurate data. Examples use 2001:db8:100::/48 and 192.0.2.0/24.
Where location data comes from
Geolocation providers combine several kinds of evidence:
- Registry data: the country in the allocation or assignment record in WHOIS or RDAP. It is coarse and reflects where the holder registered the block, not where traffic originates.
- Network measurements: latency from probes in known places, and traceroute paths with location hints in router names.
- Routing data: which AS announces the prefix, and where that AS operates.
- Customer-submitted corrections: the data providers accept from address holders and users.
- Self-published geofeeds: the topic of this article.
None of these is authoritative, which is why two providers can disagree about the same address, and why a block that moved from one country to another can keep its old location for a long time.
What a geofeed is
A geofeed is a plain CSV file, published by the party that knows where its address space is used, listing prefixes and their locations. RFC 8805 defines the format: one line per prefix, with these fields:
| Field | Meaning | Example |
|---|---|---|
ip_prefix |
An IPv4 or IPv6 prefix | 2001:db8:100::/48 |
alpha2code |
ISO 3166-1 country code | US |
region |
ISO 3166-2 subdivision code | US-CA |
city |
Free-text city name | Los Angeles |
postal_code |
Postal code | usually left empty |
Lines starting with # are comments, and the file is UTF-8 text. A complete example:
# Geofeed for AS64496
192.0.2.0/24,US,US-CA,Los Angeles,
2001:db8:100::/48,US,US-CA,Los Angeles,
2001:db8:101::/48,US,US-NY,New York,
The RFC discourages postal codes because of privacy concerns, and recommends not publishing location data more precise than needed. A prefix can be given a country only, or country and region, by leaving later fields empty. Geofeed data is a statement by the publisher, meant to be consumed by providers who choose how much to trust it.
Making a geofeed discoverable
A file nobody finds does nothing. RFC 8805 describes publishing its URL in the address registration record, and RFC 9632 specifies finding and using it in more detail, including a geofeed: attribute for RPSL-based registries, with the older practice of a remarks: line also in use. The URL must be served over HTTPS. The mechanism available differs among the five RIRs, so read your registry's documentation on where the URL can be recorded. RFC 9632 also describes how the file can optionally be authenticated using RPKI, which helps consumers verify that it was published by the holder of the space.
An RPSL-style record for a registry that supports the attribute might look like this:
inet6num: 2001:db8:100::/48
geofeed: https://example.com/geofeed.csv
Check your registry's schema, as this varies.
Maintaining it
- Keep it in sync with reality. When you move or lease out a prefix, update the file. A stale line is worse than none.
- Match the announced prefixes. Entries can cover more specific prefixes than you announce, but a feed that does not correspond to the BGP table is harder for consumers to trust.
- Serve it reliably. Use HTTPS, and a stable URL, and keep it available. Consumers fetch it periodically.
- Validate the syntax before publishing: well-formed CIDR, correct country codes, no stray whitespace, valid UTF-8.
Correcting a provider's data
A geofeed is a hint, and providers pick it up at their own pace. For a prefix that is still wrong:
- Look it up at several providers' public lookup pages, and note which are wrong.
- Make sure your registry record and geofeed are correct and consistent.
- Use each provider's correction process, which typically accepts a prefix and the intended location, sometimes with a link to the geofeed.
- Recheck after a while. Corrections take time to propagate into the databases that applications download.
IPv6 specifics
Geolocation databases often handle IPv6 at larger granularity, so announcing and registering a prefix as a single /48 with one location gives the cleanest result. If you split one /48 between cities, providers have little to go on below the /48, and a /64-level split is rarely honoured. Users on IPv6 also move through privacy addresses and dynamic prefixes, so data about a whole site's prefix generalises better than about single addresses. Plan your address layout so that each location gets its own prefix of a size providers can use, as discussed in the subnetting articles.
What not to rely on
Do not use IP geolocation for anything that must be correct, such as legal decisions, or treat it as proof of a user's location. It is a statistical aid. For a new block, publish the geofeed before the block carries traffic, correct what is wrong early, and keep it current.
About IPYE
IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.
Disclosure: I run IPYE
Top comments (0)