IPv6 Adoption: Why the Internet Still Uses IPv4
Quick Answer
IPv6 adoption does not automatically remove IPv4 dependencies. A network can successfully deploy IPv6 while still needing to communicate with IPv4-only clients, services or application dependencies.
Successful communication requires compatible endpoints and a working network path, or an appropriate intermediary connecting the two protocol environments. Dual stack supports both IPv4 and IPv6. Translation mechanisms and some proxies or gateways can provide IPv4 compatibility across an IPv6-oriented network.
The central distinction is:
IPv6 Capability ≠ IPv6 Usage ≠ Complete IPv4 Replacement
Deploying IPv6 creates the opportunity to use it. Removing IPv4 requires resolving the remaining compatibility dependencies.
Key Takeaways
- IPv6 capability, operational deployment and actual traffic usage describe different things.
- An IPv6-capable client cannot automatically reach every destination natively over IPv6.
- IPv4 connectivity remains necessary wherever required systems support only IPv4; each device does not necessarily need native IPv4.
- Dual stack allows a device, network or service to support both address families.
- DNS records help applications discover addresses, but an AAAA record does not guarantee working IPv6 connectivity.
- NAT64 translates packets; DNS64 synthesizes DNS answers. They perform different functions.
- Removing IPv4 from an access segment does not necessarily remove IPv4 from the complete service path.
- Adoption measurements must be interpreted according to what they count.
What Is IPv6 Adoption?
IPv6 adoption is the process of making IPv6 available and operational across devices, applications, networks and services, and increasingly using it for communication.
IPv6 was designed as IPv4’s successor. It expands address size from 32 bits to 128 bits, providing an address space large enough to avoid IPv4’s comparable scarcity constraint at practical Internet scale. That expanded capacity does not automatically make existing IPv4 systems compatible with IPv6. RFC 8200
For the background on limited IPv4 availability, see IPv4 Exhaustion.
Adoption and Replacement Describe Different Outcomes
The following distinctions help make deployment claims more precise:
| State | What it means | What it does not establish |
| IPv6-capable | Relevant hardware or software supports IPv6 | IPv6 has been configured or is reachable |
| IPv6 deployed | IPv6 operates within a defined network or service scope | Every application or destination uses it |
| IPv6 actually used | Observed communication takes place over IPv6 | Other traffic no longer needs IPv4 |
| IPv4 removed from one segment | That segment no longer carries native IPv4 | Translation or another segment has no IPv4 dependency |
| Complete IPv4 dependency removal | All required communication within the stated scope works without relying on IPv4 | The wider Internet has reached the same state |
These are useful analytical distinctions, rather than a mandatory sequence of migration stages.
A conceptual model for coexistence is:
- Networks deploy IPv6 independently.
- IPv4-only, IPv6-only and dual-stack environments coexist.
- Communication uses native connectivity or transition mechanisms.
- IPv4 dependencies can be reduced where compatibility allows.
This is a conceptual model, not a universal migration path. Networks can follow different deployment approaches, and progress in one environment does not automatically change another.
Why IPv4 Is Still Needed
IPv4 connectivity remains necessary wherever required clients, destinations or dependencies are IPv4-only.
That connectivity can be provided natively, alongside IPv6 through dual stack, or through an appropriate transition mechanism. An IPv6-only access network can therefore support some IPv4-dependent communication without assigning native IPv4 connectivity to every attached device. RFC 6180
Required Destinations May Still Support Only IPv4
An organization may enable IPv6 throughout its own network while relying on an external API, supplier system or hosted application that accepts only IPv4 connections.
Its local deployment does not upgrade that external service. The organization still needs a compatible way to reach it.
The reverse also matters: a service that must remain accessible to IPv4-only customers needs an IPv4-compatible entry point, even if its internal infrastructure uses IPv6.
Application Dependencies Extend Beyond the Visible Endpoint
A working IPv6 website does not establish that its complete application environment is independent of IPv4.
Consider a hypothetical service whose public endpoint supports IPv6, but whose payment integration accepts only IPv4 connections. Customers can successfully use IPv6 to reach the service while the service retains an IPv4 dependency elsewhere.
The relevant question is therefore broader than whether the homepage loads over IPv6: which required connections still depend on IPv4?
Operational Readiness Takes More Than Protocol Support
Migration can involve application changes, equipment replacement, vendor support, staff training, monitoring updates and revised access policies. These introduce costs and coordination work beyond enabling IPv6 on an interface.
Enterprise deployment guidance treats infrastructure readiness, application readiness, testing, training and security policy as separate concerns. An IPv6-capable router does not resolve all of them. RFC 7381
Continued IPv4 use reflects compatibility and operational requirements. It does not establish that IPv4 is technically superior.
Client, Network and Destination Compatibility
An IPv6-capable client does not make every destination natively reachable over IPv6.
For direct IPv6 communication, both endpoints must support it and the effective path must carry it successfully. Where capabilities differ, an appropriate intermediary may provide compatibility.
The following table separates the questions that a general statement such as “this network supports IPv6” can hide:
| Component | Compatibility question | Why it matters |
| Client | Can the device and application use IPv6? | Operating-system support alone does not establish application support |
| Access network | Does the connection provide usable IPv6 service? | Device capability does not create network connectivity |
| DNS | Can the application discover a suitable destination address? | Address discovery and address reachability are separate |
| Destination endpoint | Does the intended service accept IPv6 connections? | A server’s IPv6 address does not establish that every service listens on it |
| Path / policies | Do routing and relevant traffic policies permit the connection and response? | Compatible endpoints still need a working path |
| Intermediary / proxy / gateway | Does an intermediary support the required address families and communication model? | It may connect environments that cannot communicate directly |
This describes the effective communication path. Encapsulation and intermediary architectures mean that underlying transport infrastructure need not expose the same address family at every layer. RFC 4213
What A and AAAA Records Tell You
At a conceptual level:
- An A record contains an IPv4 address.
- An AAAA record contains an IPv6 address.
The record type is independent of whether the DNS exchange itself travels over IPv4 or IPv6. A DNS query sent over IPv4 can retrieve an AAAA record, and a query sent over IPv6 can retrieve an A record. RFC 3596
However:
AAAA Record ≠ Guaranteed Working IPv6 Connectivity
Publishing an address does not prove that the service accepts connections, the route works or the relevant policies allow traffic.
An address may also represent a public frontend rather than every backend component. DNS answers alone cannot establish that an entire application has eliminated IPv4 dependencies.
What Is Dual Stack?
Dual stack means that a device, network or service supports both IPv4 and IPv6.
For example, a dual-stack client can use IPv6 to reach one service and IPv4 to reach another. Both protocol environments are available, but an ordinary connection uses the address family selected for that connection. Dual stack itself does not translate between them. RFC 4213
This provides a practical coexistence model, but operating two protocol environments adds work. Addressing, routing, monitoring and traffic policies need appropriate coverage for each.
Dual stack is also not the only transition approach. Some networks use IPv6-only segments with mechanisms that preserve access to required IPv4 services.
Why Connections Do Not Always Use IPv6: Happy Eyeballs
When a destination offers both IPv4 and IPv6 addresses, applications still need to select a working connection.
Happy Eyeballs Version 2 describes an approach that coordinates address resolution and overlapping connection attempts to reduce delays when an address or path is slow or unavailable. It avoids making the user depend entirely on one potentially unsuccessful attempt. RFC 8305
Consequently, IPv6 availability does not mean every connection will use IPv6. Address availability, application behavior and connection outcomes influence the result. Applications also do not all implement identical selection behavior.
IPv6-Only Networks and Transition Mechanisms
“IPv6-only” needs a scope. It might describe an access network or another segment while IPv4 remains in use beyond that boundary.
Several mechanisms can support communication across different protocol environments. They solve different problems and are not interchangeable.
NAT64: Packet Translation
Stateful NAT64 enables suitable IPv6-client-to-IPv4-server communication by translating packets between the two protocol environments. RFC 6146 describes support for unicast TCP, UDP and ICMP scenarios. RFC 6146
The client-facing path can use IPv6 while the destination-facing path uses IPv4. The destination remains an IPv4 service.
NAT64 therefore supports compatibility without making that destination natively IPv6-capable.
DNS64: DNS Synthesis
DNS64 can synthesize an AAAA answer from an A record so an IPv6 client can address an IPv4 destination through a compatible translator.
DNS64 itself does not translate packets. DNS64 handles address discovery; NAT64 handles packet translation in a deployment that combines them. RFC 6147
This distinction explains why a synthesized IPv6 address does not mean the original server supports IPv6. It represents a way to reach that server through translation.
The combination is not a universal solution for every application. For example, an application using an IPv4 address literal may not perform the DNS lookup on which this synthesis depends.
464XLAT: IPv4 Compatibility Across an IPv6-Only Network
464XLAT is a documented architecture that combines stateless translation at the edge with stateful translation elsewhere in the network. It provides limited IPv4 connectivity across an IPv6-only network. RFC 6877
Its relevance here is that applications requiring certain IPv4 connectivity can continue operating while the intervening access infrastructure uses IPv6.
That does not imply universal support for every IPv4 application or removal of IPv4 from the destination side.
Proxies and Gateways
An application intermediary can terminate a connection using one address family and establish a separate connection using another, if its implementation supports that arrangement. Transition guidance describes proxies and relays as one approach to connecting IPv4 and IPv6 environments. RFC 6180
This differs from packet translation: the intermediary participates in separate connections.
Future visual placement — “Why IPv4 and IPv6 Still Coexist”: show three separate scenarios after this section:
| Scenario | Communication shown |
| Dual-stack client and IPv6-capable service | IPv6 connection, where selected and reachable |
| Dual-stack client and IPv4-only service | IPv4 connection |
| IPv6-only access and IPv4-only service | IPv6 on the access side, translation, then IPv4 to the service |
Keep DNS64 in a separate address-discovery annotation if included. Do not place it in the packet-forwarding path or combine the scenarios into one abstract “Dual-Stack Internet.”
Why IPv6 Adoption Is Uneven
IPv6 adoption is not one global switch.
ISPs, mobile operators, enterprises, hosting providers, cloud services and content networks make deployment decisions independently. Countries and regions contain many such networks, each with its own customers and dependencies.
Different environments also have different deployment boundaries. An access provider considers subscriber connectivity and customer equipment. An enterprise must account for internal applications and business integrations. A hosting or content provider considers service endpoints and customer reachability.
RFC 9386 documents deployment across multiple environments and discusses differing motivations and transition choices. Its observations provide historical context, not a live measurement of every network today. RFC 9386
The practical consequence is that one operator’s successful rollout does not complete another operator’s migration. A service provider may enable IPv6 while some customers remain IPv4-only; a customer network may enable IPv6 while a required service remains IPv4-only.
Adoption Measurements Count Different Things
Share of Users ≠ Share of Requests ≠ Share of Websites ≠ Share of Networks
For example, Google describes its metric in terms of users accessing Google over IPv6. Cloudflare Radar provides an HTTP-request distribution by IP version. These observations have different populations and denominators. Google IPv6 Statistics, Cloudflare Radar
A website count would answer another question, as would a count of networks meeting a particular deployment criterion. Different results can therefore coexist without contradicting each other.
An adoption figure becomes meaningful only when its measurement scope is clear.
Where CGNAT Fits During the Transition
CGNAT allows providers to continue sharing limited public IPv4 resources while IPv6 deployment grows. It addresses continuing IPv4 demand alongside the deployment of IPv6.
For how provider-scale sharing works, see CGNAT Explained.
What This Means for Proxy Connections
A proxy connection has two distinct legs:
| Connection leg | What its address family describes |
| Client to proxy | How the client reaches the proxy endpoint |
| Proxy to destination | How the proxy reaches the requested destination |
Those legs may use different address families if the proxy implementation supports it.
A client connecting to a proxy over IPv6 does not automatically prove IPv6 egress to the destination.
For example, the proxy might accept the client’s IPv6 connection and create an IPv4 connection to an IPv4-only service. The destination would then observe the destination-facing IPv4 connection.
For the separate proxy comparison topic, see IPv4 vs IPv6 Proxies.
Practical Examples
These examples are conceptual and do not describe any particular provider’s architecture.
Example 1: Successful IPv6 Deployment With a Remaining IPv4 Dependency
A company provides working IPv6 connectivity to its employees. Its collaboration service supports IPv6, while a required supplier portal supports only IPv4.
Employees use IPv6 for the first service and retain IPv4-compatible access for the second.
The IPv6 deployment is successful. The supplier dependency determines why IPv4 compatibility remains necessary.
Example 2: IPv4 Removed From the Access Segment
An access network carries IPv6. A client reaches a suitable IPv4-only service through DNS64 and NAT64.
The access segment does not need native IPv4 for that communication, but the translator still communicates with the destination over IPv4.
This is a reduction in the scope of IPv4 deployment, rather than complete removal of IPv4 from the service path.
Example 3: IPv6 at the Frontend, IPv4 Behind It
A service exposes an IPv6-capable frontend. That frontend communicates with an internal application over IPv4.
A customer’s successful IPv6 request establishes that the public endpoint is reachable over IPv6. It does not establish that the backend is IPv6-capable or that the service has no remaining IPv4 dependencies.
Identify the Dependency Before Declaring the Migration Complete
When assessing IPv6 progress, define the scope first: a device, application, access segment, public endpoint or complete service.
Then distinguish three questions:
- Where is IPv6 available?
- Which required connections actually use it?
- Which connections still require IPv4, directly or through an intermediary?
These questions turn a broad deployment claim into a useful account of what works and what remains dependent on IPv4.
Final Thoughts
The meaningful measure of migration is whether required communication continues working as IPv4 dependencies are reduced.
That requires examining more than protocol support on a device or interface. Clients, services, application dependencies and intermediaries can reach different stages independently. Defining those boundaries makes it possible to recognize real IPv6 progress while accurately describing the IPv4 compatibility that remains.
Glossary
| Term | Meaning |
| Address family | The addressing environment used for communication, such as IPv4 or IPv6 |
| IPv6-capable | Able to support IPv6, without necessarily having it configured or in use |
| Dual stack | Support for both IPv4 and IPv6 within a stated device, network or service |
| IPv6-only segment | A defined segment operating without native IPv4 service |
| IPv4 dependency | A required connection or function that still relies on IPv4 |
| Native IPv6 communication | Communication using IPv6 between the relevant endpoints without IPv4/IPv6 translation |
| A record | A DNS record containing an IPv4 address |
| AAAA record | A DNS record containing an IPv6 address |
| NAT64 | Translation supporting suitable communication between IPv6 clients and IPv4 servers |
| DNS64 | Synthesis of AAAA answers from A records for use with compatible translation |
| 464XLAT | An architecture combining stateless and stateful translation to provide limited IPv4 connectivity across an IPv6-only network |
| Happy Eyeballs | A connection-establishment approach using coordinated attempts to reduce delays associated with unavailable or slow alternatives |
Frequently asked questions
Here we answered the most frequently asked questions.
Why hasn’t IPv6 replaced IPv4?
Networks and services migrate independently. Required IPv4-only clients, destinations and application dependencies continue to need compatible connectivity, even where IPv6 has been successfully deployed.
Can an IPv6-only client access an IPv4-only website?
It can in an appropriately supported scenario using translation or an intermediary. IPv6 capability alone does not provide that access, and compatibility depends on the application and mechanism.
Does dual stack mean each connection uses IPv4 and IPv6 together?
No. Dual stack makes both available. An ordinary connection uses the address family selected for that connection.
Is DNS64 the same as NAT64?
No. DNS64 synthesizes DNS answers. NAT64 translates packets. They can work together, but DNS64 does not forward or translate application traffic.
Does an AAAA record prove a website works over IPv6?
No. It provides an IPv6 address. The endpoint, network path and relevant policies must also support a successful connection.
Does “IPv6-only network” mean IPv4 is no longer involved?
Not necessarily. The description may apply to an access segment while a translator or proxy still uses IPv4 to reach external services.
Does IPv6 deployment mean every application will choose IPv6?
No. Destination addresses, application behavior and path availability influence connection selection. Happy Eyeballs can help applications establish a working connection across available alternatives.
Will IPv4 eventually disappear?
IPv4 dependencies can be removed from particular environments when their requirements allow it. No single deployment milestone establishes a universal shutdown date for the Internet.