Resumo
- A versão 2 retirou deliberadamente a reavaliação ampla; depois, o proponente disse que o titular existente não sofre consequências enquanto sua necessidade de espaço não muda.
- Havendo crescimento, entra em cena o próximo limite de nibble e, sem espaço contíguo, uma nova atribuição com devolução das anteriores durante um prazo de seis meses.
- Um recibo de catorze campos e cinco vetores de teste pode provar essa transição sem publicar topologia, clientes, uso detalhado ou o cronograma interno de migração.
O valor de não mexer
Política de numeração não precisa transformar toda diferença histórica em dívida. Se uma rede opera legitimamente com vários prefixos PI e não pede nada novo, a continuidade pode ser a opção menos arriscada.
O debate tem um exemplo concreto. Em março de 2025, um participante afirmou que sua rede tinha nove atribuições PI /48 distintas e gostaria de consolidá-las, de preferência sem renumerar. Ele mencionou objetos do banco e DNS.
É um relato atribuído, não uma consulta independente à base, nem uma medida de quantos titulares vivem a mesma situação. Nove /48 não significam, por si, abuso, desperdício ou descumprimento. Significam apenas que o estado anterior pode ter nove identidades incorporadas a rotas, zonas reversas, filtros e configurações.
A versão 2 escolheu a contenção
O anúncio da versão 2, de outubro de 2025, enumera o que saiu da primeira versão: a definição proposta de End Site e a reavaliação de necessidade quando se pede uma atribuição adicional ou maior. Os autores queriam um texto mais curto e legível. Não se trata de uma peça esquecida por acidente.
Em março de 2026, alguém voltou ao ponto dos titulares com várias PI, mas sem crescimento. A resposta do proponente foi que não há implicações se a necessidade de espaço não mudar.
Essa frase protege a autonomia operacional. O RIPE NCC pode coordenar o recurso sem tomar para si o calendário de roteadores, DNS, ACLs e aplicações. Uma regra nova não deve obrigar uma rede estável a atravessar uma migração apenas para deixar a base mais uniforme.
O pedido novo liga outro circuito
O tratamento muda quando surge uma necessidade adicional ou maior. A discussão da seção 7.1.2 aponta para a extensão até o próximo limite de nibble. Sem espaço contíguo, o titular pode receber uma nova atribuição e precisa devolver a anterior ou as anteriores dentro de seis meses. Um participante reproduziu essa passagem e questionou o prazo, sugerindo doze ou 24 meses ou uma extensão justificada.
Este artigo não escolhe o número. Também não relata atraso, pane ou caso aplicado. O que a redação revela é uma máquina de estados:
conjunto anterior → pedido de crescimento → teste de contiguidade → ampliação ou substituição → convivência → devolução.
A nova linha de prefixo não preserva automaticamente qual pedido iniciou o processo, qual versão foi aplicada, quais objetos formavam o conjunto anterior, qual reserva foi testada, quando começou o prazo e qual correção alterou a decisão.
Ainda há tempo para especificar
Em 15 de junho de 2026, os copresidentes registraram oito apoios e a intenção de levar a proposta à Review Phase. Disseram que seriam incorporados ajustes editoriais pequenos e publicados um texto de política e uma análise de impacto.
Isso não equivale a consenso, aceitação ou implantação. O conjunto de fontes aqui usado não demonstra sequer a abertura posterior da fase. A análise trata de uma proposta em elaboração e deve continuar usando esse nome.
Justamente por isso, o recibo cabe agora. Uma análise de impacto deveria dizer não só o que o sistema final mostrará, mas também como a transição será identificada, corrigida e encerrada.
Renumerar exige uma sobreposição real
O RFC 4192 descreve a renumeração IPv6 sem virada instantânea. O novo prefixo é preparado e adicionado; roteamento, DNS, DHCP e referências configuradas são atualizados em etapas; os dois prefixos convivem; o novo estado é testado; só então o antigo sai.
O RFC 5887 mostra a parte menos limpa: endereços estáticos ficam dispersos, alguns aparecem somente quando um usuário encontra um problema, regras e monitoramento precisam acompanhar os dois lados, e ferramentas operacionais nem sempre suportam bem múltiplos prefixos.
Esses documentos não governam a RIPE nem definem seis meses. Eles demonstram que o prazo do registro atravessa vários relógios locais. Um recibo comum deve comprovar a relação entre eles sem levar o plano técnico inteiro para o registro público.
Um modelo do evento, não apenas dos extremos
Considere P0 o conjunto PI anterior, ordenado e datado; N0, a necessidade documentada antes do novo pedido; q, o pedido adicional; H, a versão do texto. C(q, P0) registra o resultado de reserva e contiguidade; T, a escolha entre ampliar e substituir; P1, o recurso resultante; D, a sobreposição, o prazo e o encerramento.
O evento auditável é:
E = G(P0, N0, q, H, C, T, P1, D).
É um modelo analítico de Theo March, não um esquema publicado pelo RIPE NCC. Antes de q, P0 permanece legítimo e quieto. Depois, cada elemento precisa continuar ligado aos demais para que a decisão não dependa da memória de quem tratou o caso.
Catorze campos para o recibo de crescimento
- Identidade do recibo. ID estável e versão do esquema.
- Regra aplicável. Proposta ou política, versão, hash autêntico, estado e data efetiva.
- Corte anterior. Data, hora e fuso do conjunto inicial.
- Titular e pedido. Referência pública limitada, ID do caso e hora autenticada; contatos privados ficam fora.
- Classe do gatilho. Consulta sem mudança, espaço adicional, atribuição maior ou correção, com a justificativa para acionar ou não a seção 7.1.2.
- Conjunto PI anterior. Identidades ordenadas, comprimentos, estados e hashes dos registros.
- Necessidade avaliada. Aprovada, negada ou indeterminada, unidade-alvo e código público restrito; topologia bruta pode ser protegida.
- Alvo nibble. Limite pedido, limite avaliado e motivo da diferença.
- Contiguidade. Identidade do instantâneo de reservas, faixa adjacente testada, hora e resultado determinístico, sem expor terceiros.
- Caminho escolhido. Ampliar, substituir, manter, negar ou pedir evidência.
- Recurso resultante. Identidade, prefixo, versão do objeto e ativação.
- Relógio de convivência. Início, prazo de devolução, fuso e identidade de pausa ou extensão autorizada.
- Devolução e fechamento. Lista dos objetos antigos, estado individual, prova de conclusão e exceção pendente.
- Cadeia de correção. Autoridade, revisão, recibo substituído e estado final.
O recibo não confirma a necessidade só porque o pedido foi autenticado. Ele separa afirmação, avaliação, decisão e efeito.
Cinco respostas que precisam ser previsíveis
- Várias PI sem crescimento. Nenhum gatilho e nenhum prazo de devolução.
- Ampliação contígua. O conjunto antigo, a reserva testada e o objeto ampliado permanecem ligados.
- Substituição não contígua. Nova atribuição, conjunto explícito a devolver e período de convivência.
- Pedido retirado antes da ativação. Encerramento sem iniciar o relógio.
- Erro no conjunto ou na data. Correção acrescentada e encadeada; nada é sobrescrito em silêncio.
Esses vetores permitem ferramentas diferentes. O requisito comum é o significado da saída.
O mínimo que precisa viajar
A Nota 64 do HENG.LU sugere um núcleo estrito apenas para identidade, interoperabilidade e segurança compartilhada. Para esta transição, viajam identidades, versão da regra, gatilho, resultado de contiguidade, caminho, relógio, fechamento e correção.
Ficam locais ou protegidos a topologia, o tráfego, clientes, provas detalhadas de uso, equipamentos, motivos comerciais e a ordem dos trabalhos. A comunidade faz a política; o RIPE NCC aplica e registra sua decisão; o titular apresenta fatos e opera; o leitor verifica sem ganhar poder de alocar, rotear ou invalidar.
O mesmo limite preserva a não ação voluntária. Se a necessidade não mudou, não se cria uma migração para alimentar um formulário. Se mudou e o registro decide, a prova mínima acompanha o evento.
Fontes
- Relato das nove atribuições
/48 - Anúncio da versão 2
- Resposta sobre titulares sem crescimento
- Discussão da seção 7.1.2 e do prazo
- Aviso do avanço pretendido à revisão
- RFC 4192 — renumeração IPv6 sem virada instantânea
- RFC 5887 — lacunas operacionais da renumeração
- Nota 64 do HENG.LU
Limites da evidência
Verificado: a versão 2 retirou a reavaliação ampla; o proponente excluiu quem não cresce; o texto discutido tem a bifurcação e seis meses; os copresidentes pretendiam avançar; renumeração envolve estados sobrepostos.
Inferência: o recurso final não reconstrói sozinho o gatilho, a contiguidade, a lista de devolução e o relógio.
Recomendação: recibo de catorze campos e cinco vetores antes da implantação.
Desconhecido: texto de revisão, análise de impacto, prazo final, início do relógio, exceções, esquema interno, número de titulares e qualquer implantação em produção.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
