IP geolocation in the modern network stack
IP geolocation data quietly influences a large number of operational decisions on today’s Internet.
It affects:
- Geo-based cybersecurity policies
- Compliance and sanctions enforcement
- Content licensing restrictions
- Fraud detection systems
- Traffic analytics and reporting
Yet in most cases, the geographic location of IP address space is still determined by inference performed by third-party commercial databases.
There is a better way.
Geofeed, standardised in RFC 9632, allows network operators to publish authoritative geographic information for their own prefixes. It is a simple, standardised and independent workflow free of any vendor involvement.
This article explains:
- What Geofeed is and how it works
- How it evolved and where adoption stands today
- Why operators should take it seriously
- How to publish IP geolocation data for your network
Terminology note:
Before going further, it is worth clarifying terminology.
- IP geolocation refers to the process of mapping IP address space to geographic locations. This is a generic, industry-wide term describing the technical function, not a specific product.
- Geofeed refers to the standardised mechanism defined in RFC 8805 and updated in RFC 9632 that allows network operators to publish authoritative IP-to-location mappings for their own prefixes.
- GeoIP is a trademark of MaxMind and refers to that company’s product line. While the underlying concept of IP geolocation is vendor-neutral and implemented by many providers, the term “GeoIP” itself is not generic.
In this article, we use the term IP geolocation to describe the broader ecosystem, and Geofeed to describe the standards-based publication mechanism.
The IP geolocation accuracy problem
The uncomfortable reality: IP geolocation is mostly inference
Historically, and still partially today, most IP geolocation databases are built and maintained by commercial providers such as MaxMind and Digital Element. Their datasets are assembled using a combination of datapoints:
- WHOIS and registry information
- BGP announcements
- Latency and topology measurements
- Traffic observation
- Customer-submitted corrections
At Internet scale, this approach works surprisingly well. But it is still inference.
There is no field in BGP that says “this prefix is physically located in Helsinki.” Registry objects were never designed to serve as structured, machine-readable geolocation sources. Routing data does not encode physical deployment geography.
As a result, most commercial IP geolocation data is a best-effort approximation based on educated guessing.
When the approximation is correct, nobody notices. But when something breaks, the guesswork becomes painfully obvious.
When inference gets it wrong
The failure modes are familiar to many network teams.
For example, a company registered in one country deploys infrastructure in another, but databases map its prefixes to headquarters rather than physical location. Or, a recently transferred IPv4 space retains the previous owner’s country attribution for months. Another example would be when anycast prefixes are treated as single-location deployments. Also, hosting providers with globally distributed infrastructure may appear to exist in one jurisdiction only. These are not edge cases. They are natural consequences of a system built on inference rather than authoritative declaration.
Common IP geolocation misclassification scenarios
These are some of the very common and well-documented scenarios where IP geolocation data gets misclassified.
- Corporate registration vs physical deployment
- IP space registered to a UK company but physically deployed in Germany gets mapped to the UK.
- Geo-based filtering now behaves incorrectly.
- Reassigned address space
- Transferred IPv4 blocks retain old country mappings in databases for months.
- Traffic analytics and fraud systems misclassify users.
- Anycast and distributed infrastructure
- Anycast prefixes get treated as single-location deployments.
- Country-level traffic reporting becomes misleading.
- Hosting and cloud providers
- Infrastructure deployed in multiple jurisdictions gets simplified into one country entry.
The dirty laundry of bad data
Network operators have historically had limited control over how their IP space is geographically represented on the Internet. Yet when inaccurate IP geolocation data causes problems, it is the operators who are expected to resolve them.
When location data is incomplete or incorrect, the remediation process is rarely straightforward. Correcting errors typically requires opening support tickets with each IP geolocation database provider individually. Operators have no control over the timelines, internal workflows or prioritisation decisions of commercial vendors, who may not share the same operational urgency.
Even after a correction is accepted, propagation across downstream consumers is not always predictable. Some services update quickly; others refresh data on longer cycles. In the meantime, filtering rules, analytics systems and compliance controls may continue operating on outdated information.
It is not difficult to understand why many operators concluded that there had to be a better way — one where authoritative data could be published directly, rather than negotiated indirectly through vendor processes.
The solution: Geofeed under RFC 9632
How it works
Geofeed introduces a simple but important shift. Instead of relying purely on inference, the address holder can publish authoritative location data.
Under RFC 9632, an operator creates a publicly accessible, machine-readable CSV file that maps IP prefixes to geographic information.
Each entry includes:
- IPv4 or IPv6 prefix
- Country code (ISO 3166-1 alpha-2)
- Optional region
- Optional city
A minimal example looks like this:
203.0.113.0/24,FI,Uusimaa,Helsinki
2001:db8::/32,GB,England,London
The file is hosted over HTTPS and referenced from the relevant RIR object (inetnum/inet6num) or exposed via RDAP. IP geolocation database providers can automatically discover and ingest the data.
Why it works
The design philosophy of RFC 9632 is intentional:
- Minimal format
- No proprietary API
- No central authority
- No vendor dependency
This moves IP geolocation from a vendor-inferred model to an operator-declared model. This mirrors other developments in Internet hygiene. RPKI allows operators to declare valid route origins. IRR allows them to publish routing policy. Geofeed allows them to declare geographic location.
In each case, authoritative publication reduces ambiguity.
For operators who already maintain accurate IPAM data, Geofeed is not about creating new information. It is about exposing existing truth in a structured, ecosystem-consumable way.
History and adoption
How it started: RFC 8805 in 2020
Geofeed was first standardised in 2020 through RFC 8805. Over time, the community refined the mechanism based on real-world deployment experience, leading to the publication of RFC 9632 in 2024.
Before standardisation, some networks experimented with informal methods. A few operators published CSV files describing prefix-to-location mappings, and certain IP geolocation providers began consuming them on an ad hoc basis. However, there was no agreed format, no discovery mechanism and no consistent validation model.
This informal ecosystem highlighted two things:
- Operators wanted a way to declare authoritative IP geolocation data.
- Vendors were willing to consume it, but they needed a standardised format.
That led to the development of RFC 8805, published in 2020. RFC 8805 formally defined:
- The CSV format
- Field structure and ordering
- Discovery via RIR inetnum/inet6num objects
- Basic validation expectations
It was intentionally simple. The goal was not to build a complex geolocation framework, but to introduce a lightweight mechanism that could be widely adopted.
Operational maturity and refinement
Between 2020 and 2024, real-world deployment exposed edge cases and ambiguities:
- Clarifications were needed around file formatting and validation behaviour.
- RDAP-based discovery became more important as registry systems evolved.
- Operators needed clearer guidance on handling overlapping or granular prefixes.
Rather than replacing the mechanism, the IETF refined it. This work resulted in RFC 9632, published in 2024.
RFC 9632 obsoletes RFC 8805 but does not fundamentally redesign Geofeed. Instead, it:
- Clarifies validation requirements
- Improves alignment with RDAP-based discovery
- Incorporates operational lessons learned
- Strengthens interoperability expectations
This transition marked an important point: Geofeed moved from initial deployment into a more mature and operationally stable phase. Today, Geofeed is no longer experimental. It is a stable IETF standard backed by several years of production deployment experience. From a protocol lifecycle perspective, Geofeed has passed the “early concept” stage. The remaining challenge is not technical viability; it is ecosystem adoption.
Steady growth but incomplete coverage
Adoption has grown steadily since 2020. The most detailed public measurement study from late 2023 observed roughly 34 million IPv4 addresses published in geofeed files, representing around 0.8% of globally allocated IPv4 space. Approximately 2,800 autonomous systems were publishing feeds at that time, equating to only a few percent of all ASNs.
Since then, additional operators — particularly in IPv6 space — have begun publishing feeds. Major networks and infrastructure providers have integrated Geofeed into their workflows. The direction of travel is clearly upward.
However, the broader picture remains the same: the majority of networks still do not publish authoritative IP geolocation data.
As long as adoption remains partial, most IP geolocation databases will continue to rely primarily on inference. The ecosystem benefits of Geofeed increase with participation, but we are not yet at the point where operator-declared data dominates.
This creates a clear opportunity — and arguably a responsibility — for network operators.
Why operators should adopt Geofeed now
Geofeed under RFC 9632 is arguably the best way to publish geographic information about your IP space without relying on commercial IP geolocation providers.
It is standardised, simple and field-tested. With RFC 9632, the mechanism is mature and production-grade. At this point, publishing authoritative IP geolocation data should not be optional for serious operators.
If you do not publish a Geofeed, your prefixes will still be geolocated — just not by you.
What can go wrong without Geofeed?
- Unintended traffic filtering
Country-based filtering may block legitimate traffic if prefixes are misclassified. - Compliance risk
Over-blocking or under-blocking due to incorrect country attribution. - Weakened fraud detection
Inaccurate geolocation reduces signal quality in risk-scoring systems. - Misleading analytics
Country-level traffic reporting may not reflect actual deployment. - Slow correction cycles
Fixing errors requires vendor tickets and unpredictable propagation.
Geofeed does not solve every IP geolocation issue. But it replaces inference with operator-declared data — a material improvement for systems that depend on geographic signals.
The strategic question
If you do not publish authoritative data, others will classify your network for you. For small networks, that may be tolerable. For larger or distributed operators, it introduces unnecessary uncertainty.
Geofeed is a low-effort, standards-based way to regain control over how your IP space is represented. The protocol is mature. The ecosystem support exists. The remaining step is adoption.
How to publish a Geofeed
Deploying Geofeed is generally straightforward, but it should be treated as a formal operational task rather than an afterthought.
First, generate a clean and consistent CSV file from your IPAM system. Ensure prefixes are valid, properly aggregated, and accurately mapped to ISO 3166-1 alpha-2 country codes. Avoid overlapping or conflicting entries. Strict adherence to RFC 9632 formatting rules is important, as ingestion systems may reject malformed files.
Second, host the file over HTTPS at a stable, publicly accessible URL. Avoid unnecessary redirects and monitor availability. Reliability matters; if the file becomes inaccessible, automated ingestion may fail.
Third, add the geofeed attribute to the relevant inetnum or inet6num object in your RIR database. Verify via RDAP that the reference is visible externally. Discovery depends on this linkage.
Finally, integrate Geofeed maintenance into your IP lifecycle processes. When prefixes are reassigned, moved geographically or decommissioned, the Geofeed file must be updated. Treat it with the same discipline as RPKI ROAs or IRR route objects.
Closing thoughts
Geofeed under RFC 9632 provides a simple, standardised mechanism for publishing authoritative IP geolocation data. It addresses a long-standing structural gap in how geographic information about IP space is shared.
Adoption is growing, but it is still far from universal. Most IP geolocation data remains inference-based, even though operators are in the best position to declare accurate information.
For networks that already maintain structured IPAM data, publishing a Geofeed requires limited additional effort. The benefits — improved accuracy, reduced dependency on vendor correction workflows and stronger alignment between operational reality and public data — are tangible.
At this point, Geofeed should be viewed not as an experimental feature, but as part of modern network hygiene. The mechanism is stable. The operational cost is low. The ecosystem impact increases with every additional operator who chooses to participate.
