Dual stack: which address a host actually prefers

When a host has both IPv4 and IPv6 connectivity, which does it actually use? The answer is not obvious, and the behavior varies by operating system, application, and network conditions. Understanding address selection is critical for troubleshooting dual-stack deployments, diagnosing connectivity issues, and preparing for IPv6 readiness. This guide explains the mechanisms that determine which protocol wins.

RFC 6724: The address selection standard

RFC 6724 defines a deterministic algorithm that most modern operating systems follow when a hostname resolves to both A (IPv4) and AAAA (IPv6) records. The algorithm ranks candidate addresses based on a set of rules and selects the highest-scoring match. The ranking considers factors like scope (link-local, site-local, global), address type (unicast, multicast), and policy preferences.

The core principle: prefer addresses of the same type as the destination. If you are connecting to a global unicast address, prefer a global unicast source. This minimizes routing complexity and avoids scope mismatches. However, the algorithm also respects a system policy table that can override these defaults.

Example: getaddrinfo() on Linux with dual-stack resolution

Hostname: example.com
A record: 192.0.2.1
AAAA record: 2001:db8::1

RFC 6724 evaluation (simplified):
  2001:db8::1 (IPv6): scope=global, label=1, precedence=50
  192.0.2.1 (IPv4): scope=global, label=4, precedence=35

Result: IPv6 preferred (higher precedence)

Happy Eyeballs: practical dual-stack connection

RFC 6555 introduced Happy Eyeballs, a mechanism that prevents long timeouts when one protocol is broken or slow. Instead of waiting for a TCP connection attempt to fail (often 20-30 seconds), Happy Eyeballs starts with the preferred address, then launches a second attempt to the alternate protocol after a short delay (typically 250 milliseconds).

The first connection to succeed wins. If IPv6 is preferred but the network is broken, IPv4 kicks in quickly. If IPv6 works, it is used. This approach masks many dual-stack problems and improves user experience, but it also means that the actual protocol in use may not match RFC 6724 predictions if one path has issues.

• →Start connection to preferred address (usually IPv6 on modern systems)
• →Wait 250 ms for TCP SYN acknowledgment
• →If no response, start connection to alternate address in parallel
• →Use whichever connection succeeds first
• →Future connections to the same host may cache the working protocol

Operating system differences

Not all systems implement RFC 6724 and Happy Eyeballs identically. Windows, macOS, Linux, and iOS have subtle variations in their address selection logic and caching behavior.

• →Linux: Follows RFC 6724 closely; policy table in /etc/gai.conf controls precedence
• →Windows: Prefers IPv6 by default on Windows Vista and later; uses Happy Eyeballs
• →macOS: IPv6 preferred when available; implements Happy Eyeballs in recent versions
• →iOS and Android: IPv6 preferred; Happy Eyeballs standard on modern versions
• →Older systems: May not support RFC 6724; default to IPv4 if available

Practical implications for engineers

When troubleshooting dual-stack connectivity, assume IPv6 is being attempted first on modern clients. If IPv6 DNS resolution works but the application fails, check for IPv6 reachability to the destination. Broken IPv6 connectivity will trigger Happy Eyeballs fallback, but this adds latency and may mask the real problem.

Use packet capture on both IPv4 and IPv6 to see which protocol is actually in use. Check DNS responses to confirm both A and AAAA records are being returned. Verify that your network allows IPv6 traffic end-to-end, or explicitly disable IPv6 on clients if your infrastructure does not yet support it.

For lab and certification study, understand that address selection is automatic and often invisible. The CCNA and NSE curricula expect you to know that dual-stack hosts prefer IPv6 when available, and that this behavior is defined by RFC 6724. Happy Eyeballs is less commonly tested but increasingly important in real deployments.