What Is an IP Geofeed? How It Affects IPv4 Geolocation

You lease a /24, deploy it in Frankfurt, and three weeks later a customer opens a ticket: your addresses show up as being in the United States. Nothing is broken. The route works, latency is normal, the origin ASN is exactly what was agreed. What disagreed was a database.

Geolocation data is not part of the routing system. It is a set of separate datasets, held by separate organisations, each built from its own sources, each refreshed on its own schedule, and none of them obliged to agree with the others. A geofeed is one standardised way for a network operator to publish its own answer into that mix.

Definition Box: A geofeed is a file published by a network operator that maps IP prefixes to coarse location data — country, and optionally region and city. RFC 8805 defines the file format. A geofeed is self-published location information: it is not a routing mechanism, not a registry requirement, and not a guarantee that any particular service will change what it displays.

In one line: a geofeed is a hint you publish about where your addresses are used, and consumers are free to take it or ignore it.

White-Face Xiaolu pins a small location tag onto a branch of an address ribbon, while a separate routing track crosses the frame untouched.

A geofeed attaches location information to a prefix; it does not touch the route that prefix takes.

1. What a Geofeed Is

RFC 8805 — A Format for Self-Published IP Geolocation Feeds — records a format that a network operator can use to publish a mapping of IP address prefixes to simplified geolocation data, and calls that file a "geolocation feed".

Three properties do most of the work in that sentence:

It is self-published. The network operator publishes the file. There is no central registry to apply to and no approval step. The operator hosts a file and says so.
It is intentionally coarse. The RFC states that the format "intentionally only allows specifying coarse-level location". A geofeed is not a street address for an IP. It cannot tell anyone which datacentre rack a prefix sits in, and it is not designed to.
It is a hint, not a directive. Nothing in the format obliges a consumer to accept it. RFC 8805 is explicit that a consumer "MAY treat published feed data as a hint only and MAY choose to prefer other sources of geolocation information for any given IP prefix".

That last point is the one most often missed when a geofeed is sold as a fix. Publishing a correct geofeed is a good move. It is not a switch that turns every location database into the truth you published.

2. What Is Inside a Geofeed

A geofeed is a plain text file in CSV form, served over HTTP or HTTPS from a URL. Lines are UTF-8; blank lines are ignored, and text from a # to the end of the line is a comment. Each remaining line is one entry:

ip_prefix,alpha2code,region,city,postal_code

Field	Required	What goes in it
`ip_prefix`	Yes	A single IP address, or a prefix in CIDR notation — IPv4 or IPv6
`alpha2code`	No	ISO 3166-1 alpha-2 country code, e.g. `DE`
`region`	No	Full ISO 3166-2 subdivision code, e.g. `DE-HE` for Hesse
`city`	No	Free-form city name, e.g. `Frankfurt`
`postal_code`	No	Deprecated — see below

A feed covering a few prefixes in documentation ranges looks like this:

# Example geofeed — documentation prefixes only
# Prefix,              Country, Region, City,       Postal code
192.0.2.0/24,           DE,      DE-HE,  Frankfurt,
198.51.100.0/24,        NL,      NL-NH,  Amsterdam,
2001:db8:1200::/40,     DE,      DE-HE,  Frankfurt,

The same file can carry IPv4 and IPv6 entries; the prefix column is what distinguishes them. Note the region values: RFC 8805 requires an ISO 3166-2 region code, and its own examples use the full form — US-AL, PL-MZ, NL-ZH — not the bare subdivision part.

Two parsing rules are worth knowing before you write or review one:

The most specific prefix wins. Nested prefixes are allowed, and a consumer is expected to match an address against the longest prefix that covers it. So a /24 inside a published /16 is a legitimate way to give one block its own city without splitting the rest.
Duplicates are an error. The same prefix appearing twice in one file is treated as a fault and should be logged for review. A feed generated by a script is the usual place this creeps in.

The postal code field is deprecated. RFC 8805 marks it OPTIONAL, DEPRECATED and states that "new feeds SHOULD NOT include this field due to the granularity of this information". Consumers still have to parse two feeds containing it, but there is little reason to publish it now.

Four fields do the work; the last one is deprecated and best left empty.

3. Geofeed vs Registry Records vs GeoIP Databases

These three get treated as one thing and they are not. They differ in who writes them, what they are for, and how they change.

	Geofeed	Registry records	Commercial GeoIP database
What it is	A self-published CSV of prefix → coarse location	Registration data in an RIR database, including the `country:` field	A vendor dataset sold to services
Who writes it	The network operator using the addresses	The resource holder, through the database maintainer	The vendor, from its own collection methods
Primary purpose	Tell geolocation consumers where prefixes are used	Record who holds the resource, its registration details, and its contact handles	Answer "where is this IP" for a paying customer
How it changes	Publish a new file; update the reference in the registry	Database update, subject to object authorisation	Vendor's own refresh cycle
Guarantees adoption	No	No	No

Two practical consequences follow.

First, a registry country field is administrative, not a measurement. RFC 9632 puts it directly: hints in registry objects such as country: and geoloc: "tend to be administrative, and not deployment specific" — think of a large provider whose headquarters sits far from most of its deployments. A /24 allocated to a Dutch entity but deployed in Frankfurt may well still read the Netherlands in that field.

Second, publishing a geofeed does not overwrite anything. Each GeoIP vendor maintains its own data and each one decides how much weight to give a published feed. Some consume feeds; some blend them with their own measurements; some may not use them for a given prefix at all. Feeds are read, though: RFC 8805 records that at the time it was written, one major consumer was processing roughly 400 feeds covering more than 750,000 prefixes. That is evidence that the mechanism works — not a count of who reads any particular feed.

There is one place where a geofeed changes the answer, and it is a rule about consumers rather than about the stored data. RFC 9632 requires that a consumer which has obtained geofeed data for an address range ignore the other geographic hints for that range — the country: and geoloc: attributes, and DNS geolocation records. That is a constraint on how the consumer processes a dataset it chose to fetch; it does not modify the registry object, whose attributes stay exactly as they are. So a consumer that follows the specification and reads the feed will prefer the feed over the other hints for that range. That is a rule about which source takes precedence during processing — not a claim that the feed is accurate. Everyone else keeps doing what they were doing.

4. How Other Systems Find a Geofeed

A file sitting at a URL is useless unless something knows where to look, and RFC 8805 does not say where to look. It records a format. Earlier drafts referenced discovery through WHOIS or RIR databases, but the published RFC notes that support for those mechanisms "has never been implemented" and removed the text.

RFC 9632, Finding and Using Geofeed Data, fills that gap: it defines how a registry object points at a geofeed file.

inetnum: 192.0.2.0/24
geofeed: https://example.net/geofeed.csv

Where the geofeed: attribute is not yet supported by a registry, the same information goes in a remark:

inetnum: 192.0.2.0/24
remarks: Geofeed https://example.net/geofeed.csv

Details that matter in practice:

The two forms are not equivalent, but both must be readable. The remarks: Geofeed token is case-sensitive, and where both forms appear in one object, the geofeed: attribute is the one to use. Conformant consumers must be able to handle both, because not every registry implements the attribute.
Support varies by registry. At the time RFC 9632 was published, the geofeed: attribute in inetnum objects had been implemented in the RIPE and APNIC databases. Databases without it use the remark form. ARIN's registration data is not RPSL, and its NetRange and Comment keys map to inetnum and remarks respectively.
One reference per object. An object should carry at most one geofeed reference, pointing at exactly one feed file — not a directory, not a bundle.
The registry only stores a pointer. Nothing in the registry validates that the file at that URL is accurate, current, or even reachable. RFC 9632 describes an optional RPKI-based signature mechanism for publishers who want their feed to be cryptographically attributable, but it is optional — an unsigned feed is still a valid feed.
IPv6 works the same way. Everything said about inetnum applies to inet6num.

White-Face Xiaolu follows a thin pointer line from a registry card across a short gap to a plain document pinned on a board.

The registry object does not contain the location data; it points at the file that does.

5. Who Publishes and Updates a Geofeed for a Leased Prefix

This is where leasing starts to matter, and where the answer is less obvious than it looks.

A geofeed does not live in the lease contract. It lives in a registry object, and who may change that object is determined by object authorisation — the mnt-by: maintainer that protects it. Holding a signed lease and receiving the addresses does not, by itself, grant any ability to edit the registry record for the block.

For allocations managed jointly by the RIPE NCC and an LIR, there are two maintainers on the object, and the business rules decide which attributes each party is allowed to change. In the common case, the LIR that holds the allocation is the party that can publish or change the geofeed: reference for prefixes inside it.

So during a lease, the division of labour usually looks like this:

Item	Typically held by
The registry object covering the prefix	The resource holder / LIR
The authority to add or change `geofeed:` on it	The maintainer of that object
Hosting the CSV file itself	Either party, by agreement — it just needs a stable URL
The content of the feed (which prefix gets which city)	Usually the party that knows where the equipment is deployed
Updating the feed when equipment moves	Must be assigned by agreement, or it will not happen

The failure mode is not complicated. The block moves from Frankfurt to Amsterdam, nobody updates the file, and the feed keeps publishing a correct-looking answer that is now wrong. A stale feed is treated with no more confidence than a missing one, and a consumer that cross-checks will notice the contradiction.

Before a leased block goes live, it is worth settling five things in writing:

1. The exact prefix that will be covered by the feed
2. What location values will be published for it
3. Who is authorised to add or edit the geofeed reference in the registry
4. Who maintains the CSV file and the URL it is served from
5. How a change is requested, and what turnaround to expect

SKNK lists Geofeed and location records among the items that can be customised by agreement or Order on the IPv4 address leasing service. That is the level at which the work is actually scoped: prefix, published values, authority, and change path. If review authority matters for your deployment, raise it during the application rather than after delivery — the same discipline the route, ROA, and LOA arrangements on a lease need.

White-Face Xiaolu writes on a blank registry card with a pen, while two small request slips wait on a shelf nearby.

Only the maintainer that protects the object can change the reference in it — a lease does not carry that authority.

6. How to Check the Result, and What a Geofeed Does Not Change

Verification takes four steps, and they follow the chain in order:

1. Query the registry object covering the prefix.
   Look for "geofeed:" or "remarks: Geofeed" and note the URL.
2. Fetch that URL and confirm it returns a feed file.
3. Find the delivered prefix in the file and check the values.
4. Compare against several geolocation services and record the date.

Step 4 is the one that separates a check from an assumption. Different services update at different rates, so a single lookup proves very little on its own. If you are verifying on behalf of a customer, record the services you queried and the date, exactly as a reputation review would.

White-Face Xiaolu compares one small pointer line against a row of separate gauges, each gauge showing a different reading.

Several services, several update cycles: verification means comparing several readings and recording the date.

Then the limits, stated plainly:

A geofeed does not change BGP routing. It is not a route object, not a ROA, and not an authorisation to originate anything. Prefixes are routed according to BGP and routing policy; they are located according to databases. The two systems do not read each other.
A geofeed does not guarantee that any third-party service will change. It provides a hint, and consumers decide what weight to give it.
A geofeed does not replace the registry country: field. It supplements it. A consumer that follows RFC 9632 and reads the feed will ignore the other geographic hints for that range, but the registry data itself is not modified by anyone.
A geofeed does not make a block "belong" to a country. Some services treat location as a factor in access decisions. Publishing a feed is an attempt to correct a data record, not a way to relocate a resource, and describing it as the latter invites the wrong expectations.
A geofeed is not a registry requirement. Nothing obliges a holder to publish one. It is a practice an operator adopts when inaccurate geolocation is costing them something.

FAQ

Will a geofeed make every GeoIP service show the same location?

No. It gives consumers a published hint. Services that consume geofeeds will generally reflect it — some quickly, some after a refresh cycle — and the ones that rely on their own measurements may not change at all, or may keep blending your feed with other signals. If a specific service matters to you, check that service rather than assuming the feed settles it.

Can a leased IPv4 block's geolocation be changed?

Often, yes — by publishing a geofeed and having the registry reference updated. But both steps depend on parties who are not necessarily you: the maintainer of the registry object has to make the change, and enough consumers have to read the feed. Ask who holds that authority before signing, not after.

Is a geofeed the same as an RIR country field?

No. The country: attribute in a registry object is administrative registration data. RFC 9632 notes that these location hints "tend to be administrative, and not deployment specific", so the value is not a statement about where the equipment runs. Contact details live in separate attributes of the same object. A geofeed is a separate, optional, self-published statement about where addresses are used. A consumer that follows RFC 9632 and reads the feed will prefer it over the other hints for that range, but the country: attribute itself is not modified.

Does a geofeed change where traffic is routed?

No. Routing and location are separate systems. A geofeed sits in the location system only. If you need to change how traffic reaches a prefix, that is a routing change — origin ASN, route objects, ROAs, and upstream policy — not a geofeed change.

Conclusion

A geofeed corrects a database record. It does not move a route.

The value of a geofeed is narrow and real: it lets the party who knows where a prefix is deployed publish that fact, in a format consumers can read, without waiting for anyone else to guess correctly. What it cannot do is force agreement — not from a GeoIP vendor, not from a service that has its own measurements, and not from the routing table.

For a leased block, the usable question is not "does a geofeed fix my location data" but "who can publish and update one for this prefix". That answer lives in the registry object's maintainer and in the Order, which is why it belongs in the confirmation list alongside reverse DNS, routing records, and abuse handling.

Key Takeaways

A geofeed is a self-published CSV mapping prefixes to coarse location data, defined in RFC 8805.
It carries country, region, and city — and the postal code field is deprecated, with new feeds advised not to include it.
Publishing a geofeed does not oblige any GeoIP service to adopt it; consumers may treat it as a hint only.
RFC 8805 does not say how to find a feed; RFC 9632 defines the registry reference, through the geofeed: attribute or a remarks: Geofeed line, and support differs by registry.
Changing that reference depends on the registry object's maintainer, not on holding a lease — so who publishes and updates the feed belongs in the Order.
A geofeed has no effect on BGP routing, and no effect on the registry country: field itself.

In One Sentence

A geofeed is a self-published, deliberately coarse file that tells geolocation consumers where a prefix is used — a hint that can correct what some databases show, but one that does not alter routing, does not change registry records, and does not oblige any service to agree.

Continue Reading

What Is Reverse DNS (PTR) for IPv4? — the other record that follows a leased block, and who controls it.
IPv4 Lease IP Reputation Checklist — the pre-signing checks that sit alongside geolocation.
How to Arrange Route, ROA, and LOA — routing records for a lease, and why they are a separate system.
How to Rent IPv4 Addresses — what a lease does and does not transfer.
IPv4 Leasing Below /24 — what changes when the prefix is smaller than a /24.
What Is IPv4? — the address space these records describe.
SKNK IPv4 Leasing — pricing, scope, and the items that can be customised by Order.