Testing location data with edge cases, not just happy paths
An address in a well mapped city center tells you almost nothing about how your system handles a rural route, a disputed border, or a query near the poles. Test the hard cases deliberately.
IPv6 allocation and what it means for geolocation
IPv6 was designed to solve address exhaustion, and it succeeds so thoroughly that the scale involved changes some of the practical assumptions carried over from years of IPv4-based geolocation practice. A single IPv6 allocation to an organization or even an individual subscriber can cover an address space vastly larger than an entire IPv4 allocation to a large ISP, which changes how meaningfully allocation size correlates with the size or specificity of who is using it.
This affects geolocation in a couple of practical ways. Regional internet registries still allocate IPv6 blocks along the same regional structure as IPv4, ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC each manage allocations for their region, so country and regional identification for IPv6 works on the same underlying registry logic as for IPv4. Where IPv6 differs is in how ISPs subdivide their allocations down to individual customers, since the sheer size of a typical block makes it practical to assign a large, often fixed range to a single subscriber or a single site, rather than dynamically sharing a much smaller pool the way CGNAT does routinely on IPv4.
That difference cuts both ways for geolocation accuracy. A fixed, dedicated IPv6 range assigned to a specific subscriber can in principle support more stable and consistent location tracking over time than an IPv4 address that gets reassigned frequently within a CGNAT pool. At the same time, IPv6 adoption and the underlying data mapping specific IPv6 ranges to precise locations is generally less mature than the equivalent IPv4 data, since IPv4 geolocation has had a much longer runway to accumulate detail, which can mean coarser results for some IPv6 ranges even where the equivalent IPv4 range for the same network would resolve more precisely.
There is also a practical detail worth knowing about IPv6 that has nothing to do with geolocation accuracy directly but affects how lookups are performed. IPv6 addresses can encode an IPv4 address within them using a hex-mapped form, written as something like ::ffff: followed by the IPv4 address in dotted notation. A geolocation system needs to recognize and resolve this form back to the underlying IPv4 address to look it up correctly, rather than treating it as an unrelated, opaque IPv6 address with no connection to known IPv4 data.
My Geocode's IPv6 lookup resolves hex-mapped IPv6 addresses back to their IPv4 form automatically, and returns the same country, region, city, postal code, coordinates, time zone, ASN, and organization fields as the IPv4 lookup, so you get consistent handling regardless of which protocol version a given request happens to arrive on.