O que mudou
A única mudança processual comprovada é a introdução da proposta 2024-02 em 14 de outubro de 2024. Não há fatos verificados que demonstrem revisão, adoção, rejeição, retirada ou implementação posterior.
RIPE NCC · Monitoramento de RIR
Comece aqui pelo registro de cada proposta: o que mudou, por que isso foi relevante, quem defendeu cada posição, como as posições evoluíram, o que foi decidido e onde ainda há lacunas nas evidências.
Fatos com fonte
Quem realmente moldou o debate?
Análise BTW
A única mudança processual comprovada é a introdução da proposta 2024-02 em 14 de outubro de 2024. Não há fatos verificados que demonstrem revisão, adoção, rejeição, retirada ou implementação posterior.
Não é possível determinar o objeto substantivo do debate, pois a extração não contém mensagens, argumentos, posições classificáveis nem transições de posição. A evidência mostra entrada formal no processo, mas não revela uma controvérsia comunitária mensurável.
Há registro de introdução, mas não de decisão. A coleta registra zero mensagens, zero participantes de discussão e zero dias ativos; portanto, não comprova discussão comunitária nem permite inferir consenso. O resultado decisório permanece desconhecido.
Os dois participantes contabilizados são atores formais, sem participantes de discussão registrados. As quotas das principais vozes, o HHI e o número efetivo de participantes são zero porque também há zero mensagens; esses valores não demonstram participação dispersa nem baixa concentração, apenas ausência de atividade discursiva capturada.
Não é possível identificar um ator ou etapa que tenha funcionado como gargalo decisório. Os dados mostram dois atores formais, mas não informam suas identidades, funções ou ações. O principal limite analítico é a ausência de eventos posteriores à introdução e de registros que conectem participação, influência e decisão.
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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”.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
Carregando
Parcial
Primeiro registro: 30 de jun. de 1992
Último registro: 12 de nov. de 2026