Resumo

  • A LAC-2026-3, publicada em 12 de agosto e ainda em discussão, exigiria pelo menos 80% de cobertura por ROAs válidos de quem solicitar recursos IPv4 ou IPv6 adicionais.
  • A conta abrangeria os recursos IPv4 e IPv6 já alocados ou distribuídos pela LACNIC à organização. O texto não determina perda imediata dos recursos atuais para quem estiver abaixo do limite.
  • O efeito dependerá da unidade de medida, da separação entre as duas famílias de endereços, do prazo de correção e de uma revisão capaz de refazer o cálculo contestado.

O prazo de segurança aparece quando a rede quer crescer

O índice independente de propostas dos RIRs registra a LAC-2026-3 como “Under discussion”, com mudança em 12 de agosto de 2026. A proposta dá consequência concreta a uma meta de adoção: antes de obter mais IPv4 ou IPv6, a organização precisaria demonstrar 80% de ROAs válidos sobre os recursos que já recebeu da LACNIC.

Isso concentra o impacto nas redes em expansão. Quem não precisa de novos recursos não encontra o teste imediatamente. Quem abre presença, ganha clientes ou prepara capacidade adicional pode ter o cronograma condicionado à manutenção de ROAs. Uma tarefa de segurança sem data passa a ter a mesma urgência de uma solicitação de endereços.

O alcance atual é mais estreito do que uma sanção. A proposta não está aprovada e não diz que um titular abaixo de 80% perde os blocos existentes. Ela cria uma condição para uma transação futura, caso avance no processo de políticas.

O denominador decide quem passa

“Cobertura” não é uma medida única. Os indicadores RPKI do Cloudflare Radar permitem contar a parcela de prefixos cobertos ou a parcela do espaço de endereços coberto, com séries distintas para IPv4 e IPv6. A mesma carteira pode ficar acima de 80% em uma visão e abaixo em outra.

Um bloco grande e vários pequenos têm pesos iguais quando cada prefixo vale uma unidade. Pela quantidade de endereços, o bloco grande domina. Se apenas o espaço anunciado entrar na conta, reservas não anunciadas desaparecem do denominador; se todos os recursos registrados entrarem, surge a dúvida sobre a utilidade de um ROA sem rota presente. Subalocações e origens de clientes ainda deslocam a responsabilidade operacional.

Também não há escala sensata para somar quantidades IPv4 e IPv6. As duas famílias precisam de resultados separados ou de uma regra explícita para o caso em que uma delas não existe na carteira. Um percentual fácil de comunicar só é justo se a fórmula for igualmente fácil de reproduzir.

ROA válido é uma autorização específica

A RFC 6482 define o ROA como objeto assinado pelo qual o detentor de um bloco autoriza um sistema autônomo a originar um ou mais prefixos. O campo maxLength pode limitar os anúncios mais específicos. A orientação operacional da Cloudflare explica como essa relação verificável entre prefixo e ASN apoia a filtragem de rotas.

Essa evidência não certifica toda a operação de uma empresa. Um ROA válido não prova que cada anúncio real está correto nem que todos os validadores receberam a mesma publicação no mesmo instante. A falta de ROA tampouco prova sequestro de rota. A política precisa distinguir validade do objeto, cobertura do inventário e estado das rotas observadas.

Mudanças normais geram diferenças temporárias. Uma migração troca o ASN de origem; um anúncio mais específico ultrapassa o maxLength; uma autorização expira durante a substituição; um repositório fica atrasado. Sem período de correção, uma fotografia ruim pode transformar um incidente técnico em atraso de capacidade.

O benefício de um incentivo não elimina o dever de explicar

Há um ganho provável. Campanhas de conscientização competem com falhas e entregas urgentes. Vincular o inventário RPKI a uma solicitação faz as equipes removerem autorizações antigas, criarem ROAs ausentes e conferirem origens. Quem pratica validação de origem recebe dados melhores.

Mas a métrica deixa de ser apenas educativa quando pode interromper um pedido. A descrição independente da LACNIC inclui alocação e registro de recursos entre suas funções. A LAC-2026-3 ligaria essa função a uma avaliação de segurança dos recursos distribuídos anteriormente.

No The Policy Mirror, Lu Heng separa a manutenção estreita de um registro confiável de condições mais amplas impostas no acesso a recursos escassos. A proposta fica na fronteira: o dado de ROA é diretamente relacionado ao endereço, mas a força para corrigi-lo vem da próxima alocação. Assim, conhecer, reparar e contestar a conta faz parte do desenho técnico.

Todo déficit deve vir com uma forma de reparo

Uma próxima versão deveria publicar numerador, denominador, horário da validação e um exemplo completo com IPv4 e IPv6. O solicitante precisa receber a lista exata do que reduziu a nota e códigos distintos: ROA ausente, objeto inválido, ASN divergente, comprimento não coberto ou titularidade em disputa.

Problemas corrigíveis merecem prazo sem perda da posição do pedido. Falhas do repositório ou do validador não podem ser lançadas na conta do solicitante. Uma exceção legítima deve ter critério estreito, documento e trilha de auditoria, não depender de negociação reservada.

A revisão deve conseguir verificar a carteira, a fotografia RPKI e a aplicação da fórmula. Estatísticas agregadas sobre os motivos de insuficiência mostrariam se a regra está corrigindo negligência, encontrando ambiguidades ou produzindo bloqueios.

Os 80% podem se tornar um piso útil de manutenção. Hoje ainda são parte de um texto em discussão. A LAC-2026-3 identificou um momento poderoso para melhorar a cobertura: quando a organização quer crescer. O próximo passo é garantir que esse poder leve a uma correção verificável, não a uma recusa indecifrável.

Fontes