Resumo

  • O Product Roadmap da APNIC coloca no terceiro trimestre de 2026 a exibição, no REx, de informações atuais e históricas de VRPs para recursos numéricos individuais; a ficha pública ainda não define campos, frequência de coleta, validador ou limite do arquivo.
  • Um ROA assinado, o VRP derivado por um relying party, o resultado Valid, Invalid ou NotFound de uma rota BGP e a política executada por um operador são quatro fatos distintos.
  • Cada intervalo histórico deveria trazer uma faixa de proveniência com recurso consultado e relação de cobertura, prefixo–maxLength–ASN de origem, instante observado, versão do conjunto, método de derivação, integridade da coleta e um aviso de que a tela não comprova a ação nem o encaminhamento de uma rede específica.

Toda linha do tempo conta uma história antes de apresentar sua legenda. Quando uma barra verde termina e uma vermelha começa, o leitor fornece os verbos: alguém mudou uma autorização, o sistema recebeu a mudança, o roteador reagiu. Talvez tenha sido isso. Talvez a tela esteja apenas colocando lado a lado duas observações de um sistema distribuído.

A APNIC pode resolver essa ambiguidade no desenho inicial. Seu roteiro de produtos inclui “Display RPKI VRP information for individual INR in REx”, sob a equipe de Information, com REx e RPKI como produtos e o terceiro trimestre de 2026 como alvo. Os resultados pretendidos são facilitar o acesso comunitário às informações de estado RPKI e acrescentar contexto histórico a cada recurso numérico da Internet.

Uma ficha de roteiro não precisa conter toda a especificação. Na captura examinada, o changelog do registro legível por máquina estava vazio. O texto público não informava quais campos serão exibidos, a cadência de observação, a implementação de validação, o conjunto de trust anchors, os identificadores dos objetos de origem, as regras de comparação ou a retenção. Isso não prova que a APNIC não tenha essas respostas internamente. Prova apenas que o contrato público de significado ainda não foi publicado.

Esse contrato ficará importante no instante em que o recurso entrar no ar. Uma imagem do REx pode aparecer em um chamado de abuso, em um relatório de incidente, na diligência de uma transferência ou em uma série acadêmica. Uma ferramenta de consulta adquire peso probatório porque terceiros começam a citá-la. Se a proveniência não viaja com o resultado, a confiança visual substitui a precisão.

Quatro registros, uma coincidência de identificadores

O mesmo prefixo e o mesmo ASN aparecem em diferentes camadas do RPKI. A repetição não transforma as camadas em um único estado.

Primeiro existe o ROA. A APNIC o descreve como um objeto assinado digitalmente que especifica qual sistema autônomo tem autorização para originar um prefixo. Ele carrega o ASN autorizado, o prefixo e o comprimento máximo. A RFC 9582 exige que o relying party valide o objeto assinado e execute as verificações próprias do ROA antes de utilizá-lo para validar um anúncio. Se uma verificação obrigatória falhar, o ROA inteiro deve ser considerado inválido.

Depois existe o VRP. Ele não é apenas outro nome para o arquivo assinado. A explicação técnica hospedada pela APNIC mostra o software de relying party buscando e verificando objetos RPKI e extraindo tuplas de ASN, prefixo do ROA, comprimento do prefixo e maxLength. O Validated ROA Payload é uma saída derivada naquele processo. Ele preserva a autorização relevante para o cálculo de origem, mas não comprova que outro validador tenha produzido o mesmo conjunto no mesmo segundo.

Em seguida vem o estado de uma rota. A RFC 6811 toma um prefixo BGP e seu ASN de origem. Se ao menos um VRP cobre o prefixo, permite seu comprimento e coincide com a origem, o resultado é Valid. Se há cobertura, porém nenhuma coincidência, é Invalid. Sem VRP que cubra o prefixo, é NotFound. Esses termos qualificam a rota avaliada, não o recurso isolado.

Por fim vem a ação do operador. A RFC 7115 deixa à política local a decisão sobre como usar o resultado. Uma rede pode descartar Invalid, outra pode primeiro observar, outra pode combinar a classificação com preferências, exceções e outros atributos. A classificação não contém uma ordem global. Também não comprova o caminho efetivo dos pacotes, pois o plano de controle BGP não garante o plano de dados.

Uma interface clara preserva esses quatro sujeitos. O titular assina dentro de sua autoridade. O relying party valida e deriva. Um observador ou roteador compara uma rota determinada com o conjunto. O operador decide. O REx pode declarar com autoridade o que sua própria metodologia observou; não pode herdar a autoridade das demais etapas porque todas contêm o mesmo prefixo.

O vazio não vem com causa embutida

A presença de um VRP oferece campos para exibir. A ausência oferece espaço para imaginar.

Um intervalo sem VRP aplicável pode coincidir com a retirada deliberada de um ROA. Também pode refletir expiração ou falha de validação de objeto, problema em certificado ou manifesto, atraso de publicação ou coleta, reset de cache, lacuna histórica, mudança de método ou uma consulta que não incluiu a relação de cobertura esperada. A linha do tempo, sozinha, não identifica a causa.

Por isso a frase segura é “nenhum VRP aplicável foi derivado nesta observação do REx”. Ela é diferente de “o titular deixou de autorizar o prefixo”. A primeira descreve um conjunto, um método e um instante. A segunda atribui uma ação e talvez uma intenção; precisa de evidência própria.

Essa modéstia torna o dado mais operacional. Um membro pode recuperar o snapshot e confrontá-lo com seu registro. Um pesquisador pode separar mudança no RPKI de mudança no arquivo. Uma equipe de suporte pode investigar uma divergência reproduzível. Um bloco vazio sem proveniência obriga todos a discutir primeiro o significado do desenho.

A palavra “atual” depende do relógio

A RFC 8210 torna visível a temporalidade do sistema. Ela trata o cache RPKI como uma cópia agregada dos dados publicados globalmente, obtida periodicamente por software de relying party. O serial identifica uma versão lógica do cache. Os intervalos de refresh, retry e expire indicam quando consultar novamente, quando tentar de novo e por quanto tempo uma versão anterior pode continuar em uso. Se o cache não consegue fornecer o histórico incremental, pode responder com reset e exigir uma carga completa.

O mesmo documento reconhece que caches distribuídos não permanecem rigorosamente síncronos. A observação do REx em um momento pode diferir, por algum tempo, da observação de um validador em Jacarta, Sydney ou Seul. Essa diferença não é automaticamente fraude, erro ou omissão. É a razão pela qual o ponto de vista integra o resultado.

O estudo de sincronização publicado no APNIC Blog separa os sistemas de publicação, cache intermediário e enforcement. Ele alerta que uma visão incompleta ou desatualizada pode produzir validações erradas e define um critério de atualidade para a própria pesquisa. Em vez de usar “recente” como adjetivo tranquilizador, os autores o transformam em condição de medição.

O histórico do REx deve seguir o mesmo método. Além de início e fim, cada período precisa de observed-at, fuso e release do conjunto. Se houver troca de validador, trust configuration relevante, lógica de reconstrução ou regra de comparação, a tela deve marcar a fronteira de método. Sem isso, uma alteração do instrumento parece uma alteração do objeto medido.

Identificar a perspectiva não exige revelar topologia interna, credenciais ou controles. Basta delimitar o enunciado: este conjunto do REx, produzido por este método documentado, estava completo ou qualificado desta forma neste horário.

Uma busca individual ainda pode ser exata ou abrangente

Ao inserir um /24, o usuário pode estar fazendo três perguntas. Há um VRP cujo prefixo é exatamente o /24? Existe um VRP mais amplo, como um /16, cujo maxLength autoriza o /24? Existem autorizações mais específicas dentro do espaço pesquisado?

As três visualizações são legítimas, mas têm significados diferentes. A cobertura definida na RFC 6811 depende dos bits e comprimentos do prefixo; maxLength limita até onde uma rota mais específica pode coincidir. Um selo sem a relação exata ou covering apaga o elemento que explica o resultado.

O REx deveria mostrar a relação da consulta como campo: exact, covering, more-specific ou uma visão agregada formalmente definida. Se várias tuplas forem relevantes, a interface não deve eleger uma representante. Ao mudar o conjunto, o histórico precisa indicar qual tupla entrou, saiu ou foi alterada. O mesmo total pode esconder troca de ASN de origem, redução de maxLength ou eliminação de uma autorização redundante.

Dez elementos para uma proveniência suficiente

Não é necessário criar outro painel complexo. Uma faixa junto de cada estado atual e período histórico poderia conter:

  1. O recurso digitado e a relação com o prefixo exibido: exata, covering, more-specific ou agregada.
  2. A classe de registro: ROA assinado, VRP derivado ou resultado sobre uma rota identificada.
  3. A tupla completa de prefixo, maxLength e ASN de origem.
  4. Início, fim, instante de observação e fuso; um intervalo aberto é atual apenas até a última coleta.
  5. Um identificador estável de dataset, release ou snapshot do REx.
  6. O método de derivação e sua versão quando isso afetar a comparação.
  7. O conjunto de trust anchors e uma nota limitada sobre integridade da obtenção.
  8. Um marcador de mudança metodológica ou lacuna de arquivo, para que falta de dados não pareça ausência de VRP.
  9. Links para a definição vigente e a observação seguinte.
  10. Uma frase inequívoca: a página não mostra o cache de um operador específico, sua política local, sua rota selecionada ou o trajeto real dos pacotes.

Esses elementos descrevem a afirmação pública. Não pedem chave privada, credencial de membro, detalhes sigilosos de incidente, política particular de rede ou topologia dos coletores.

O que poderá ser afirmado sem exagero

Com essa faixa, o REx pode dizer que sua metodologia derivou certa tupla em um snapshot identificável, que ela permaneceu em observações sucessivas, que foi substituída ou que um trecho não é comparável devido a lacuna ou mudança técnica. Terceiros podem reproduzir contagens; operadores podem colocar o registro público ao lado da visão local.

O REx não pode provar, com o primeiro vazio, que o titular retirou intencionalmente a autorização naquele momento. Não pode afirmar que todos os relying parties receberam a mudança juntos. Não pode chamar uma rota de Invalid sem informar seu prefixo e origem. Não pode deduzir que uma rede a rejeitou. E não pode, sem outros dados, comprovar sequestro, indisponibilidade, alteração de tráfego ou efeito comercial.

A pesquisa da APNIC sobre medir ROAs e ROV mostra como uma atribuição escapa do dado. Se um provedor upstream rejeita rotas Invalid, redes single-homed atrás dele podem parecer capazes de executar ROV por conta própria. O efeito observado existe; o agente inferido está errado. Uma perspectiva omitida transforma uma medição correta em uma história incorreta.

A futura memória do REx será mais útil como testemunha delimitada. Em uma investigação, ela poderá ser juntada a observações BGP, exportações locais, logs de roteadores, comunicações dos titulares e medições do plano de dados. Em pesquisa, cada snapshot terá método e comparabilidade. Em suporte, um membro poderá contestar uma linha concreta.

A APNIC prometeu acesso e contexto histórico. Não prometeu narrar a decisão de cada roteador. A proveniência é o mecanismo que mantém a promessa no tamanho certo.

Fontes