IPv4 gives the internet about 4.3 billion addresses. That pool was exhausted years ago. IPv6 expands it to 340 undecillion addresses, but it has not replaced IPv4. Production systems need to understand both.
The difference between IPv4 and IPv6 is mostly address space and packet design. For application code, the practical difference is simpler: an incoming client address can be either format, and your validation, logging, storage, allowlists, and IP geolocation calls must accept both.
What is the difference between IPv4 and IPv6?
IPv4 uses a 32-bit address written as four decimal numbers, such as 203.0.113.42. IPv6 uses a 128-bit address written as hexadecimal groups, such as 2001:4860:4860::8888. The longer format is not cosmetic. It creates enough addresses for the internet to keep growing without the address-sharing workarounds IPv4 relies on.
| Data point | IPv4 | IPv6 |
| Address length | 32 bits | 128 bits |
| Address format | Four decimal octets, such as 192.0.2.1 | Eight hexadecimal groups, such as 2001:db8::1 |
| Total address space | 2³², about 4.29 billion addresses | 2¹²⁸, about 340 undecillion addresses |
| Header size | 20 to 60 bytes | 40 bytes |
| Configuration | Manual or DHCP, commonly with NAT | SLAAC and DHCPv6, with no need for NAT for address conservation |
| Geolocation support | Yes | Yes |
The difference between IPv4 and IPv6 is not just the number of available addresses.
IPv6 also has a redesigned header, a different configuration model, and native support for features such as Neighbor Discovery. IPv4 commonly relies on Network Address Translation, or NAT, because public IPv4 addresses are scarce.
IPv6 was designed to make globally unique addressing practical again.
Why IPv4 still runs alongside IPv6
IPv4 is not disappearing because networks, devices, business systems, and vendor integrations were built around it. NAT lets many private devices share one public IPv4 address, stretching a scarce resource. It also means a public IPv4 address may describe a gateway, not one person or device.
IPv6 removes the need for that scale of address sharing, but migration is incremental. Most networks use dual stack: they give devices IPv4 and IPv6 connectivity, then choose the appropriate path. IPv4-only clients and IPv6-only clients can also communicate through translation layers.
Do not infer that a colon means an address is suspect, or that a long address needs special treatment beyond proper parsing. Store addresses in a type large enough for IPv6, use an IP-aware database type when available, and let a tested IP library normalize and validate input.
What changes for IP geolocation?
IP geolocation works for IPv4 and IPv6. The lookup maps an address to network registration and routing data, then returns fields such as country, region, city, latitude, longitude, ASN, and connection type. It is useful for localization, fraud signals, and routing decisions. It is not a precise device-location system.
Accuracy depends on the provider’s data and the network’s allocation practices. Mobile carriers, privacy relays, corporate networks, VPNs, and shared gateways can all move the apparent location away from the user. Treat the result as a signal, not proof.
IPstack accepts IPv4 and IPv6 lookups through its API endpoint. It is part of the APILayer suite, so one account, one API key, one dashboard, and one invoice cover the service.

Look up IPv4 and IPv6 withIPstack
The same endpoint handles both formats. Pass a public address in the path and your API key as access_key. The example below calls an IPv4 address and Google’s public IPv6 resolver. Keep the key in an environment variable, not in source control.
# IPstack API v1.0.0: the address can be IPv4 or IPv6 IPSTACK_API_KEY=“your_access_key”
curl “https://api.ipstack.com/134.201.250.155?access_key=${IPSTACK_API_KEY}” curl “https://api.ipstack.com/2001:4860:4860::8888?access_key=${IPSTACK_API_KEY}” |
A lookup response is JSON. This is an abbreviated response structure from the API, showing the address and the fields you can use. Values can change as network registrations and geolocation data change.
{ “ip”: “134.201.250.155”, “type”: “ipv4”, “country_name”: “United States”, “region_name”: “California”, “city”: “Los Angeles”, “latitude”: 34.0655517578125, “longitude”: -118.24053955078125 } |
Read the official IPstack documentation for available fields and options. In a request path, IPv6 colons are valid. If your HTTP client builds URLs from structured components, use its normal path encoding rather than hand-assembling the URL.
A practical migration checklist
First, test your edge layer. Confirm your proxy and framework preserve the correct client address and that you only trust forwarded-address headers from known proxies. Then test IPv4 and IPv6 through the same sign-in, rate-limit, audit-log, and geolocation paths.
Next, review schema constraints and regular expressions. A VARCHAR(15) column fits a maximum-length IPv4 string but fails on IPv6. A brittle IPv4-only regex creates the same failure earlier in the request. Use an address parser, persist a normalized value, and keep the original only when your audit requirements need it.
Create one IPstack account, grab your API key, and make your first geolocation call in minutes. No credit card required. Start here:
https://dashboard.ipstack.com/signup/free/monthly