IPv6 address management without the headaches

IPv6 isn't IPv4 with more digits — it's a different way of thinking about address space, and the habits that kept a spreadsheet usable for years fall apart the moment you paste in your first /48. The good news: once you manage IPv6 the way it wants to be managed — as a hierarchy of prefixes rather than a list of hosts — it becomes easier to run than IPv4, not harder.

Why IPv6 defeats the spreadsheet

A spreadsheet works for IPv4 because a /24 is 256 rows you can eyeball. IPv6 removes every assumption that made that workable.

• The space is vast. A single /64 holds 2^64 addresses. A site /48 contains 65,536 of those /64s. You will never enumerate hosts in a grid again.
• Hex doesn't sort or scan. 2001:db8:a3f0::/48 and 2001:db8:a3f1::/48 are adjacent, but nothing about a text column makes that obvious. Copy-paste typos hide in the middle of eight groups of hex.
• /64 is the atomic subnet. SLAAC and many autoconfiguration mechanisms assume a /64 on every segment. You don't "save space" by using a /112 — you break address autoconfiguration.
• The unit of management changes. Because addresses aren't scarce, you stop tracking every host and start tracking allocations: which prefix belongs to which site, VLAN, or purpose.

A flat list can't express containment, can't validate that a child fits inside its parent, and can't tell you what's still free. That's exactly what an IPAM is for.

Think in prefixes, not addresses

IPv6 management is fundamentally about delegating prefixes down a tree. A typical hierarchy looks like this:

• Your RIR assigns an organisation prefix — often a /32 (or /29 for larger allocations).
• You carve a /48 per site, giving each location 65,536 subnets to work with.
• Inside a site you assign a /64 per segment (VLAN, point-to-point link, VM network).

Every level is contained by the one above it, and an IPAM enforces that containment for you: a /64 can only live inside a /56 that lives inside a /48. That's the same parent/child model good IPv4 tooling already uses — IPv6 just makes the discipline non-optional.

Build an addressing plan on nibble boundaries

A nibble is 4 bits — one hex digit. If you allocate prefixes on multiples of 4 bits (/48, /52, /56, /60, /64), each level of your plan lands cleanly on a hex-digit boundary. That means humans can read the plan at a glance, and reverse DNS (ip6.arpa) zones split on the same boundaries instead of forcing bit-level delegation.

Compare a nibble-aligned plan to one that isn't:

Org prefix        2001:db8::/32
  Site A          2001:db8:0100::/48   <- 3rd hex group = site ID
    Segment 01    2001:db8:0100:0001::/64
    Segment 02    2001:db8:0100:0002::/64
  Site B          2001:db8:0200::/48
    Segment 01    2001:db8:0200:0001::/64

Because every field sits on a digit boundary, "site A, segment 2" is literally readable in the address. You can also encode meaning into specific nibbles — a digit for region, one for site, one for function — but keep it light: a plan that's too clever becomes impossible to renumber later. Reserving room on nibble boundaries is worth more than any elaborate scheme.

One more habit: allocate sparsely. Don't hand out /48s sequentially with no gaps — leave space between assignments so a site can grow and routes summarise cleanly later. You have the room; use it.

Keep IPv4 and IPv6 in one model

The biggest dual-stack mistake is running IPv6 in a second spreadsheet "until it settles down." Now you have two sources of truth that drift apart.

The fix is to treat address family as an attribute of the same objects. A network segment is one VLAN that happens to carry both a v4 prefix and a v6 /64. A server is one device with both an A and a AAAA record. Your sites, racks, VLANs, and devices don't double — only the prefixes attached to them do. An IPAM that models both families in one prefix hierarchy lets you ask "what's on VLAN 40?" and get the v4 and v6 answer together.

Track allocations, not every host

Host-level bookkeeping doesn't scale to IPv6 — with SLAAC and privacy extensions the host set churns constantly anyway. Track the things that are stable and meaningful:

1. Prefixes and delegations — the /48s, /56s, and /64s and who owns them.
2. Anchored addresses — gateways, anycast addresses, and manually assigned server addresses.
3. Documentation and reservations — ranges you've set aside but not yet deployed.

Let DNS and network discovery handle the ephemeral client addresses. Your source of truth records intent and structure; it doesn't need to know every temporary privacy address a laptop generated this morning.

Common pitfalls to avoid

• Subnetting smaller than /64. It feels frugal and it breaks SLAAC. Use /64 for every host segment; save longer prefixes for point-to-point links only.
• Confusing ULA and GUA. Unique Local Addresses (fc00::/7) are for internal-only ranges; Global Unicast is your routable space. Label which is which in your plan.
• Forgetting reverse DNS. Nibble-aligned prefixes make ip6.arpa delegation sane — off-boundary prefixes make it painful.
• Sequential, gap-free allocation. It works until the first time you need to grow a site or summarise a route.

Where Danbyte fits

Danbyte models IPv6 with the same prefix hierarchy it uses for IPv4: parent/child containment, utilization tracking, and dual-stack prefixes hanging off the same sites, VLANs, and devices — so v4 and v6 live in one place instead of two spreadsheets. Because it exposes a REST API, your addressing plan is queryable from Ansible, Terraform, or a quick script when you're building reverse zones or provisioning a new segment.

It's free and open source: self-host it on your own hardware, or run the identical software on Danbyte Cloud with export-anytime freedom. See the feature overview for how prefixes, VLANs, and devices tie together.

Plan on nibble boundaries, track prefixes instead of hosts, and IPv6 stops being the scary column in your spreadsheet and starts being the tidiest part of your network.