Resumo

  • O Draft 2 preserva a regra de 90% e propõe uma dispensa para finalidades técnicas essenciais demonstradas.
  • O processo deveria registrar topologia, tamanho do prefixo, cálculo de utilização, alternativas e controles antifraude.
  • O consenso aproximado da AFRINIC 37 e o status Last call não significam ratificação nem implementação.

Nota de publicação: Publicado é a data editorial programada, 7 de setembro de 2026. O horário efetivo de publicação no servidor ainda não está definido.

A seção 5.4.6.1 do CPM atual exige que um LIR ou End User que solicite outra alocação ou atribuição IPv4 durante a fase de exaustão tenha utilizado pelo menos 90% dos recursos anteriores. A primeira solicitação de um novo LIR ou End User sem recursos anteriores é exceção.

O AFPUB-2026-IPv4-002-DRAFT02, de 16 de junho de 2026, após o primeiro rascunho de 6 de maio, manteria essa base. A AFRINIC poderia dispensar o limite quando uma finalidade técnica essencial, demonstrada, não pudesse ser atendida na prática pelo pool existente do operador ou criasse restrições técnicas para ele. Os exemplos não exaustivos são redundância e alta disponibilidade, mecanismos de transição IPv6 e expansão para novos sites. A justificativa teria de ser documentada para permitir verificação, mas o texto não define um esquema público de evidências, conjunto mínimo de documentos, registro decisório ou publicação dos casos.

Essa lacuna importa para tratamento igual, resistência a fraude e decisões auditáveis dos hostmasters. Os exemplos de expansão de data center e de um ISP com vários pontos de presença BGP usando 464XLAT e NAT64 são ilustrações do autor da proposta, não prova verificada sobre um membro específico. A referência a cerca de três milhões de endereços IPv4 recuperados também é argumento atribuído ao autor, não medição independente do estoque neste material.

A equipe da AFRINIC entende que 90% continua sendo a condição básica e que a exceção deve cobrir restrições técnicas, não operacionais. Diz que será necessária uma política documentada para hostmasters e que os procedimentos deverão detectar pedidos fraudulentos. Procedimentos e FAQs do Member Services precisariam ser atualizados; não foram identificadas mudanças em WHOIS, RDAP, MyAFRINIC, NetSuite, NMRP ou RPKI. A avaliação de implementação em até 30 dias após a ratificação é plano, não evidência de ratificação ou implementação.

Na AFRINIC 37, em 24 de junho de 2026, discutiram-se os desafios de atingir 90% em múltiplos sites e a diferença entre uso eficiente e topologia operacional. A decisão formal da presidência registrou consenso aproximado e disse que a Secretaria compartilharia uma definição de utilização durante o Last Call. Uma fala no microfone inicialmente disse que a proposta não havia passado; o copresidente do PDWG esclareceu que ela havia alcançado consenso aproximado. No congelamento do relatório, a página atual indica Last call. Essa etapa é distinta de recomendação posterior ao Board, ratificação e implementação.

Análise BTW: pacote de evidências recomendado. O dossiê deveria apresentar topologia, sites e papéis dos serviços; justificativa do tamanho do prefixo; cálculo de utilização atual e projetada; alternativas consideradas; necessidade limitada no tempo; verificações antifraude; identidade do revisor; data da decisão; condições e revisão posterior. Um recibo decisório deveria registrar regra, evidências decisivas, razões e condições. Esta é uma recomendação da BTW, não produto ou requisito adotado pela AFRINIC.