JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

IPv6 and the Long Road to a Bigger Internet

The last guide showed how NAT bought the Internet time by hiding whole networks behind one address. The real cure was always to build a bigger address space. Meet IPv6, its eye-watering size, its cleaner header, and the slow, stubborn, decades-long job of actually switching the world over to it.

Why 4 billion was never going to be enough

Recall from earlier in this rung that an IPv4 address is 32 bits wide. That sounds generous until you do the arithmetic: 32 bits can name at most 2^32 distinct addresses, which is about 4.3 billion. In the 1970s, when the Internet Protocol was designed for a few hundred research machines, 4.3 billion felt absurdly, almost embarrassingly, large. Nobody imagined that one day there would be more phones than people, plus laptops, cameras, doorbells, cars, and light bulbs all wanting an address.

And it is worse than the raw number suggests, because addresses are handed out in blocks, not one at a time. As you saw with CIDR, an organisation gets a whole prefix like a /16 or a /24, and much of every block sits unused — addresses reserved, set aside for growth, or simply stranded. So the usable count was always well under 4.3 billion. By the early 2010s the regional registries that hand out blocks began running dry, one continent at a time, and there was no more to give.

The previous guide showed the stopgap that kept things running: NAT, letting whole homes and companies share one public address. NAT bought a decade or two, but it is a patch, not a cure — it breaks the clean idea that any machine can address any other, and it complicates everything from peer-to-peer apps to running a server at home. The honest fix was the one the engineers reached for in the mid-1990s: design a successor protocol with an address space so vast we would never have this conversation again. That successor is IPv6.

128 bits: a number you cannot really picture

The headline change in IPv6 is brute force on the address: it widens the address from 32 bits to 128 bits. That is not four times bigger; each extra bit doubles the count, so 128 bits gives 2^128 addresses, which is roughly 3.4 followed by 38 zeros. The usual analogy is that there are enough IPv6 addresses to give one to every grain of sand on Earth and still have almost all of them left over. The shortage that drove NAT simply ceases to be a problem — every device on the planet can have a real, globally unique address again.

Because a 128-bit number written in dotted decimal would be hopeless, IPv6 addresses are written as eight groups of four hexadecimal digits, separated by colons. To keep them readable, leading zeros in a group are dropped, and one run of all-zero groups can be collapsed to a double colon. So the long form 2001:0db8:0000:0000:0000:0000:0000:0001 shrinks to the friendly 2001:db8::1. The double colon may appear only once in an address, since otherwise you could not tell how many zero groups it stood for.

IPv4 address   32 bits   ->  192.168.1.10            ~ 4.3 x 10^9 addresses (2^32)
IPv6 address  128 bits   ->  2001:db8::1             ~ 3.4 x 10^38 addresses (2^128)

Writing an IPv6 address, step by step:
  full     2001:0db8:0000:0000:0000:0000:0000:0001
  drop leading zeros in each group   2001:db8:0:0:0:0:0:1
  collapse ONE run of zero groups    2001:db8::1

A prefix still uses CIDR slash notation:  2001:db8::/32  (first 32 bits = network)
The same slash-prefix idea you learned for IPv4 carries straight over to IPv6 — only the address got wider and the spelling switched to hexadecimal with a zero-collapsing double colon.

Not just bigger: a cleaner, leaner packet

The designers did not stop at a wider address; they took the chance to tidy the IP datagram header itself. The IPv4 header had grown a thicket of fields, many rarely used, and a variable length that routers had to parse carefully. The IPv6 header is fixed at 40 bytes and carries far fewer fields. The fiddly things — fragmentation controls, options — were moved out of the main header into optional extension headers chained on only when needed, so the common case is a simple, predictable header a router can process fast.

One change matters enough to call out. Recall IP fragmentation from earlier: when a datagram is too big for a link's MTU, IPv4 lets a router in the middle chop it into pieces. IPv6 forbids routers from fragmenting at all — if a packet is too big for the next link, the router drops it and sends back an ICMP message saying so, and the original sender must learn the right size and send smaller packets itself. This is called path MTU discovery, and it keeps the hard work at the endpoints where the datagram was born, leaving routers free to do nothing but forward.

The hard part: you cannot just flip a switch

Here is the catch that makes this a long road rather than a quick upgrade: IPv6 is not backward-compatible with IPv4. A pure-IPv6 host and a pure-IPv4 host literally cannot understand each other's packets — the headers are different shapes and the addresses are different sizes. There is no central off-switch for the old Internet and on-switch for the new one. With billions of devices, routers, and servers already speaking IPv4, the only realistic path was a gradual, decades-long coexistence. That coexistence is the whole story of the IPv6 transition.

  1. Dual stack: the workhorse approach. A device runs IPv4 and IPv6 side by side, with both kinds of address. When it wants to reach another machine, it asks DNS, which can return an IPv6 address, an IPv4 address, or both; the device prefers IPv6 if a working path exists and quietly falls back to IPv4 if not.
  2. Tunnelling: when two IPv6 islands are separated by an IPv4-only ocean, you wrap each IPv6 packet inside an IPv4 packet to carry it across, then unwrap it at the far shore. It is the encapsulation idea from the foundations rung, used to smuggle the new protocol through the old network.
  3. Translation: a gateway in the middle actually rewrites packets from one protocol to the other, so a pure-IPv6 client can still reach a pure-IPv4 server. It is powerful but lossy and complex, much like NAT, and is used where dual stack is not possible.
  4. Over the years the balance tips: more networks turn on IPv6, dual stack becomes the norm, and the IPv4 side is gradually leaned on less until, someday, it can be retired. We are deep into this transition but not finished with it.

Why it took so long, and what it means for a router

If IPv6 is so clearly better, why are we still mid-transition more than twenty-five years after it was specified? Because the people who pay to deploy it are not the people who benefit. NAT worked well enough that there was little pressure on home users, and an ISP saw real cost and risk in upgrading equipment for a service its customers could not even tell apart from IPv4. This is a classic chicken-and-egg standoff: content providers waited for users to have IPv6, while networks waited for content worth reaching over it. Only the genuine pain of IPv4 exhaustion finally moved both sides. The honest lesson is that a better technology does not deploy itself — incentives and momentum decide the pace.

Whichever version a packet wears, the router's core job is unchanged, and that is exactly what the next and final guide in this rung opens up. A router still reads the destination address out of the header and looks it up in its forwarding table to decide which interface to send it out of. The lookup uses the longest matching prefix — and notice that this is one place where wider IPv6 addresses cost more, because there are 128 bits to match against instead of 32. The principle is identical for both; the next guide takes you inside that lookup, where a router forwards a packet in nanoseconds.