{{ summaryTitle }}

{{ summaryValue }}{{ summaryLine }} {{ badge.label }} {{ badge.value }}

Prefix tree unavailable.

Use one CIDR such as 2001:db8:1200::/48 or fd12:3456:789a::/48.
A /56 boundary creates 256 site prefixes from a /48 parent.
/ bits
Keep /64 for ordinary SLAAC-capable LANs; use other boundaries only with an explicit design reason.
/ bits
Count current sites and any deliberate growth or reservation slots.
sites
This demand is checked independently inside every site allocation.
LANs/site
{{ workflowFeedback }}
Leave 0 for the first site; the ledger shows up to eight consecutive allocations.
Blank uses Site; this label never changes address calculations.
MeasureValuePlanning meaningCopy
{{ row.label }}{{ row.value }}{{ row.note }}
CheckStatusRecommended actionCopy
{{ row.label }}{{ row.value }}{{ row.note }}
AllocationSite prefixFirst LANLast LANLAN slotsCopy
{{ row.label }}{{ row.sitePrefix }}{{ row.firstLan }}{{ row.lastLan }}{{ row.lanSlots }}
{{ row.label }}: {{ row.bits }} bits ({{ row.range }})
IPv6 Address and Subnet Calculator Calculate an IPv6 network from an address and prefix, then review canonical boundaries, child-prefix capacity and reverse DNS or EUI-64 guidance.
Internet Protocol version 4 (IPv4) Subnet Calculator Calculate an IPv4 subnet boundary from CIDR or a dotted mask, then check usable hosts, special-purpose ranges and reserve-adjusted capacity.
IPv4 Supernet Calculator Summarize IPv4 CIDR blocks as one cover route or an exact aggregate set, with normalization and clear warnings for addresses exposed by gaps.
IPv4 Renumbering Planner Build dependency-ordered IPv4 renumbering waves with CIDR and DNS/DHCP timing checks, window-fit rules and rollback-ready runbooks.

An IPv6 allocation succeeds when its boundaries remain useful long after the first subnet is connected. The 128-bit address is divided from the left: an assigned parent prefix identifies the organization or aggregate, added bits identify sites, more bits identify LANs, and the remaining bits identify interfaces. Each longer prefix therefore trades the number of child networks against the address space left inside them.

Hierarchical planning matters because routes, firewall policy, reverse DNS, monitoring, and asset records all benefit from predictable blocks. Giving every branch an equal site prefix makes summarization and delegation easier. Giving every site the same LAN boundary makes local allocations comparable, even when some sites initially need only a few networks.

Parent prefix
The assigned Classless Inter-Domain Routing (CIDR) block from which every site allocation must be drawn.
Site prefix
An equal child block reserved for one branch, region, tenant, or other planning unit.
LAN prefix
A routed subnet inside a site. A /64 leaves a 64-bit interface identifier and fits the normal assumptions of IPv6 stateless address autoconfiguration on common link types.

A common hierarchy is /48 to /56 to /64. The eight bits between /48 and /56 create 256 site blocks, while the next eight bits create 256 LANs inside every site. Those counts are independent: unused LANs in one site do not increase another site's allocation.

Demand should include known growth and deliberate reservations, but capacity alone does not approve a prefix. Address scope must match the deployment, non-network bits in an entered CIDR should be normalized to the network boundary, and unusual LAN sizes need an explicit operational reason. Nibble-aligned boundaries—prefix lengths divisible by four—also make hexadecimal documentation and reverse-DNS delegation easier, although a non-nibble boundary is still mathematically valid.

How to Use This Tool:

Start with the prefix actually assigned to the design, then choose boundaries that cover demand without breaking the intended LAN model.

  1. Enter Assigned parent prefix as one IPv6 CIDR, then confirm the normalized parent shown in Capacity audit. If host bits were present, use the normalized network in the plan.
  2. Choose Site prefix length and LAN prefix length. Keep the order parent prefix ≤ site prefix ≤ LAN prefix; a shorter site or LAN boundary is rejected.
  3. Enter Sites needed and LANs per site needed. Read the two fit checks separately because total unused address space cannot compensate for an undersized site or LAN boundary.
  4. Set the Ledger start index when you need a later allocation and add an optional site label. Check the generated site prefix, first LAN, and last LAN against the routing or IP address management record before assigning it.

Interpreting Results:

Site capacity and LAN capacity are exact powers of two for the selected boundaries. A fit means demand is less than or equal to capacity; it does not mean the allocation has enough operational reserve or matches an upstream assignment policy.

  • Use Required site prefix and Required LAN prefix as minimum bit requirements for the entered counts, then choose a boundary that also leaves deliberate growth room.
  • Treat a non-/64 LAN warning as a design review, not a syntax error. Point-to-point links and specialized systems may use other sizes, but ordinary autoconfigured LANs commonly depend on the 64-bit boundary.
  • Review documentation, unique-local, link-local, multicast, loopback, and unspecified scope warnings before copying a ledger row into a production plan.
  • Confirm the first and last generated prefixes in an independent IP address management system. The ledger proves arithmetic sequence, not ownership or route availability.

Technical Details:

Prefix capacity comes from the number of bits added at each boundary. Every added bit doubles the number of equal child prefixes, so capacity is exact even when the resulting count is too large to display conveniently as an ordinary decimal number.

Formula Core:

The site and LAN counts use the same power-of-two rule at different levels of the hierarchy.

Csite =2psite−pparent CLAN =2pLAN−psite
SymbolMeaningUnit
pparentAssigned parent prefix lengthbits
psiteSelected site prefix lengthbits
pLANSelected LAN prefix lengthbits
CsiteEqual site prefixes in the parentcount
CLANEqual LAN prefixes in each sitecount

For /48 to /56 to /64, both exponents are 8. That gives 28 = 256 sites and 256 LANs per site. The total number of LAN prefixes under the parent is 264 − 48 = 65,536, but the per-site check remains 256.

Allocation and Validation Rules:

RuleExact behaviorPlanning consequence
Boundary orderParent ≤ site ≤ LAN, with every prefix from 0 to 128Child blocks cannot be broader than their containers.
Demand fitNeeded count ≤ 2added bitsEquality fits but leaves zero spare allocations.
Required boundaryBase prefix + ceiling(log2(demand))Non-power-of-two demand consumes the next whole bit.
Ledger sequenceSite base = parent network + index × site block sizeThe zero-based start index must be below site capacity.
Text normalizationHost bits are cleared and the address is compressed consistentlyDifferent spellings of the same network converge on one CIDR.

Limitations:

The plan models equal-size hierarchical allocations. It does not test route advertisements, registry ownership, duplicate use elsewhere, variable-length allocations, DHCPv6 or SLAAC policy, reverse-DNS configuration, or firewall reachability. Special-scope warnings identify address categories but cannot decide whether a private lab, documentation example, or production network is appropriate.

Worked Examples:

Regional plan with reserved growth

An assigned 2001:db8:1200::/48 is divided at /56 for sites and /64 for LANs. Demand of 120 sites and 80 LANs per site fits within 256 at each boundary, leaving 136 site slots and 176 LAN slots per site. The documentation-prefix warning remains important: the arithmetic is valid, but 2001:db8::/32 belongs in examples rather than a live routed deployment.

References: