IPv6 Address Space

What is the IPv6 address space?

IPv6 is the current-generation Internet Protocol addressing system, built to replace IPv4 whose address pool has been exhausted. IPv4 uses 32-bit addresses, giving about 4.3 billion possible addresses — a number that seemed limitless in the 1980s and ran out in reality years ago as the world connected billions of phones, servers, and IoT devices. IPv6 uses 128-bit addresses, expanding the space to roughly 340 undecillion (3.4 × 10³⁸) addresses — a quantity so vast it’s effectively inexhaustible, often described as enough to assign an address to every atom on Earth’s surface many times over. Addresses are written in hexadecimal like 2001:0db8:85a3::8a2e:0370:7334, with :: shorthand for runs of zeros.

Why the giant address space actually matters

The point isn’t just “more addresses” — it’s what abundance enables and what scarcity forced. IPv4 scarcity is the direct reason NAT (Network Address Translation) became ubiquitous: because there weren’t enough public IPv4 addresses, entire networks hide behind a single public address, with private addresses inside. NAT works, but it breaks the internet’s original end-to-end principle — devices behind NAT aren’t directly addressable, which complicates peer-to-peer connections, servers, and protocols, and pushes complexity into gateways. IPv6’s abundance means every device can have a globally unique, routable address, restoring end-to-end connectivity and removing the need for NAT as a scarcity workaround. It also brought clean-ups: simplified headers for more efficient routing, stateless address autoconfiguration (SLAAC) letting devices self-assign addresses without necessarily needing DHCP, and mandatory support for modern features. The catch that surprises people: IPv6 is not backward-compatible with IPv4 — they’re separate protocols, so the transition requires running dual-stack (both at once) or translation mechanisms, which is a big part of why migration has been slow.

The slow, uneven reality of adoption

Despite IPv4 exhaustion being old news, IPv6 adoption is partial and gradual — global traffic sits around 40-something percent and climbing, but far from universal. The reasons are instructive: NAT and CGNAT (carrier-grade NAT) worked well enough to defer the pain, letting providers stretch IPv4 further and reducing urgency; dual-stack complexity means running and securing two protocols simultaneously; and a long tail of legacy hardware, software, and configs that assume IPv4. Mobile networks and large content providers have pushed IPv6 hardest (many mobile carriers are IPv6-primary now), while plenty of enterprise and home networks remain IPv4-centric behind NAT. For cloud engineers, IPv6 shows up as an option you increasingly should consider — AWS, GCP, and Azure all support it in their VPCs, sometimes with cost advantages (AWS has charged for public IPv4 addresses, nudging IPv6 adoption). The practical wrinkles: security groups and firewall rules must cover IPv6 separately (a rule that only restricts IPv4 leaves IPv6 wide open — a genuine and common misconfiguration), and address management/monitoring tooling has to understand the new format.

What people get wrong

• Forgetting IPv6 in firewall rules — securing only IPv4 while IPv6 is enabled leaves an open path; every rule needs an IPv6 counterpart.
• Assuming it’s backward-compatible: IPv6 and IPv4 are distinct protocols, so you run dual-stack or translation — you can’t just “switch over.”
• Thinking exhaustion forced fast adoption — NAT/CGNAT relieved the pressure, which is exactly why IPv6 migration has been decades-long and is still incomplete.

Primary source: RFC 8200: Internet Protocol, Version 6 (IPv6)