Resumo

  • O IRR Auto-Manager pode criar ou vincular um objeto de rota IRR durante a criação de um ROA, mas preserva escolhas que depois separam o ciclo de vida dos dois registros.
  • A ACSP 2026.9 pede um histórico de ações IRR equivalente ao histórico de ROA. Duas listas semelhantes melhoram a visibilidade, porém não identificam sozinhas quais eventos pertencem à mesma intenção.
  • Um recibo limitado entre registros pode documentar estado anterior, escolha, correspondência, resultado e correção sem tratar uma autorização ROA e uma declaração RPSL como dados idênticos.

A ARIN resolveu um problema que raramente ganha destaque, embora ocupe tempo de operadores. Um Route Origin Authorization e um objeto de rota no Internet Routing Registry descrevem superfícies relacionadas, mas tradicionalmente exigiam manutenção em sistemas distintos. Repetir o par prefixo-AS de origem cria mais uma tarefa e mais uma oportunidade para os registros se afastarem. O IRR Auto-Manager inclui a criação ou a vinculação do objeto route ou route6 no fluxo de criação do ROA.

O ponto de partida justo é reconhecer o mérito. A automação reduz digitação duplicada, sem retirar a decisão do titular. O serviço pode ser desligado para um Org ID. Mesmo quando está ligado, a criação do objeto IRR pode ser recusada em uma operação específica. Se já houver um objeto correspondente não gerenciado, o usuário escolhe substituí-lo por um objeto autogerenciado ou deixá-lo como está. Para ROAs existentes, a ferramenta Sync Up pode criar o objeto ausente ou vincular aquele que já existe.

O desenho também mantém uma saída. Um objeto IRR pode ser apagado independentemente, sem alterar o ROA. Na exclusão do ROA, o usuário pode apagar os objetos vinculados ou preservá-los como não gerenciados. Quando um ROA contém vários prefixos, a automação cria um objeto IRR para cada um. O vínculo simplifica a coordenação; não institui uma dependência permanente nem garante uma cardinalidade de um para um.

Há ainda uma diferença de significado que não deve ser suavizada. O ROA é uma autorização de origem assinada e pode conter maxLength, que limita a especificidade das rotas autorizadas. O objeto de rota IRR é uma declaração RPSL baseada em prefixo e AS de origem. O Auto-Manager usa a entrada de prefixo e não transforma maxLength numa série de objetos IRR mais específicos. A aparente assimetria de campos é uma proteção contra a fusão de dois modelos.

As APIs confirmam a fronteira. Na criação, roaSpec:autoLink controla se cada recurso do ROA será associado a um objeto apropriado, com criação se necessário. O campo autoLinked na resposta informa o resultado. A API IRR, por sua vez, continua permitindo operações independentes sobre os objetos. A conveniência atravessa os sistemas, mas a autoridade e o ciclo de vida de cada registro continuam próprios.

Portanto, a melhor defesa do estado atual é forte: a ARIN automatizou um trabalho delimitado, deixou escolhas explícitas e preservou a distinção de significado. A questão pendente não é se a automação presta algum serviço. É se a evidência visível acompanha a operação inteira que ela passou a oferecer.

O que o histórico de ROA já entrega

A documentação da ARIN descreve o Origin AS/Prefix Pair Change Log para ROAs novos e modificados de uma organização nos 365 dias anteriores. Acima de cem itens, os resultados são paginados. As colunas trazem Timestamp, Operation, Source, Origin AS, Prefix, Max Length e Changed By. A operação aparece como Added ou Removed; a fonte distingue Web User, API User e ARIN System. O usuário também pode solicitar por chamado um CSV completo. A ARIN diz que o pedido será revisto e respondido em até dois dias úteis e que o arquivo ficará disponível por 90 dias.

Isso é mais do que um inventário atual. O histórico localiza no tempo a inclusão ou a remoção de um par de origem e prefixo. Separa uma ação de interface de uma chamada de API e de uma ação do sistema. Uma alteração pode aparecer como os pares removidos e adicionados; não é preciso inventar uma opção pública Modified que a tabela não documenta.

Para os objetos IRR, a documentação pública consultada não descreve uma superfície equivalente. Em 11 de maio de 2026, Randal Kohutek apresentou a sugestão ACSP 2026.9 para adicionar registro de ações IRR igual ao registro de ROA. A formulação foi cuidadosa: o sistema IRR “não parece” incluir essa visibilidade. A observação não demonstra ausência de logs internos, histórico de banco de dados ou controles de segurança da ARIN.

Em 19 de maio, a ARIN concordou que a função beneficiaria clientes que precisam acompanhar ações sobre objetos IRR. Acrescentou a sugestão ao roteiro de segurança de roteamento, encaminhou-a ao processo interno de priorização e planejamento de implementação e encerrou o item. Reconhecer e encaminhar a necessidade em oito dias é uma resposta construtiva. Não equivale a anunciar versão, data, esquema ou disponibilidade atual.

Colunas iguais ainda deixam a operação sem identidade

Um futuro histórico IRR com hora, fonte, usuário e ação fecharia uma diferença evidente. O operador teria duas linhas do tempo. Ainda assim, continuaria a pergunta que mais importa durante uma investigação: quais eventos surgiram da mesma decisão?

Na criação do ROA, o sistema pode encontrar um objeto não gerenciado e permitir que ele seja substituído ou mantido. Vários prefixos geram vários objetos. Mais tarde, o objeto IRR pode ser apagado enquanto o ROA permanece. A exclusão do ROA pode apagar os objetos associados ou deixá-los como não gerenciados. Sync Up tanto pode criar como apenas vincular. Cada ramificação produz estados finais que não revelam automaticamente sua origem.

Horários próximos ajudam na busca, não provam causalidade. Duas linhas no mesmo segundo podem resultar de pedidos distintos. Duas linhas separadas por uma etapa de confirmação podem integrar uma única intenção. Um objeto ausente não informa por si só qual opção de exclusão foi tomada. Um objeto presente não revela se foi preservado de propósito ou recriado mais tarde.

Até a concordância atual pode esconder uma história. Um objeto IRR apagado separadamente e depois recriado por Sync Up volta a coincidir com o ROA. A comparação de valores mostra o estado do momento. A procedência da operação explica como esse estado foi alcançado. São funções diferentes.

Essa explicação tem valor mesmo sem um incidente conhecido. ROAs podem servir como entradas assinadas para validação de origem. Dados IRR podem ser usados para montar ou revisar filtros de política. Nenhum deles prova o que foi anunciado em BGP nem o que um roteador aceitou. Ainda assim, quando divergem, a equipe precisa diferenciar recusa explícita, objeto anterior, exclusão independente, relação de um para muitos, resultado parcial e correção.

O objeto adequado não é um fluxo público com a atividade de todas as organizações. É um recibo limitado para a parte autorizada, interpretado por um esquema público.

Um recibo que acompanha a ação

O recibo começaria com um identificador opaco de operação e uma marca de tempo. Indicaria a superfície inicial — ARIN Online, API RPKI, API IRR, Sync Up ou ARIN System —, uma classe de ator e a organização autorizada, sem expor um nome pessoal sem necessidade. A intenção seria explícita: criar ou modificar ROA, excluí-lo, criar ou vincular objeto IRR, substituir objeto não gerenciado, apagar apenas o IRR, preservá-lo como não gerenciado ou sincronizar novamente.

Em seguida viriam os estados anterior e posterior. No ROA: identificador, AS de origem, prefixo e maxLength. No IRR: chave route ou route6, prefixo, origem, condição gerenciada e estado do vínculo. Se um ROA abranger vários prefixos, a cardinalidade apareceria. Se já existisse um objeto, o recibo diria se foi reutilizado, substituído ou deixado intacto.

A decisão de saída precisa de um campo próprio. “Excluir o ROA e os objetos vinculados” não é igual a “excluir o ROA e manter os objetos como não gerenciados”. A ausência final não deveria ser a única prova. Se uma etapa funcionar e a outra falhar, o recibo deve separar os resultados e dizer se o estado esperado foi atingido. Uma correção futura deve apontar para o recibo que substitui, em vez de reescrever silenciosamente a história.

Não é preciso publicar chaves de API, identidades permanentes ou o histórico de outra organização. A ARIN pode preservar mais detalhes em seus controles internos, entregar o recibo ao titular autorizado e publicar o esquema, as regras de retenção, o formato de exportação e as mudanças de versão. Verificabilidade numa relação autenticada não exige exposição irrestrita.

O Auto-Manager já contém uma disciplina institucional adequada: coordena sem fundir, automatiza sem impedir a saída. A ACSP 2026.9 indica o próximo passo. A implementação mais útil não copiaria apenas as colunas do ROA para o IRR. Ela permitiria demonstrar se duas mudanças fizeram parte de uma operação ou se nasceram de escolhas independentes, sem obrigar o horário a provar o que ele não prova.

Fontes