RIPE IPv6 PI draft lacks a transition receipt

Summary

Version 2 deliberately removed broad re-evaluation machinery, and its proposer said existing holders face no implications while their address needs remain unchanged.
Once need grows, the draft's next-nibble and non-contiguous replacement branch can make several old assignments, one new resource and a six-month return period part of one transition.
Preserve that boundary with a fourteen-field receipt and five test cases; keep topology, customers and migration choreography local or protected.

Nine prefixes are a state, not a verdict

The most useful number in this policy debate did not come from a registry total. In March 2025, one participant said his network had nine different /48 PI assignments and wanted to consolidate them, preferably without renumbering. He mentioned both database objects and DNS. That is an attributable account of one operator's problem, not an independent verification of current holdings and not evidence that nine prefixes are abusive, wasteful or typical.

Its value is architectural. It gives the proposal an initial state: an ordered set of separately registered prefixes already embedded in routers, access lists, reverse zones, monitoring systems and applications. Nothing in a final aggregate alone can explain how those earlier identities were treated.

Grandfathering that state is not a policy failure. A registry should not manufacture migration risk merely to make old records resemble a newer design. The hard question begins when the holder asks for more.

Version 2 made non-intervention explicit

The October 2025 version 2 announcement is unusually helpful about what changed. It says the proposed End Site definition and the re-evaluation of addressing needs when requesting an additional or larger assignment were removed. The authors made the document shorter and more readable. The deletion was intentional, not a drafting accident.

Five months later, a participant asked directly how version 2 treated existing holders of multiple PI assignments whose space needs did not grow. The proposer's answer was bounded: there are no implications for existing holders if their space needs do not change.

That sentence is the first side of the contract. An unchanged holder does not have to prove a new case simply because the policy language evolves. Non-adoption of a new aggregate by that holder does not invalidate the old state. Stability remains local until an authoritative event engages a new rule.

A growth request crosses the seam

The second side appears in the discussion around section 7.1.2. A holder of one or more PI assignments that needs additional space is directed towards an extension to the next nibble boundary. If sufficient contiguous space is unavailable, the holder may request a new assignment and must return the previous assignment or assignments within a six-month renumbering period. A participant quoted that branch and challenged the six-month duration, proposing a longer or extendable period.

The duration dispute remains a policy choice. This article does not decide whether six, twelve or 24 months is correct and does not claim that anyone has missed such a deadline. The more basic observation is that the text creates a state transition:

unchanged old set → changed need → contiguity test → extension or replacement → overlap → return.

Each arrow needs an owner and an identity. Which request changed the need? Which policy version was applied? Which old assignments were in scope? What reservation snapshot supported the contiguity result? Did the registry extend one object or issue a new one? When did the return clock begin? Which previous assignments must close, and how is an error corrected?

The resulting prefix row cannot answer those questions by itself.

This is still a proposal window

Status must remain precise. On 15 June 2026, the working-group co-chairs reported eight expressions of support, minor editorial changes and an agreement to advance the proposal to Review Phase. Their message said a policy draft and impact analysis would be published and the next phase announced.

That is evidence of intended progress, not adoption or implementation. The source set reviewed for this article does not establish that a Review document was later published, consensus reached or production systems changed. The receipt belongs in the design discussion now, while the impact analysis and operative wording can still name the boundary.

Renumbering is not one registry timestamp

The six-month phrase looks simple only if the resource record is mistaken for the network. RFC 4192 describes IPv6 renumbering without a flag day: obtain the new prefix, plan link prefixes, introduce new addresses, update routing, DNS, DHCP and configured references, operate old and new together, test the new state, then remove the old prefix.

The sequence is deliberately make-before-break. A return date at the registry is the end of a chain whose earlier clocks may sit in resolver caches, router advertisements, firewall rules, monitoring targets and software configuration.

RFC 5887 explains why that chain remains difficult. Static addresses can be dispersed and discovered only after a user encounters failure. During overlap, policy rules and monitoring have to recognise both old and new prefixes. Tools do not always handle multiple-prefix operation cleanly even though IPv6 permits it.

Neither RFC governs RIPE proposal 2024-01 or chooses its deadline. They establish a narrower fact: a registry transition with operational renumbering has more states than “old” and “new”. Evidence has to survive those intermediate states.

The transition can be written as an object

Let P0 be the ordered old PI set at a dated cutoff. Let N0 be the previously documented need, q the later additional-or-larger request, and H the applicable text and version. Let C(q, P0) be the reservation and contiguity result. Let T be the selected extension or replacement path, P1 the resulting resource identity, and D the overlap/return clock and closure evidence.

Then define the auditable event as:

E = G(P0, N0, q, H, C, T, P1, D).

This is my audit model, not RIPE NCC's schema. Its purpose is to show why neither P0 nor P1 is sufficient alone. Before q, the proposer's explanation leaves P0 undisturbed. After q, the decision is a joined event. If any component changes, a later reviewer needs the version and correction chain rather than a reconstructed story.

A fourteen-field growth-transition receipt

The common record can remain compact. It does not need the holder's full network plan.

Receipt identity. Stable receipt ID and receipt-schema version.
Applicable rule. Proposal or policy identifier, text version, authoritative digest and effective status/date.
Prior-state cutoff. Exact observation time and timezone for the old assignment set.
Holder and request. Public-safe holder reference, request ID and authenticated submission time, excluding private contacts.
Trigger class. No-change inquiry, additional-space request, larger-assignment request or correction, plus why section 7.1.2 is or is not engaged.
Prior PI set. Ordered old assignment/object identities, prefix lengths, statuses and record digests.
Assessed need. Approved, denied or undetermined outcome, target unit and bounded public reason code; raw topology may remain protected.
Nibble target. Requested and assessed boundary, with the reason for any difference.
Contiguity evidence. Reservation-snapshot identity, tested adjacent range, result time and deterministic outcome without exposing unrelated holdings.
Selected path. Extend an existing assignment, issue a new one, leave the set unchanged, deny or request more evidence.
Resulting resource. New or extended assignment identity, prefix, object version and activation time.
Coexistence clock. Overlap start, return deadline, timezone and any rule-authorised pause or extension identity.
Return set and closure. Old assignments due for return, per-item state, completion evidence and unresolved exception.
Correction chain. Decision authority, review/correction route, superseded receipt link and final status.

These fields do not declare that a holder's need is true merely because a request was signed. They preserve who asserted what, which rule evaluated it and what state followed.

Five tests before implementation

A prose rule is not ready for interoperable use until ordinary edge cases produce the same record.

No-growth legacy set. Several old assignments and no additional need produce trigger=no_change and no return clock.
Contiguous extension. Justified growth with suitable adjacent space links the old set, reservation result and extended assignment.
Non-contiguous replacement. Justified growth without suitable adjacent space creates a new assignment, explicit return set and overlap deadline.
Withdrawn request. Withdrawal before new-resource activation ends the case without starting a return clock.
Correction. An incorrect old-set member or clock start is superseded through an append-only correction; history is not silently rewritten.

Publication of those vectors would expose ambiguities before an operator has to discover them in a live migration. Different registry tools could still implement the rule differently while emitting the same minimum semantics.

Keep the shared layer narrow

HENG.LU Note 64 offers the right institutional limit. Specify only what has to be common for uniqueness, interoperability and shared safety. Leave future and local decisions with the participants running the system.

For this transition, the portable layer is resource identity, rule version, trigger, contiguity result, selected branch, clock, closure and correction. The protected layer is topology, customers, detailed utilisation, device inventory, commercial purpose and the order in which the holder changes its network.

RIPE NCC would apply the community rule and attest to its decision. The holder would supply evidence and control routing, DNS and migration. Independent parties could validate the receipt or run the test vectors. None of them gains authority over the others merely by reading the record.

That boundary also preserves voluntary non-action. A valid holder with unchanged need is not ordered to consolidate just so a new receipt can exist. The common artifact is required only when an authoritative transition is evaluated or recorded.

Sources

Evidence limits

Verified: version 2 intentionally removed broad re-evaluation; the proposer said unchanged needs have no implications; the discussion text contains a growth-triggered extension/replacement path and six-month return period; co-chairs intended to advance the proposal; IPv6 renumbering requires overlapping operational states.

Inference: an event-triggered crossing cannot be reconstructed reliably from the resulting prefix row alone, and uncertainty about the crossing can encourage request avoidance or inconsistent case reconstruction.

Recommendation: bind the crossing in a protected/publicly bounded fourteen-field receipt and publish five test vectors before implementation.

Unknown: the forthcoming Review text and impact analysis, final deadline, clock-start event, exception or extension rule, internal case schema, number of affected holders and any production implementation.

RIPE's IPv6 PI Draft Has a Trigger but No Transition Receipt