IPv6 for Humans

On a CCTV commissioning job, a colleague of mine carefully wrote down "the NVR's IP" in the project binder: fe80::ba27:ebff:fe12:34c9. Two weeks later, nobody at the remote office could reach the recorder. Of course they couldn't — he'd written down the link-local address, which only exists inside that one network segment. That's like giving "back room, second door on the left" as your mailing address: perfectly accurate if you're already inside the house, useless from anywhere else.

Accidents like that happen because IPv6 looks intimidating, so the natural reflex is to copy-paste it without reading it. Here's the good news: those 128 bits hide less mystery than IPv4 ever did. Let's take it apart.

From 32 to 128 bits: why it looks so weird

An IPv4 address is 32 bits dressed up as four decimal numbers. An IPv6 address is 128 bits dressed up as 8 groups of 16 bits, each group written as 4 hexadecimal digits, separated by colons. That's the whole trick. If it looks long, that's because it is long: written out in full, it's 39 characters.

Since typing 39 characters per address would be cruel and unusual, the standard (RFC 5952) gives you two compression rules:

• Rule 1: inside each group, drop the leading zeros. 0db8 becomes db8, 0000 becomes 0.
• Rule 2: the longest run of all-zero groups collapses into ::. And you can only do this ONCE per address — with two :: you couldn't tell how many zeros went where, and the address would be ambiguous.

So 2001:0db8:0000:0000:0000:0000:0000:0001 shrinks to 2001:db8::1. Same address, 28 characters lighter. If you want to play with this in both directions — expand and compress — the IPv6 calculator does it instantly and also tells you the address type and range.

Anatomy of a GUA: three pieces, not eight

The most common reading mistake is trying to parse the 8 groups the way you'd parse the 4 octets of IPv4. Don't. A global unicast address (GUA) reads as three pieces, like an international phone number — country code, area code, local number:

Look at the proportions: out of 128 bits, you only manage 16. The prefix arrives ready-made, and hosts auto-generate their own interface identifier via SLAAC. The entire "network design" of an IPv6 site lives in 4 hex digits. That's why IPv6 planning ends up simpler than IPv4: the problem got smaller, not bigger.

The address types you'll meet in the field

The first word of the address tells you immediately what you're looking at. These are the ones that show up in real life:

Link-local is the misunderstood star of the show. Every IPv6 interface gives itself an fe80:: address the moment it comes up, without asking anyone, and it's only valid on that physical link. Routers use it to talk to each other, and the default gateway a router advertises via RA is almost always a link-local address. That's why seeing fe80::… as a next hop in a routing table is perfectly normal — and why writing it down as "the device's IP" to reach it from another network is exactly my colleague's NVR mistake.

ULAs are the spiritual heir of 10.0.0.0/8, with one upgrade: the standard (RFC 4193) tells you to generate 40 random bits for your fd…::/48 prefix. That sounds like bureaucracy right up until your company merges with another one and you both used 10.0.0.0/8 — in IPv4 that means renumbering and tears; with randomized ULAs a collision is practically impossible. If you've inherited someone else's networks, the subnet overlap checker tells you in seconds whether two prefixes clash.

And broadcast? It's gone. IPv6 replaced it with well-aimed multicast: ff02::1 reaches every node on the link, ff02::2 only the routers. Even ARP's replacement (NDP) uses targeted multicast instead of shouting at the whole segment. Your switches send their regards.

The golden rule: every LAN is a /64

Tattoo this one somewhere: every VLAN, every segment, every LAN gets a /64. Not a /96 "because it's only a few devices", not a /120 "to avoid waste". A /64. Always.

The reason is technical, not aesthetic: SLAAC — the mechanism hosts use to configure their own addresses — requires exactly 64 bits of interface identifier (RFC 4862). Give it less and SLAAC simply stops working, leaving you dependent on DHCPv6 for everything… and Android does not speak DHCPv6. A "trimmed" /64 is a network where phones can't get an address.

As for the "waste" — let's do the math. A /64 holds 2⁶⁴ addresses: 18.4 quintillion. The entire IPv4 address space is 2³² ≈ 4.3 billion. In other words, each /64 could hold 4.3 billion copies of the whole IPv4 internet — and we still assign one to the VLAN with three printers on it. That's fine. It's designed that way: the 64 host bits aren't inventory that runs out, they're the room autoconfiguration and address privacy need in order to work without coordination.

The hierarchical plan: /48 → /56 → /64

Once the golden rule is settled, planning means handing out /64s. A site /48 leaves you 16 subnet bits: 2¹⁶ = 65,536 /64 networks. The point isn't the quantity — it's how you organize it. The pattern that never fails:

• /48 = the site. What your ISP delegates (or your ULA block).
• /56 = the building (or floor, or zone): 8 bits → 256 buildings per site.
• /64 = the VLAN: another 8 bits → 256 VLANs per building.

Is 256 buildings more than you'll ever need? Doesn't matter. The goal of an IPv6 plan isn't to "use up" the space — it's to make the address read itself: you glance at …cafe:0530::/64 and know it's building 05, VLAN 30, without opening a single spreadsheet. During a 3 AM incident, that's worth its weight in gold.

The nibble boundary: why 4 bits at a time

A nibble is 4 bits — exactly one hexadecimal digit. Split your prefixes on multiples of 4 bits (/48, /52, /56, /60, /64) and every block starts and ends on a whole hex digit, so prefixes can be read at a glance. Cut at /49 or /57 and the boundary lands in the middle of a digit: 2001:db8:cafe:8000::/49 exists and is perfectly valid, but figuring out what it contains requires mental binary arithmetic. Nobody wants that at 3 AM.

There's a bonus prize: IPv6 reverse DNS (ip6.arpa) is delegated digit by digit — that is, nibble by nibble. A nibble-aligned plan translates into clean, delegable PTR zones; a misaligned one, into headaches. The reverse PTR zone tool generates the ip6.arpa names from any prefix, and you'll see it immediately.

Hands on: a complete plan in 6 steps

Say your ISP delegated 2001:db8:cafe::/48 for a campus, and we start with VLAN 10 (data) in building 5:

1. Locate your 16 bits. The first 48 bits (2001:0db8:cafe) are fixed. Your canvas is the entire fourth group: 4 hex digits. The last 64 bits belong to the hosts.
2. Split the group on the nibble boundary: first 2 digits = building (8 bits → 256 buildings), last 2 = VLAN (8 bits → 256 VLANs per building).
3. Building 5 → 05. Its whole block is 2001:db8:cafe:0500::/56: any address whose fourth group starts with 05 lives there.
4. VLAN 10 → 10. The fourth group becomes 0510, so the LAN is 2001:db8:cafe:0510::/64.
5. Compress (RFC 5952): the leading zero drops (0510 → 510) and the zero groups collapse into ::. Result: 2001:db8:cafe:510::/64, with gateway 2001:db8:cafe:510::1.
6. Count what you've got: 256 buildings × 256 VLANs = 65,536 /64 networks from a single /48. Each holding 2⁶⁴ addresses. You can stop rationing now.

Building 5's plan ends up this readable:

site                2001:db8:cafe::/48
building 05         2001:db8:cafe:500::/56
├─ vlan 10 data     2001:db8:cafe:510::/64
├─ vlan 20 voice    2001:db8:cafe:520::/64
├─ vlan 30 cameras  2001:db8:cafe:530::/64
└─ gw vlan 10       2001:db8:cafe:510::1

Every line explains itself: site cafe, building 05, VLAN in plain sight. Paste any of these prefixes into the IPv6 calculator to double-check the expansion, range and type before you configure anything.

What to do next

Pick a real site you manage, sketch its building → VLAN hierarchy, and run it through the IPv6 planner: five minutes gets you a complete nibble-aligned plan. Then go audit any fe80:: addresses written down somewhere as if they were reachable — now you know why they never answer from the other office.