IPv4 vs IPv6

One protocol ran out of numbers

IPv4 gives every address 32 bits, which allows roughly 4.3 billion distinct values. That was an extraordinarily generous number in 1981 and an obviously insufficient one by the mid-1990s. The regional registries began exhausting their free pools in 2011, and today an IPv4 address is a traded asset with a market price.

IPv6 uses 128 bits. The number of addresses that produces is not usefully expressible in ordinary language — it is about 340 undecillion, which is enough to assign a unique address to every atom on the surface of the Earth several times over. The point of that absurd headroom is that allocations can be generous and hierarchical without anybody ever needing to economise again.

Everything else about IPv6 follows from having enough addresses. Once you are not rationing them, a household can have billions rather than one, network address translation stops being necessary, and every device can hold a genuinely globally routable address.

The differences that actually show up

Reading an IPv6 address

The notation looks intimidating and is not. An address is eight groups of four hexadecimal digits, separated by colons. Two abbreviation rules make it manageable: leading zeros within a group may be omitted, and exactly one run of consecutive all-zero groups may be collapsed to a double colon.

So 2001:0db8:0000:0000:0000:ff00:0042:8329 may be written 2001:db8::ff00:42:8329. The double colon is permitted only once in an address, because two of them would leave no way to tell how many zero groups each one stood for.

The prefix length works exactly as it does in IPv4 CIDR notation. A /64 is the standard size for a single network segment, and it is not a small allocation: it contains 18 quintillion addresses, which is why stateless autoconfiguration can simply derive an address without any risk of collision. Home connections are typically delegated a /56 or a /48, giving hundreds or thousands of separate /64 segments.

Autoconfiguration replaces DHCP for most devices

In IPv4, a device asks a DHCP server for an address and is given one from a pool. IPv6 devices normally use stateless address autoconfiguration instead: the router advertises the network prefix, and each device generates its own host portion and checks that nothing else is using it. No server tracks the assignment, which is possible only because the address space is large enough that random selection essentially never collides.

Privacy addresses, and why yours keeps changing

Early IPv6 derived the host portion from the network interface’s hardware address. That produced a stable, globally unique identifier that followed a laptop from home to office to café — a tracking identifier by accident, and a serious one.

Privacy extensions fixed it. Modern operating systems generate a random temporary address for outbound connections and rotate it, typically once a day, keeping a stable address available for inbound connections. The practical consequence is that the IPv6 address a site sees for you today will usually differ from the one it saw last week, even though nothing about your connection changed. That is working as intended.

Dual stack and Happy Eyeballs

Almost nobody runs one protocol exclusively. The normal arrangement is dual stack: both protocols configured on the same connection, with the operating system choosing between them per destination. When a name resolves to both an A record and an AAAA record, the client has to pick.

Browsers implement an algorithm known as Happy Eyeballs for exactly this. Rather than committing to IPv6 and waiting for a timeout if it is broken, the browser starts an IPv6 connection, gives it a short head start measured in tens of milliseconds, then starts an IPv4 connection in parallel and uses whichever completes first. The result is that a badly deployed IPv6 path degrades to a barely perceptible delay rather than to a failure — which is a large part of why IPv6 could be rolled out at all.

What NAT costs, and what removing it changes

Address translation was a workaround that became permanent. It works well enough that most people never think about it, but it has real costs: inbound connections need explicit port forwarding, peer-to-peer protocols need elaborate hole-punching, every connection consumes an entry in a shared state table, and logs on the far side cannot distinguish devices behind one address.

Carrier-grade NAT makes all of that worse by putting many customers behind a single address. Port forwarding becomes impossible, one abusive customer can get an address blocked for everybody sharing it, and geolocation becomes less accurate. IPv6 removes the need for any of it, which is the most concrete day-to-day benefit of having it.

Checking what you actually have

The reliable test is not what your settings claim but what an outside server observes. A probe that can only be reached over IPv4 and a second that can only be reached over IPv6 will each answer only if that protocol genuinely works end to end — which is the difference between IPv6 being configured and IPv6 being functional.

A common and confusing state is having an IPv6 address assigned locally while having no working IPv6 route to the internet. Your device reports an address, your settings look correct, and every IPv6-only destination times out. Testing against a real external endpoint is the only way to tell the difference.