Resumo

  • Na série 23421, o Routinator 0.14.2 público da AFRINIC registrou 39.059 VRPs válidas de entrada, 8.212 duplicatas e 30.847 VRPs finais.
  • Na série 23422, os dois primeiros números passaram a 39.058 e 8.211; o total final permaneceu 30.847, com toda a mudança concentrada em IPv4.
  • A documentação define duplicatas como VRPs geradas por ROAs com a mesma autorização e alerta que a atribuição pode variar conforme a ordem de processamento.
  • As capturas não apontam a tupla, a ROA ou o titular, nem demonstram efeito em BGP. Falta um recibo de linhagem que conecte fontes, multiplicidade, conjunto único e evidência separada do roteador.

A mudança ocorreu antes da última coluna

A validação de série 23421 foi concluída em 29 de agosto às 06:37:53 UTC. Para a âncora de confiança da AFRINIC, o serviço mostrou 39.059 VRPs encontradas presentes e válidas. Classificou 8.212 como duplicatas. Não havia VRPs inseguras nem filtradas localmente. O cálculo até a saída era, portanto, transparente: 39.059 menos 8.212 resultava nas 30.847 que contribuíam para o conjunto final.

Às 06:57:08 UTC terminou o ciclo seguinte, de série 23422. As entradas válidas foram a 39.058 e as duplicatas a 8.211. A saída ainda era 30.847. Uma ocorrência deixou de aparecer antes da deduplicação; o número de autorizações únicas atribuído àquela âncora não diminuiu.

O recorte por família ajuda a não ampliar o fato. Em IPv4, o total passou de 37.804 para 37.803 e as duplicatas de 8.136 para 8.135, enquanto as finais ficaram em 29.668. Em IPv6, total, duplicatas e finais continuaram em 1.255, 76 e 1.179. Os pontos de publicação válidos permaneceram 1.408; os rejeitados, zero.

Outra linha também se moveu. A primeira resposta contava 12.171 ROAs válidas e nenhuma inválida. A segunda contava 12.170 válidas e uma inválida. A simetria permite formular uma hipótese, mas o endpoint não fornece o elo necessário para adotá-la. Não há hash, URI ou identificação da ROA que associe aquela mudança ao desaparecimento da ocorrência duplicada.

O que está provado é um par de estados de um validador. Não está provado que um detentor retirou, reemitiu ou corrigiu uma autorização. Não está provado que a AFRINIC praticou a ação responsável pela diferença. Não aparece uma rota BGP afetada nem uma decisão tomada por qualquer roteador.

Também convém limitar a frase “o conjunto final não mudou”. O que não mudou foi sua quantidade. Dois conjuntos com 30.847 elementos podem ter conteúdo diferente se uma tupla sair e outra entrar. A aritmética observada é consistente com a perda de uma ocorrência redundante, mas apenas um diff das tuplas pode demonstrar identidade de conteúdo.

Cada camada responde a uma pergunta própria

Uma Route Origin Authorisation é um objeto assinado na RPKI. Ela indica um AS de origem e contém uma ou mais autorizações de prefixo, com comprimento e, quando usado, comprimento máximo. O arquivo tem certificado, local de publicação e estado de validação.

Uma Validated ROA Payload é o resultado reduzido que o validador oferece para a validação de origem: endereço IP, comprimento do prefixo, comprimento máximo e ASN de origem. Uma ROA pode gerar várias VRPs. Objetos ou caminhos de publicação distintos podem gerar a mesma tupla.

A duplicata é uma ocorrência adicional dessa mesma autorização. Segundo a métrica do Routinator, ela resulta de ROAs que contêm a mesma autorização. Remover a multiplicidade antes do conjunto final não condena a autorização restante e não revela uma rota duplicada. Evita apenas fornecer duas cópias equivalentes da mesma instrução.

A rota BGP pertence a outra superfície. Ela contém um prefixo e um caminho de AS do qual se deriva a origem. A validação verifica se ao menos uma VRP combina com a rota, se alguma a cobre sem combinar, ou se nenhuma a cobre. Daí vêm os estados Valid, Invalid e NotFound. Nenhum deles é dedutível do total de duplicatas de uma âncora.

Há ainda a decisão do operador. O cache pode disponibilizar o conjunto final pelo protocolo RPKI-to-Router, mas a rede escolhe o cache, recebe uma série e aplica política local. A existência de uma sessão não prova que uma rota específica foi aceita, rejeitada ou rebaixada.

Essas separações identificam os responsáveis. O detentor assina a autorização. O repositório publica. O validador busca, verifica e atribui ocorrências conforme configuração e ordem. A rede decide como usar o resultado. A AFRINIC opera o serviço observado e sua âncora; isso não a transforma em autora de toda ROA sob a cadeia nem em operadora de todo roteador consumidor.

Duplicação é multiplicidade observada, não nota de qualidade

Fora da RPKI, a palavra duplicata sugere uma cópia inútil. Dentro de uma infraestrutura distribuída, duas ocorrências equivalentes podem surgir de sobreposição, renovação, migração, redundância de publicação ou erro. O contador agregado não distingue essas possibilidades.

A documentação do Routinator acrescenta uma ressalva central. Se uma VRP aparece em mais de uma âncora de confiança ou repositório, qual ocorrência será considerada a duplicata depende da ordem de processamento. Como essa ordem pode mudar entre validações, a atribuição e o próprio número podem variar de modo inesperado.

Logo, a coluna é uma medição local. Ela descreve este software, nesta versão, com esta configuração, estes repositórios e este instante. Não mede diretamente o cuidado de um detentor e não funciona como avaliação institucional da AFRINIC.

O mesmo impede uma tabela competitiva entre RIRs. Quantidades diferentes por âncora podem refletir grafos de publicação e regras de atribuição diferentes. Um número alto não comprova má higiene; zero não comprova perfeição. Comparar exigiria manter instrumento e objetos constantes e expor a linhagem.

Neste caso, o 30.847 inalterado é uma trava contra exagero. A alteração na multiplicidade não reduziu a quantidade final. Isso enfraquece qualquer alegação de perda automática de autorização única. Mas a trava não autoriza o extremo oposto: dizer que nada relevante ocorreu sem verificar o conteúdo e o recebimento downstream.

O vocabulário correto deve carregar o limite. O validador contou uma ocorrência válida e uma duplicata a menos; o total final atribuído à âncora ficou igual. A causa permanece não resolvida e o efeito em roteamento não foi observado.

O endpoint é uma boa fotografia, não uma ata causal

O serviço público oferece uma base incomum para análise. A documentação descreve o endpoint como fonte JSON exaustiva sobre âncoras, repositórios, conexões RRDP e rsync e sessões RTR e HTTP. Ele alimenta a interface que exibe as estatísticas do último ciclo. Versão, série e horários dão identidade à captura.

Ainda assim, “exaustivo” qualifica o retrato do serviço, não uma história completa de mudanças. A resposta não publica o diff entre 23421 e 23422 que ligaria hashes de ROA, URI, certificado, tupla, multiplicidade e causa. Os números têm data; a ação que os alterou não tem sujeito público.

As sessões RTR também não fazem o papel de recibo do roteador. Uma conexão pode existir sem provar a série instalada. Uma série instalada não prova a presença de determinada rota BGP. Uma rota validada não prova a ação de política. Cada afirmação exige a evidência de sua camada.

Preservar essa cadeia não obriga a divulgar topologia interna ou identidade de clientes. Hashes de objetos públicos, tuplas de autorização, contagens, transições e correções podem compor uma camada pública limitada. Diagnósticos sensíveis ficam em um registro protegido. O essencial é não deixar o agregado órfão.

Uma ficha de linhagem daria nome à diferença

O cabeçalho registraria versão e impressão da configuração, série de validação, início e fim, conjunto de âncoras e impressão do conjunto de repositórios. Dessa maneira, nenhuma contagem se apresenta como censo universal.

Para cada tupla única afetada, viriam ASN de origem, prefixo e comprimento máximo. Os hashes e URI das ROAs fonte, com referências à cadeia de certificados, mostrariam de onde vieram as ocorrências. A ficha indicaria multiplicidade antes e depois e a atribuição de duplicata em cada ciclo.

A classificação da mudança precisaria ser conservadora. Retirada observada, reemissão, falha de validação, indisponibilidade do repositório ou mudança de atribuição só entrariam quando demonstradas. Enquanto isso, não resolvida seria uma situação registrável e corrigível.

O bloco seguinte traria o diff do conjunto final: a tupla entrou, saiu ou permaneceu, ligado à série do cache. Qualquer alegação de efeito operacional começaria em outro bloco, com recibo de cliente RTR, rota contemporânea e política aplicada. O validador não falaria em nome da rede.

A ficha poderia revelar que duas ocorrências equivalentes viraram uma e a tupla única permaneceu. Poderia também mostrar uma substituição escondida pelo mesmo total. Ela não existe para produzir alarme ou tranquilidade; existe para permitir que ambos sejam proporcionais à prova.

O papel registral mais forte é não ocupar o lugar dos outros

Nenhuma captura identifica rede, rota, prefixo ou titular prejudicado. Não há prova de uma correção feita pela AFRINIC ou de uma mudança de decisão no roteador. Há dois estados precisos e um aviso explícito de que a atribuição de duplicatas pode variar.

Isso basta para uma conclusão institucional. A AFRINIC pode ser uma fonte confiável sobre o que seu validador registrou sem transformar essa observação em uma declaração sobre intenção do titular ou política de todas as redes. O detentor, o repositório e o operador conservam seus próprios campos de autoridade.

Um registro ganha confiança quando mantém fatos estreitos, versionados e corrigíveis. O valor de 30.847 não está em sugerir ausência de evento. Está em obrigar a investigação a mostrar exatamente onde a mudança parou.

Fontes