IPv4 vs IPv6
IPv4 (RFC 791, 1981) was never designed to address the entire internet – it assumed a small network of trusted research institutions. IPv6 (RFC 8200, originally RFC 2460, 1998) was designed with the internet's scale in mind. The transition has been slow because IPv4 and IPv6 are not interoperable – dual-stack deployment (running both simultaneously) is the dominant approach. Most major cloud providers, mobile carriers, and CDNs are fully dual-stack.
IPv4 uses 32-bit addresses (4.3 billion total) – exhausted in 2011. IPv6 uses 128-bit addresses (340 undecillion) – designed to last indefinitely. Beyond address space, IPv6 removes NAT as a requirement, mandates IPsec support, simplifies headers for router efficiency, and has built-in stateless address autoconfiguration (SLAAC). IPv6 adoption passed 40% globally in 2024.
| Feature | IPv4 | IPv6 |
|---|---|---|
| Address length | 32 bits – 4 octets (e.g., 192.168.1.1) | 128 bits – 8 groups of 4 hex digits (e.g., 2001:db8::1) |
| Address space | ~4.3 billion addresses – exhausted at IANA level since 2011 | 3.4 × 10³⁸ addresses – effectively unlimited |
| NAT requirement | Required due to address exhaustion – complicates P2P | Not required – every device can have a globally unique address |
| Header size | 20–60 bytes (variable due to options field) | 40 bytes fixed – no options field, extension headers instead |
| Header checksum | Present – recalculated at every router hop (slow) | Removed – TCP/UDP checksums cover transport; routers skip recompute |
| Fragmentation | Routers can fragment packets | Routers cannot fragment – source does it via Path MTU Discovery |
| IPsec | Optional | Mandatory implementation (optional use) |
| Autoconfiguration | DHCP required for dynamic addressing | SLAAC – stateless autoconfiguration from router advertisements |
| Multicast/Anycast | Multicast supported; broadcast also exists | Multicast and anycast; broadcast abolished (replaced by multicast) |
| DNS record type | A record (IPv4 address) | AAAA record (IPv6 address) |
| Loopback | 127.0.0.1 | ::1 |
| Global adoption | Universal – every device supports IPv4 | ~40% of Google traffic is IPv6 (2024) |
When to use IPv4
IPv4 remains necessary for compatibility with legacy devices, internal networks that have no IPv6 routing, and situations where all infrastructure components don't yet support IPv6. Dual-stack (IPv4 + IPv6 simultaneously) is the current best practice – not choosing one over the other.
When to use IPv6
IPv6 should be preferred for new deployments, mobile networks (where carrier-grade NAT causes serious problems), IoT at scale, and any situation where end-to-end connectivity without NAT traversal matters. Cloud providers (AWS, GCP, Azure), major CDNs, and Google/Facebook/Apple all serve IPv6 natively.
Common Mistakes
- Configuring only IPv4 in new cloud infrastructure – AWS, GCP, and Azure all support IPv6 natively. Not enabling it means missing ~40% of traffic that prefers IPv6.
- Assuming IPv6 is less common on mobile – major mobile carriers (T-Mobile, Verizon, AT&T) are predominantly IPv6. Mobile users often have IPv6-only connections with IPv4 via NAT64.
- Forgetting AAAA records – a domain with only an A record but no AAAA record forces IPv6-capable clients to fall back to IPv4, adding latency.
- Treating IPv6 addresses as static – SLAAC generates privacy extensions (temporary addresses) that rotate. Applications that log IPs should use the /64 prefix for user identity, not the full 128-bit address.
- Not updating firewall rules for IPv6 – many deployments carefully firewall IPv4 but forget that IPv6 traffic bypasses those rules entirely, exposing services directly.
FAQ
Do I need to run IPv4 and IPv6 at the same time?
Yes – dual-stack is the answer for now. IPv4 and IPv6 are not interoperable without translation (NAT64/DNS64). During the transition period (which may last decades), running both protocols simultaneously ensures you reach all users. Happy Eyeballs (RFC 8305) in modern operating systems and browsers automatically picks the faster of IPv4 or IPv6 for each connection.
Why is IPv6 adoption still below 50% after 25 years?
NAT worked too well as a workaround. By allowing many devices to share a single IPv4 address via NAT, the address exhaustion problem became manageable in practice. This reduced urgency for IPv6 adoption. Additionally, IPv4-only infrastructure (customer-premises equipment, enterprise routers, embedded devices) has a very long tail. Mobile networks accelerated adoption significantly – in some countries IPv6 traffic exceeds 70%.