My Geocode

Guides

Tell IPv4 and IPv6 visitors apart in your logs

· 3 min read · My Geocode · #ip-lookup#ipv4#ipv6#logging

An address like 203.0.113.42 and one like 2001:db8::1 look obviously different, but once addresses are buried in a log file or a database column, a script that assumes one format will quietly mishandle the other.

Reading the version field

The /v1/ip endpoint returns a version field on every response, either 4 or 6, alongside the rest of the location data. There is no need to parse the address string yourself to work out which family it belongs to.

GET /v1/ip?ip=2001:db8::1
{
  "status": "ok",
  "ip": "2001:db8::1",
  "version": 6,
  "found": true,
  "country": "Canada",
  "country_code": "CA",
  "region": "Ontario",
  "city": "Toronto",
  "postcode": "M5H",
  "lat": 43.6511,
  "lon": -79.3808,
  "timezone": "America/Toronto",
  "asn": 4321,
  "org": "Example ISP"
}

Why the distinction matters for quota

The free allowance is counted per network, and that network is defined differently for each address family: all IPv4 addresses sharing a /24 share one allowance, and all IPv6 addresses sharing a /48 share one allowance. A single IPv6 customer with a large allocated block can look like many different addresses in your logs while actually sitting inside one shared allowance, and knowing the version helps you group log entries by the right kind of network boundary rather than treating every distinct address string as unrelated.

A concrete case where this bites

A visitor with a home internet connection that supports both address families can show up in your logs as two seemingly unrelated addresses across two visits, one IPv4 and one IPv6, depending on which one their device happened to use that day. Treated naively, that looks like two different visitors. Grouping by version alongside a stable identifier like a session cookie, rather than by raw address alone, avoids inflating your visitor counts or splitting one customer's history across two profiles.

Practical log handling

When you write your own analytics or abuse detection on top of raw logs, branch on the version field before you try to compute a network prefix, since a /24 mask makes no sense applied to an IPv6 address and a /48 mask makes no sense applied to an IPv4 one. Store the version alongside the address itself rather than re-deriving it from string parsing every time you read the log back.

A mistake worth avoiding

Applying a single regular expression written for IPv4 dotted notation to a column that also contains IPv6 addresses is a quiet source of dropped or miscategorized log rows. Test any address-parsing code against both formats explicitly, including the shortened double-colon notation IPv6 addresses commonly use, rather than assuming one pattern covers both families.

Cost of checking

Looking up version this way costs one request per address checked, same as any other IP lookup. If you are auditing a large log file, batch the addresses through a bulk POST rather than one request per line, keeping the same per-item cost in far fewer calls.

Treating IPv4 and IPv6 as genuinely separate address families, not just different string lengths, avoids a class of bugs that only shows up once IPv6 traffic becomes a meaningful share of your visitors. The IPv6 lookup docs cover the endpoint in full.

More in Guides