IPv6 Basics: Why We Need It, How It Differs from IPv4, and What It Unlocks

June 5, 2026 12 min read Networking Deep Dives

networkingipv6ipv4fundamentalsslaacaddressingdual-stack

Contents

For most of the internet’s history, IPv6 was the protocol that was perpetually five years away. It was ratified in the late 1990s, everyone agreed it was necessary, and almost nobody deployed it. That era is over. In late March 2026, native IPv6 crossed 50% of Google’s global user traffic for the first time, and IPv6 overtook IPv4 as the majority of internet traffic shortly after. In countries like India, France, and Germany, IPv6 penetration is well past 80%. If you build or operate anything on a network, IPv6 is no longer a thing you can defer learning.

This post is the conceptual on-ramp: why the internet needed a new addressing protocol at all, what actually changes when you move from IPv4 to IPv6 (it is much more than “bigger numbers”), and the genuinely interesting capabilities the larger address space unlocks. It is deliberately a basics piece — for the hands-on side (SLAAC vs DHCPv6 config, dual-stack on Linux and Docker, firewalling, running it in a homelab), the IPv6 practical guide is the companion reference. Here we’re after the intuition.

Why We Needed a New Protocol

IPv4 addresses are 32 bits. That gives 2^32 — about 4.3 billion — possible addresses, which sounded limitless in 1981 and turned out to be nowhere near enough for a planet with more phones than people, plus laptops, servers, cameras, thermostats, cars, and a few billion IoT widgets. The central registry (IANA) handed out its last free blocks in 2011, and the regional registries that allocate addresses to ISPs ran dry over the following years. There simply are no more fresh IPv4 addresses to give out; what trades hands now is a secondary market where a single IPv4 address sells for tens of dollars.

The internet didn’t collapse in 2011 because of a clever, ugly workaround: NAT (Network Address Translation). NAT lets a whole network of devices hide behind a single public IPv4 address — your home has dozens of devices but your ISP gives you one public address, and your router rewrites the port numbers so it can tell the return traffic apart. NAT is why IPv4 limped on for a decade past exhaustion. It is also the source of a long list of problems we’ll come back to: it breaks the assumption that any host can directly reach any other host, it complicates peer-to-peer applications, and it forces increasingly desperate “carrier-grade NAT” layers where even your ISP is sharing one address across hundreds of customers.

IPv6 solves the shortage at the root. Addresses are 128 bits, which is 2^128 — roughly 3.4 × 10^38, or 340 undecillion. The numbers are too large to be meaningful; the useful framing is that there are enough IPv6 addresses to give every grain of sand on Earth its own enormous network and never run out. The shortage that defined three decades of network engineering simply ceases to exist. That abundance is not just relief from scarcity — it’s what enables most of the “cool stuff” later in this post.

What an IPv6 Address Looks Like

A 128-bit address would be unreadable in decimal, so IPv6 uses eight groups of four hexadecimal digits, separated by colons:

2001:0db8:0000:0000:0000:ff00:0042:8329

Two abbreviation rules make this tolerable. First, drop leading zeros in each group. Second, replace one run of all-zero groups with a double colon ::. Applying both:

2001:0db8:0000:0000:0000:ff00:0042:8329
2001:db8::ff00:42:8329

The :: can appear only once in an address (otherwise it would be ambiguous how many zero-groups it stands for). 2001:db8::/32 is the documentation prefix, the IPv6 equivalent of 192.0.2.0/24 — reserved for examples, which is why you see it everywhere including here.

The structure is hierarchical and, refreshingly, standardized. A typical global address splits cleanly:

| <----------- 64-bit network prefix -----------> | <-- 64-bit interface ID --> |
  2001:0db8:1234:5678  :  0000:0000:0000:0001
  └ routing prefix ┘  └sub┘    └ identifies the host on the link ┘
        (/48 from ISP)  (/64 subnet)

The convention that almost every LAN is a /64 is worth internalizing now, because it changes how you think about subnetting. In IPv4 you agonize over whether a subnet should be a /26 or a /27 to avoid wasting addresses — the whole partial-octet subnetting discipline exists because addresses are scarce. In IPv6 a single /64 contains 18 quintillion addresses, you give every LAN a /64 and never think about host counts again, and you subnet on the network portion (a site gets a /48, giving it 65,536 /64 subnets to organize however it likes). Address conservation, the central anxiety of IPv4 design, just isn’t a concern.

How IPv6 Actually Differs (Beyond Size)

The address space is the headline, but several design decisions make IPv6 behave differently in ways you’ll notice day to day. Here’s the side-by-side:

Aspect	IPv4	IPv6
Address size	32 bits (~4.3 billion)	128 bits (~3.4×10^38)
Notation	Dotted decimal `192.168.1.1`	Hex groups `2001:db8::1`
Typical LAN subnet	varies (/24, /26…)	almost always /64
Address config	Manual or DHCP	SLAAC (stateless) or DHCPv6
NAT	Ubiquitous, near-mandatory	Designed to be unnecessary
Finding neighbors	ARP (broadcast)	NDP via ICMPv6 (multicast)
Broadcast	Yes	None — replaced by multicast
Header	Variable length, 14+ fields	Fixed 40 bytes, streamlined
Router fragmentation	Routers may fragment	Never — hosts use Path MTU Discovery
Addresses per interface	Usually one	Many, as normal operation

A few of these deserve unpacking because they change behavior, not just syntax.

Autoconfiguration (SLAAC). This is the one people notice first. In IPv6, a host can configure its own working address with no DHCP server at all. When it joins a link it sends a Router Solicitation; the router replies with a Router Advertisement containing the /64 prefix; the host appends its own interface identifier and now has a globally routable address. The whole exchange is “plug in cable, have address.” DHCPv6 still exists for when you want centralized control, but the default path is stateless and serverless.

   Host                         Router
    |  --- Router Solicitation -->  |   "anyone out there? what's the prefix?"
    |  <-- Router Advertisement --  |   "the prefix here is 2001:db8:1:1::/64"
    |                               |
    |  builds 2001:db8:1:1:<own-interface-id>  -- done, no DHCP involved

No broadcast; multicast instead. IPv4 leans on broadcast (shout to everyone on the segment) for things like ARP, which is noisy — every host’s CPU processes every broadcast. IPv6 has no broadcast at all. Address resolution uses NDP (Neighbor Discovery Protocol) over ICMPv6 and targets a solicited-node multicast group, so only the handful of hosts whose addresses might match actually get interrupted. It’s the same job ARP did, done more surgically.

A simpler header. The IPv6 header is a fixed 40 bytes with far fewer fields. The header checksum is gone (the layers above and below already checksum, so it was redundant work at every hop), and rarely-used options moved into optional extension headers chained after the main one. The result is a header routers can process faster and more predictably. Relatedly, routers never fragment IPv6 packets — if a packet is too big for a link, the router drops it and signals the sender, which is expected to do Path MTU Discovery. Fragmentation, a frequent source of IPv4 performance and security headaches, is pushed entirely to the endpoints.

Multiple addresses are normal. An IPv6 interface routinely holds several addresses at once: a link-local address (fe80::/10, always present, used for on-link housekeeping and never routed off the segment), one or more global unicast addresses, often a temporary privacy address, and maybe a unique local address (fc00::/7, the IPv6 analog of RFC 1918 private space). Where IPv4 trained you to expect one address per interface, IPv6 expects many, each with a scope and a purpose.

The NAT Question

This is the difference with the biggest practical consequences, so it gets its own section. In IPv4, NAT became so universal that people forgot it was a workaround and started treating it as a security feature — “my devices are safe because they’re behind NAT and not directly reachable.” That safety is a side effect, not a design: NAT happens to drop unsolicited inbound traffic because it has no translation entry for it.

IPv6 is built so that NAT is unnecessary — there are enough addresses for every device to have a real, globally routable one. That restores end-to-end connectivity, the original architecture of the internet where any host could in principle address any other host directly. For peer-to-peer applications, voice/video, gaming, and anything that struggles with NAT traversal, this is a genuine simplification — no more STUN/TURN/relay gymnastics just to connect two endpoints that both sit behind NAT.

But “globally routable” is not “exposed to the world,” and this is the part people get wrong. End-to-end addressability does not mean end-to-end reachability — a properly configured IPv6 network still runs a stateful firewall that defaults to denying unsolicited inbound traffic, exactly like NAT did, but on purpose and with explicit rules rather than as an accident of address translation. The shift is that security becomes something you configure (deliberately, with a default-deny firewall) instead of something you get for free from a translation table. For the per-platform firewall specifics, the NAT and PAT post covers the IPv4 model you’re leaving behind, and the practical guide covers IPv6 nftables rules. The honest summary: IPv6 trades the accidental firewall of NAT for an intentional one, which is strictly better engineering and a real operational responsibility you must not skip.

The Cool Stuff a 128-Bit Space Enables

Abundance changes what’s possible. A few capabilities that are awkward or impossible in IPv4 become natural:

Plug-and-play addressing at scale. SLAAC means you can drop thousands of devices onto a network with zero address management. For IoT fleets, sensor networks, and ephemeral container/VM workloads, “addresses configure themselves” is a real operational win. Protocols like Thread and 6LoWPAN build directly on IPv6 for exactly this reason.
Subnets too large to scan. A /64 has 2^64 addresses. An attacker can sweep an entire IPv4 /24 (256 addresses) in milliseconds during reconnaissance; brute-force scanning a /64 to find live hosts is computationally infeasible. It’s not a substitute for a firewall, but it does quietly retire the “scan the whole subnet” recon technique that’s trivial in IPv4.
Privacy addresses. Because addresses are plentiful, a host can generate temporary addresses (RFC 8981) that rotate over time for outbound connections, so your traffic isn’t trivially linkable to a stable hardware-derived identifier. You get a stable address for inbound services and disposable ones for browsing, simultaneously.
Painless renumbering and multihoming. Changing providers or prefixes can be as simple as advertising a new prefix in Router Advertisements and letting SLAAC propagate it, with the old prefix deprecated gracefully. Hosts can hold addresses from multiple prefixes at once, which makes multihoming far less painful than IPv4’s NAT-bound approach.
SRv6 — the address as a program. This is the genuinely modern one. Segment Routing over IPv6 uses the enormous address space to encode a list of instructions — waypoints, services, traffic-engineering steps — directly into IPv6 addresses in the packet header. The network becomes programmable using nothing but standard IPv6 forwarding: you steer a packet through a specific path or chain of network functions by writing addresses, no extra signaling protocol required. Large carrier and data-center backbones increasingly run on SRv6 precisely because IPv6’s address room makes it feasible.
IPv6-mostly networks and graceful transition. Mechanisms like NAT64/DNS64 and 464XLAT let IPv6-only clients still reach the remaining IPv4-only internet through a translator, so networks can go IPv6-first without breaking legacy destinations. Apple has required IPv6 support in App Store apps since 2016, which dragged a lot of the ecosystem forward.

Honest Trade-offs and the Reality of Transition

IPv6 is not free of friction, and pretending otherwise sets people up for surprises.

Dual-stack is the real world, and it’s twice the surface. Almost nobody flips from IPv4 to IPv6 overnight. The normal state is dual-stack — running both protocols side by side — which means two addressing schemes, two firewall rule sets, and two sets of things that can break. Browsers use “Happy Eyeballs” (RFC 8305) to race IPv4 and IPv6 connections and use whichever answers first, which papers over a lot, but operationally you maintain both stacks for years.
The security model genuinely changes. As covered above, losing NAT’s accidental firewall means you must configure a stateful inbound firewall. Networks that enable IPv6 without doing this have directly exposed hosts that they assumed were protected. This is the single most common IPv6 mistake.
Human factors. Hex addresses are harder to read, remember, and type than dotted decimal. Tooling, runbooks, monitoring, and muscle memory across the industry were built IPv4-first, and some of it still lags. Plenty of engineers can subnet IPv4 in their sleep and freeze at 2001:db8::/48.
Uneven support. Adoption past 50% globally hides enormous variation — some ISPs, cloud regions, and enterprise networks still treat IPv6 as an afterthought, so you can’t assume it’s there end to end.

The mental model that helps: IPv6 is not “IPv4 with longer addresses.” It’s a protocol that took the chance to fix several of IPv4’s accumulated workarounds — autoconfiguration instead of mandatory DHCP, multicast instead of broadcast, a clean fixed header, endpoint-only fragmentation, and the removal of NAT — using the address abundance as the foundation that makes all of it possible.

The Verdict

IPv6 exists because IPv4 ran out of addresses and NAT was only ever a stay of execution. But the interesting part is what the redesign enabled along the way: self-configuring hosts, subnets too vast to scan, rotating privacy addresses, painless renumbering, restored end-to-end connectivity, and programmable forwarding via SRv6 — none of which fit comfortably in a 32-bit world. The cost is a real transition period of dual-stack complexity and a security model you now have to configure deliberately rather than inherit by accident from NAT.

With IPv6 now carrying the majority of internet traffic, the practical advice is simple: learn to read the addresses, understand SLAAC and the /64 convention, and — above all — firewall your IPv6 the way NAT used to firewall your IPv4 for free. When you’re ready to actually configure it, the IPv6 practical guide takes it from here, and if you’re shaky on the addressing math underneath all of this, the Linux networking fundamentals and OSI/TCP-IP model posts are good ground to stand on first.