A dual-stack test is a specialized network connectivity assessment that verifies a system's ability to communicate using both IPv4 and IPv6 protocols simultaneously when connecting to servers that offer both address types. Unlike basic IPv4-only or IPv6-only tests that check each protocol in isolation, a dual-stack test evaluates the most critical real-world scenario: how your network behaves when faced with a choice between protocols.
This type of testing has become essential as more websites and services transition to dual-stack configurations, publishing both A records (IPv4) and AAAA records (IPv6) in their DNS. When your browser visits sites like Google, Facebook, or Netflix—all of which operate dual-stack infrastructure—your network must intelligently choose which protocol to use, or attempt both in parallel. The dual-stack test reveals exactly how well your network handles this critical decision.
The primary function of a dual-stack test is verifying that both IPv4 and IPv6 connections succeed when connecting to the same destination. The test server publishes both A and AAAA DNS records, creating a realistic environment where your browser must choose between protocols.
This differs fundamentally from separate protocol tests. You might have working IPv4 connectivity and working IPv6 connectivity when tested individually, but experience failures when connecting to dual-stack sites. This paradox occurs because broken IPv6 with long timeouts can block access to sites that would otherwise work perfectly via IPv4.
A successful dual-stack test confirms that at least one protocol—preferably both—establishes connections to dual-stack endpoints without failures or excessive delays. The test typically attempts to fetch data from servers configured with both address types, measuring whether the connection completes successfully.
When both protocols work correctly, your network receives the highest compatibility score. When only one protocol succeeds, the test identifies whether you're effectively operating in IPv4-only or IPv6-only mode despite having both protocols configured.
Beyond simple connectivity, dual-stack tests measure the performance characteristics of connections to dual-stack endpoints. This includes:
Response Time: How quickly the connection establishes and returns data. Dual-stack connections should complete within milliseconds to a few seconds. Timeouts exceeding 5 seconds indicate serious problems that will cause noticeable website loading delays.
Protocol Selection Efficiency: Whether your network automatically selects the faster, more reliable protocol. Modern systems should prefer IPv6 when it offers better performance, but fall back to IPv4 seamlessly when IPv6 is slow or broken.
Large Packet Handling: Advanced dual-stack tests verify that connections can handle full-sized packets, not just small initial handshakes. This reveals MTU (Maximum Transmission Unit) issues that might cause some websites to appear broken even when basic connectivity works. For more details, see Path MTU Discovery in IPv6.
Testing IPv4 and IPv6 separately, while useful, fails to reveal the most common dual-stack failure mode: broken IPv6 that causes timeouts when accessing dual-stack sites.
Consider this scenario: Your ISP has deployed IPv6, and your device successfully configures an IPv6 address. When you test IPv6-only connectivity to an IPv6-only endpoint, the test might succeed. When you test IPv4-only connectivity, it also succeeds. However, when you visit dual-stack websites in the real world, pages take 60-90 seconds to load before finally working.
This occurs because the dual-stack website publishes AAAA records, your browser attempts IPv6 first, IPv6 connections time out after 60 seconds, and only then does your browser fall back to IPv4. Single-protocol tests would indicate everything is working, but the dual-stack test reveals the critical failure.
Modern Internet services primarily operate in dual-stack mode:
Major Content Providers: Google, Facebook, Netflix, Amazon, and Microsoft all serve both IPv4 and IPv6. When you visit these sites, your browser receives both address types and must choose which to use.
Content Delivery Networks: Cloudflare, Akamai, and other CDNs operate dual-stack edge servers worldwide. Accessing any site behind these CDNs triggers dual-stack behavior.
Corporate and University Networks: Many enterprises and educational institutions run dual-stack infrastructure, requiring employees and students to successfully connect regardless of protocol preference.
A comprehensive dual-stack test simulates these real-world conditions, connecting to endpoints that mirror the configuration of the sites you visit daily.
Modern browsers and operating systems implement an intelligent algorithm called "Happy Eyeballs" that makes dual-stack operation seamless when everything works correctly. This algorithm is defined in RFC 8305 and governs how your system chooses between IPv4 and IPv6. Understanding this algorithm is crucial to interpreting dual-stack test results.
When connecting to a dual-stack destination, Happy Eyeballs performs these steps:
Simultaneous DNS Resolution: The client requests both A and AAAA records in parallel, minimizing DNS resolution delays.
Address Sorting: Received addresses are sorted according to RFC 6724 rules, typically preferring IPv6 addresses over IPv4.
Initial Connection Attempt: The client initiates a connection to the first address (usually IPv6) immediately.
Delayed IPv4 Attempt: After a brief delay—typically 200-300 milliseconds—the client initiates a parallel IPv4 connection attempt without waiting for the IPv6 attempt to complete or fail.
First Success Wins: The first connection that successfully establishes is used for the session. All other pending connections are cancelled immediately.
This elegant approach provides optimal performance when IPv6 works perfectly (IPv6 establishes before IPv4 is even attempted), excellent fallback when IPv6 is slightly slow (IPv4 attempts in parallel and may win the race), and acceptable fallback when IPv6 is broken but fails quickly (IPv4 succeeds soon after).
However, Happy Eyeballs has a critical weakness: it assumes broken connections fail quickly. When IPv6 is configured but fundamentally broken—connectivity exists at the network layer but traffic never successfully reaches the destination—connections time out slowly, typically after 60-90 seconds.
During this timeout period, Happy Eyeballs has already committed to the IPv6 connection attempt. Even though IPv4 was attempted in parallel, many implementations prefer the IPv6 result if it eventually completes (even slowly), or wait for both attempts to complete before giving up.
This is precisely what dual-stack tests identify: whether your network falls into this problematic "broken IPv6" category where everything appears configured correctly, but real-world dual-stack connections experience severe delays.
Different browsers implement Happy Eyeballs with slight variations:
Chrome and Chromium-based browsers use a 300ms Connection Attempt Delay (CAD), meaning IPv4 attempts begin 300ms after IPv6.
Firefox follows the RFC recommendation of 250ms CAD.
Safari implements the most sophisticated version, using dynamic delays based on network conditions and interleaving multiple addresses when available.
curl (command-line tool) uses the smallest delay of 200ms, favoring rapid fallback.
These implementation differences mean dual-stack test results may vary slightly between browsers, though the fundamental connectivity behavior remains consistent.
A critical component of dual-stack testing is protocol preference detection—determining which protocol your network actually uses when both are available. This reveals whether your configuration follows the expected behavior of preferring IPv6, or whether misconfigurations, performance differences, or network policies cause unexpected protocol selection.
Protocol preference tests work by connecting to a dual-stack endpoint and examining which IP address the connection uses. The test server can identify this by logging the source address of incoming connections, or by returning the client's IP address in the response.
When the preference test shows IPv6 is used, this indicates:
When the preference test shows IPv4 is used despite having IPv6 available, several scenarios might apply:
Scenario 1: IPv6 Performance Issues: IPv6 might be working but significantly slower than IPv4, losing the connection race consistently.
Scenario 2: Application Configuration: Some applications can be configured to prefer IPv4, overriding system defaults.
Scenario 3: DNS Resolution Delays: Slow AAAA record resolution might cause IPv4 to win by default even when IPv6 would be faster.
Scenario 4: Intermittent IPv6 Failures: IPv6 might fail often enough that your operating system has temporarily deprioritized it.
It's crucial to distinguish between what protocols are available and which protocol is actually preferred. You might have both IPv4 and IPv6 fully functional (capability), but your system might consistently choose IPv4 (preference).
This isn't necessarily problematic—if IPv4 performs better in your network, preferring it makes sense. However, the combination of IPv6 capability with IPv4 preference sometimes indicates suboptimal IPv6 configuration that should be investigated.
The most severe dual-stack issue is broken IPv6 that times out slowly. In this scenario:
This creates a catastrophic user experience. Websites take over a minute to load despite having perfectly functional IPv4 connectivity. Users perceive your entire Internet connection as broken, not realizing IPv6 is the culprit.
Dual-stack tests immediately identify this condition by attempting connections to dual-stack endpoints and measuring response times. When tests show IPv4 succeeds quickly but dual-stack tests timeout, broken IPv6 is the diagnosis.
Solution: Either fix the IPv6 connectivity issue (work with your ISP, check router configuration, verify firewall rules) or temporarily disable IPv6 to restore normal operation while investigating the root cause.
IPv6 relies heavily on Path MTU Discovery (PMTUD) because IPv6 routers don't fragment packets—only the source can fragment. If ICMP "Packet Too Big" messages are blocked anywhere along the path, PMTUD fails, and large packets simply disappear into the network.
This creates a insidious problem: small packets work perfectly (initial connection establishment succeeds), but large transfers fail mysteriously. Websites might load partially but hang when transferring images or large content.
Advanced dual-stack tests include large packet tests that verify full-sized frames can successfully traverse the network. When basic dual-stack tests succeed but large packet tests fail, MTU/PMTUD issues are indicated.
Common Causes:
Solution: Ensure ICMPv6 is not blocked by firewalls, verify MTU settings throughout the network path, and test with varying packet sizes to isolate where fragmentation becomes necessary.
Dual-stack operation depends entirely on correct DNS configuration. Several DNS-related problems can break dual-stack connectivity:
Missing AAAA Records: Services that have IPv6 connectivity but don't publish AAAA records will operate as IPv4-only, wasting IPv6 capability.
AAAA Records with Broken IPv6: Publishing AAAA records before thoroughly testing IPv6 creates the timeout problem described earlier. This is the single most common dual-stack deployment mistake.
Slow AAAA Resolution: If AAAA queries take significantly longer than A queries, Happy Eyeballs might consistently prefer IPv4 simply because it gets answers faster.
DNS64/NAT64 Interference: In IPv6-only networks with DNS64/NAT64, AAAA records are synthesized for IPv4-only destinations. This can create confusion when dual-stack testing from these networks.
Dual-stack networks require different firewall configurations than IPv4-only networks:
Stateful Firewalls: IPv6 typically assigns global addresses directly to endpoints, eliminating NAT. This means firewalls must explicitly protect devices that were previously hidden behind IPv4 NAT.
ICMPv6 Filtering: Overly aggressive firewall rules that block ICMPv6 break essential IPv6 functionality, including Neighbor Discovery and Path MTU Discovery.
Asymmetric Filtering: Some firewalls allow IPv4 traffic but block IPv6, or vice versa, creating inconsistent dual-stack behavior.
Connection Tracking Issues: Firewalls tracking IPv4 connections might not properly track parallel IPv6 connections, causing unexpected drops.
When dual-stack tests show all connection types succeed quickly (under 2 seconds), your network has optimal dual-stack configuration. This means:
This is the ideal state, indicating properly configured equipment, working ISP connectivity for both protocols, and correct DNS operation.
Sometimes tests show dual-stack functionality with warnings:
Slow IPv6 Performance: IPv6 works but consistently takes longer than IPv4. This might indicate suboptimal routing, tunnel overhead, or capacity constraints on IPv6 paths. Not critical, but worth investigating for optimization.
Large Packet Issues: Basic connectivity works but large packet tests fail. This reveals MTU/PMTUD problems that might affect some websites but not others.
IPv4 Preference Despite IPv6 Availability: Both protocols work, but IPv4 is consistently preferred. This might be acceptable if IPv4 performs better, but could indicate IPv6 configuration that needs tuning.
When dual-stack tests show only IPv4 works (IPv6-only and dual-stack tests fail, but IPv4-only succeeds), your network operates in IPv4-only mode. This is a stable configuration—you can access most of the Internet—but you cannot reach IPv6-only sites and services.
This might be intentional if your ISP doesn't offer IPv6, or might indicate disabled IPv6 configuration. If IPv6 was recently enabled and tests show IPv4-only operation, configuration issues should be investigated.
The worst dual-stack test outcome shows:
This definitively indicates broken IPv6 causing severe connectivity problems. When accessing dual-stack websites, your browser attempts IPv6 first, waits for timeout, then falls back to IPv4. Every website visit experiences this delay, making browsing appear completely broken despite functional IPv4.
Immediate Action Required: Either fix IPv6 connectivity or disable IPv6 entirely until the underlying issue is resolved. Operating with broken IPv6 is worse than having no IPv6 at all.
test-ipv6.run provides the most thorough dual-stack testing available through your browser, performing six critical tests that cover all aspects of dual-stack operation:
1. IPv4-Only Connectivity Test: Verifies IPv4 works by connecting to endpoints with only A records. This establishes your baseline IPv4 capability.
2. IPv6-Only Connectivity Test: Confirms IPv6 functionality by connecting to endpoints with only AAAA records. This tests pure IPv6 without IPv4 fallback.
3. Dual-Stack Basic Test: The most critical test—connects to endpoints with both A and AAAA records, revealing how your network behaves in real-world dual-stack scenarios. This test immediately identifies broken IPv6 configurations.
4. IPv4 Latency Measurement: Measures IPv4 response time, providing performance baseline for protocol comparison.
5. IPv6 Latency Measurement: Measures IPv6 response time when IPv6 is available, allowing direct performance comparison between protocols.
6. Protocol Preference Detection: Determines which protocol your browser actually uses when connecting to dual-stack endpoints, revealing whether your system follows expected IPv6 preference or has configuration issues.
After completing all tests, test-ipv6.run calculates a comprehensive IPv6 readiness score from 0 to 10, along with separate IPv4 and IPv6 protocol scores. Here's what different scores indicate:
Score 10/10 (Full IPv6 Support): Perfect dual-stack operation. Both protocols work excellently, dual-stack connections succeed quickly, and you can access any Internet resource regardless of protocol.
Score 7-9/10 (IPv6 Available): Dual-stack works but with minor issues—slow IPv6 performance, large packet problems, or DNS issues. Your network functions well but has room for optimization.
Score 0/10 with "Broken IPv6" Badge: Critical failure. IPv6 is configured but fundamentally broken, causing timeouts on dual-stack sites. This requires immediate attention.
Score 0/10 with "IPv4 Only" Badge: IPv6 is not available or disabled. Stable configuration but you cannot reach IPv6-only sites.
Beyond the overall score, test-ipv6.run provides detailed diagnostic information for each test:
Success Status: Green indicators show working connectivity, red shows failures, and orange indicates warnings.
Latency Measurements: Response times are displayed for each successful test, highlighting performance differences between protocols.
Detailed Test Results: Expanding each test shows technical details including which API endpoints were tested, exact response times, and specific failure conditions.
IP Address Detection: The site displays both your IPv4 and IPv6 addresses, confirming what addresses your ISP has assigned.
This granular information helps diagnose specific problems rather than simply indicating "something is broken."
Dual-stack connectivity isn't static—ISP changes, router firmware updates, and network reconfigurations can all affect operation. We recommend testing regularly:
After Network Changes: Test immediately after enabling IPv6, changing routers, updating firmware, or modifying firewall rules.
Monthly Checks: Periodic testing ensures your dual-stack configuration remains optimal over time.
When Experiencing Issues: If websites start loading slowly or connectivity seems degraded, run a test to identify whether dual-stack issues have developed.
Before Publishing AAAA Records: If you operate services and plan to add IPv6, test your connectivity thoroughly before publishing AAAA records to ensure you won't create broken dual-stack situations for your users.
Dual-stack behavior can vary significantly by location and network path. For comprehensive assessment:
Home Network: Test from your primary home network to verify residential ISP configuration.
Mobile Networks: Mobile carriers often deploy IPv6-only networks with NAT64, creating unique dual-stack behavior.
Corporate Networks: Enterprise networks might have different dual-stack policies and configurations than residential connections.
Public WiFi: Hotels, airports, and coffee shops often have incomplete or broken dual-stack implementations.
Testing from multiple networks reveals whether issues are specific to one location or systemic to your device configuration.
While Happy Eyeballs is standardized, browser implementations vary slightly. Testing with Chrome, Firefox, and Safari can reveal browser-specific issues or confirm that problems are network-level rather than application-level.
Some dual-stack issues only manifest under network load. If possible, test both during idle periods and when your network is busy with other activities.
Record your test results when dual-stack is first configured and working well. This baseline makes it easier to identify when degradation occurs and what changed.
Dual-stack testing is essential for modern Internet connectivity, verifying that networks can successfully operate with both IPv4 and IPv6 when connecting to real-world services that offer both protocols. Unlike single-protocol tests that only verify isolated functionality, dual-stack tests reveal how your network behaves in the most common scenario: choosing between protocols or attempting both simultaneously.
The most critical insight from dual-stack testing is identifying broken IPv6 configurations that cause severe timeout issues despite having functional IPv4. This "broken IPv6" state creates worse user experience than having no IPv6 at all, making dual-stack tests invaluable for both initial deployment validation and ongoing monitoring.
Understanding Happy Eyeballs behavior, protocol preference selection, and common failure modes allows proper interpretation of test results and effective troubleshooting when issues arise. Whether you're deploying IPv6 for the first time, troubleshooting connectivity problems, or simply verifying your network's IPv6 readiness, comprehensive dual-stack testing provides the essential information needed for optimal network operation.
Visit test-ipv6.run to test your dual-stack connectivity now. The site provides instant results, detailed diagnostics, and a comprehensive readiness score—all running directly in your browser with no software installation required. Understanding your dual-stack status is the first step toward ensuring fast, reliable Internet connectivity across all protocols.