description: An IPv6 (and IPv4) prefix arithmetic cheat sheet for isp6 members: how many /48s, /56s, and /64s fit inside any prefix, with worked examples for sizing an allocation.

The isp6 Prefix Chart

Audience: network engineers, architects, and on-call operators who need to know, at a glance, how many /48s, /56s, or /64s fit inside a given prefix, or how many host addresses sit beneath an IPv4 mask. A reference card for the question that comes up every time you size an allocation, design an aggregation tier, or write a firewall rule. Pairs with Planning Your isp6 Allocation for the full sizing arc and IPv6 in the Wild: A Field Reference for the classification cheat sheet.

Last updated: May 2026

1. Introduction

Address-plan work in IPv6, and aggregation work in IPv4, keeps coming back to the same arithmetic. How many /64 subnets does a /52 contain? If we hand a branch office a /56, how many /48-equivalent customer assignments could we have made instead? Does a /29 give us four /31 point-to-point links or eight?

The answer is always a power of two, but the cognitive load of computing it on the fly is a tax on the engineer doing the planning. This chart removes that tax. Pin it to the wall, bookmark it on a phone, paste it into a runbook. It exists so that nobody on the isp6 team or in an isp6 member organisation has to do the binary arithmetic by hand at 03:00.

The numbers themselves are not isp6-specific; they are properties of the IPv6 addressing architecture. What is isp6-specific is the boundary at which they matter most: every isp6 allocation starts at a /48 or a /44, every customer subnet ends at a /64, and the design space inside that range is exactly what the table below makes legible.

2. How to Read This Chart

Each row in the IPv6 chart represents a single prefix length. The three count columns answer the same question for different sub-prefix sizes:

Inside one prefix of length /N, how many sub-prefixes of length /48, /56, or /64 fit?

The fourth column, Host bits, is the number of bits below the prefix: 128 − N. It is the size of the host (or sub-allocation) space available to whoever holds the prefix, expressed as a bit count rather than as a power.

A blank cell means the relationship is undefined: a /49 cannot contain any /48s because /48 is shorter than /49. The chart starts at /24 (the largest aggregation seen at internet scale today, used by RIRs and very large carriers) and ends at /64 (the architectural floor for any subnet that supports SLAAC).

Reading direction. Going down the chart, prefixes get longer and blocks get smaller: each step of four bits divides the count by sixteen. Going up, each step of four bits multiplies the count by sixteen. This is the nibble discipline at work; the same discipline that Planning Your isp6 Allocation covers in depth.

3. The IPv6 Prefix Chart

The bold rows are the prefix lengths an isp6 member encounters most often:

• /44: the larger isp6 PA allocation. 16 × /48.
• /48: the standard isp6 PA allocation. 65,536 × /64.
• /56: the customary residential or branch-office assignment inside a larger allocation. 256 × /64.
• /64: the architectural subnet boundary. One link, one /64, no exceptions outside the /127 point-to-point convention.

Anything below /64 is not "subnetting" in the usual sense. It is reaching into the Interface ID, which SLAAC and Privacy Extensions both expect to be the full 64 bits. The chart stops at /64 deliberately.

4. The IPv4 CIDR Chart

For completeness, and because most isp6 deployments are dual-stack during transition, the IPv4 CIDR chart in the same format. Read it the same way: inside a prefix of length /N, how many usable host addresses are there? The subnet-mask column is the legacy dotted-decimal form of the same prefix.

The host-address column is the raw count of addresses in the prefix, and it does not subtract the network and broadcast addresses, so the usable-host count for a /24 is 254 rather than 256, and for a /30 is 2 rather than 4. The distinction matters when you are sizing point-to-point links.

5. Notation Used in the Charts

The single-letter suffixes in the count columns are powers of two, not the SI decimal multipliers they superficially resemble:

A "1 T" entry in the IPv6 chart is therefore a little over a trillion /64 subnets, not the SI trillion. This is the same convention IPv4 has always used for address counts and the convention RIRs, RFCs, and IPAM tooling all follow.

6. Worked Examples

6.1 Sizing a Standard isp6 PA Allocation

A typical isp6 enterprise member receives a /48. Reading the row:

• 1 × /48 (the allocation itself).
• 256 × /56, useful if the customer hands /56 blocks to branch offices.
• 64 K × /64, the underlying subnet count, which is the figure that matters for VLAN, VXLAN, and segment planning.

A multi-region or multi-cloud member typically takes a /44 instead:

• 16 × /48, one /48 per region or per major business unit, with room to grow.
• 4 K × /56.
• 1 M × /64.

The estimation procedure for choosing between the two is in Phase 1 of the planning guide.

6.2 Carving a /48 Into Branch-Office /56s

A regional bank with a /48 wants to give every branch office its own /56. Reading the /48 row's /56s contained column: 256. The bank can address up to 256 branch offices and still hand each one a /56 large enough to subdivide into 256 internal /64 VLANs.

If the bank's branch count grows beyond 256, the next nibble jumps it to 4 K branches via a /44. There is no need to consider any prefix length in between, because the nibble discipline keeps the routing table aggregation clean.

6.3 RIR-Scale Aggregation

The RIPE NCC holds 2a00::/12 and 2a10::/12. Reading the /12 row would give rougly 16 G × /48, but the chart starts at /24, because numbers larger than that exceed any operator's planning horizon. For the sub-allocations RIPE NCC actually issues to LIRs, the relevant rows are /29 (the maximum allocation without additional justification) and /32 (the minimum):

A /32 allocation contains 65,536 /48 customer assignments, enough to make a /48-per-customer LIR business viable for a long time.

6.4 IPv4: Sizing a /29 for Point-to-Point Links

A pair of cloud-hosted firewalls needs four point-to-point /31 links between them. The IPv4 chart says a /29 contains 8 addresses, which is 4 × /31. A /29 is exactly the right size: no waste, no shortfall.

If a fifth link is later required, the team must allocate a fresh prefix; there is no way to "extend" the /29 in place without renumbering.

7. Where This Fits in the Knowledge Base

This article is a reference card. It is intentionally short on prose and long on numbers, and is meant to be linked-to rather than read end-to-end. The full context behind the numbers lives elsewhere in the knowledge base:

• The protocol foundations. Designing the Next Internet: An Introduction to IPv6: why /64 is load-bearing, why nibble alignment matters, and how the prefix / Interface ID split underlies every figure in this chart.
• Estimating and structuring an allocation. Planning Your isp6 Allocation: the three-phase estimate, procure, implement arc that turns the figures here into a concrete addressing plan.
• Classifying an address in the wild. IPv6 in the Wild: A Field Reference: the prefix-spotting matrix and the four-bit decoder for parsing an address from a log line at speed.
• Avoiding IPv4 reflexes. Stop Thinking in IPv4: including why "subnet smaller than /64 to save space" is a misconception that breaks SLAAC.

8. References

This document is provided for informational purposes. Protocol specifications and cloud provider behaviour are subject to change. Consult the linked RFCs and vendor documentation for authoritative, up-to-date information before making architectural decisions.