IPv6 Address Planning: Why Everything You Know About Conserving Space Is Wrong

If you learned networking on IPv4 (Internet Protocol version 4, the addressing system most of the internet still runs on), you absorbed a set of habits without noticing. Count your devices. Pick the smallest subnet that fits. Guard every address, because the world is running out of them. Those habits served everyone well for decades, and IPv6 (Internet Protocol version 6, the successor with a vastly larger address space) asks you to unlearn all of them. Good IPv6 planning rewards generosity, round numbers, and what looks like deliberate waste, while engineers who carry IPv4 frugality across tend to build plans that fight the protocol instead of working with it. This guide explains how IPv6 address planning actually works and why the old rules run backwards. If subnets and slash notation are new to you, start with our visual guide to CIDR notation; everything there about how prefixes work carries over directly.

The size difference explains everything else, so start there. An IPv4 address is 32 bits long, which yields about 4.3 billion possible addresses for the entire planet. An IPv6 address is 128 bits long, which yields about 340 undecillion addresses, a number with 39 digits. We write IPv6 addresses as eight groups of four hexadecimal digits (base-16 numbers using 0 through 9 and a through f) separated by colons. Because that gets long, two shorthand rules exist: you can drop leading zeros within any group, and you can collapse one consecutive run of all-zero groups into a double colon. Slash notation works exactly as it does in IPv4, so a /64 means the first 64 bits identify the network and the remaining bits identify devices on it.

The same address, three ways

Full form:        2001:0db8:acad:0001:0000:0000:0000:0042
Drop lead zeros:  2001:db8:acad:1:0:0:0:42
Compress zeros:   2001:db8:acad:1::42

Now for the rule that surprises every IPv4 veteran: in IPv6, every ordinary network segment gets a /64. The conference room Wi-Fi with twelve devices gets a /64. The server LAN (local area network, a single network segment such as one office floor or one VLAN) with forty machines gets a /64. The decision you used to agonize over, sizing each subnet to its expected host count, simply disappears. The reason is baked into the standards. SLAAC (Stateless Address Autoconfiguration), the mechanism that lets IPv6 devices generate their own addresses without waiting for a server to assign one (the job DHCP performs in IPv4), requires exactly 64 bits of host space to function. RFC 4291 (an RFC, or Request for Comments, is one of the numbered specification documents the internet is built on) defines this structure, and it has remained stable ever since, which is why advice about IPv6 fundamentals ages so well.

A single /64 contains about 18.4 quintillion addresses, so that forty-server network will occupy a fraction of its subnet so small it rounds to zero at any number of decimal places. Judged by IPv4 instincts, this looks like malpractice. In IPv6 it is the intended design, and utilization percentage stops being a useful measure of whether a subnet is sized correctly. The one widely accepted exception is the link between two routers, where many operators use a /127 (two addresses, the IPv6 cousin of the IPv4 /31) to close off a handful of attacks specific to router-to-router links. We walk through the IPv4 version of that decision in our guide to point-to-point links, and the same logic translates.

If every network is a /64, then planning an IPv6 network means counting subnets rather than counting hosts, and the supply of subnets is enormous. A /48, the allocation a business site commonly receives, contains 65,536 individual /64 networks. A /56, common for smaller sites and home connections, contains 256 of them. Your ISP (internet service provider) typically holds a /32 from a regional registry, which contains 65,536 /48s to hand out. The table below shows the prefix sizes you will encounter most often and how many /64 networks each one holds.

Notice that every prefix length in that table is a multiple of four. That habit is called planning on nibble boundaries, and it is the second big idea in IPv6 design. A nibble is four bits, which happens to be exactly one hexadecimal digit, so when your subnet boundaries land on multiples of four, each level of your network hierarchy occupies its own visible digit in the written address. A human can read 2001:db8:acad:5210::/64 and see site 5, building 2, VLAN (virtual LAN, a logically separated network segment) 10, straight from the text. Splitting on a /50 or a /59 is mathematically legal, but the boundary lands in the middle of a digit, the addresses become unreadable to humans, and reverse DNS (Domain Name System, the system that maps addresses back to names) gets awkward because its delegation also works one nibble at a time.

Nibble boundaries: each hierarchy level gets its own digit

2001:db8:acad : 5 2 10 :: /64
|-- /48 org --| │ │ │
     site ──────┘ │ │   (one digit  = 16 sites)
     building ────┘ │   (one digit  = 16 buildings)
     VLAN ──────────┘   (two digits = 256 VLANs each)

Before assigning any of those prefixes, you have to decide which flavor of address space to use, and IPv6 gives you two. A GUA (Global Unicast Address) is a publicly routable address, currently always beginning with a 2 or 3, that your ISP or a regional registry allocates to you. A ULA (Unique Local Address) lives under the fd00::/8 prefix and works only inside your own network, making it the IPv6 cousin of the private IPv4 ranges like 10.0.0.0/8 covered in our tour of reserved IP ranges. ULA comes with one clever requirement: you generate 40 bits of the prefix randomly, so when two companies merge, the odds that their internal networks collide are vanishingly small. Anyone who has untangled two overlapping 10.0.0.0/8 deployments after an acquisition will appreciate why the designers insisted on that.

The tempting move for an IPv4 veteran is to use ULA everywhere and bolt on NAT (Network Address Translation, the technique of rewriting private addresses to public ones at the network edge), recreating the familiar IPv4 architecture. Resist that pull. IPv6 was designed for end-to-end connectivity using global addresses, with your firewall, rather than address hiding, providing the security boundary. ULA earns its keep on networks that should never touch the internet, such as lab environments, industrial controls, and management interfaces, and some organizations run GUA and ULA side by side since IPv6 interfaces happily hold several addresses at once. For anything that communicates beyond your walls, global addresses are the intended path.

The final habit to rewire is how you place allocations inside your space, and this is where IPv4 instincts do the most damage. Dense packing was a virtue in IPv4: you placed subnets shoulder to shoulder because every block you skipped was a block you might run out of later. In IPv6 the better strategy is sparse allocation. Give each site a generous prefix, space the allocations far apart, and leave most of your plan deliberately empty. Sparse plans keep routes aggregatable, meaning each site summarizes to a single tidy route instead of a pile of fragments, and they let any site grow without renumbering. Address space costs you nothing, while renumbering a live network costs weekends. Spend the cheap resource to protect the expensive one.

A sparse /48 plan: sites spaced out, room everywhere

2001:db8:acad::/48                  (your org: 65,536 /64s)
├── 2001:db8:acad:1000::/52     HQ (4,096 /64s)
│     ├── 2001:db8:acad:1001::/64   Workstations
│     ├── 2001:db8:acad:1002::/64   Wi-Fi
│     └── 2001:db8:acad:1010::/64   Servers
├── 2001:db8:acad:2000::/52     Factory
├── 2001:db8:acad:4000::/52     Cloud
└── (everything else held in reserve)

That tree is the IPv6 version of the exercise we ran for IPv4 in our worked example of designing an IP plan from scratch, and the two plans are happiest living side by side, since nearly every real network runs both protocols at once during the long transition. The bookkeeping, however, gets harder in IPv6, and the spreadsheet tricks that limp along for IPv4 collapse entirely. The same IPv6 address has several legal spellings (2001:db8::1 and 2001:0db8:0000:0000:0000:0000:0000:0001 are the same address), so text matching and sorting in a spreadsheet quietly break. An IPAM (IP Address Management) tool sidesteps this by storing addresses as actual 128-bit values rather than text. IPCraft stores both protocols in native database types, so the folder hierarchy, parent and child subnet relationships, and utilization views work identically whether you paste in 10.1.0.0/16 or 2001:db8:acad::/48, and the plan above maps directly onto nested subnets in a folder. If you want to experiment with prefix math before committing to a plan, our free IPv6 subnet calculator handles the expansion, compression, and splitting for you.

The fundamentals here have not moved since the 1990s, which makes IPv6 planning knowledge a durable investment: give every LAN a /64, split on nibble boundaries so humans can read the plan, prefer global addresses with a firewall over private addresses with NAT, and allocate sparsely because your time is the scarce resource now. The mechanics are simple; the hardest part is giving yourself permission to be wasteful after years of treating addresses as precious. Once that clicks, IPv6 plans turn out to be simpler than the IPv4 plans they replace.