IPv6 Geolocation Accuracy: Why It Still Lags IPv4
IPv6 geolocation accuracy is generally lower and less consistent than IPv4 accuracy because IPv6 addresses are allocated in very large prefixes, change frequently on client devices, and have had far less time to accumulate the measurement data that location databases depend on.
That does not mean IPv6 lookups are useless. Country-level answers are usually dependable, and network ownership is exact because it comes from registry data. The weaker part is city-level precision, which is where developers tend to get surprised. This article explains the causes and what to do about them in an application.
Why IPv6 location data is harder to build
An IPv4 address is a single scarce resource, so providers and networks tend to carve it into small, geographically tidy blocks, and measurement projects have had decades to map them. IPv6 flips the economics. A home subscriber commonly receives a /56 or /64 prefix, which on its own contains more addresses than the entire IPv4 internet, and ISPs hold allocations large enough to cover a whole country in a single announcement.
Several consequences follow. First, a single large IPv6 block can serve customers across many cities, so a database that assigns one location to the whole block will be wrong for most of them. Second, the strategies that infer location from latency, from routing data or from user-submitted corrections have fewer samples per prefix. Third, the numbering inside a prefix is not tied to geography in any reliable way: two neighbouring /48 blocks can be allocated to customers on opposite sides of a country.
The sheer sparseness matters too. In IPv4 you can reasonably hope to have observed a large share of active addresses. In IPv6 almost every address is unique to a moment and a device, so databases must generalise from prefixes rather than from individual hosts.
Privacy addresses, mobile networks and tunnels
Client devices usually rotate temporary IPv6 addresses for privacy, so the same phone can appear under many addresses within one prefix over a day. That is good for users, but it means any approach that tries to remember a specific address is fragile. What stays stable is the prefix, and a good lookup works at that level.
Mobile carriers add another layer of uncertainty. Traffic from a phone often exits the carrier network at a regional gateway, so the address you see maps to the gateway's region and not the handset. The same applies to IPv4 behind carrier-grade NAT, but IPv6 mobile prefixes are frequently large and shared across wide areas. Corporate networks, VPNs and IPv6 tunnel brokers can also announce prefixes registered in one country while the traffic originates in another. Our article on why an IP location describes a network and not a person covers this reasoning in detail.
Finally, registry data lags real life. A prefix reassigned between companies or regions may keep its old registration country for a while, so treat the registration country as a strong hint and not as proof of where the user sits.
What is reliable on IPv6 and what is not
Reliable: the origin AS, the organisation that holds the prefix, the registered country, and whether the prefix is a reserved or documentation range. These facts come from routing and registry data and do not depend on guessing where a device is. Approximate: city, region, timezone and any coordinates. Treat those as a pointer to the area served by the network, not a street address.
ipto accepts IPv4 and IPv6 in the IP lookup and returns the same fields for both, including country, city, ASN, organisation and the flags is_vpn, is_tor, is_abuser, is_datacenter and bogon. The IPv6 range and ASN dataset is built on a best-effort basis alongside the IPv4 one and refreshed daily, so coverage can be thinner for IPv6 than for IPv4, and a missing city field is a normal outcome you should handle. We do not claim a specific accuracy percentage for either protocol, and you should be sceptical of anyone who does without describing their test set.
Designing around the uncertainty
Practical rules that work well for dual-stack applications:
- Use country for compliance-style decisions and city only for soft personalisation such as a default weather location or a pre-filled form field.
- Prefer the ASN and organisation as a signal. The ASN lookup shows the owner and announced ranges for a network, which is stable across protocol versions.
- Run a whois lookup via RDAP when you need the registered allocation, contact and dates for a prefix instead of a guess.
- Check reverse DNS when a hostname exists, since carriers and hosting companies sometimes encode a city or airport code in it. Treat this as a hint only.
- Let users correct their location, and store the correction against the account rather than the address.
- Cache by prefix rather than by individual address for IPv6, because a /64 usually belongs to a single subscriber or site.
Test with your own traffic. Pull a day of IPv4 and IPv6 addresses from logs where you know the true location, such as shipping addresses on completed orders, and compare. The gap you measure is the number that matters for your product, and it will differ by country and by carrier mix.