IPv6 Connectivity Test

IP Address Detection

Your IP addresses are detected using external services (ipify.org). The IPv4 test queries an IPv4-only endpoint, while the IPv6 test uses a dual-stack endpoint that returns your IPv6 address if available. ISP information is retrieved from ipinfo.io.

Connectivity Tests

Basic connectivity is tested by attempting to fetch data from known IPv4-only (ipv4.icanhazip.com) and IPv6-only (ipv6.icanhazip.com) endpoints. A successful response indicates that your network can route traffic over that protocol.

DNS Resolution Tests

These tests verify that your browser can resolve and load resources from different types of DNS configurations:

• IPv4-only: Tests connectivity to hosts that only have A (IPv4) records
• IPv6-only: Tests connectivity to hosts that only have AAAA (IPv6) records
• Dual-stack: Tests connectivity to hosts with both A and AAAA records (your browser should prefer IPv6 when available)

All tests use image loading techniques to avoid CORS restrictions.

Site Connectivity Tests

When testing well-known sites, the script attempts to load each site's favicon over both IPv4 and IPv6. The test uses a timeout of 8 seconds per request. Sites are tested by:

• Creating an invisible image element and loading the site's resource
• Measuring response time to compare IPv4 vs IPv6 performance
• Detecting failures when resources can't be loaded within the timeout
• Identifying which CDN (Content Delivery Network) is serving the content by analyzing HTTP headers

Note: Some sites may fail these tests even if they're reachable, due to missing favicons, anti-bot protections, or CORS policies. Sites marked as "Not Supported" do not have IPv6 addresses configured. CDN detection is done via HTTP headers (cf-ray, x-cache, server, etc.) when available.

Performance Comparison

After running the site connectivity tests, the system calculates which protocol performed better on average:

• Dual-Success Sites Only: Only sites where both IPv4 and IPv6 connections succeeded are included in the calculation
• Average Latency: The average response time is calculated for all successful dual-stack connections
• Percentage Difference: The performance difference is expressed as a percentage showing how much faster the winning protocol was
• Real-World Performance: This represents actual end-user experience differences between IPv4 and IPv6 for these specific sites
• Detailed Timing: The browser console shows granular timing breakdowns (DNS lookup, TCP connection, TLS handshake) using the Resource Timing API

Note: Performance can (will) vary based on your ISP's IPv6 implementation, network configuration, peering arrangements, and the CDN infrastructure serving these sites, if any. The results show relative performance for your specific connection at this moment in time.

Browser and Platform Differences

Different browsers implement networking stacks differently, which can significantly affect test results:

Network Stack Architecture

• Chromium-based browsers (Chrome, Brave, Opera): Use Chromium's cross-platform network stack with consistent behavior across operating systems. These browsers provide the most consistent performance regardless of the underlying OS.^[1]
• Microsoft Edge on Windows: Uses Windows' native networking APIs (WinHTTP/WinINet) which may add overhead compared to Chromium's stack. Edge's integration with Windows networking means it's more affected by OS-level DNS caching, firewall rules, and IPv6 configuration.^[2]
• Safari: Uses Apple's CFNetwork framework on macOS/iOS, which has its own performance characteristics and caching behaviors.^[3]
• Firefox: Uses its own Necko network library with platform-specific backends, providing a middle ground between fully native and fully abstracted approaches.^[4]

DNS Resolution

• Edge on Windows: Uses the Windows DNS Client service, which consults multiple sources (hosts file, DNS cache, configured DNS servers, LLMNR) and may be slower than browser-managed DNS
• Chromium/Brave: Use their own async DNS resolver with aggressive caching, typically faster and more consistent^[5]
• Firefox: Can use either native OS DNS or TRR (Trusted Recursive Resolver) over HTTPS, depending on configuration^[6]

TLS/SSL Implementation

• Edge on Windows: Uses Schannel (Windows' native TLS stack), which may have different performance characteristics than browser-managed TLS^[7]
• Chromium/Brave: Use BoringSSL (Google's optimized fork of OpenSSL) with hardware acceleration support^[8]
• Firefox: Uses NSS (Network Security Services) library^[9]
• Safari: Uses Apple's SecureTransport framework

Happy Eyeballs (Dual-Stack Connection Racing)

When connecting to dual-stack servers (both IPv4 and IPv6), browsers use "Happy Eyeballs" algorithms to race both protocols:^[10]

• Safari: Implements Happy Eyeballs v2 (RFC 8305) for optimal dual-stack performance^[11]
• Chrome/Edge/Firefox: Currently implement Happy Eyeballs v1, with v3 available experimentally in Chrome via chrome://flags/#happy-eyeballs-v3
• Typical behavior: IPv6 is attempted first, with IPv4 starting 250-300ms later as a fallback. The first successful connection wins
• Edge on Windows: May exhibit different timeout thresholds and fallback behavior due to Windows network stack integration

Scoring System

Your readiness score (out of 10 points) is calculated based on:

• IPv4 Connectivity: 2 points
• IPv6 Connectivity: 3 points
• IPv4 DNS Resolution: 1 point
• IPv6 DNS Resolution: 2 points
• Dual-stack Capability: 1 point
• IPv6 Large Packet Handling: 1 point

Limitations

Browser-based testing has some limitations:

• Cannot directly control protocol selection (browser decides IPv4 vs IPv6). This can be mitigated by sites using a specific domain for IPv6, but in reality it is ultimately controlled by Happy Eyeballs in your browser. At this time (Nov-2025), only Safari supports HEv2. All other browsers perform HEv1. It is possible to enable HEv3 on Chrome by navigating to chrome://flags/#happy-eyeballs-v3 in the address bar, selecting Enabled from the dropdown menu, and restarting Chrome This might work on Chromium based browsers, too. Happy Eyeballs is one of those less-understood-but-absolutely-critical technologies that we all rely on. Learning more about it is worth your time
• Cannot perform true MTU/fragmentation tests
• Subject to CORS restrictions and site security policies
• VPN, proxy, or privacy extensions may (will definitely) affect results
• Some sites block automated requests, causing false failures. The favicon method isn't perfect, but was the least intrusive

References

1. Chromium Network Stack Design - The Chromium Projects
2. Microsoft Edge Network Stack Integration - Microsoft Learn
3. WebKit Networking Improvements - WebKit.org
4. Firefox Necko Networking Library - Mozilla
5. DNS Prefetching in Chromium - The Chromium Projects
6. DNS over HTTPS (DoH) in Firefox - Mozilla Support
7. Schannel Security Package - Microsoft Learn
8. BoringSSL - Google Source
9. Network Security Services (NSS) - Mozilla
10. Happy Eyeballs - Wikipedia
11. RFC 8305: Happy Eyeballs Version 2 - IETF