What changed
The only verified change is procedural: proposal ripencc/2024-02 was introduced on 14 October 2024. No proposal revisions, substantive policy-text changes, implementation events, or later dispositions are supplied.
RIPE NCC · RIR Watchdog
Start here for the proposal-by-proposal record: what changed, why it mattered, who argued for what, how positions evolved, what was decided, and where the evidence still has gaps.
Source facts
Who actually shaped the debate?
BTW Analysis
The only verified change is procedural: proposal ripencc/2024-02 was introduced on 14 October 2024. No proposal revisions, substantive policy-text changes, implementation events, or later dispositions are supplied.
The subject of any debate cannot be determined from the supplied record because it contains no discussion messages, arguments, objections, responses, participant stances, or stance transitions.
Neither a decision outcome nor observable discussion is established. The chronology records introduction only, while the measured record has zero messages, zero discussion participants, and zero active days. No adoption, rejection, withdrawal, abandonment, implementation, or other disposition is supplied.
Participation concentration cannot be meaningfully assessed. The top-message shares and HHI are zero because there were zero recorded messages and zero discussion participants, not because participation was broad or evenly distributed. Two formal actors are counted, but their identities, roles, actions, and positions are unknown.
No actor-level procedural or decision chokepoint can be identified from the supplied facts. The principal analytical chokepoint is the missing record after introduction and the absence of captured discussion: without later chronology, actor roles, interventions, or a decision event, control or influence cannot be attributed.
Initial allocation range · Version 2 changes the undocumented initial-allocation choice from /32 or /28 to the full range /32 up to /28. Intermediate sizes therefore become explicit options. Requests larger than /28 still require justification.
LIRs that meet the initial allocation criteria are eligible to receive an initial allocation of /32 or /28 without needing to supply any additional information.Source facts ↗
LIRs that meet the initial allocation criteria are eligible to receive an initial allocation of /32 up to /28 without needing to supply any additional information.Source facts ↗
One extension per organization · Version 2 replaces the entitlement of an LIR to extend each qualifying allocation with a one-time extension of one allocation per organization. The rationale identifies limiting stockpiling as the purpose. The /28 ceiling and the restriction to allocations originally issued directly by RIPE NCC as a single prefix remain.
LIRs that hold one or more IPv6 allocations that were originally issued directly by the RIPE NCC as a single prefix may request an extension of each such allocation up to a /28 without the need for additional documentation.Source facts ↗
Organizations, not LIRs, that hold one or more IPv6 allocations that were originally issued directly by the RIPE NCC as a single prefix may request once an extension of one of such allocation up to a /28 without the need for additional documentation.Source facts ↗
Conservation objection and reserved-space response · Version 2 replaces the absence of opposing arguments with a conservation objection: the new maximum initial block contains twice as much space as /29. Its response says RIPE NCC already reserves a /26 for each new /29 and argues the depletion rate would not increase significantly. That is a stated counter-argument, not a measured outcome; smaller requests remain possible.
This policy proposal is perceived as counterproductive to conservation efforts. Under the proposal, LIRs can initially receive up to twice the amount of IPv6 space compared to the current system. Counterarguments: For each new /29 allocation, the RIPE NCC already reserves a /26 block. This means that the proposed change will not significantly increase the depletion rate of the RIPE NCC address pool.Source facts ↗
Partial-transfer objection and scope of the extension estimate · Version 2 adds the objection that a /28 can be split into sixteen /32 transfers, with the response that partially transferred allocations cannot be extended again. It also qualifies the unchanged 91% extension-availability estimate as including presumed stockpilers. Neither the numerical estimate nor the original-single-prefix restriction is newly introduced here.
Allowing extensions only for allocations originally issued as a single prefix avoids the risk of abuse by infinitely extending chunks resulting from partial IPv6 transfers.Source facts ↗
By extending the initial allocation size to /28, LIRs gain the ability to split and transfer up to 16 /32 blocks (the current minimum allocation size) to other LIRs. Counterargument: This practice would be discouraged by the fact that allocations resulting from partial transfers could not be extended anymore.Source facts ↗
Member-based extension entitlement and direct issuance · Version 3 replaces organization with Member and expressly requires the allocation to have been issued directly to that Member. It states separately that only one extension is available per Member regardless of how many LIR accounts it holds. The /28 limit, single-prefix origin and initial /32-to-/28 range are unchanged.
Organizations, not LIRs, that hold one or more IPv6 allocations that were originally issued directly by the RIPE NCC as a single prefix may request once an extension of one of such allocation up to a /28 without the need for additional documentation.Source facts ↗
A Member, that holds one or more IPv6 allocations originally issued directly to them by the RIPE NCC as a single prefix, may request an extension of one of these allocations up to a /28 without the need for additional documentation. Only one such extension may be granted per Member, regardless of the number of LIR accounts they hold.Source facts ↗
Extension allowance moves from Member to LIR · Version 4 returns the extension clause to LIRs and removes the explicit one-per-Member limit across multiple LIR accounts. Its rationale now describes one extension per LIR without further justification and cites Executive Board concerns about using Members. This changes the unit of eligibility; the initial allocation range and /28 extension ceiling remain unchanged.
Only one such extension may be granted per Member, regardless of the number of LIR accounts they hold.Source facts ↗
The proposal allows only one extension per LIR without further justification, which limits some of the potential adverse effects of stock-pilers. It also addresses the RIPE NCC Executive Board’s concerns in the previous impact analysis about using “Members” instead of “LIRs”.Source facts ↗
Original allocation provenance wording · Version 4 retains the requirement that the allocation originated as a single prefix directly from RIPE NCC but removes the words requiring issuance directly to the current applicant. The retained text no longer states that original-recipient condition explicitly. This wording change alone does not establish that every transferred block qualifies; the single-prefix restriction and the proposal’s warning about partial transfers remain.
A Member, that holds one or more IPv6 allocations originally issued directly to them by the RIPE NCC as a single prefix, may request an extension of one of these allocations up to a /28 without the need for additional documentation.Source facts ↗
LIRs that hold one or more IPv6 allocations originally issued directly by the RIPE NCC as a single prefix can request an extension of one of these allocations up to a /28 without providing further documentation.Source facts ↗
Loading
Partial
Earliest captured: Jun 30, 1992
Latest captured: Nov 12, 2026