Disclosure up front: I run IPYE, a company that leases IP space. Most of this article is practical how-to; IPYE appears where a free /48 helps you try the work, with a short call to action at the end.
You announce a brand-new prefix from Ashburn and databases still show another country. That is normal for fresh, transferred, or leased space—including a free IPv6 /48 you just claimed from IPYE with instant setup. This article covers measuring errors, publishing an RFC 8805 geofeed, chasing vendors, and what to tell app owners while you wait. Examples use 2001:db8:100::/48 and 198.51.100.0/24 as stand-ins for space you announce from your ASN with a portal LOA and automatic ROA.
Measure before you complain
Sample several addresses across the prefix in multiple public GeoIP views and in the databases your own applications use (MaxMind-style MMDB files, cloud provider geo APIs, and browser-side services). Record country, region, and city. Also test from user perspective: ask two people in different places to open a page that prints the geo your app believes, using a host in the new prefix.
dig +short TXT example.com # if you publish self-test records; optional
curl -s https://ifconfig.io/country_code # from a host inside the prefix; one of many checkers
Prefer reproducible notes over a single web screenshot. Databases disagree; your job is to move the majority toward truth.
Publish a geofeed (RFC 8805)
A geofeed is a CSV of prefixes to location codes, published at an HTTPS URL and referenced from WHOIS/RDAP remarks so findable crawlers can discover it. Minimal process:
- Host a UTF-8 CSV over HTTPS (for example on a stable ops hostname).
- Each data line: prefix, country (ISO), optional region, city, postal.
- Add the feed URL to the inetnum/inet6num remarks in the format geofeed parsers expect (see RFC 8805).
- Keep the file updated when you move announcements between PoPs.
Example CSV lines (documentation prefixes):
# prefix,country,region,city,postal
198.51.100.0/24,US,US-VA,Ashburn,
2001:db8:100::/48,US,US-VA,Ashburn,
Validate that your RIR portal accepted the remark and that curl -fsSL retrieves the feed without redirects through fragile short links.
Chase the big databases
Geofeed adoption is improving but not universal. For databases your customers care about:
- Use each vendor's official correction or self-service submission form.
- Attach evidence: LOA or RIR whois, PoP city, looking-glass announcement, geofeed URL.
- Track ticket IDs and revisit after their published SLA.
Do not expect overnight updates. Plan application-level overrides for critical customers if a wrong country breaks login fraud scoring.
Application mitigations while geo is wrong
- Allow users to pick a region manually when geo is only a hint.
- Avoid hard hard-blocks based solely on GeoIP country for your own infrastructure addresses.
- For CDN steering, pin origins or use provider-specific location overrides when available.
- Document the issue in status notes so support does not chase ghosts.
IPv6-specific notes
IPv6 geo is often coarser and stickier because historical data is thinner. Publish geofeeds for the aggregated /48 you announce, not for every /64. If you announce from multiple cities, either split announcements into regional aggregates or accept a single "primary" location in databases that only store one point per prefix.
Done criteria
You are finished when your geofeed is live, RDAP remarks point to it, major databases you depend on show the correct country (city is nicest-to-have), and internal runbooks describe how to re-submit after a PoP move. Geolocation is part of announcing space, not an optional marketing task after launch.
Common failure modes
- Feed URL in WHOIS but HTTPS certificate wrong — crawlers skip it.
- CSV with a header dialect parsers do not expect — validate against RFC 8805 examples.
- Feed lists a /48 but you announce only a /56 — still OK if accurate; do not list cities you do not route from.
- Correction submitted to the wrong product line of a geo vendor — legacy vs GeoIP2-style databases differ.
- NAT or CDN in front of the test host — you measured the edge, not your prefix.
When a vendor refuses a change, ask what evidence format they need. Provide looking-glass links showing the prefix originated from your ASN at the expected upstream. Patience plus clean evidence beats repeated angry tickets with no attachments.
Communicating to stakeholders
Tell product owners: "Country accuracy may take weeks; do not ship hard geo blocks on this prefix until the tracker says green." Give them a status page row: prefix, intended city, geofeed URL, vendor tickets, last verified date. That single row prevents surprise outages when a payment provider starts treating your Ashburn space as another continent.
IPv4 and IPv6 together
If you announce both families from the same PoP, publish both in the same feed and submit both to vendors. Mixed results—IPv4 correct, IPv6 wrong—are common and confuse dual-stack users differently depending on Happy Eyeballs winners. Verify with tests that force -4 and -6. Align both families before you call the incident closed.
Fresh free /48, stale maps
After you claim a free /48 at IPYE and announce it, publish a geofeed for the aggregate you actually route. Region changes in the IPYE dashboard apply automatically for the service side; third-party GeoIP databases still need your feed and correction tickets. Do not promise day-one city accuracy.
Annual review
Put a calendar reminder to re-check geo for each announced aggregate every six to twelve months, and whenever you open a new PoP. Databases drift, and a correct entry can become wrong again after quiet routing changes. Re-fetch your own geofeed, confirm WHOIS still points at it, and spot-check the three vendors your customers mention most.
Announce, then geofeed
Free /48: the IPYE IPv6 rental page (see About) · ipye@turnel.com
About IPYE
IPYE (https://ipye.com) leases IPv4, IPv6 and ASN space with instant setup. Your first IPv6 /48 is free for the first year, a real allocation you can announce on your own ASN, with a LOA from the portal and the ROA created automatically. ASN and region changes apply automatically. IPv4 /24 to /22 leases include LOA, ROA and per-/24 rDNS; WHOIS is editable on IPv6 /44 and larger. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, Frankfurt. Claim your free /48: https://my.ipye.com/products/ipv6-rental. Questions: ipye@turnel.com.
Disclosure: I run IPYE
Top comments (0)