Planning Your isp6 Allocation

Audience: isp6 members and prospective members in the planning stage — network architects deciding between a /48 and a /44, and those structuring subnets inside an allocation they already hold. Assumes familiarity with IPv6 fundamentals; if the /64 boundary, address scopes, or SLAAC are new concepts, read Designing the Next Internet: An Introduction to IPv6 first. Complements the operational guidance in Stop Thinking in IPv4 and the cloud-specific BYOIP guides.

Last updated: April 2026

Table of Contents

1. Introduction
2. The Mentality Shift: From Scarcity to Routing Optimisation
3. Address Anatomy and the Nibble
4. Phase 1: Estimate Your Needs
5. Phase 2: Choose Your isp6 Allocation
6. Phase 3: Implement With IPAM
7. Future-Proofing With the Bisection Method
8. Hardening the Hierarchy
9. The Architect's Checklist
10. What isp6 Handles vs. What You Plan
11. References

1. Introduction

Most engineering effort in IPv6 deployment happens after the address plan is in place — BYOIP to a cloud provider, firewall configuration, dual-stack testing. But the shape of everything that follows is determined by decisions made in the first week: how many bits you budget at each tier of the hierarchy, where you draw the nibble boundaries, which block you reserve for core infrastructure, and whether you request a /48 or a /44 from isp6.

Get those decisions right and the rest of the work is mechanical. Get them wrong and you will spend the next three years routing around an addressing plan that fights you at every turn — collapsed aggregation, unreadable firewall rules, reverse-DNS zones that nobody wants to maintain, and customers or environments that cannot grow without renumbering.

This article is the planning companion to the rest of the knowledge base. The misconceptions guide explains how to think about IPv6 once you are deploying; this one explains how to size and structure what you deploy into. It is written for isp6 members and follows a three-phase arc: estimate, procure, implement.

flowchart LR
    P1["Phase 1<br><b>Estimate</b><br>Map the hierarchy.<br>Count entities.<br>Sum the bits."]
    P2["Phase 2<br><b>Procure</b><br>Choose /48 or /44<br>from isp6."]
    P3["Phase 3<br><b>Implement</b><br>IPAM, bisection,<br>harden p2p and loopbacks."]
    P1 --> P2 --> P3

2. The Mentality Shift: From Scarcity to Routing Optimisation

Address planning in IPv4 is an exercise in conservation. A /24 gives you 254 hosts; a /22 aggregates four /24s; anything larger is expensive and hard to justify. The engineer's instinct is to subnet as tightly as possible — /29 for a six-host segment, /30 for a point-to-point — because every address is a resource you will eventually answer for.

IPv6 inverts that logic. The goal of an IPv6 address plan is not to conserve addresses but to produce a clean routing topology, a readable reverse-DNS tree, and room for future growth without renumbering. The arithmetic is different, and so is the discipline.

The headline figure is worth internalising: the IANA has allocated only a small fraction of the 2000::/3 global unicast range, and within it isp6 alone has access to enough /48 blocks to assign one to every large enterprise on Earth several times over. A /48 allocation contains 65,536 /64 subnets; a /44 contains 16 /48 blocks. These are not figures that will run out.

What does run out, if you let it, is the human discipline that keeps the hierarchy legible. That is the real resource being managed.

3. Address Anatomy and the Nibble

Before the estimation work, a brief refresher on the building block.

An IPv6 address is 128 bits, written as eight groups of four hexadecimal characters separated by colons:

2001:0db8:acad:0001:0000:0000:0000:0001
└────────── 64-bit prefix ──────────┘└─── 64-bit interface ID ───┘

Each hex character represents exactly 4 bits — a nibble. Every meaningful boundary in an IPv6 address plan should fall on a nibble boundary, which means prefix lengths that are multiples of 4:

There are two legitimate reasons not to align to a nibble:

• /127 on point-to-point inter-router links (RFC 6164) — a security-driven exception covered in §8.
• /128 on loopbacks and anycast addresses (RFC 4291).

Everything else — every subnet ID, every aggregation boundary, every firewall summary — should sit on a 4-bit line. The cost of breaking this rule is paid every day in reverse-DNS zone delegation, route aggregation, and the cognitive load of reading a firewall rule that spans two hex characters.

When a Prefix Falls Mid-Nibble

Your own address plan should align to nibble boundaries — but you will encounter non-nibble prefixes in the wild. Transit providers, cloud platforms, and some RIR allocations use prefix lengths like /29, /33, /47, or /93 that slice through the middle of a hexadecimal character. When this happens, you must drop to binary to find the exact network boundary.

When a prefix length is a multiple of 4, the boundary falls cleanly at the end of a hex character — no binary work is required. A /56, for example, divides the address after the 14th hex character (56 / 4 = 14). You can read the network prefix directly from the hex notation.

When a prefix length is not a multiple of 4, the boundary bisects a single hex character and you must decompose that character into its four binary bits to determine which bits belong to the network and which to the host.

Worked example — finding the network address for …:000b::/93:

The prefix length /93 is not a multiple of 4. To find which hex character the boundary falls inside:

93 ÷ 4 = 23 remainder 1

The boundary falls after 23 complete hex characters, then 1 bit into the 24th. The 24th hex character in this address is b.

The network address changes from …:000b::/93 to …:0008::/93.

flowchart LR
    A["Hex b<br>Decimal 11"] --> b["Binary<br>1 0 1 1"]
    B["Hex b"] --> C["Split at /93 boundary<br><strong>1</strong> · 0 1 1"]
    C --> D["Zero host bits<br><strong>1</strong> · 0 0 0"]
    D --> E["Binary<br>1 0 0 0"] --> F["Hex 8<br>Decimal 8"]

This technique applies whenever you receive a prefix at a non-nibble boundary from an upstream provider or need to verify a route filter for a non-standard prefix length. Inside your own allocation, design on nibble boundaries and you will never need to reach for it — but when you encounter one in the wild, this five-step process resolves it deterministically. For the foundational hex-to-binary conversion table, see The Anatomy of a 128-Bit Address in the introduction guide.

4. Phase 1: Estimate Your Needs

The estimation phase produces a single number: the total number of bits you need below your allocation to reach a /64 at the leaf. That number determines whether a /48 or a /44 from isp6 is the right starting point.

4.1 Map the Hierarchy

Most organisations fit one of three archetypes:

flowchart TD
    subgraph isp["ISP / Service Provider"]
        ISP1["Regions / Cities"] --> ISP2["Points of Presence"] --> ISP3["End Customers"]
    end
    subgraph uni["University / Campus"]
        U1["Campuses"] --> U2["Buildings"] --> U3["Departments / VLANs"]
    end
    subgraph ent["Enterprise"]
        E1["Branches / HQ"] --> E2["Service Types"] --> E3["Departments / VLANs"]
    end

Pick the archetype that matches your organisation and draw the tree. Keep it rough — this is a sizing exercise, not an engineering diagram. For each tier you only need to answer one question: what is the largest entity count I will ever need at this level?

4.2 The Estimation Matrix

To size a tier, round your largest entity count up to the next tier in the bit-to-entity table, and take the corresponding bit count:

Rounding up is the whole trick. If you operate in 10 regions, you reserve 4 bits for the region tier (up to 16). If the largest region has 50 PoPs, you reserve 8 bits for the PoP tier (up to 256). If the largest PoP serves 2,700 customers, you reserve 12 bits for the customer tier (up to 4,096). The bit budgets are based on the largest entity at each level; smaller entities automatically fit.

4.3 Sum the Bits

Add the bit budgets for every tier above /64. The result is the number of bits between your allocation and the per-subnet /64, which tells you whether a /48 or a /44 from isp6 is the right choice:

• /48 gives 16 bits above /64 (64 − 48 = 16).
• /44 gives 20 bits above /64 (64 − 44 = 20).

A tier budget that sums to 16 bits or fewer fits a /48; 17–20 bits needs a /44. Anything beyond 20 bits is almost always a miscount — re-examine whether every tier in your hierarchy truly needs its own bit budget, or whether two tiers can be collapsed. A plan that appears to require more than 20 bits is a signal to tighten the hierarchy, not to look beyond isp6's /48 and /44.

4.4 Two Worked Examples

Enterprise with three AWS regions and four business units:

A /48 gives 16 bits above /64. 12 bits are consumed, 4 bits remain for growth. Request a /48 from isp6.

Global enterprise with 12 regions, two clouds, and strict segregation of prod/stage/dev across 30+ accounts:

16 bits above /64 is exactly a /48 with zero growth headroom. The prudent choice is a /44 (20 bits above /64), which leaves 4 bits — a 16× multiplier — for new regions, clouds, or a restructuring event. Request a /44 from isp6.

5. Phase 2: Choose Your isp6 Allocation

5.1 Portable PA: Your Allocation Moves With You

Your allocation from isp6 is Provider Assigned address space — with a crucial difference from the PA that most ISPs offer: it is portable. Traditional PA ties your prefix to a single upstream provider's routing, and announcing it from anywhere else gets the route filtered. isp6-issued PA can be announced from AWS, Azure, Google Cloud, a colocation facility, on-prem, or several of these simultaneously via BYOIP. You own the cryptographic proof-of-ownership key; isp6 handles the inet6num, route6, ROA, and reverse DNS delegation behind the scenes. The prefix moves with you, not with your provider.

The planning question for isp6 customers is therefore not "where do I source address space from?" but simply: how much space do I need?

5.2 /48 or /44?

Work through the Phase 1 arithmetic honestly before deciding. A /48 is adequate for most enterprises and leaves room for a realistic hierarchy; a /44 is the right choice whenever the plan has a per-region or per-account tier that itself will hold hundreds of subnets. Upgrading later is possible but not free — the simpler outcome is to size correctly up front.

5.3 Never Delegate a /64 to a Subnet-Capable Downstream

If you sub-delegate pieces of your isp6 allocation to internal business units, subsidiaries, or downstream customers, follow the same /48 / /56 / /60 / /64 hierarchy that isp6 applies when allocating to you:

Do not delegate a /64 to anyone who may ever need to create a second subnet. A /64 is a leaf, not a block — it cannot be split while preserving SLAAC. If in doubt, give a /56 (still only 256 /64 subnets, but enough for any realistic small site) and sleep soundly.

6. Phase 3: Implement With IPAM

6.1 Why Spreadsheets Fail

A /48 contains 65,536 /64 subnets. A /44 contains just over a million. The density and cascading hierarchy make manual tracking in a spreadsheet or wiki table mathematically and operationally untenable after the first few months of growth. Common failure modes:

• Collision on delegation — two engineers allocate the same /56 to different teams because the tracking sheet was stale.
• Aggregation drift — ad-hoc assignments drift off nibble boundaries, producing routing tables that no longer summarise.
• Orphaned blocks — subnets allocated but never deployed, undetectable without a reconciliation pass against the live network.
• No source of truth for reverse DNS — the PTR record structure falls out of sync with the allocation table.

The IPv6 discipline is to run a dedicated DDI/IPAM platform (NetBox, BlueCat, EfficientIP, Infoblox, Men&Mice, phpIPAM, or equivalent) from day one. The platform owns the hierarchy; humans query it for the next available block at a given prefix length, and the platform guarantees alignment and uniqueness.

6.2 Avoid the Mapping Trap

Do not encode legacy IPv4 addresses inside the IPv6 host portion to preserve old numbering — the IPv4 octet boundary is 8 bits, IPv6 is designed around 4-bit nibbles, and forcing the former into the latter breaks reverse-DNS delegation and defeats route aggregation. The full treatment, including the impact on firewall rule readability and worked before/after examples, lives in Avoid the Mapping Trap in the misconceptions guide — read it there once you have your own hierarchy on paper, and design the IPv6 scheme on its own terms.

6.3 Respect the /64 Multi-Host Boundary

Every multi-host LAN or VLAN must be configured as a /64. Stateless Address Autoconfiguration (SLAAC) generates the 64-bit Interface ID from the host's MAC address (EUI-64) or a randomised identifier (Privacy Extensions, RFC 8981) and combines it with the 64-bit prefix advertised by the router. Subnetting past /64 on a multi-host link — for example, carving a /80 to "save space" — breaks SLAAC, breaks Duplicate Address Detection, and degrades Neighbor Discovery performance.

This rule is worth stating plainly because the temptation to tighten it persists:

Every multi-host link gets a /64. Full stop. The only exceptions are point-to-point inter-router links (/127) and loopbacks (/128).

See Microsegment Your Subnets in the misconceptions guide for the full list of what breaks when you violate the /64 rule.

7. Future-Proofing With the Bisection Method

The order in which you hand out subnets matters. Sequential assignment is the naive default:

Customer A → :1::/56
Customer B → :2::/56
Customer C → :3::/56
Customer D → :4::/56

It works until Customer A asks for more space. Because Customer B now sits immediately adjacent, Customer A cannot grow contiguously — they have to accept a discontiguous second block, which fragments the routing table and the reverse-DNS tree.

The bisection method allocates from the middle of the available range instead:

flowchart LR
    subgraph seq["Sequential (avoid)"]
        S1["1"] --- S2["2"] --- S3["3"] --- S4["4"]
        SX["Customer A blocked<br>from growing past :1::/56"]
    end
    subgraph bis["Bisection (best practice)"]
        B1["1"] -.- B2["..."] -.- B3["5"] -.- B4["..."] -.- B5["9"] -.- B6["..."] -.- B7["d"]
        BY["Every customer has<br>contiguous room to grow"]
    end

The rule is simple: when making an initial assignment, skip blocks so that any single customer can double or quadruple in place without colliding with a neighbour. The first customer gets :1::/56, the second gets :9::/56, the third gets :5::/56, and so on — each sitting in the middle of a large unused range. When a customer needs more space, the surrounding blocks are still free.

Reserve the 0th Subnet for Core Infrastructure

Regardless of how you bisect the rest of the space, keep the first block of any allocation off-limits for customer or workload use. Reserve …:0::/64 (within a /48) or the first /48 (within a /44) for:

• Router and switch loopbacks (/128s)
• Point-to-point inter-router links (/127s)
• Management and out-of-band networks
• Shared services that every downstream subnet may need to reach

Keeping core infrastructure at a predictable, low-numbered prefix makes monitoring scopes, route filters, and firewall allow-lists easier to write — and it means the "interesting" part of the allocation (:1::/64 onwards) matches the bisection scheme that appears in logs and dashboards.

8. Hardening the Hierarchy

Two implementation details carry disproportionate security weight.

8.1 /127 on Point-to-Point Inter-Router Links

Numbering a point-to-point link as a full /64 exposes roughly 18 quintillion unconfigured addresses on each router interface. An attacker who can send traffic toward the link (directly or via a compromised host elsewhere in your network) can force the router into perpetual Layer 2 resolution by pinging random addresses in the range. Each unresolved destination consumes a neighbour cache entry and triggers an NS flood, and the cache fills faster than entries expire. This is the Neighbor Cache Exhaustion attack class (RFC 6583).

flowchart LR
    A["Attacker"] -->|"Ping 18 quintillion<br>random /64 addresses"| R["Router interface<br>(unconfigured /64)"]
    R -->|"NS flood for<br>every destination"| R
    R -.->|"Cache exhausted<br>Legitimate traffic stalls"| X["Neighbour cache<br>overflow"]

The mitigation is to configure /127 on the interfaces — exactly two addresses, one per end. There is nothing for the attacker to resolve, and the attack surface disappears. Reserve a full /64 for the link in your IPAM (for documentation and aggregation), but configure /127 on the live interfaces:

Reserved in IPAM:  2001:db8:acad:ff00::/64   (link rtr-a ↔ rtr-b)
Configured on rtr-a interface:  2001:db8:acad:ff00::0/127
Configured on rtr-b interface:  2001:db8:acad:ff00::1/127

Use /126 only if a legacy vendor platform does not support /127 correctly.

8.2 /128 on Loopbacks

Each router's loopback interface receives a single /128 address. Loopbacks are the stable identity of the device for BGP peering, management, and monitoring — they do not need to sit inside a larger prefix, and giving them one would waste an entire /64. Carve loopbacks from a dedicated block inside the 0th subnet reserved in §7.

8.3 A Minimal Core Infrastructure Layout

Inside the reserved 0th subnet, a reasonable template:

Every other block (:1::/64 onwards, or :1000::/48 onwards in a /44) is available for workloads and is allocated using the bisection method.

9. The Architect's Checklist

A one-page summary to review before locking in an allocation plan:

If every row is a clear yes, the plan will survive contact with growth, audits, and the inevitable re-org.

10. What isp6 Handles vs. What You Plan

Planning a clean hierarchy is the architect's job. Registering and maintaining it at the RIR is isp6's.

The split is deliberate. The parts of the work that need to be done once per allocation and carry compliance obligations — RIR registration, ROA propagation, reverse-DNS delegation — sit with isp6. The parts that are specific to your organisation's structure and that you will revise as it changes — the hierarchy, the IPAM, the BYOIP — stay with you.

11. References

RFCs

RIPE NCC documentation

• RIPE NCC IPv6 Address Allocation and Assignment Policy (ripe-738)
• RIPE NCC IPv6 Address Space Policy

Related isp6 knowledge base articles

• Designing the Next Internet: An Introduction to IPv6 — protocol-level primer covering address anatomy, scopes, multicast, and SLAAC; the conceptual foundation this planning guide builds on
• Stop Thinking in IPv4: Misconceptions That Sabotage Your IPv6 Deployment — operational and mental-model complement to this planning guide
• Building an IPv6 Integrated Project Team — the organisational context in which address planning actually gets done
• Bring Your Own IPv6 to AWS
• Bring Your Own IPv6 to Azure
• Bring Your Own IPv6 to Google Cloud

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.