RFC 3531 Sparse Allocation¶
The RFC 3531 Sparse Allocation drawer applies an RFC 3531 bit-reservation strategy to a parent IPv6 prefix, producing a growth-friendly allocation order for the child blocks.
When to use this¶
You have a delegated parent prefix (say 2001:db8::/48) and need to
hand out smaller child prefixes (say /52s) to internal sites,
customers, or VRFs. You want each new allocation to leave room either
side for the recipient (or its neighbour) to grow later, instead of
densely packing from one end.
That is what RFC 3531 is for: it orders the reservation field so the centre of the address space is allocated first, then the halves bisect outward, then the quarters, and so on. Every active reservation sits between two large free blocks until the field is fully consumed.
Strategies¶
| Strategy | Order (4 reservation bits) | Use when |
|---|---|---|
centermost |
8, 4, 12, 2, 6, 10, 14, 1, 3, 5, 7, 9, 11, 13, 15 |
You want growth headroom for every reservation (RFC 3531 §3 default). |
leftmost |
0, 1, 2, 3, …, 15 |
You explicitly want dense sequential allocation. |
rightmost |
15, 14, 13, …, 0 |
Allocate from the top of the field down (mirror of leftmost). |
The centermost strategy in detail¶
For 4 reservation bits the centermost order is the canonical RFC 3531 §3 worked example:
Level 1 (1 value): 8 → middle of 0..15
Level 2 (2 values): 4, 12 → middles of 0..7 and 8..15
Level 3 (4 values): 2, 6, 10, 14 → middles of 0..3, 4..7, 8..11, 12..15
Level 4 (8 values): 1, 3, 5, 7, 9, 11, 13, 15 → all remaining odd values
Each level halves the gap between previously-allocated values. The first
allocation (8, the middle) leaves 0..7 and 8..15 both fully
available. The second allocation (4) splits the lower half into two
halves of 4. And so on.
Compare against leftmost (0, 1, 2, 3, …): after three allocations
you have 0, 1, 2 consumed and 3..15 free as a single contiguous
block. Under centermost after three allocations you have 4, 8, 12
consumed and 0..3, 5..7, 9..11, 13..15 all available — every
existing reservation has room either side.
Composes with the prefix-delegation planner¶
This drawer pairs naturally with the IPv6 Prefix-Delegation Planner:
- The planner answers "how many child blocks fit in my parent and what do they look like?"
- RFC 3531 answers "in what order should I assign them so future growth survives?"
Both tools are pure operator math — neither one detects anything about the input prefix; they apply a plan you already chose.
Capacity caps¶
The default cap on reservation_bits is 8 (256 children). Operators
can raise it via the $rfc3531_max_bits config token, up to a hard
ceiling of 12 (4096 children).
API¶
curl -X POST -H 'Content-Type: application/json' \
-d '{"parent_prefix":"2001:db8::/48","reservation_bits":4,"strategy":"centermost"}' \
https://example.com/api/v1/rfc3531
See the API reference for full request/response schemas.