Summary

  • Proposal 2024-01 recommends reserving address space to the next nibble boundary whenever a new IPv6 PI assignment is issued. RIPE NCC’s impact analysis illustrates a /44 assignment with a /40 reservation.
  • The same analysis says newly assigned PI space could be transferred immediately and is expected to undergo partial transfers, fragmenting the original block and making reservations unusable for extensions. This is a forecast about an unadopted draft, not evidence that such a transfer or loss has occurred.

A small block inside a larger promise

Picture an End User with two separate End Sites. In the RIPE NCC’s worked example, that user and another with sixteen End Sites would each receive a /44 IPv6 PI assignment. Around either assignment, the proposal recommends reserving enough contiguous space to reach a /40. A user with seventeen End Sites would cross the next threshold: a /40 assignment and a /36 reservation.

The assigned prefix and the reservation are not the same object. The /44 is the resource placed under the holder’s control, subject to the applicable registry and transfer rules. The surrounding /40 is a planning envelope. Its purpose is to keep adjacent space available so that justified growth can be served by extension rather than by replacing the assignment and renumbering the network.

That is a sensible piece of address planning. IPv6 is written in hexadecimal, and nibble boundaries make prefixes easier to read and administer. Leaving a clean outer frame can avoid scattering related assignments. The draft therefore does more than enlarge a request: it tries to preserve a path from today’s justified need to tomorrow’s larger one.

But a path is not preserved merely because space was empty on the day the first block was issued. It remains useful only if later decisions do not change the relationship among the assignment, the surrounding reservation and the holder entitled to request the extension.

The impact analysis finds the break

RIPE NCC’s impact analysis puts the problem plainly. The proposal mandates the return of existing PI space in its replacement branch, but it places no corresponding constraint on transferring some or all of the newly assigned space. The analysis says the new PI space could be transferred immediately and is expected to undergo partial transfers. That would fragment blocks originally issued at nibble boundaries and make the reservations unusable for extensions.

This is not a report of a completed transfer. Proposal 2024-01 entered Review Phase on 25 August 2026 and remains open for discussion until 23 September. The working-group chairs have not declared rough consensus in the captured record, and RIPE-738 remains the current policy. No /44, /40 or /36 in this article identifies a real holder.

The warning matters because the two features optimize different moments. A growth reservation protects the future of the original assignment. Transferability protects the holder’s ability to reorganize, dispose of a resource or move it to another eligible party. Each can be defensible. Together they require a rule for what happens to the outer frame when the inner block changes hands or is split.

Suppose a /44 sits inside a reserved /40, and part of the /44 is transferred. The public draft does not by itself answer whether the /40 reservation follows the remaining fragment, follows the transferred fragment, is divided, is released, or continues to exist even though neither resulting block can expand cleanly into it. A reservation that has no defined beneficiary and no remaining contiguous path is not the same thing as a reservation that can still support growth.

The distinction is administrative before it is technical. More-specific routes may be announced from an assignment; that does not divide the registry right. A registered transfer changes the resource relationship; it does not prove a routing change. Reserved space can remain unassigned without being usable for the same extension. Those states should not be collapsed into a single map of occupied and empty prefixes.

Give both sides their strongest case

The proposal’s supporters have a real operational problem. The current /48 minimum and a history of multiple discrete assignments can leave organisations with many objects and a future renumbering burden. The draft allows a larger justified assignment, aligns it to a nibble boundary and recommends holding the next boundary open. Where contiguous space exists, section 7.1.2 would let an existing assignment grow. Where it does not, a replacement assignment and six-month renumbering period provide a transition path.

Transfer freedom also has a serious case. A holder’s network, corporate structure and demand can change. A blanket lock could trap unused capacity, obstruct a legitimate reorganisation or make PI resources behave differently from the transfer policy the community already operates. The impact analysis does not argue that every partial transfer is improper. It says the design has a consequence for the reservation.

That is exactly what an impact analysis should reveal before a proposal is accepted. The document is not evidence that the process failed; it is evidence that the process surfaced a collision early enough to resolve it. The open question is whether the community wants growth continuity, transfer flexibility or a conditional combination—and which state must be visible when one objective displaces the other.

One response would be to make the reservation follow an indivisible assignment and release it when that assignment is split. Another would be to place a time-bounded transfer constraint on the assigned block while the growth reservation remains active. A third would be to treat the reservation as best-effort capacity that can be displaced, provided the registry tells the holder that extension is no longer available. These are policy choices, not conclusions supplied by the current sources.

A reservation-and-transfer receipt

The public record does not need to expose an addressing plan, customer list or commercial transfer terms. It does need to make the lifecycle coherent.

For each issued assignment under the proposed model, a privacy-safe receipt could record the assigned prefix class, the covering nibble boundary reserved for growth, the date and authority for that reservation, and the justified planning horizon. It should distinguish a firm hold from a recommendation or best-effort planning state. A reader should not have to infer the strength of the reservation from empty registry space.

The receipt should then record the assignment’s transferability state. If a transfer is requested, it should identify whether the request concerns the whole assignment or a subrange; whether the growth reservation follows, changes or ends; and how much contiguous extension capacity remains after completion. Public output can use prefix-length and state classes rather than naming parties or publishing sensitive documents.

Where a replacement rather than an extension is required, the same record should join the new assignment to the old assignments and their six-month return clock. That is adjacent to, but distinct from, the transfer problem. Renumbering explains how old resources leave the registry state after a larger replacement is issued. The reservation receipt explains whether the space held around the new resource still serves the purpose for which it was left open.

A correction history matters. A reservation can be created, reduced, released, displaced or restored. If the registry later learns that a transfer left no compatible extension path, the public record should not silently preserve the old “reserved for growth” meaning. It should show the changed state and the decision that caused it.

What the draft establishes—and what it does not

The sources establish an open proposal, a reservation recommendation and an implementation concern identified by RIPE NCC. They show that the draft’s transfer reference does not itself prevent immediate partial transfer of a newly issued PI assignment. They also show the analysis predicting that fragmentation could make reservations unusable for extensions.

They do not establish adoption, implementation or harm. No production reservation has been observed. No transfer is identified. No holder has been forced to renumber, no address has been stranded, and no route-table change is measured here. “Unusable” is the impact analysis’s description of a possible reservation state, not a claim that IPv6 addresses themselves stop working.

That boundary is the reason to commission the receipt now. A policy can promise a clean expansion path and preserve transfer freedom, but it cannot treat the relationship between them as self-explanatory. If a future /44 is meant to grow inside a /40, the public design should say what survives when part of the smaller block leaves.

Sources