NAT, addressing, and IPv6 deployment

WebRTC video calls need both parties to connect directly — but a typical user is behind two NAT layers. The STUN server has to tell each side its public IP and port. The TURN server relays the call if direct connection fails. Understanding why NAT exists, how it works, and what it breaks is essential for any full-stack engineer building peer-to-peer or real-time features.

RFC 1918 private addressing

IPv4’s 32-bit address space holds ~4.3 billion addresses. That ran out. RFC 1918 reserved three ranges for private use:

Hosts on private addresses cannot be reached directly from the public Internet. They can only initiate outbound connections (after which the NAT table holds the mapping for replies).

Network Address Translation (NAT)

NAT (RFC 2663) rewrites packets at the network boundary:

1. Outgoing packet: source IP (private, e.g. 192.168.1.10) + source port (e.g. 45231) → rewritten to router’s public IP + a unique source port (e.g. 203.0.113.5:12345). The router stores this mapping.
2. Incoming reply: destination IP + port (203.0.113.5:12345) → router looks up the NAT table → rewrites back to 192.168.1.10:45231 and forwards to the internal host.

NAT enabled the IPv4 Internet to grow past its address limit but it fundamentally broke end-to-end addressing: the public Internet sees one IP for many internal hosts, and internal hosts cannot accept unsolicited inbound connections.

What NAT breaks:

• Peer-to-peer protocols (BitTorrent, VoIP, WebRTC): either side needs to initiate — NAT only permits outbound-initiated connections.
• Port forwarding: must be configured manually for each service you want externally reachable.
• Abuse-tracking: a single public IP may hide hundreds of unrelated users.

Carrier-Grade NAT (CGNAT)

Mobile carriers and ISPs deploy CGNAT to share one public IPv4 address across hundreds or thousands of customers:

1. Customer’s home router NATs to 100.64.x.x (RFC 6598 shared address space — “NAT64 carrier space”).
2. The carrier’s CGNAT NATs again to a public IP.

Double NAT compounds the P2P problem. CGNAT users cannot host any service on their IP, and peer-to-peer NAT traversal is harder. Rate-limiting by IP is meaningless (hundreds of unrelated users share one IP).

Working around NAT: STUN/TURN/ICE

WebRTC and modern P2P protocols use a three-tier approach:

• STUN (Session Traversal Utilities for NAT): a STUN server tells each peer its public IP and port as seen from outside the NAT. Peers try to connect directly using this information.
• TURN (Traversal Using Relays around NAT): if direct connection fails (e.g. symmetric NAT, CGNAT), a TURN server relays all traffic. Latency penalty; only fallback.
• ICE (Interactive Connectivity Establishment): the framework that iterates through STUN candidates, direct addresses, and TURN until one path works.

IPv6 addresses: structure and SLAAC

IPv6 addresses are 128 bits, written as eight colon-separated hex groups. Shorthand: leading zeros omitted, longest run of zeros replaced by ::. Example: 2001:db8::1.

Typical allocation: /48 prefix to a site → /64 per subnet within the site. SLAAC (Stateless Address Autoconfiguration, RFC 4862) lets a host derive its own address:

1. Router broadcasts a /64 prefix in Router Advertisement messages.
2. Host generates the low 64 bits (interface ID) — originally EUI-64 from MAC address, now random for privacy (RFC 8981 privacy extensions).
3. Host checks for duplicates (Duplicate Address Detection), then starts using the address.
4. No DHCP required for basic connectivity.

Privacy extensions (RFC 8981) randomise the interface ID per site to prevent cross-site tracking via IPv6 addresses. Modern OSes enable this by default.

Anycast: one IP, many locations

Anycast announces the same IP prefix from multiple geographic locations. BGP routes each user to the AS-path-shortest POP. Applications: DNS resolvers (1.1.1.1, 8.8.8.8), CDN edges, root nameservers, DDoS-protected services.

Anycast works well for stateless services (UDP DNS) — each packet may go to a different POP. For stateful services (TCP, TLS), short flows are fine (BGP routing is stable for the duration), but long flows need either stable BGP or session-state replication across POPs (Cloudflare replicates TLS session tickets globally for this reason).

Dual-stack and Happy Eyeballs

Most current deployments run dual-stack: both IPv4 and IPv6 enabled simultaneously. IPv6-first for content delivery, IPv4 as fallback.

Happy Eyeballs v2 (RFC 8305): when a dual-stack host resolves a hostname, it races IPv4 and IPv6 connect attempts with a short head-start for IPv6. If IPv6 succeeds first, use it; if IPv4 wins or IPv6 stalls, use IPv4 — seamlessly, without user-visible delay. This makes IPv6 adoption safe even when IPv6 paths have intermittent problems.