Was sich geändert hat
Nachgewiesen ist ausschließlich die Einführung des RIPE-NCC-Vorschlags 2024-02 am 14. Oktober 2024. Materielle Änderungen des Vorschlags oder spätere Verfahrensschritte sind in den gelieferten Fakten nicht enthalten.
RIPE NCC · RIR-Beobachtung
Beginnen Sie hier mit der Dokumentation zu jedem einzelnen Vorschlag: Was änderte sich, warum war dies von Bedeutung, wer argumentierte wofür, wie entwickelten sich die Positionen, was wurde beschlossen und wo weist die Beleglage noch Lücken auf?
Quellenbelegte Fakten
Wer hat die Debatte tatsächlich geprägt?
BTW-Analyse
Nachgewiesen ist ausschließlich die Einführung des RIPE-NCC-Vorschlags 2024-02 am 14. Oktober 2024. Materielle Änderungen des Vorschlags oder spätere Verfahrensschritte sind in den gelieferten Fakten nicht enthalten.
Der Gegenstand einer Debatte lässt sich nicht bestimmen, weil weder der materielle Inhalt des Vorschlags noch Diskussionsbeiträge, Argumente oder Positionsdaten vorliegen.
Belegt ist eine formale Einführung, aber weder eine beobachtete Nachrichtendiskussion noch ein Entscheidungsresultat. Annahme, Ablehnung, Rücknahme, Ablauf oder fortdauernde Beratung können aus den gelieferten Fakten nicht festgestellt werden.
Erfasst wurden null Nachrichten, null Diskussionsteilnehmende und null aktive Diskussionstage. Die zwei gezählten Teilnehmenden sind ausschließlich formale Akteure. Die Konzentrationswerte von 0,0 zeigen daher keine gleichmäßige oder breite Beteiligung, sondern sind strukturelle Nullwerte, weil keine Beitragsverteilung existiert.
Ein personeller oder institutioneller Einflussengpass ist nicht nachweisbar. Als analytischer Engpass wirkt vielmehr die fehlende beobachtete Diskussion und Chronologie: Ohne Nachrichten, Rollen, Positionen und spätere Verfahrensereignisse kann weder ein dominanter Sprecherkreis noch der entscheidende Verfahrenspunkt identifiziert werden.
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.Quellenbelegte Fakten ↗
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.Quellenbelegte Fakten ↗
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.Quellenbelegte Fakten ↗
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.Quellenbelegte Fakten ↗
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.Quellenbelegte Fakten ↗
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.Quellenbelegte Fakten ↗
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.Quellenbelegte Fakten ↗
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.Quellenbelegte Fakten ↗
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.Quellenbelegte Fakten ↗
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.Quellenbelegte Fakten ↗
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”.Quellenbelegte Fakten ↗
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.Quellenbelegte Fakten ↗
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.Quellenbelegte Fakten ↗
Wird geladen
Teilweise
Früheste Erfassung: 30.06.1992
Letzte Erfassung: 12.11.2026