IPv6 Prefix Plan Calculator

{{ prefixFanStageMetrics.siteSlots }} site slots {{ prefixFanStageMetrics.lanSlots }} LANs/site {{ prefixFanStageMetrics.interfaceBits }} interface bits

Assigned parent prefix:

Enter CIDR notation such as 2001:db8:1200::/48 or fd12:3456:789a::/48.

Site prefix length:

Choose the per-site boundary; /56 gives 256 site prefixes from a /48 parent.

/{{ parentPrefixForSlider }} parent {{ prefixFanStageMetrics.siteSlots }} site slots /128 max

LAN prefix length:

Use /64 for normal access networks; longer prefixes should be limited to special cases.

/{{ sitePrefixForSlider }} site {{ prefixFanStageMetrics.lanSlots }} LANs/site /128 max

Sites needed:

Enter the current or planned number of sites, branches, regions, or tenants.

sites

0 {{ Number(sites_needed || 0).toLocaleString() }} planned {{ sitesNeededSliderMax.toLocaleString() }}

LANs per site needed:

Count VLANs, routed segments, VRFs, service zones, and growth slots that need distinct LAN prefixes.

LAN prefixes

0 {{ Number(subnets_per_site_needed || 0).toLocaleString() }} planned {{ lansNeededSliderMax.toLocaleString() }}

{{ error }}

{{ warning }}

Ledger start site index:

Use 0 for the first site prefix; large plans can preview a later allocation block.

Ledger preview rows:

Choose how many site prefixes to render in the visible ledger.

Site label prefix:

Use a short label such as Site, Branch, Region, Tenant, or POP.

{{ header }}	Copy
No prefix rows available Correct the parent, site, and LAN prefix values to rebuild this allocation artifact.
{{ cell }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

IPv6 planning is less about conserving individual addresses than choosing repeatable prefix boundaries that routing, DNS, firewall, and documentation systems can all read the same way. A parent block has to summarize cleanly, each site or tenant needs enough equal child prefixes, and each access network usually needs a /64 so hosts can use normal IPv6 address configuration.

Prefix length tells how many leftmost bits are fixed. A /48 parent has 48 routing bits fixed and leaves 80 bits to divide. If that parent is carved into /56 site blocks, eight extra bits create 256 equal site prefixes. If each site is then carved into /64 LANs, another eight bits create 256 routed LAN prefixes per site. The remaining 64 bits belong to interface identifiers inside each LAN.

IPv6 prefix planning boundary questions
Boundary question	What the bits control	Risk when undersized
Parent to site	How many equal site, branch, customer, region, or tenant prefixes can be allocated.	Growth forces a second aggregate or a renumbering project.
Site to LAN	How many VLANs, VRFs, service zones, and routed segments fit inside each site.	Dense sites exhaust local slots while other sites still have spare space.
LAN to interface ID	How many bits remain for host addressing inside the routed segment.	Non-`/64` access LANs can conflict with SLAAC and other 64-bit interface-ID assumptions.

The bit budget should match the jobs those prefixes perform. Aggregates should be large enough to summarize routes. Site prefixes should leave room for real organizational growth. LAN prefixes should match the host-addressing method used on the link. A common mistake is to treat IPv6 like IPv4 conservation work and make access LANs longer than /64 just to save addresses. That can break assumptions in stateless address configuration, multicast mechanisms, and operating-system behavior that grew around a 64-bit interface identifier.

IPv6 address bits divided into parent route, site ID, LAN ID, and interface ID sections

Several boundaries matter beyond raw math. Prefixes that land on four-bit hexadecimal nibbles are easier to document and delegate in reverse DNS because each nibble maps to one hex digit. Public global unicast space, unique local address space, link-local space, and the 2001:db8::/32 documentation range also carry different operational meanings. A clean-looking hierarchy still needs the right source prefix for the environment.

Prefix planning answers a capacity question, not an authority question. It can show that a parent block can be divided into the requested number of site and LAN slots, but it cannot prove that the parent was delegated, routed, filtered correctly, or accepted by every host stack on a non-standard LAN boundary.

How to Use This Tool:

Work from the top of the hierarchy down. The parent block sets the space available, the site boundary decides how many equal site prefixes exist, and the LAN boundary decides how many routed segments fit inside each site.

Enter Assigned parent prefix in IPv6 CIDR notation, such as 2001:db8:1200::/48 or a unique local prefix such as fd12:3456:789a::/48. If host bits are present, the result uses the normalized network boundary.
Set Site prefix length. Use the number field for exact values or the slider for exploration. The summary and visual update with the current site-slot count.
Set LAN prefix length. A /64 value is the normal access-LAN target. Shorter values usually mean aggregates, while longer values need a deliberate infrastructure reason.
Enter Sites needed and LANs per site needed. The summary badges show whether each demand count fits the selected hierarchy.
Check any warning or error message before using result rows. Prefix-order errors block the result; warnings call out normalization, non-/64 LANs, non-nibble boundaries, and out-of-range ledger starts.
Use Prefix Fit Metrics for capacity, Allocation Guidance for the next correction, Site Prefix Ledger for allocation rows, Prefix Bit Budget for the 128-bit split, and Plan Inputs or JSON when you need an audit trail.
Open Advanced when the ledger needs a later Ledger start site index, a different Ledger preview rows limit, or labels such as Branch, Region, Tenant, or POP.

When Capacity shortfall appears, adjust the relevant prefix length first. Copying ledger rows before the fit checks pass can preserve a plan that cannot actually hold the requested site or LAN count.

Interpreting Results:

The main number is the count of equal site prefixes available from the normalized parent. Read it together with LAN capacity per site, Interface ID bits per LAN, and the badges for site fit, LAN fit, /64 status, nibble alignment, and parent prefix scope.

Site fit means the parent has enough site slots for Sites needed. A shortfall means the site prefix is too long, the parent is too small, or the demand count needs to change.
LANs per site fit means each site block can hold LANs per site needed at the selected LAN prefix length.
Access segment boundary is a standards and operations warning, not just a capacity label. Non-/64 segments can be valid for loopbacks, point-to-point links, aggregates, or controlled infrastructure, but they should not be used casually for ordinary client LANs.
Hex nibble alignment points to documentation and reverse-DNS friction. The CIDR math still works, but a boundary such as /57 is harder to read and delegate than /56 or /60.
Parent prefix scope is a sanity check. A documentation prefix should not be copied into production, unique local prefixes need local routing policy, and link-local prefixes are not a site-wide addressing plan.

A passing result is still a planning draft. Confirm the normalized parent CIDR against the real delegation, routing policy, DNS plan, and host-addressing method before treating the ledger as an operational record.

Technical Details:

IPv6 prefix planning is a deterministic bit-allocation problem. The parent prefix fixes the routed aggregate, the site prefix adds site identifier bits, the LAN prefix adds routed-segment bits inside each site, and the rest of the 128-bit address remains available for interface identifiers. Moving a prefix boundary by one bit doubles or halves the number of equal child prefixes at that level.

The child relationship is valid only when prefix lengths move from shorter to longer values. A site prefix must be equal to or longer than the parent prefix. A LAN prefix must be equal to or longer than the site prefix. Once that order holds, capacity follows directly from powers of two.

Formula Core:

The capacity equations use prefix-length differences as bit counts. Each added bit creates two choices, so each level is a power-of-two count.

\begin{array}{lcl} S_{b} & = & S_{p} - P_{p} \\ S_{c} & = & 2^{S_{b}} \\ L_{b} & = & L_{p} - S_{p} \\ L_{c} & = & 2^{L_{b}} \\ I_{b} & = & 128 - L_{p} \end{array}

IPv6 prefix formula symbols and meanings
Symbol	Meaning	Displayed result
`Pp`	Parent prefix length.	`Parent prefix` after normalization.
`Sp` and `Sb`	Site prefix length and the site ID bits added after the parent.	`Site prefix capacity` and `Site utilization`.
`Lp` and `Lb`	LAN prefix length and the LAN ID bits added inside each site.	`LAN capacity per site` and `LAN utilization per site`.
`Ib`	Remaining interface identifier bits inside each LAN prefix.	`Interface ID bits per LAN`.

For a /48 parent, /56 site prefix, and /64 LAN prefix, the site ID width is 56 - 48 = 8 bits, so the parent contains 2^8 = 256 site prefixes. The LAN ID width is 64 - 56 = 8 bits, so each site contains 2^8 = 256 LAN prefixes. The interface ID width is 128 - 64 = 64 bits.

Ledger rows are built by stepping through zero-based site slots. Each site row starts at the normalized parent network plus the site index multiplied by the site-prefix block size. The first LAN is the site base at the selected LAN prefix. The last LAN is the same site base plus the final LAN-sized slot inside that site.

IPv6 prefix plan validation and warning rules
Condition	Rule	Planning meaning
Valid CIDR parent	IPv6 address plus a whole-number prefix length from `0` to `128`.	Invalid hextets, multiple `::` markers, invalid embedded IPv4 tails, and zone identifiers are rejected.
Prefix order	`parent prefix <= site prefix <= LAN prefix`.	Broken hierarchy blocks capacity rows because a child prefix cannot be shorter than its parent.
Site fit	`Sites needed <= 2^(site prefix - parent prefix)`.	The site boundary has enough equal slots for the requested sites.
LAN fit	`LANs per site needed <= 2^(LAN prefix - site prefix)`.	Each site has enough LAN-sized routed segments.
Access LAN default	`LAN prefix = /64`.	Longer or shorter values are calculated, but they are flagged for review.
Nibble alignment	Parent, site, and LAN prefix lengths divisible by `4`.	Hexadecimal notation and `ip6.arpa` reverse-DNS delegation stay easier to read.

Address text is normalized for comparison and display. Compressed zero runs, lowercase hexadecimal, and cleared host bits make the same prefix easier to compare across rows, but the normalized text does not change who owns or routes the block.

Limitations and Privacy Notes:

The calculation is local capacity math from the values you enter. It does not perform a routing lookup, registry lookup, device compatibility test, or policy review.

A documentation prefix such as 2001:db8::/32 is useful for examples but should not appear in a production plan.
A unique local prefix can be valid for private routing, but it still needs local routing, filtering, and DNS decisions.
A non-/64 LAN result needs host-addressing proof outside the calculator before it is used for ordinary devices.
Copied rows, downloaded files, screenshots, and shared URLs can expose entered prefixes and planning counts. Treat production addressing plans as operational information.

Worked Examples:

A common enterprise draft starts with 2001:db8:1200::/48, sets Site prefix length to /56, and keeps LAN prefix length at /64. Prefix Fit Metrics shows 256 site prefixes and 256 LAN prefixes per site. With 120 sites and 80 LANs per site, Allocation Guidance reports that both demand counts fit and the Prefix Bit Budget keeps 64 interface ID bits.

A smaller unique local plan might use fd12:3456:789a::/48 with a /52 site prefix and a /64 LAN prefix. That gives 16 site prefixes and 4096 LAN prefixes per site. If Sites needed is 18, Site fit reports Capacity shortfall even though each site has plenty of LAN room. The correction is to use a shorter site prefix such as /51, choose a larger parent block, or reduce the site count.

An infrastructure-only draft with /72 LAN prefixes can produce large LAN counts, but Access segment boundary reports Using /72. Treat that as a special-purpose result for manually managed links, loopbacks, or aggregates, not as a default client subnet plan.

If someone enters 2001:db8:1200:1234::/48, the parent row is normalized to 2001:db8:1200::/48. Use the normalized parent shown in Prefix Fit Metrics before comparing the ledger to routing documentation.

FAQ:

Why does the tool warn about LAN prefixes longer than /64?

Many IPv6 host and link mechanisms assume a 64-bit interface identifier. Longer LAN prefixes may be valid in controlled infrastructure cases, but they should be reviewed before being used for normal access networks.

Why did my parent prefix change after I typed it?

CIDR planning uses the network boundary. If the address contains host bits below the parent prefix length, they are cleared and the normalized parent is shown in the metrics and outputs.

Can I plan with a unique local address prefix?

Yes. Prefixes in fc00::/7 are labeled as unique local scope. The capacity math is the same, but routing, filtering, DNS, and any inter-site use remain local design decisions.

What should I change when site fit fails?

Use a shorter Site prefix length, start from a larger parent block, or reduce Sites needed. Allocation Guidance shows the minimum site prefix needed for the entered demand.

Why does nibble alignment matter?

IPv6 reverse DNS represents addresses one hexadecimal nibble at a time. Prefix lengths divisible by four line up with hex digits, which makes allocation maps and reverse-DNS delegation easier to review.

Glossary:

Parent prefix: The delegated or chosen IPv6 CIDR block being divided into smaller prefixes.
Site prefix: The equal allocation size assigned to each site, branch, tenant, region, campus, or POP.
LAN prefix: The routed segment size inside each site prefix.
Interface identifier: The remaining address bits used to identify interfaces within a LAN prefix.
Nibble boundary: A prefix length divisible by four, matching one hexadecimal digit.
Normalized parent: The parent CIDR after host bits below the prefix boundary have been cleared.
Ledger start site index: The zero-based site slot where the visible allocation ledger begins.

References:

RFC 4291: IP Version 6 Addressing Architecture, RFC Editor, February 2006.
RFC 6177: IPv6 Address Assignment to End Sites, RFC Editor, March 2011.
RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing, RFC Editor, January 2015.
RFC 3596: DNS Extensions to Support IP Version 6, RFC Editor, October 2003.
RFC 5952: A Recommendation for IPv6 Address Text Representation, RFC Editor, August 2010.
RFC 3849: IPv6 Address Prefix Reserved for Documentation, RFC Editor, July 2004.
RFC 4193: Unique Local IPv6 Unicast Addresses, RFC Editor, October 2005.
IPv6 Special-Purpose Address Space, IANA.