IPv4 vs IPv6: Why Your Connection Can Have Both
Recognise IPv4 and IPv6 addresses, understand dual-stack connections, and check what an IP result or DNS record can actually tell you.
WhatsMyIP Team ·
IPv4 and IPv6 are two versions of the Internet Protocol. Your device can use both, and an individual website connection normally uses one of them. Seeing an IPv4 address on one visit is not proof that your connection lacks IPv6.
Show the public IP for this visit. This identifies the address reaching WhatsMyIP; it is not a complete test of every address family or every application on your network.
How to recognise the two formats
- IPv4: four decimal numbers separated by dots
- Example:
192.0.2.25. IPv4 addresses are 32 bits long. - IPv6: hexadecimal groups separated by colons
- Example:
2001:db8::25. IPv6 addresses are 128 bits long, providing a much larger address space. A double colon compresses consecutive zero groups; it may appear only once in an address.
These examples are documentation addresses, not live destinations. The address-size distinction is specified in RFC 8200; IPv6 notation is described in RFC 4291.
Why a device can have several addresses
A dual-stack connection supports both IPv4 and IPv6. A device can also have multiple network interfaces, such as Wi-Fi and a VPN, with addresses for different purposes. “The IP address” is therefore incomplete unless you say which interface, address family and connection you mean.
An IPv6 address beginning with fe80: is link-local: it is not evidence of working IPv6 internet access. Global connectivity also depends on routing and the provider. See the IPv6 link-local definition. Similarly, a private IPv4 address only describes local addressing; see our public vs private IP guide.
Why different sites can show different IP versions
A site may offer IPv4, IPv6 or both. When several connection options exist, modern clients can try alternatives to reduce delays rather than wait indefinitely for a broken route. Happy Eyeballs, RFC 8305, describes this approach. The result depends on the client, DNS answers and network conditions; it is not a vote for the universally faster protocol.
A VPN or proxy adds another variable: it may carry both families, carry one, or deliberately block one. An IP result alone does not certify that every application is using the VPN.
A useful troubleshooting sequence
- Record the context. Which network, browser and VPN state are you using? Check the public address for that visit. Keep these details private when sharing a screenshot publicly.
- Inspect the destination's DNS. In DNS lookup, query the same hostname for A and AAAA records. A records contain IPv4 addresses; AAAA records contain IPv6 addresses, as defined in RFC 3596. A record shows an advertised destination, not a successful connection from your device.
- Separate local and remote tests. Our server-side network tools run from the test server. A successful server check cannot prove that your Wi-Fi, mobile provider or VPN has the same route.
- Change one variable at a time. If permitted, compare Wi-Fi with mobile data, or the same destination with and without your VPN. Save the error and test time for your provider. Do not disable a required work VPN or firewall to follow a troubleshooting suggestion.
Is IPv6 faster or more secure?
Not automatically. A protocol label does not measure congestion, routing quality or server performance, and neither label proves a connection is encrypted. Use a speed measurement to observe that test path under current conditions, and HTTPS for encrypted web connections. Repeated speed tests can differ even without an address-family change.
A globally routed address also does not mean a device accepts unsolicited connections: firewall policy still matters. Avoid turning off a working protocol merely because an IP checker displayed the other one. If only one family fails, the useful next step is to identify the failing route or configuration with your network administrator, not to assume the whole internet connection is broken.