IPv4 Geolocation and Leasing: What You Need to Know Before You Deploy
This article covers both sides: when geolocation is a real operational concern, and when it isn't.
Artem Kohanevich
Co-Founder & CEO at IPbnb
May 21, 2026
Last updated
Table of Contents
item
AI Summary
For most operators, geolocation is not something to worry about. It only becomes relevant for specific use cases: VPN services, ad tech, CDN operators, compliance-sensitive infrastructure, and web scraping.
"Geolocation" actually means two separate things — what's recorded in the RIPE database, and what third-party databases like MaxMind display. These don't always match, and they update independently.
In RIPE, the geofeed: attribute is the most effective tool for influencing commercial databases. The geoloc: attribute has limited adoption, and the country: field is administrative — not a geolocation signal.
After a lease activates, expect a propagation window. MaxMind updates daily, but downstream services (CDNs, ad exchanges) can take two to six weeks. Build in a buffer before relying on accurate geolocation in production.
Geolocation and IP reputation are completely separate systems. Fixing one does nothing to the other. If you're worried about a subnet's history, run a reputation check — not a geolocation lookup.
IPv4 geolocation is one of the most common topics our support team gets asked about. Operators want to know whether their leased subnet will appear in the right country, how long it takes to update, and what happens if something looks wrong.
The honest answer is that for most workloads, geolocation is not something you need to worry about. But for a specific set of use cases - VPN services, ad tech, content platforms, compliance-sensitive infrastructure - it does matter, and it helps to understand how it works before you deploy.
Two Things People Call "Geolocation"
It helps to separate two things that often get conflated.
The first is the registered location - what the RIPE database records for your subnet via the geoloc: and geofeed: attributes. Of these, the geofeed: attribute has the broadest support among geolocation database providers and is the recommended starting point for operators who need accurate location data.
The second is database location - what third-party services like MaxMind, IPinfo, and Google display when they look up your IP block. These are independent commercial databases drawing on multiple signals: RIR records, BGP routing data, latency measurements, and user-submitted corrections. They don't always agree with each other and update on their own schedules.
When operators ask "will my subnet show up as France?" they're usually asking about the second category. The answer depends on which database they're checking, when it was last updated, and what signals it's reading. The IPbnb catalog shows each subnet's MaxMind-verified location at the time of listing, so you know the starting point before you commit.
Geolocation in the RIPE Region: More Flexible Than You Think
Operators can configure geolocation data directly on their inetnum objects using two dedicated attributes.
The geoloc: attribute records latitude and longitude coordinates in the RIPE database. Its adoption among third-party geolocation providers remains limited - a senior RIPE engineer has confirmed it is not currently used by most major databases. Worth setting for completeness, but not a reliable mechanism for influencing commercial databases.
The geofeed: attribute, added to the RIPE database on December 7, 2021, links to a structured CSV file that providers supporting RFC 9632 discovery can find and ingest automatically. This is the mechanism with actual traction, and it's what operators should prioritize.
A note on the country: field: it is a general administrative registration field, not a geolocation tool. RIPE's own documentation states that "it has never been specified what this country represents" and that it "cannot be used in any reliable way to map IP addresses to countries." Treat it as background data, not as a signal for controlling database output.
RIPE does not verify any of the information operators enter. Publishing a correctly configured geofeed gives providers a structured signal they can act on - but update timelines vary by provider.
When Geolocation Actually Matters
For the majority of operators leasing IPv4, geolocation has no practical effect on their work. But there are use cases where it is genuinely important to get right.
VPN and proxy services. Your product is a country presence. If you sell a France endpoint, your IP block needs to register as France in the databases your customers' applications check.
Programmatic advertising and ad tech. Ad exchanges use IP geolocation to categorize traffic by geography. European inventory is priced differently from traffic that appears to originate elsewhere. Incorrect geolocation means miscategorized inventory.
Content delivery and CDN configuration. CDNs route user requests to edge nodes based on IP location. A subnet in the wrong region means users are routed to suboptimal nodes, adding unnecessary latency.
Regulatory compliance and data localization. Organizations processing data under GDPR sometimes need infrastructure to be clearly identifiable as EU-based. An IP block appearing outside the EU creates friction even when the physical servers are in Frankfurt.
Web scraping and data collection. Many sites serve different content, pricing, and availability by detected country. Your IP's geolocation determines the geographic view your infrastructure gets.
When Geolocation Doesn't Matter - Which Is Most of the Time
If no system your traffic passes through makes decisions based on your IP's perceived country, geolocation is irrelevant to your operation. This covers most hosting and application workloads, ISP and telecom infrastructure, internal networking, and general web traffic delivery. BGP routing operates on routing tables, not geolocation databases.
One specific misconception worth naming: email deliverability depends on your IP's reputation record - spam history, blacklist status, authentication setup - not on geolocation. A subnet geolocated in the Netherlands and one geolocated in France are treated identically by mail servers.
Propagation, Timelines, and Correcting Your Data
After your lease activates, there is a normal propagation window before all databases reflect the correct location.
MaxMind - the most widely used geolocation database, and the one IPbnb uses for catalog listings - updates the majority of its GeoIP databases every weekday, Monday through Friday. MaxMind does not publicly commit to a review timeline for individual correction requests. For time-sensitive situations, the geofeed route will produce more predictable results than submitting a one-off correction form.
Downstream services - CDN networks, ad exchange databases, streaming platform geolocation layers - can take two to six weeks to fully reflect a change. This is not a failure condition; it is how the ecosystem works. If your use case is geolocation-sensitive, plan for a one-to-two week buffer after lease activation before relying on correct geolocation in production. For ad tech or CDN-critical deployments, two to four weeks is a safer margin.
If your geolocation needs correcting, the most effective approach is publishing a geofeed: a CSV file in the format defined by RFC 8805, hosted at a public HTTPS URL and linked from your inetnum object via the geofeed: attribute. Discovery is standardized in RFC 9632 (published August 2024). MaxMind now directs network operators primarily to its GeoIP Exchange program, through which geofeed submission is the standard correction method. Providers supporting RFC 9632 discovery will find and ingest your geofeed automatically on their next crawl cycle - no need to contact each database separately.
For one-off corrections where a geofeed isn't yet in place, major databases each have their own submission process. Correcting your data with one provider does not automatically update others.
Our Help Center has a dedicated guide covering geolocation correction in detail. If you want to talk through your specific situation, support is available to help.
Geolocation Is Not the Same as IP Reputation
These get confused regularly, and acting on that confusion wastes time.
Geolocation is about where your IP block appears to be located. Reputation is about the historical behavior associated with that IP - spam history, blacklist status, abuse records. They are completely separate systems. A subnet can have perfect geolocation and a problematic reputation, or an outdated geolocation entry and a completely clean record. Fixing one does not affect the other.
If you are concerned about the reputation of a subnet you're considering leasing, run a reputation check - not a geolocation lookup. IPbnb validates all listed subnets before they appear in the catalog, and our Help Center covers how to run your own checks before deployment.
If you have questions about how geolocation applies to your specific setup, contact our support team at support@ipbnb.com, or browse the IP Catalog to see current subnet locations before you commit to a lease.
You can also use the Pricing Calculator to model costs across different subnet sizes and plan your deployment.
