Summary

  • The RIPE Address Policy Working Group co-chairs announced on 24 September 2026 that proposal 2024-01, the Revised IPv6 PI Assignment Policy, had been withdrawn. They said it would be archived and that the topic could be reintroduced. They did not state why it was withdrawn or report a decision to adopt any of its clauses.
  • When checked directly on 27 September, the proposal's version 3.0 page still displayed “Review Phase: Open for discussion.” The later dated chair message is evidence of the disposition; the lagging page is evidence of a public-record mismatch, not of continued policy progress or deliberate concealment.
  • The published IPv6 policy, RIPE-738, and the current PI request guidance remain the documents an applicant must use. A /48 is the PI minimum, a larger request needs documented justification, and PI space cannot be further assigned as prefixes to outside organisations merely because draft 2024-01 contemplated different language.
  • The withdrawal did not roll back a rule that had never been enacted. It also did not decide every technical argument in the draft. RIPE's PDP permits a topic to return through a new policy discussion; the reviewed notice gives no reason to treat a future text or outcome as settled now.

The request in front of the applicant

Imagine a network with a legitimate need for more independently routable IPv6 space. It has read proposal 2024-01 and sees a path from /48 to /44 where the need is justified, with room reserved for later growth. It may also have a design that gives another party a prefix at the same site. Those details are concrete enough to affect an address plan, a customer contract and an application to the registry. They are not concrete enough to become a right merely by appearing on a proposal webpage.

The distinction became unusually easy to miss in late September. On 24 September, Alex Le Heux wrote to the Address Policy Working Group for its co-chairs: proposal 2024-01 “has been withdrawn.” The note said the draft aimed to reduce the operational burden of IPv6 PI space and clarify old policy wording. It said the proposal would be archived and that anyone was free to reintroduce the topic under the PDP. It did not describe a poll, a failed consensus call, an Executive Board veto, a withdrawn author's reasoning or a technical incident. The word “withdrawn” is the disposition the public message supplies.

A causal story would have to come from other evidence.

On 27 September, a direct check of the proposal page still displayed “Review Phase: Open for discussion” for version 3.0, dated 25 August. The archived-proposals index had not yet exposed a 2024-01 entry in the reviewed result. A website can take time to reflect a mailing-list act. The inconsistency is real as a reading problem, but the page's stale status cannot convert the later announcement into a still-active review. Nor does it establish why the page lagged or who was responsible for updating it. Those are different questions.

The applicant needs a hierarchy, not a guess. The dated co-chair notice supplies the proposal's most recent public process state. The published numbered policy supplies the current rule. The RIPE NCC's request guidance shows the path for presenting a case under that rule. The withdrawn draft and its impact analysis remain useful records of arguments and implementation costs. A route table, a customer agreement and a registry assignment each have their own state; none changes when a process page moves—or fails to move—from one label to another.

One draft carried several decisions

Version 3.0 was not a single numerical amendment. It proposed changes to what an assignment may do in §2.6, how assignments from allocations are described in §5.4, and PI size and growth in §7.1–7.1.2. It tried to clarify whether certain co-located uses and addressing arrangements would count as sub-assignment. It proposed nibble-boundary sizes and recommended reserving contiguous room for growth. Where an existing PI assignment could not be extended contiguously, it set out a replacement path with renumbering and return of the old space.

Each piece touches a different operational decision: the scope of use, the amount initially registered, the ability to enlarge a block, and the fate of a network that must migrate.

There was a respectable reason to put those questions together. An applicant cannot make a credible growth plan if the size rule ignores intended use. An aggregation rule cannot be assessed without asking what transfers or deaggregation will do to the reserved space. A relaxation of assignment wording cannot be evaluated without knowing whether it changes the boundary between an end user's own infrastructure and service to another organisation. The authors' attempt to make those dependencies visible deserves to be read as an attempt at simplification, not as evidence of hidden power.

The RIPE NCC impact analysis tested that bundle and described high operational impact if adopted. It anticipated substantial software, process, documentation and training changes. It said some proposed use and compliance requirements would be hard to verify or enforce efficiently. It questioned what happens to existing assignments and whether partial transfers could fragment a newly issued nibble-boundary block enough to defeat the reserved-growth idea. Its legal and implementation sections asked how to handle incomplete plans, renumbering that is not finished within six months and proportionate responses to non-compliance. The Executive Board strongly advised revision.

Those assessments matter. They explain why no one should treat a change in §7.1 as a free-standing promise that the registry could implement without resolving §2.6, transfer treatment, records and exceptional cases. But the analysis is not a published answer to the question “why was 2024-01 withdrawn?” The co-chair note did not make that causal connection. It also did not say the Board rejected a policy. RIPE's Policy Development Process describes community discussion and consensus stages, with the RIPE NCC providing administrative and impact-analysis support. The distinction between assessing a proposal and deciding its status should survive even when the assessment is sharply critical.

The live rule is less expansive, and more definite

For today's application, RIPE-738 is the important document. It says the minimum IPv6 PI assignment is a /48; a request for a larger assignment must be assessed against documented need and applicable routing considerations. It says PI space cannot be further sub-assigned to other organisations. Its LIR provision is tied to the LIR's own infrastructure rather than customer end sites. RIPE NCC's PI request instructions put the applicant's work in operational terms: explain the need for a larger block or special routing requirements, and do not use PI to distribute a prefix, even a /64 or /96, to an outside party. Separate addresses and prefixes are not interchangeable for this purpose.

That does not prove every applicant will be limited to a /48. The current guidance itself contemplates a larger request with justification. It does mean the draft's proposed automatic nibble-boundary progression, recommended reservation and co-located prefix language are not an application checklist. A holder should ask RIPE NCC about its specific documented need under current rules, not claim draft text as an entitlement. An operator planning service to another entity should check whether its addressing design crosses the present PI sub-assignment restriction, not assume that the withdrawn draft's exception is available.

Where another route—an allocation, upstream space or a differently structured service—is appropriate, that is a design decision under existing options, not a withdrawal remedy.

The same precision protects current holders. Withdrawal is not a cancellation of existing PI assignments. It is not a direction to renumber networks that relied on current policy. It is not a registry instruction to unwind transfers, issue a new object, modify RPKI, change a route origin or withdraw a prefix from BGP. Those would require their own authority, records and operational steps. A proposal that never completed the PDP cannot be “rolled back” in the way an implemented policy might be. The draft disappears from the active decision route; its discussion and impact analysis remain in the public record.

What survives an abandoned text

The co-chair message leaves a legitimate future path: anyone may reintroduce the topic. That is not a commitment to resurrect version 3.0, a timetable, or a declaration that its provisions had rough consensus. It means the underlying problems may still be debated. A future proposer could ask the community to distinguish, for example, a rule about use at an End Site from a rule about PI size, or to specify how transfers interact with promised contiguous growth.

But the person doing so would need to supply text, answer objections and pass the PDP's phases; they cannot inherit a withdrawn draft's authority as though time spent in review had adopted it.

There is also a narrow public-information lesson. A proposal page is valuable because it joins a stable identifier, version history, status and impact analysis. Once a disposition message and the page disagree, a reader must work harder to know which sentence is operative. Updating the page and archive matters, but the need is not for theatrical unanimity across every website at the same second. It is for a visible chain from the dated disposition to the current policy and to the versioned historical record.

The lag seen on 27 September should be corrected as ordinary record maintenance; the evidence reviewed here does not justify treating it as an intentional attempt to bind applicants to a draft.

An applicant cannot postpone a real addressing decision until every archive label is tidy. It can, however, refuse to let the untidiness decide for it. It can cite the current policy in its request, document its own routing and utilisation case, and distinguish a registry answer about the present request from a community debate about a possible future rule. That is not bureaucratic caution for its own sake. It keeps a network from building on a sentence that has no present standing, while keeping the ideas behind that sentence available for a properly evidenced new proposal.

Sources