Resumo

  • A sugestão 2026.11 da ARIN pede que rpki.arin.net e rrdp.arin.net respondam a solicitações ICMP Echo. A página pública mostra o status “Confirmed”, não informa prazo e não apresenta registro de implantação.
  • Uma resposta Echo responde a uma pergunta restrita sobre alcance a partir de uma sonda específica. Ela não comprova que um validador obteve o repositório, sincronizou seu estado mais recente ou validou os objetos assinados.
  • Operadores precisam de observações separadas para alcance de rede, obtenção do repositório e atualidade dos dados assinados. O ping só ajuda quando seus limites permanecem visíveis.

O status aparece antes do cronograma

O registro público da sugestão 2026.11 da ARIN é curto. Job Snijders a apresentou em 6 de outubro de 2026, pedindo que rpki.arin.net e rrdp.arin.net respondam a solicitações ICMP Echo. Segundo o autor, isso ajudaria a diagnosticar conectividade, monitorar alcance e otimizar caminhos. A página exibe o status “Confirmed”, mas diz que o prazo não foi especificado. As seções visíveis de acompanhamento e comentário da ARIN não contêm resposta nem detalhe de lançamento.

Esses são os fatos públicos. “Confirmed” é o rótulo exibido na página; ela não define o que o status significa no fluxo interno. Não se deve convertê-lo em “implementado”, “agendado” ou promessa de lançamento iminente. A página não registra medição dos endpoints, resultado para usuários ou incidente.

A sugestão também afirma que outros três serviços da ARIN já respondem a solicitações Echo e que os demais RIRs permitem ping em seus endpoints públicos de Rsync e RRDP. Essas comparações constam da própria submissão. Este artigo não as verificou por medições independentes.

O que uma resposta Echo pode informar

ICMP Echo é um diagnóstico conhecido porque faz uma pergunta simples: uma resposta voltou do endereço consultado para esta sonda? A resposta vale para a localização da sonda, a família de endereços, a rota e aquele momento. Ela pode ajudar a investigar um problema aparente de caminho ou alcance. Não testa todos os caminhos de aplicação associados ao mesmo nome de host, e o silêncio não prova por si só que o serviço do repositório falhou.

Essa distinção importa especialmente no RPKI. A ARIN descreve seu serviço como publicador de certificados de recursos e declarações de origem assinadas que operadores obtêm e validam. O repositório fornece dados aos validadores; a resposta ICMP não é uma dessas declarações assinadas nem integra o resultado de validação.

Três perguntas exigem três observações

A primeira é alcance de rede. Uma resposta Echo indica que uma sonda recebeu retorno na camada de rede. O sistema de monitoramento também deve identificar o ponto de observação, a família de endereços e o horário. O sucesso em um ponto não representa alcance global.

A segunda é obtenção e sincronização do repositório. O RRDP tem sua própria troca na camada de aplicação. A RFC 8182 descreve um arquivo de notificação com identificador de sessão e número de série, um snapshot atual e, quando disponíveis, deltas. O validador obtém esses arquivos e verifica seus hashes antes da sincronização. A obtenção via Rsync é outra transação concreta do serviço. Uma resposta ICMP não executa nenhuma dessas operações.

A terceira é estado e validade dos dados. A RFC 9286 define manifestos assinados que listam objetos do repositório e seus hashes, além de informações de atualização. Os requisitos para validadores explicam como o software avalia o estado do manifesto, inclusive nos casos de conteúdo desatualizado ou inválido. Um servidor pode responder ao ping e ainda assim falhar em uma verificação separada de obtenção ou atualidade; também pode não responder ao ping enquanto o download da aplicação funciona. Nenhuma divergência prova um incidente na ARIN. Ela mostra por que os sinais não devem ser combinados.

Um registro útil de monitoramento manteria as camadas separadas

Se a ARIN implementar a sugestão, um registro para operadores poderia identificar o endpoint, o escopo da sonda e a data de publicação, e depois separar os resultados: resposta Echo; obtenção da notificação RRDP e dos objetos; obtenção via Rsync; sessão/número de série RRDP observados; e atualidade do manifesto ou resultado de validação. Cada campo precisaria de horário e fonte de medição próprios. A nota de lançamento poderia informar quais endpoints e famílias de endereços foram cobertos, quando a mudança chegou à produção e o que foi verificado depois.

Esse é um desenho de prestação de informação, não um compromisso assumido pela ARIN. Também não exige que cada validador use ICMP. Cada rede pode decidir se inclui Echo em seu conjunto de diagnósticos e continuar verificando o repositório pelo protocolo que realmente consome.

Separar os sinais pode acelerar a investigação. Se Echo falha, mas RRDP funciona a partir do ponto de observação relevante, o primeiro resultado não deve ser tratado como prova de falha na publicação RPKI. Se Echo funciona, mas RRDP não consegue obter uma notificação ou um objeto, a resposta não deve suprimir o alerta da aplicação. Se os arquivos chegam, mas o manifesto assinado está desatualizado ou inválido, o alcance de rede não é o fato determinante. Cada resultado aponta para uma investigação distinta.

A solicitação de ICMP é útil justamente por ser modesta. Ela pede um sinal diagnóstico adicional, não uma mudança na confiança do RPKI. Não se deve atribuir a esse sinal mais autoridade do que ele tem.

O que continua desconhecido

Em 14 de outubro de 2026, a página pública da sugestão não informa data de entrega nem evidência posterior à implementação. Este artigo não mediu de forma independente o comportamento atual dos dois hosts. As fontes citadas não comprovam interrupção, repositório desatualizado, falha de validação, efeito no roteamento ou prejuízo a clientes. O status exibido não responde a essas perguntas.

A regra prática para os operadores é registrar alcance como alcance, sincronização do repositório como sincronização e validação criptográfica como validação. Se a sugestão passar de rótulo de status a mudança implantada, o registro público deve tornar essa transição visível. Até lá, “Confirmed” é um status publicado, não um segundo sinal.

Fontes