IPv6 deployment has reached a tipping point. Over 40% of internet traffic now flows over IPv6, major networks have completed transitions, and mobile carriers route most traffic exclusively over IPv6. This progress raises a tempting question: can we drop IPv4 entirely and deploy AAAA-only domains that serve content exclusively via IPv6?
The technical answer is straightforward, yes, IPv6-only domains work perfectly for users with IPv6 connectivity. The practical answer is more complex. Real-world deployment reveals geographic disparities, compatibility issues, monitoring challenges, and business risks that make IPv6-only strategies viable for some organizations while disastrous for others.
The Dual-Stack Reality
Dual-stack configurations, maintaining both A records (IPv4) and AAAA records (IPv6), remain the dominant deployment pattern. When a client queries your domain, it receives both address types and can choose which to use based on its own connectivity.
Modern operating systems implement "Happy Eyeballs" algorithms that attempt connections over both IPv4 and IPv6 simultaneously, using whichever responds faster. This approach provides seamless failover: if IPv6 connectivity is broken or slow, the client falls back to IPv4 without user intervention.
Dual-stack deployment carries costs. You maintain two parallel network infrastructures, manage twice as many IP addresses, configure firewalls and monitoring for both protocols, and troubleshoot issues that might affect only one protocol. For organizations with limited IPv6 expertise, this operational overhead is significant.
Despite these costs, dual-stack provides maximum reachability. Users with only IPv4 connectivity can reach your services, users with only IPv6 connectivity work fine, and users with both get optimal performance through protocol selection.
The Case for IPv6-Only
Several compelling arguments support IPv6-only deployment for appropriate use cases.
Operational Simplification
Managing a single protocol stack reduces complexity. Your network architecture, security policies, monitoring systems, and troubleshooting procedures focus on one address family instead of maintaining parallel configurations that must stay synchronized.
IPv6's larger address space eliminates NAT requirements for internal networks, simplifying routing and firewall rules. Network management becomes more straightforward when every device has a globally routable address without complex translation layers.
IPv4 addresses are expensive. Organizations purchasing IPv4 address space in 2025 pay significant premiums due to exhaustion. For cloud infrastructure where IPv4 addresses incur ongoing costs per address, eliminating IPv4 can produce meaningful savings at scale.
IPv4 will eventually become legacy infrastructure. Organizations that transition to IPv6-only now position themselves ahead of the inevitable shift and avoid future migration pain when IPv4 finally becomes untenable.
In networks with robust IPv6 deployment, IPv6-only can deliver better performance. Eliminating Happy Eyeballs connection races, avoiding NAT traversal overhead, and routing traffic over newer, better-optimized IPv6 infrastructure can reduce latency and improve throughput.
The Case Against (Or: Why Dual-Stack Persists)
Real-world constraints make IPv6-only deployment risky or impossible for many organizations.
IPv6 adoption is wildly uneven geographically. Some regions approach 70-80% IPv6 deployment while others remain below 10%. An IPv6-only domain that works perfectly in India or the United States might be completely unreachable in parts of Eastern Europe, Africa, or Central Asia.
For organizations with global reach, abandoning IPv4 means abandoning users in low-IPv6-adoption regions. Unless your business explicitly doesn't care about those markets, maintaining IPv4 is necessary.
While mobile carriers and major ISPs have deployed IPv6 extensively, enterprise networks lag significantly. Many corporate environments, educational institutions, and government networks still operate primarily on IPv4 with incomplete or absent IPv6 deployment.
If your services target enterprise users, B2B SaaS platforms, professional tools, or business services, going IPv6-only may exclude significant portions of your potential user base who access your services from corporate networks without IPv6 connectivity.
Legacy Systems and Dependencies
Your infrastructure might depend on third-party services, APIs, or systems that don't support IPv6. Even if your frontend services run IPv6-only, backend dependencies requiring IPv4 create complexity. You might need IPv6-to-IPv4 translation layers, proxy systems, or dual-stack infrastructure anyway.
Monitoring and Troubleshooting Gaps
Many monitoring tools, security systems, and operational platforms have better IPv4 support than IPv6 support. While this gap narrows, organizations moving to IPv6-only might discover their existing monitoring stack can't adequately observe IPv6 traffic or that troubleshooting tools they rely on don't work properly with IPv6.
Happy Eyeballs: The Protocol Perspective
Understanding Happy Eyeballs behavior illuminates why dual-stack deployment works well and where IPv6-only strategies break down.
When a dual-stack client queries a dual-stack domain, it receives both A and AAAA records. Happy Eyeballs initiates an IPv6 connection attempt immediately. If that connection doesn't complete within a short timeout (typically 250-300ms), it starts an IPv4 connection attempt in parallel. Whichever succeeds first wins.
This algorithm provides automatic failover for broken IPv6 connectivity, if a user's IPv6 path is broken, they fall back to IPv4 transparently. It also optimizes for working IPv6 by preferring it when connectivity is good.
For IPv6-only domains, there's no fallback. If a user queries the domain and receives only AAAA records, they must have working IPv6 connectivity or the connection fails entirely. No Happy Eyeballs algorithm can save them, there's simply no IPv4 address to fall back to.
This binary outcome, works or doesn't, with no graceful degradation, is IPv6-only deployment's fundamental risk. Users with broken or absent IPv6 connectivity get hard failures instead of transparent fallback.
Real-World Breakage Patterns
IPv6-only deployment failures manifest in specific patterns that help identify and address issues.
Partial Network Deployment
Networks claiming IPv6 support sometimes have incomplete deployment. Users have IPv6 addresses assigned, routing tables include IPv6 routes, and DNS resolvers respond with AAAA records, but actual IPv6 connectivity to the internet is broken or severely degraded.
These partial deployments create the worst-case scenario: clients attempt IPv6 connections that fail slowly rather than failing fast and falling back. With dual-stack domains, Happy Eyeballs eventually falls back to IPv4. With IPv6-only domains, users experience timeouts and connection failures.
Firewall Misconfigurations
IPv6 firewall rules often receive less attention than IPv4 rules. Organizations might carefully configure IPv4 firewalls while leaving IPv6 firewalls in default-deny states that block legitimate traffic. IPv6-only services become unreachable from these networks even though IPv6 connectivity technically exists.
Some networks deploy DNS64 and NAT64 to provide IPv6-only clients with access to IPv4-only services. These translation mechanisms work well for dual-stack destinations but add unnecessary overhead when native IPv6 connectivity exists.
For IPv6-only domains accessed from DNS64/NAT64 networks, the translation layer isn't invoked, the client gets AAAA records and connects directly. This generally works fine but can create confusion during troubleshooting when behavior differs from IPv4-only destinations the user typically accesses.
Monitoring Playbook for IPv6 Deployment
Successful IPv6-only deployment requires comprehensive monitoring that catches issues before they impact users broadly.
Protocol-Specific Availability Checks
Implement monitoring that explicitly tests both IPv4 and IPv6 reachability separately. For dual-stack services, ensure both protocols work. For IPv6-only services, verify IPv6 connectivity from multiple vantage points representing different geographic regions and network types.
Monitor DNS resolution specifically, ensure AAAA records propagate correctly and that queries from IPv6-only resolvers work properly. DNS issues are a common source of IPv6 connectivity problems.
Deploy monitoring from geographic regions matching your user base. If you serve European users, monitor from multiple European locations. If you serve global users, worldwide monitoring coverage is essential.
Regional monitoring catches geographic disparities in IPv6 deployment and identifies where users might experience connectivity issues.
User-Agent and Platform Diversity
Different operating systems, browsers, and platforms implement IPv6 and Happy Eyeballs differently. Monitor from diverse platforms, Windows, macOS, Linux, iOS, Android, to catch platform-specific issues.
Mobile monitoring is particularly important since mobile carriers have the highest IPv6 deployment rates. Issues affecting mobile users might not appear in desktop-focused monitoring.
Track not just availability but performance, connection establishment time, latency, throughput. IPv6 paths sometimes have different performance characteristics than IPv4 paths, and suboptimal IPv6 performance can impact user experience even when connectivity technically works.
Monitor application error rates segmented by protocol. Increasing error rates correlated with IPv6 traffic suggest protocol-specific issues requiring investigation. For services handling both hosting infrastructure and email services, protocol-specific error tracking identifies whether issues affect all services or only specific components. Staged Rollout Strategy
Smart IPv6-only deployment follows a staged approach that minimizes risk while gathering real-world data.
Deploy IPv6-only for internal services where you control the entire network infrastructure. Internal wikis, monitoring dashboards, or development tools accessed only from corporate networks let you validate IPv6-only operations in controlled environments.
This stage builds operational experience with IPv6-only infrastructure, identifies monitoring gaps, and validates that your team can troubleshoot IPv6-specific issues effectively.
Progress to public services with limited user bases or where connectivity issues have minimal business impact. Developer documentation, status pages, or regional services in high-IPv6-adoption areas serve as real-world testing grounds without exposing core business services.
Monitor user behavior and error rates closely. Unexpected issues discovered during this phase should be resolved before expanding deployment.
Gradual Migration with Fallbacks
For critical services, implement gradual migration. Start by serving a small percentage of traffic via IPv6-only paths while maintaining IPv4 fallbacks. Geographic or user-agent-based routing can direct high-IPv6-adoption regions or platforms to IPv6-only infrastructure while others remain dual-stack.
Gradually increase the IPv6-only percentage based on observed error rates, user feedback, and performance metrics. This approach limits blast radius if issues emerge while accelerating deployment where conditions are favorable.
Maintained Dual-Stack for Critical Paths
Some services may never justify full IPv6-only deployment. Authentication systems, payment processing, or other critical user paths where any connectivity issues cause severe business impact might warrant maintaining dual-stack indefinitely.
This hybrid approach, IPv6-only where practical, dual-stack where necessary, balances operational simplification with business risk management.
Decision Framework
Determining whether IPv6-only deployment is appropriate requires honest assessment of your specific context.
Organizations with geographically concentrated user bases in high-IPv6-adoption regions face lower risk than those serving global audiences. Services targeting mobile users, who benefit from carrier IPv6 deployment, work better IPv6-only than those targeting enterprise users on lagging corporate networks.
Internal services within organizations controlling end-to-end infrastructure can deploy IPv6-only with minimal risk. Public-facing services requiring maximum reachability should maintain dual-stack until IPv6 adoption becomes truly universal, which won't happen in 2025 or likely 2026.
The cost-benefit calculation depends heavily on IPv4 address costs, operational complexity, and user base characteristics. For organizations managing domain registration across multiple TLDs and services, the operational complexity of dual-stack might justify IPv6-only deployment for specific services while others remain dual-stack. The Path Forward
IPv6-only deployment isn't a binary choice between technical purity and pragmatic compromise. It's a spectrum of strategies ranging from full dual-stack maintenance to selective IPv6-only deployment based on service requirements, user characteristics, and risk tolerance.
The internet's transition to IPv6 continues, and IPv6-only deployment will become more viable over time. Geographic disparities will narrow, enterprise networks will complete migrations, and tooling gaps will close. Organizations investing in IPv6 competence now position themselves to take advantage of these improvements.
However, declaring IPv4 dead remains premature. The long tail of IPv4-only networks, systems, and users ensures dual-stack deployment remains necessary for services requiring universal reachability. The question isn't whether to support IPv6, that's mandatory, but whether eliminating IPv4 is worth the operational simplification given your specific user base and business requirements.
For most organizations in 2025, the answer remains "not yet." But for the right services, in the right regions, serving the right users, IPv6-only deployment works. Understanding where those boundaries lie separates successful deployment from user-impacting failures.
.png&w=2048&q=75)
