WebRTC IPv4 and IPv6 Dual Stack Support

This article explains how WebRTC natively supports and transitions between dual-stack IPv4 and IPv6 networks. It covers the underlying mechanisms of Interactive Connectivity Establishment (ICE), the gathering of IP candidates, how WebRTC prioritizes IPv6 over IPv4, and how it handles seamless transitions during network changes to maintain uninterrupted peer-to-peer communication.

The Role of ICE in Dual-Stack Networks

WebRTC relies on the Interactive Connectivity Establishment (ICE) framework (RFC 5245 / RFC 8445) to establish peer-to-peer connections. In a dual-stack network environment where a device is assigned both an IPv4 and an IPv6 address, the ICE agent natively gathers routing paths (candidates) for both protocols simultaneously.

WebRTC gathers three types of candidates for both IPv4 and IPv6: * Host Candidates: Direct IP addresses from the device’s local network interfaces. * Server Reflexive (STUN) Candidates: Public IP addresses allocated by a STUN server. * Relayed (TURN) Candidates: Public IPs allocated by a TURN server to route traffic when direct connection fails.

By gathering both IPv4 and IPv6 addresses across all candidate types, WebRTC ensures it has a complete map of potential connectivity paths.

Candidate Prioritization and Selection

Once candidates are gathered, the ICE agent pairs local candidates with remote peer candidates. To manage dual-stack networks efficiently, WebRTC prioritizes these pairs based on strict formulas defined by the IETF.

1. IPv6 Preference: By default, WebRTC prioritizes native IPv6 candidates over IPv4 candidates. This alignment follows RFC 6724 guidelines, promoting the use of the more modern IPv6 protocol which often bypasses Network Address Translation (NAT) and reduces latency.
2. The “Happy Eyeballs” Principle: To prevent connection delays caused by misconfigured or broken IPv6 routing, WebRTC implementations utilize a variation of the “Happy Eyeballs” algorithm (RFC 8305). Instead of waiting for an IPv6 connection attempt to time out before trying IPv4, WebRTC initiates connection checks on IPv6 and IPv4 dual-stack pathways almost concurrently. It gives IPv6 a head start of a few dozen milliseconds. If IPv6 fails or is slow, the IPv4 connection check succeeds first, and WebRTC immediately establishes the media channel over IPv4 without user-perceptible delay.

Dynamic Transitioning and Connection Migration

WebRTC is designed to adapt to real-time changes in network topology, such as a user switching from an IPv6-enabled Wi-Fi network to an IPv4-only cellular network.

• Continuous Connectivity Checks: WebRTC continuously sends STUN binding requests (consent checks) every few seconds along the active data path. If the active path (e.g., IPv6) degrades or drops, WebRTC immediately evaluates alternative candidate pairs (e.g., IPv4) that were previously validated during the initial ICE gathering phase.
• ICE Restart: If a network transition is drastic (such as a change in network interface), WebRTC triggers an “ICE Restart.” This process generates a completely new set of IPv4 and IPv6 candidates and performs quick connectivity checks to transition the live media stream to the new viable IP stack seamlessly, preventing call drops.