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 DNS Resolution: Tests connectivity to hosts that only have A (IPv4) records. Uses ipv4.google.com to verify IPv4-only resource access.
• IPv6-only DNS Resolution: Tests connectivity to hosts that only have AAAA (IPv6) records. Uses ipv6.google.com to verify IPv6-only resource access.
• Dual-stack DNS Resolution: Tests connectivity to hosts with both A and AAAA records (your browser should prefer IPv6 when available). Uses www.google.com to test Happy Eyeballs behavior.
• IPv6 Large Packet Test: Verifies that larger resources can be loaded over IPv6, testing basic MTU handling and the ability to transfer multi-packet resources.

All tests use image loading techniques to avoid CORS restrictions and measure actual connection times.

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

Advanced Performance Tests

In addition to basic connectivity tests, the site performs several advanced performance and diagnostic tests:

Happy Eyeballs Detection

This test detects which version of the Happy Eyeballs algorithm your browser implements. Happy Eyeballs is the mechanism browsers use to race IPv4 and IPv6 connections to dual-stack servers, selecting whichever connects first. The test analyzes connection timing patterns and user agent strings to determine:

• Safari: Uses Happy Eyeballs v2 (RFC 8305), which provides better performance and more sophisticated connection racing
• Chrome/Edge/Firefox: Use Happy Eyeballs v1 (with v3 available experimentally in Chrome via flags)
• Typical behavior: IPv6 attempts first, with IPv4 fallback starting 250-300ms later

Understanding your browser's Happy Eyeballs implementation helps explain dual-stack connection performance characteristics.

Path MTU Discovery (PMTUD)

This test verifies that your IPv6 connection can successfully transfer resources of different sizes. It tests small (favicon), medium (~1KB), and large (~2KB+) resources to identify potential issues with:

• Broken PMTUD: Misconfigured firewalls or middleboxes that drop ICMPv6 "Packet Too Big" messages, causing large transfers to fail silently
• MTU mismatches: Network segments with different MTU sizes that aren't properly negotiated
• Packet filtering: Security devices that incorrectly drop large IPv6 packets

Passing all three size tests indicates healthy IPv6 path MTU discovery. Failures on larger packets suggest MTU/fragmentation issues that can cause intermittent connectivity problems.

IPv6 Privacy Extensions Detection

This test analyzes your IPv6 address to determine if you're using privacy extensions (RFC 4941). Privacy extensions enhance user privacy by:

• Temporary addresses: Generating randomized interface identifiers instead of hardware-based (MAC-derived) addresses
• Rotation: Periodically changing addresses to prevent long-term tracking
• Detection method: The test examines the interface identifier (last 64 bits) for EUI-64 patterns vs. random patterns

Enabled privacy extensions indicate a privacy-conscious configuration. Disabled extensions (EUI-64 addresses) are more predictable but may be preferred in enterprise environments for device tracking and management.

IPv6 Jitter and Variance Test

This test measures connection stability by performing 10 consecutive latency measurements to the same IPv6 endpoint. It calculates:

• Average latency: Mean response time across all tests
• Jitter (standard deviation): Variation in latency, with lower values indicating more stable connections
• Min/Max: Range of latency values observed
• Quality ratings:
  • Excellent: Jitter < 10ms (ideal for VoIP, gaming, video conferencing)
  • Good: Jitter 10-30ms (suitable for most real-time applications)
  • Fair: Jitter 30-50ms (acceptable for general use)
  • Poor: Jitter > 50ms (may impact real-time applications)

Low jitter indicates stable routing and consistent performance. High jitter may indicate congestion, route flapping, or poor network conditions that can degrade user experience for latency-sensitive applications.

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

Note: Advanced performance tests (Happy Eyeballs, Path MTU, Privacy Extensions, Jitter) are informational and don't directly affect the readiness score, but provide valuable diagnostic information about your IPv6 connection quality.

Ad Blockers and Privacy Extensions

Ad blockers and privacy extensions may interfere with the functionality of this site:

• Blocked External Requests: Ad blockers may prevent connections to external services like ipify.org (IP detection) and ipinfo.io (ISP information), causing tests to fail or return incomplete results
• Tracking Protection: Privacy extensions that block tracking scripts may interfere with image loading tests and site connectivity checks
• DNS-Level Blocking: DNS-based ad blockers (Pi-hole, NextDNS, etc.) may block requests to test endpoints, resulting in false negatives
• Favicon Blocking: Some blockers prevent favicon requests, which will cause the "Other IPv6 Sites" tests to fail even when connectivity is working properly

Recommendation: If you're experiencing unexpected test failures or missing results, try temporarily disabling your ad blocker or privacy extensions for this site, then run the tests again. The tests only contact public IPv4/IPv6 test endpoints and do not track users or serve advertisements.

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