📜 IPv6 CIDR: Why CIDR Means Something Different Once You're Past 32 Bits

CIDR Was Invented to Solve a Problem IPv6 Doesn't Have

Classless Inter-Domain Routing, defined in 1993 under RFC 1519 (later obsoleted and refined by RFC 4632), existed to solve a specific IPv4 crisis: the original classful A/B/C addressing system wasted enormous amounts of address space (a Class B allocation gave you 65,536 addresses whether you needed 300 or 60,000) while simultaneously bloating the global routing table with inefficiently-sized announcements. CIDR fixed both problems by letting network operators define arbitrary prefix boundaries instead of fixed class sizes. IPv6 was designed from the ground up with CIDR-style variable prefix lengths as the only addressing model — there was never a classful IPv6 system to retrofit around. This matters more than it sounds: it means IPv6 CIDR isn't a patch bolted onto a legacy system, it's the native design, and the philosophy behind how prefixes get allocated reflects that from the start.

Same Notation, Different Numbers

The slash notation itself — address/prefix-length — is identical in concept between IPv4 and IPv6: the number after the slash indicates how many leading bits identify the network. But the actual numbers you'll encounter differ enormously in practice. IPv4 CIDR blocks commonly range from /8 (16.7 million addresses) down to /30 (4 addresses) — a fairly narrow practical range given genuine address scarcity. IPv6 CIDR blocks span from /12-ish RIR mega-allocations down to /64 standard subnets and /128 single hosts, with the vast majority of meaningful allocation activity happening in a completely different numeric range (/32 to /64) than IPv4 CIDR ever needed to operate in.

Route Aggregation: Still the Point, Even With Abundant Addresses

It would be easy to assume that because IPv6 has no address scarcity problem, CIDR's route-aggregation benefit doesn't matter anymore. That's incorrect — global routing table size is an operational concern independent of whether the underlying address space is scarce, because every entry in the global BGP table costs memory and processing on every backbone router that carries a full table. IPv6's hierarchical allocation model (RIR holds large blocks, ISPs get /32-ish allocations, customers get /48 or /56 sub-allocations) is specifically structured so that an ISP can announce a single aggregate route for its entire customer base rather than one route per customer — exactly the same aggregation principle CIDR introduced for IPv4, just applied to a hierarchy with much more headroom at each layer.

Worked Example: Aggregation in Practice

An ISP holding 2001:db8::/32 and assigning /48 blocks to 500 business customers doesn't need to announce 500 separate /48 routes to the rest of the internet — it announces the single aggregate 2001:db8::/32 route, and internal routing within the ISP's own network handles directing traffic to the correct customer /48. Only if a customer needs independent internet routing (multi-homing to a different upstream provider, for instance) would that customer's /48 need its own separate global route announcement, breaking the clean aggregation for that one case — a well-understood and accepted trade-off, not a design flaw.

CIDR Comparison: Aggregation Efficiency by Allocation Pattern

Real-World Scenarios by Deployment Context

Advantages of CIDR-Native Design in IPv6

• No legacy classful system to work around, unlike IPv4's 1993 retrofit — every allocation decision starts from a clean, variable-length prefix model.
• Hierarchy from RIR to ISP to customer maps naturally onto nested CIDR blocks at every layer, without the class-boundary awkwardness IPv4 occasionally still shows in legacy configurations.
• Room for generous, human-readable prefix boundaries (nibble-aligned /48, /56, /64) without meaningfully impacting routing table efficiency, since IPv6's scale absorbs that generosity easily.

Limitations Worth Understanding

Common Beginner Mistake

Case Study: An ISP's Aggregation Discipline Paying Off

A regional ISP received customer complaints requesting flexibility to choose their own address ranges rather than accepting sequentially-assigned /48 blocks from the ISP's /32 allocation. After evaluating the request, the ISP's engineering team declined it specifically to preserve aggregation — allowing customers to select non-contiguous ranges within the /32 would have forced the ISP to announce many smaller routes instead of one clean /32 aggregate, increasing their contribution to the global routing table without any real benefit to the customers making the request (who had no actual technical need for a specific range, just a preference). This decision reflects a broader principle: aggregation discipline sometimes means saying no to individually reasonable-sounding requests that would collectively undermine a design property that benefits the entire internet's routing infrastructure, not just one ISP.

Checklist for CIDR-Aware IPv6 Planning

1. Allocate address blocks contiguously within your parent CIDR block wherever possible, preserving aggregation potential.
2. Reserve provider-independent (PI) space only for genuine multi-homing needs, not general preference.
3. Document which of your announced routes are aggregates versus necessary exceptions, and why each exception exists.
4. When peering or requesting transit, understand your upstream's aggregation policy before assuming you can announce arbitrary sub-blocks independently.

Summary

IPv6 CIDR uses identical slash notation to IPv4 CIDR, but the underlying story is different in almost every practical respect: it was never retrofitted onto a legacy classful system, its typical prefix ranges occupy a completely different numeric space, and while address scarcity is no longer the driving concern, route aggregation — the other half of what CIDR was originally invented to solve — remains just as operationally important as it ever was. Understanding IPv6 CIDR well means understanding that the notation carried over, but the reasons it matters shifted almost entirely from "we're running out of addresses" to "we need the global routing table to stay manageable."