Resumo

  • A ACSP 2023.1 registra que AS13335:AS-CUSTOMERS, mantido por cargas automatizadas na API XML, foi convertido pela ARIN em RPSL com muitos membros em uma única linha física members:.
  • O autor exibiu uma consulta recursiva a um espelho que acreditava usar IRRd v3; a resposta completa trouxe apenas sete ASNs. A ARIN concordou que limitar os itens por linha melhoraria as consultas e manteve a sugestão aberta até a implementação.
  • Conjunto lógico, atributos RPSL, bytes serializados, objeto importado, resultado recursivo e filtro gerado são estados distintos. A validade do primeiro não prova a integridade dos demais.
  • Um recibo de serialização entre espelhos deve ligar contagem e resumo canônicos aos bytes exatos, limites de linha, identidade da importação, contagem analisada e resumo do resultado, com sinal explícito de rejeição ou truncamento.

A resposta curta no fim de uma cadeia longa

Na Sugestão ACSP 2023.1 da ARIN, Joe Abley relatou que a Cloudflare publicava AS13335:AS-CUSTOMERS por cargas XML automatizadas. A ARIN transformava os dados em RPSL e colocava uma grande sequência de ASNs em uma única linha members:.

A página mostra uma parte extensa da sequência, abrevia o trecho intermediário e apresenta alguns membros finais. Ela comprova o formato de linha longa, mas não é uma cópia integral capaz de fornecer hoje uma contagem canônica completa.

O registro também contém a saída de !iAS-CLOUDFLARE,1 em outro servidor. O autor disse acreditar que se tratava de uma instância IRRd v3 e apresentou a resposta como completa no protocolo: sete ASNs seguidos do terminador. Este artigo não repetiu a consulta e não supõe que o espelho histórico continue disponível.

Em 7 de fevereiro de 2023, a ARIN respondeu que reduzir o número de itens por linha produziria resultados melhores nas consultas de AS-SET. Disse que investigaria os requisitos, programaria o recurso para desenvolvimento futuro e manteria a sugestão aberta até a implementação. A página ainda aparece como Open. Isso descreve o tíquete público; não demonstra que a saída atual da ARIN continua idêntica.

O limite factual também exclui conclusões sobre o roteamento atual da Cloudflare. Não há prova de filtro incorreto, vazamento de rota, interrupção ou sequestro. O que o registro estabelece é uma divergência histórica entre uma publicação rica e uma resposta derivada muito pequena.

Um conjunto assume várias formas

O RFC 2622 define members como atributo opcional e multivalorado. Cada valor pode ser uma lista de números de AS ou nomes de outros AS-SETs. Uma lista com muitos itens e um atributo que pode se repetir são propriedades independentes.

Há também a forma física do texto. Cada par atributo-valor começa em uma linha; o valor pode continuar quando a linha seguinte se inicia por espaço, tabulação ou sinal de mais. Como members é multivalorado, a chave também pode aparecer várias vezes. Assim, o mesmo conjunto lógico pode ocupar uma linha enorme, várias ocorrências do atributo ou linhas de continuação. O significado pode ser equivalente, mas os bytes, o número de linhas e o comprimento máximo não são.

Essa diferença vira contrato de interoperabilidade. Um analisador recente pode aceitar linhas de muitos quilobytes; um leitor legado pode impor buffer ou tamanho de campo menor. Todos os bytes podem chegar e, ainda assim, o importador preservar só o começo. Uma atualização rejeitada pode deixar a versão anterior visível.

A ACSP não publica rastreamento do analisador nem banco do espelho. Portanto, não prova qual mecanismo ocorreu e não autoriza culpar um buffer ou defeito específico do IRRd. Ela demonstra que a serialização física merece medição própria.

O serializador integra a interface operacional

A visão atual do IRR da ARIN afirma que objetos simples submetidos em XML são convertidos no back-end para RPSL. O guia da API REST descreve representações XML e RPSL e define members como ASNs ou outros AS-SETs integrantes.

O publicador controla a coleção enviada. A ARIN controla como o XML se transforma em RPSL físico. Segundo a sugestão histórica, o esquema XML não permitia escolher quantos membros apareceriam em cada linha; o código de construção da ARIN tomava a decisão.

Dividir a linha é uma mitigação sensata, pois reduz a exposição a limites de leitores antigos. Mas não é prova final. A interface pode quebrar visualmente a linha sem alterar a exportação. O espelho pode aceitar todas as linhas e ainda impor limite de membros. A consulta recursiva pode variar pela seleção de fontes mesmo com o objeto intacto.

O teste completo compara significado e bytes: contagem e resumo normalizados na origem, bytes realmente exportados, bytes recebidos e conjunto analisado no destino.

O espelho é uma nova fronteira de custódia

A ARIN oferece NRTM, arquivos e Whois e identifica o servidor atual como IRRd Version 4. A documentação de espelhamento do IRRd descreve instantâneos e atualizações que são obtidos, analisados, validados e gravados em um banco local.

O espelho não é uma janela passiva. Possui versão, configuração, política de fontes, histórico de importação e tratamento de erros próprios. A publicação completa na origem não prova armazenamento completo no espelho; armazenamento completo não prova resultado recursivo sob a fonte e profundidade esperadas.

Três comparações são necessárias. Os bytes recebidos correspondem aos exportados? Os membros normalizados armazenados correspondem ao conjunto de origem? A consulta com parâmetros explícitos corresponde ao estado armazenado? Sem a etapa intermediária, uma resposta curta não revela se a perda surgiu no transporte, na importação ou na resolução.

A atomicidade das cargas modernas evita que usuários vejam uma importação pela metade. Ela não certifica a semântica de um objeto aceito. Tampouco permite deduzir o comportamento de um espelho antigo a partir da versão atual.

A expansão recursiva é um cálculo local

A documentação Whois do IRRd descreve !i como consulta de dados processados. Com recursão, o sistema percorre conjuntos aninhados e devolve membros separados por espaços. Não é o texto RPSL bruto.

Uma leitura direta mostra o que o espelho guardou. A consulta recursiva mostra o que seu grafo local deriva. Um gerador de filtros pode então buscar prefixos e compilar política para roteadores. Cada artefato depende do anterior, mas não é equivalente a ele.

Uma resposta curta pode estar corretamente terminada e, por isso, parecer segura à automação. O código de sucesso comprova a conclusão do protocolo, não a completude do conjunto. Antes da geração de filtros, o consumidor precisa comparar o universo resultante com uma identidade esperada.

Um recibo para comparar significado e bytes

Um recibo de serialização entre espelhos tornaria a fronteira observável. É recomendação editorial, não compromisso publicado da ARIN, do IRRd ou da Cloudflare.

Na origem, o recibo registraria chave do AS-SET, versão ou série, contagem canônica e resumo dos membros sob ordenação documentada. Identificaria o serializador e incluiria resumo dos bytes RPSL exatos, tamanho total, número de linhas e maior linha.

No espelho, registraria fonte, instantâneo ou intervalo NRTM, horário, versão do analisador e resultado. Compararia o resumo recebido e informaria resumo do objeto armazenado, contagem e resumo dos membros analisados. O estado distinguiria completo, rejeitado, truncado, parcialmente analisado ou antigo após falha.

No momento da consulta, acrescentaria comando, fontes, recursão ou profundidade, exclusões, horário, contagem e resumo do resultado. O gerador poderia vincular o resumo do filtro sem publicar configuração privada.

O recibo não impõe software único nem autoridade central de roteamento. Ele revela o primeiro ponto em que duas representações deixam de carregar o mesmo significado.

Fontes