Resumo

  • A Sugestão ACSP 2026.3 relatou que, diante de um ROA /16 com maxLength /24, novos prefixos do mesmo Origin AS entre /16 e /24 eram redundantes, enquanto /25 a /32 continuavam possíveis.
  • A ARIN atualizou a FAQ e encerrou o item como concluído, mas o exemplo hoje publicado diz apenas “any prefix covered”, sem manter os dois lados da fronteira.
  • Um recibo versionado com cinco testes de semântica pode provar a regra de admissão na interface web, na API REST e em OT&E sem revelar código, chaves ou dados de clientes.

A resposta institucional foi boa

Chris Woodfield apresentou a Sugestão ACSP 2026.3 em 13 de janeiro de 2026. O relato tinha a qualidade que um processo de melhoria precisa: reproduzia a formulação problemática, descrevia o comportamento observado, isolava a diferença e oferecia uma redação substituta.

Em 18 de fevereiro, a ARIN informou que havia atualizado a FAQ para resolver a confusão e encerrou a sugestão como implementada. Cerca de cinco semanas separaram o relato da resposta. O histórico ficou público, com autoria e decisão. Isso mostra um canal de participação que consegue transformar experiência de uso em mudança concreta.

A escolha de reduzir ROAs redundantes também é defensável. A renovação automática tirou a necessidade antiga de criar uma cópia antes de o ROA existente expirar. Objetos que não ampliam uma autorização podem poluir a lista, induzir a edição do registro errado e complicar uma exclusão. Uma regra de admissão mais estrita pode manter o serviço hospedado compreensível sem alterar o significado criptográfico de RPKI.

O ponto, portanto, não é negar o mérito da resposta nem exigir que a ARIN aceite toda estrutura permitida pelo formato. É perguntar qual evidência liga a sugestão aceita ao estado que recebeu o rótulo “concluído”.

O próprio pedido continha um teste de aceitação

A formulação antiga citada na sugestão começava com um ROA para /16 e maxLength /24. Ela dizia que outro ROA, usando o mesmo Origin AS, seria impedido para qualquer prefixo dentro daquele /16. O autor informou que seus testes encontraram uma regra mais estreita.

Para o mesmo AS, máscaras entre /16 e /24 já estariam autorizadas pelo objeto existente; a nova entrada não acrescentaria autoridade e seria rejeitada como redundante. Máscaras de /25 a /32, embora ainda contidas no espaço do /16, ultrapassariam o maxLength. Segundo o teste relatado, elas poderiam ser criadas em outro ROA.

O texto sugerido trocava “overlapping” por “redundant” e preservava o intervalo proibido e o exemplo permitido. Esse segundo lado evita um erro comum: confundir inclusão de endereços com equivalência de autorização. Ele também permite uma verificação simples, usando um prefixo de cada lado de /24.

A FAQ atual de RPKI diz que a renovação automática tornou duplicatas desnecessárias e que ROAs não podem mais se sobrepor. No exemplo do /16 com maxLength /24, outro ROA do mesmo Origin AS é impedido para “any prefix covered in the existing ROA”. O texto não mantém o intervalo de /16 a /24 nem informa que o de /25 a /32 formava o contraexemplo proposto.

Isso é uma comparação documental, não uma acusação de defeito. Não foi feita uma operação autenticada em produção ou em uma conta de cliente. O comportamento de janeiro é o relato do autor da sugestão. A implementação atual pode estar correta e uniforme; “covered in” pode ter sido escolhido como abreviação de “já autorizado”. A lacuna está em não haver prova pública suficiente para fixar essa leitura.

Coberto no endereço não é necessariamente casado pelo VRP

O RFC 6811 separa relações próximas. Um prefixo de rota é Covered por um VRP quando o prefixo do VRP é igual ou menos específico e os bits relevantes coincidem. Essa etapa não usa o comprimento máximo. Para ser Matched, a rota também precisa ter comprimento menor ou igual ao máximo do VRP e Origin ASN igual.

A FAQ não apresenta “covered” como termo normativo, e não é preciso supor que quisesse fazê-lo. Ainda assim, quem trabalha com RPKI conhece as duas leituras. Um /25 sob o /16 é coberto no plano dos endereços, mas não corresponde a um VRP cujo maxLength termina em /24, mesmo com o mesmo ASN. O contraexemplo omitido era exatamente a peça que eliminava essa ambiguidade.

O RFC 6482 define maxLength no objeto assinado: é o prefixo mais específico que o AS pode anunciar; se o campo estiver ausente, só o prefixo exato é autorizado. O documento também permite que um ROA válido contenha uma entrada englobada por outra, ou até entradas de prefixo idênticas, embora desaconselhe a que não concede autoridade adicional.

Nada disso obriga a ARIN a aceitar todas essas formas em seu produto. Validade do objeto, resultado da validação de uma rota e regra de admissão do serviço são camadas distintas. A ARIN pode selecionar um subconjunto operacional mais limpo. Justamente por ser uma escolha de produto, porém, a fronteira deve ser publicada como tal.

As superfícies públicas mostram os campos, não o predicado

O guia de ROAs da ARIN define um ROA por Origin AS, prefixo e comprimento máximo. Também repete que duplicatas e sobreposições não são permitidas, remetendo o detalhe à FAQ. Não há uma matriz de fronteira nessa página.

O guia da API REST de RPKI documenta uma transação unificada capaz de criar, modificar e excluir ROAs. Ela pode ser combinada de forma atômica com operações ASPA: tudo tem êxito ou tudo falha. O payload expõe startAddress, cidrLength e maxLength; a página direciona erros à lista geral, mas a captura examinada não formula o teste completo de duplicidade ou sobreposição.

A atomicidade cria uma borda relevante. Se uma requisição remove um ROA antigo e cria o substituto, a redundância é avaliada contra o estado inicial, o estado final pretendido ou alguma etapa intermediária? O serviço precisa ter uma resposta coerente. A ferramenta que faz pré-validação precisa da mesma resposta, pois a rejeição de um item derruba a transação inteira.

O ambiente OT&E é apropriado para experimentar sem mudar a produção. A ARIN informa que ele oferece o mesmo conjunto de recursos, permite criar ROAs de teste e validar payloads antes de alterar configurações reais. Também deixa claro que o ambiente é separado, recebe uma cópia mensal dos dados, não oferece interações por email e não é monitorado ativamente pela equipe.

OT&E permite reproduzir, mas não transforma um teste em contrato durável. Depois de uma atualização mensal, o estado inicial pode mudar. Depois de uma versão, o comportamento pode mudar. Sem a tupla, a expectativa, o build e a data, o resultado volta a ser apenas memória operacional.

Um recibo curto pode provar a entrega

O recibo deveria identificar a sugestão, a revisão documental, a versão da regra e a data de vigência. Cada linha traria o canal, o AS existente, o prefixo e maxLength, a nova tupla, o resultado esperado e um código de motivo estável. Data e versão de OT&E tornariam a prova repetível; revisões futuras apontariam para a versão substituída.

Cinco linhas cobrem a questão: mesmo prefixo e mesmo AS; prefixo mais específico ainda dentro de maxLength; prefixo além de maxLength; mesmo espaço com outro Origin AS; e uma transação atômica que exclui o objeto antigo e inclui o substituto. Prefixos de documentação e ASN reservados evitam expor qualquer cliente ou chave.

A FAQ poderia continuar curta. O recibo assumiria a precisão. Ele separaria três fatos: houve edição do texto; o serviço aceita ou rejeita certas tuplas; o estado “concluído” entregou a clarificação pedida. Eles se relacionam, mas não devem depender da mesma frase.