MyIP.dogHow IPv4 and IPv6 address traffic
IPv4 and IPv6 are two versions of the protocol used to address and route traffic across networks. The most visible difference is notation: version 4 uses four decimal numbers separated by dots, while version 6 uses hexadecimal groups separated by colons. The deeper difference is address space. IPv4 uses 32-bit addresses; IPv6 uses 128 bits, allowing a vastly larger range of values and different addressing practices.
Both can be present on the same device and network. A connection still uses a particular address family and route. Seeing one family in a browser's public address result does not inventory all available interfaces or prove the other family is disabled. Use the IPv6 test to try separate family-specific endpoints when you want a current browser reachability observation rather than a description of a written address.
Read the two notations
An IPv4 example is 192.0.2.10, with each decimal part representing eight bits. An IPv6 example is 2001:db8::10, where the double colon compresses a sequence of zero groups. These examples use documentation space. They illustrate formatting and should not be entered as the real address of a service you intend to reach.
Leading zeroes can be omitted within a hexadecimal group, and one sequence of consecutive zero groups can be represented by ::. As a result, two text strings can describe the same IPv6 value. Compare normalized values rather than assuming different punctuation or capitalization identifies a different endpoint. The IP lookup normalizes supported address input to make this comparison easier.
Do not confuse an address with a prefix. A suffix such as /64 identifies how many leading bits belong to a network prefix; it is not a port or a URL path. Version 4 supports prefix lengths from zero through 32, and version 6 from zero through 128. The subnet calculator derives range boundaries and exact counts for either family.
Address space and network design
IPv4's limited public space encouraged widespread address sharing through network address translation. A home can place many private devices behind one public source, and providers can share public sources across customers through CGNAT. IPv6 offers a much larger space, so networks can give devices globally scoped addresses without copying the same household NAT pattern. That architectural difference does not remove the need for a firewall.
A globally scoped address does not mean an application is open to the internet. Routing, host firewalls, network firewalls, and the service's own listening behavior still determine reachability. Similarly, a private IPv4 address is not a complete security policy. Treat addressing and access control as related but separate design questions, regardless of whether the connection uses IPv6 or its predecessor.
The larger space also changes how subnets are planned. Filling every possible host value is not the objective. Automatic configuration, routing hierarchy, administrative boundaries, and provider allocation matter more than squeezing a small pool of numbers. A mathematically valid IPv6 prefix is not automatically the right prefix for every link or device configuration. Follow the applicable architecture and equipment requirements.
A dual-stack connection
A dual-stack setup supports both address families. A hostname may publish A records for version 4 and AAAA records for version 6. The application and operating system decide which connection to attempt or prefer according to their implementation and current conditions. A successful IPv6 connection to one destination does not guarantee that every other destination offers or supports the same path.
Modern clients can attempt alternatives to avoid unnecessary delays when one path is poor. This is one reason the homepage might show an IPv4 source even though a separate IPv6-only request works. The observations are not necessarily contradictory. They describe different connections to different endpoints, and connection selection can depend on timing as well as capability.
When comparing results, record the destination, family, active network, VPN state, and time. Otherwise, a screenshot from cellular service and another from home Wi-Fi may appear to disagree when they simply measure different environments. A meaningful IPv6 investigation keeps those conditions attached to the result instead of treating a single address as a permanent property of the device.
Local scopes and temporary addresses
Version 6 includes link-local addresses for communication on a link and unique local space for local uses. A device may also hold several globally scoped addresses with different lifetimes. A fe80 address in your settings is not the public source that a remote website must see. Inspect the relevant interface and scope rather than assuming every IPv6 value serves the same purpose.
Temporary source addresses can change over time. That can be normal behavior rather than a configuration error or evidence of compromise. If you are creating an allowlist or remote access rule, understand whether the observed IPv6 address is expected to remain stable. A provider-assigned prefix can also have its own lifetime and assignment policy, separate from the device's choice of a source within it.
Translation and provider architecture
Some networks use translation mechanisms to let clients communicate with services that support only another family. DNS64 and NAT64 are examples relevant to IPv6-oriented networks reaching IPv4 destinations. A successful request to a version 4 service therefore does not always prove that the local interface has an ordinary public version 4 assignment. The source observed by the destination can belong to the translation infrastructure.
Two endpoint responses cannot fully reconstruct that architecture. If the distinction matters for hosting, troubleshooting, or application development, consult the provider and inspect the local configuration. An IPv6 test should report its direct observation and explain its limits, rather than convert a small number of successful requests into a detailed but unverified story about every part of the network.
VPNs and privacy
A VPN can route the two families differently, depending on its design and settings. It may carry both, block one, or apply policies only to particular applications. Seeing an IPv6 source while the VPN is connected does not by itself prove a leak, because the source may belong to the VPN's exit. Compare known before-and-after values and the intended routing policy.
The opposite inference is also unsafe: a failed family-specific request does not certify that no traffic of that family can leave the device. An extension or firewall might block the test endpoint while allowing another destination. DNS, browser peer connections, and split-tunnel applications require their own evidence. IPv6 support and VPN privacy are connected topics, but one short test cannot settle every question about them.
Troubleshooting without unnecessary changes
If a site fails only on one family, compare its DNS records and the reachability of the relevant destination. Check router support, provider service, local interface state, and VPN effects. Do not immediately disable IPv6 across the device simply because one endpoint fails. That can affect other services and hide the original issue without identifying its cause.
If a tool returns a long address you did not expect, first normalize and classify it. If a result changes, record whether the interface or network changed. If an inbound service is unreachable, verify that it listens on the intended family and that the applicable firewall permits the connection. An IPv4 rule does not automatically describe an IPv6 rule, and the service may bind differently for the two families.
Which version should you use?
For ordinary browsing, a correctly configured device and provider generally handle connection selection. For operating a service, support the families your users and infrastructure need and test each path explicitly. IPv6 is not inherently a universal speed upgrade or a guarantee of better privacy. Actual performance and exposure depend on routes, services, configuration, and application behavior.
The useful goal is a working, understood network rather than a preferred-looking address string. Learn the differences in public and private addressing and static and dynamic assignment as separate dimensions. Standards background is available in RFC 4291, RFC 5952, and RFC 8305. Use current measurements to apply those concepts to the IPv6 behavior you actually observe.