Anyone who works with an Internet service provider has probably seen this type of complaint:
“My client is in Paraná, but the website thinks he’s in São Paulo.”
“The streaming is saying I’m in another country.”
“The bank blocked access because it thought the IP location was strange.”
“Google is showing a weather forecast for another city.”
It’s a bit of a thankless situation, because most of the time the network is working. The client is browsing, BGP is OK, DNS is responding, traceroute is coming through, latency is acceptable.
But for the end user, the perception is simple: something is wrong with their Internet.
And often it is. Not in connectivity, but in the way that IP address is being geolocated by third parties.
IP has no city recorded inside it
The first important thing to understand is that an IP is not born with a city inside it.
There is no field in the IP protocol saying:
este endereço fica em Apucaranaor:
este prefixo pertence a LondrinaIP geolocation is an inference. Content companies, banks, CDNs, anti-fraud platforms, search engines, streaming services and commercial bases try to find out where that IP is probably being used.
To do this, they cross-reference various pieces of information: Internet log data, traffic behavior, measurements, history, user information, commercial bases, DNS, BGP, among other things.
In most cases it works well enough. But when it goes wrong, it’s a real nuisance.
A provider can receive a new block, buy or transfer resources, change prefixes between cities, activate a new POP, reorganize CGNAT, divide IPv6 by region, exchange upstreams or simply start using a block that was previously associated with another location.
It’s just that the external bases can take a while to learn this.
And then the calls begin.
Where geofeed comes in
The geofeed is a standardized way for the network operator to say:
“These IP prefixes are being used in these locations.”
It doesn’t change routing. It doesn’t change BGP. It doesn’t announce anything to the Internet. It’s not an upstream session.
It’s just a CSV file published over HTTPS, following a format defined in RFC 8805 [1].
192.0.2.0/24,BR,BR-PR,Apucarana,
198.51.100.0/24,BR,BR-PR,Londrina,
203.0.113.0/24,BR,BR-SP,Sao Paulo,
2001:db8:100::/48,BR,BR-RS,Porto Alegre,
Each line associates a prefix with an approximate location.
The format is:
ip_prefix,alpha2code,region,city,postal_codeIn practice:
192.0.2.0/24,BR,BR-PR,Apucarana,I mean:
o prefixo 192.0.2.0/24 está no Brasil, no Paraná, em ApucaranaThe comma at the end is important. It represents the last field, postal_code, which is empty.
What each field means
The first field is the IP prefix. It can be IPv4 or IPv6, in CIDR format.
192.0.2.0/24,BR,BR-PR,Apucarana,
2001:db8::/32,BR,BR-PR,Londrina,The second field is the country, using ISO 3166-1 alpha-2. For Brazil, we use BR.
The third field is the region, using ISO 3166-2. In the case of Brazilian states:
BR-PR Paraná
BR-SP São Paulo
BR-SC Santa Catarina
BR-RS Rio Grande do Sul
The official list can be consulted on the ISO platform [4]. For quick reference, there is also the ISO 3166-2:BR page, which lists the codes of the Brazilian states [5].
The fourth field is the city.
The fifth field is the postal code. It exists in the format, but I don’t normally recommend using it for providers. The RFC itself treats this field with caution, because it can give too much granularity [1].
For ISP, in most cases, country, state and city are enough.
Geolocation is approximation, not GPS
This point is more important than it seems.
When we talk about geofencing, it’s easy to fall into the temptation of trying to be too precise. But IP geolocation is not GPS.
At NANOG 96, Sid Mathur presented a talk called High-quality IP Geofeeds using AI Coding Assistants and MCP. One of the presentation’s most useful messages is precisely this: IP geolocation is statistical and inexact. The ideal is to think in geographical regions, not an exact point on the map [6].
He makes a good point: more precision doesn’t always mean higher quality.
For a fixed ISP, which knows that a particular prefix serves a specific city, it makes sense to inform the city:
192.0.2.0/24,BR,BR-PR,Apucarana,But if the same prefix serves several nearby cities, it might be better to stop in the state:
192.0.2.0/24,BR,BR-PR,,This avoids solving one customer’s problem and creating a problem for another.
In the same presentation, he also comments on very real cases: users blocked for regional content, streaming thinking the person is in another country, websites showing the wrong weather and ISPs receiving complaints for something that is often outside the connectivity layer [6].
Anyone who lives in an operation knows that this happens.
Does geofeed solve everything?
No.
And it’s important to be honest here.
Publishing geofeed does not oblige Google, Netflix, banks, MaxMind, IPinfo, Cloudflare or any other consumer to immediately accept that information.
RFC 8805 treats the geofeed as a source published by the operator. Consumers can collect it, validate it, cross-reference it with other databases and decide whether or not to use it [1].
Even so, publishing correctly greatly improves your position.
Before, you had to manually call up several different databases, each with its own process. With geofeed, you create a public, standardized and automatically discoverable source.
It’s not a guarantee of instant correction, but it’s a much better operating practice.
How do others find out about your geofeed?
Publishing the file to a URL is only part of the story.
You need to indicate where this file is in the IP block records.
This is where RFC 9632 [2] comes in.
It defines how to associate a geofeed file with IP resource registration objects, such as inetnum and inet6num.
There are two main ways.
The newest way is to use the own attribute:
geofeed: https://geo.exemplo.com.br/geofeed-192.0.2.0-24.csvThe way that is compatible with environments that don’t yet support the specific attribute is to use remarks:
remarks: Geofeed https://geo.exemplo.com.br/geofeed-192.0.2.0-24.csvThe important thing is that the consumer can look at the block record and discover that there is a geofeed file associated with it.
What about RDAP?
RDAP is the most modern way of querying registry data.
While traditional WHOIS returns text, RDAP returns JSON. This makes it much easier to automate.
RFC 9877 defines how an RDAP server can report geofeed links within the response of an IP object [3].
An example would be something like this:
{
"rel": "geofeed",
"href": "https://geo.exemplo.com.br/geofeed-192.0.2.0-24.csv",
"type": "application/geofeed+csv"
}In other words: the consumer consults the RDAP of an IP, finds the link geofeed, downloads the CSV and processes the information.
The most specific wins
The logic here is very familiar to anyone who works with networks.
The most specific wins.
But it’s worth separating two things: geolocation granularity is not necessarily BGP announcement granularity.
On the real Internet, in IPv4, /24 is usually the smallest practical unit for global announcements. So, if you have a larger block, such as a /22, and internally use each /24 in a different city, the geofeed can represent this division by /24.
bloco-a/24,BR,BR-PR,Apucarana,
bloco-b/24,BR,BR-PR,Londrina,
bloco-c/24,BR,BR-SP,Sao Paulo,
bloco-d/24,BR,BR-RS,Porto Alegre,The important thing is to understand the rule: when there are overlapping entries, the consumer should consider the most specific entry as the best match.
RFC 8805 allows nested prefixes and directs the consumer to use the most specific entry as the best match [1].
RFC 9632 follows the same idea when dealing with discovery via Internet logs: the most specific object with a geofeed reference should be used [2].
File quality matters
A bad geofeed may not help. In some cases, it can even get in the way.
Wrong example:
192.0.2.0/24,BR,PR,Apucarana,The correct answer is:
192.0.2.0/24,BR,BR-PR,ApucaranaAnother wrong example:
192.0.2.0/24,BR,BR-PR,ApucaranaThe last empty field is missing. It’s best to keep it:
192.0.2.0/24,BR,BR-PR,Apucarana,Another common mistake is to mix independent blocks within the same file, especially when the system where you are going to publish requires one file per block.
For example, if the file is associated with the block 192.0.2.0/24, do not place another independent block inside it, such as 198.51.100.0/24.
Even though in the RFCs there are scenarios where a single file can be used with care, in operational practice it is better to start simple: one file per block, containing only that block or sub-blocks of it.
In Brazil, attention to Registro.br’s current policy
Registro.br has started to implement support for geofeed-related RFCs.
For the time being, the policy is stricter. In practice, the safest way is to keep one file per block, containing only the block itself or sub-blocks of it, in UTF-8, with the correct number of fields and published in such a way that the file is downloaded directly.
This is important because one thing is what the RFC allows in more general terms. Another thing is how a specific implementation validates and accepts the data at the time.
So, to use Registro.br, think of it like this:
bloco 192.0.2.0/24 -> arquivo geofeed-192.0.2.0-24.csv
bloco 198.51.100.0/24 -> arquivo geofeed-198.51.100.0-24.csv
bloco 203.0.113.0/24 -> arquivo geofeed-203.0.113.0-24.csvAnd each file should only contain the corresponding block or sub-blocks of it.
Review cadence
Geofeed shouldn’t be a forgotten file on the server.
He needs to monitor the operation.
Has the distribution of prefixes changed?
Activated new POP?
Did you get a new block?
Did you transfer funds?
Have you sorted CGNAT by city?
Reorganized IPv6?
Have you purchased another provider?
Then review the geofeed.
In NANOG’s presentation, an interesting suggestion is to treat this with cadence. Small ISPs can review monthly. Large ISPs and mobile operators may need to review weekly. Clouds and CDNs may need to review daily [6].
For most regional providers, I would put this on the checklist for network changes.
Conclusion
Geofeed is simple, but it solves a real problem.
It helps the provider to communicate in a standardized way where their IP prefixes are being used. It doesn’t guarantee that all the bases in the world will correct it immediately, but it does create a public, organized and automatable reference.
In a nutshell:
- RFC 8805 defines the file format;
- RFC 9632 defines how to discover and use these files via Internet logs;
- RFC 9877 takes this information to RDAP;
- Registro.br has already started to support this process;
- for Brazil at the moment, it’s best to work with one file per block.
Just like RPKI, IRR, PeeringDB, reverse DNS and good IPAM documentation, geofeed becomes part of an ISP’s operational maturity.
It’s not just about “finding a city on Google”. It’s taking care of the identity of your IP resources on the Internet.
References
[1] RFC 8805 – A Format for Self-Published IP Geolocation Feeds
https://www.rfc-editor.org/rfc/rfc8805
[2] RFC 9632 – Finding and Using Geofeed Data
https://www.rfc-editor.org/rfc/rfc9632
[3] RFC 9877 – RDAP Extension for Geofeed Data
https://www.rfc-editor.org/rfc/rfc9877
[4] ISO Online Browsing Platform – ISO 3166 / Brazil
https://www.iso.org/obp/ui/#iso:code:3166:BR
[5] ISO 3166-2:BR – list of Brazilian state codes
https://en.wikipedia.org/wiki/ISO_3166-2:BR
[6] NANOG 96 – High-quality IP Geofeeds using AI Coding Assistants and MCP
https://nanog.org/events/nanog-96/content/5683/
[7] Presentation video – High-quality IP Geofeeds
https://www.youtube.com/watch?v=x_vbTj_D91I
