Resumo

  • O roteiro de produtos da APNIC inclui “Route management alignment” para o terceiro trimestre de 2026, com automação entre gestão de rotas, titularidade de recursos, Whois e RPKI depois de transferências, desalocações e mudanças de sistema.
  • As camadas têm funções distintas: a titularidade define autoridade registral; um objeto de rota no IRR publica intenção ou política; uma ROA autoriza um AS de origem; BGP mostra uma rota observada e submetida à política local.
  • O item público não informa precedência, fronteira transacional, estado de sucesso parcial, aviso nem prova de reversão. Isso demonstra uma lacuna de documentação pública, não a inexistência de desenho interno na APNIC.
  • Uma matriz de autoridade por tipo de registro e um recibo versionado por tarefa permitiriam automatizar a reconciliação preservando diferenças legítimas, o estado anterior e o caminho até a última situação segura.

Quatro relógios não produzem um único agora

Em uma transferência de recursos numéricos, a titularidade pode mudar em um instante definido pelo registro. Um objeto de rota pode desaparecer do Whois em outro. Uma ROA nova pode ser publicada e levar tempo para chegar aos caches dos validadores. Filtros derivados de IRR e anúncios BGP obedecem a decisões tomadas fora da APNIC. A palavra sincronização sugere um mesmo relógio; a operação real tem pelo menos quatro.

É nesse terreno que se encontra o item “Route management alignment” do roteiro da APNIC. A ficha pertence à equipe Registry, tem como alvo o terceiro trimestre de 2026 e cita ARMS, RPKI e Whois. A proposta é automatizar o alinhamento com a titularidade dos recursos, reduzindo a reconciliação manual tediosa e sujeita a erros depois de transferências, desalocações e alterações de sistema.

O ganho é concreto. Nenhuma rede melhora porque uma pessoa precisa repetir a mesma intenção em diversas telas. Em uma janela de migração, cada etapa manual adiciona atraso e chance de inversão da ordem. Automatizar é uma escolha sensata.

Mas alinhar pode querer dizer duas coisas. Pode significar coordenar registros diferentes, declarando o papel e o tempo de cada um. Ou pode significar escolher um registro dominante e forçar os demais a reproduzi-lo. O primeiro modelo reduz trabalho sem destruir significado. O segundo cria uma aparência de limpeza ao custo de transformar uma decisão de software em política de roteamento.

O registro estruturado do roteiro traz ano, trimestre, equipe, produtos, resumo e solução proposta. Seu changelog está vazio. Não há, no item público, uma regra de precedência, um limite para a transação, um estado de falha parcial, uma política de rollback, um mecanismo de notificação nem a fronteira com NIRs e IRRs externos. A APNIC pode ter parte ou toda essa arquitetura em documentos internos. A conclusão permitida é apenas que ela não acompanha, por enquanto, a promessa pública.

Titularidade, política, autorização e observação

A titularidade do recurso responde quem é reconhecido pelo registro como detentor de um bloco de endereços ou ASN. É uma base para decidir qual conta pode administrar serviços e solicitar mudanças. Não determina automaticamente qual AS deve originar todos os prefixos naquele momento.

O Internet Routing Registry responde a uma pergunta de política. A APNIC o descreve como um conjunto distribuído de bancos onde operadores publicam políticas e anúncios, permitindo que outras redes construam filtros e configurações. O RFC 2725 exige que a criação de um route object seja autorizada tanto para o prefixo quanto para o AS de origem. O mesmo documento reconhece origens múltiplas, prefixos mais específicos sobrepostos, mudança de provedor e períodos de renumeração.

Diferença, portanto, pode ser intenção. Um segundo origin pode ser redundância, e não sujeira. Um objeto pode permanecer durante uma transição coordenada. Uma política automática que exige exatamente um AS por prefixo pode corrigir a resiliência até ela deixar de existir.

RPKI trata de autorização criptográfica. O RFC 9582 define a ROA como o objeto assinado pelo detentor de espaço de endereços que permite a um AS originar rotas para determinados prefixos. Para vários ASes, há várias ROAs. A assinatura estabelece permissão e integridade dentro da cadeia. Não comprova que o anúncio exista agora, que o tráfego chegue ao destino ou que um roteador específico o aceite.

BGP oferece a observação operacional. O RFC 6483 descreve como o prefixo e o origin AS de uma rota recebida são comparados às ROAs válidas para produzir Valid, Invalid ou Unknown. O que fazer com esses estados continua sendo matéria de política local. O registro participa da autorização; não executa a seleção de todas as redes.

Os tempos também divergem. O RFC 6483 alerta que objetos RPKI e rotas podem se propagar em velocidades diferentes. Uma ROA publicada talvez ainda não esteja no cache local. Um anúncio pode aparecer antes da autorização atualizada. Uma origem de contingência pode ser autorizada sem estar ativa. Uma diferença temporária pode ser exatamente o que permite uma mudança segura.

Essas quatro camadas não são réplicas imperfeitas. Elas são provas de autoridade, intenção, permissão e comportamento. Qualquer sistema que as alinhe precisa conservar essa separação.

O manual antigo tratava conflito como informação

O Route Management Guide de 2017 da APNIC é útil porque mostra um predecessor do problema. Sua data impede que ele seja apresentado como contrato vigente da função de 2026. Ainda assim, o documento registra uma escolha de produto importante: a rota mantida no MyAPNIC não era idêntica ao objeto de rota publicado no Whois.

No manual, a “route” do MyAPNIC atuava como modelo para criar o objeto real no Whois. Os dois podiam existir separadamente. Podia haver modelo sem objeto público e objeto público sem rota administrada pelo modelo. Se o Whois fosse alterado por fora da ferramenta, o modelo não copiava silenciosamente a edição. A interface assinalava um conflito. O usuário podia aceitar a mudança ou restaurar o objeto à intenção do MyAPNIC.

Essa escolha preservava a divergência pelo tempo necessário para entendê-la. Uma alteração externa podia ser uma correção emergencial feita por mantenedor autorizado ou um resíduo antigo. Apagar de imediato um dos lados destruiria a pista de que outro canal havia atuado.

O guia também fala em estado pending durante algumas sincronizações de múltiplos objetos. Permite que usuários habilitados solicitem ROAs correspondentes ao criar rotas. Em um caso descrito, desabilitar uma sub-rota gerenciada com ROA ativa também apagava a ROA. A interface única já reunia permissões distintas, processamento em segundo plano e acoplamentos opcionais.

O novo sistema pode abandonar completamente essa mecânica. A lição não está no botão aceitar ou reverter; está em tornar visível a escolha. Se a automação 2026 decidir sem registrar a divergência, ela será mais rápida e menos auditável do que sua antecessora.

Uma transação termina antes de a Internet concordar

O anúncio da Registry API da APNIC, em outubro de 2024, oferece contexto mais recente. A API obtém dados de delegação e administra Whois, DNS reverso, ROAs e objetos de rota. O exemplo dado pela APNIC é a criação automática de uma ROA e de um route object quando um membro adiciona um anúncio BGP.

A descrição contém uma qualificação decisiva. Operações abstratas de gestão de rota e DNS reverso podem ser enviadas em lotes que entram em vigor “transactionally where possible”. Todas as atualizações são tarefas assíncronas: a solicitação devolve um link, o cliente acompanha o estado e recebe detalhes do resultado.

“Onde for possível” reconhece que a atomicidade é limitada. Escritas dentro de uma mesma base podem compartilhar commit. A publicação num repositório RPKI, a coleta por validadores, a atualização de outro RIR, a edição de um IRR externo e a reconstrução de filtros em uma operadora não pertencem à mesma transação. Uma API comum não dissolve as fronteiras institucionais.

O novo alinhamento precisa dizer o que acontece fora da região atômica. Se o Whois for atualizado e a ROA planejada falhar, o estado genérico Failed não informa se é seguro repetir toda a tarefa. A resposta deve identificar qual etapa foi confirmada, qual falhou, qual é o último estado seguro e se haverá compensação ou quarentena.

O inverso também vale. Completed não deveria significar que todos os caches e redes observaram a mudança. Pode significar apenas que a APNIC concluiu suas ações. O recibo precisa separar committed, published e observed.

Não há, nesta análise, teste que demonstre uma falha atual da API. O documento de 2024 importa porque já torna públicos os conceitos de lote, transação limitada, tarefa assíncrona e resultado. Eles são uma base adequada para explicar a próxima geração.

A transferência muda o direito antes de definir a rota

As condições atuais da APNIC dizem que, em transferências inter-RIR de saída, objetos associados — inclusive subalocações, route objects e domain objects — são removidos da base Whois da APNIC. Quando a transferência termina, a entidade de origem perde os direitos sobre os recursos e eles são registrados para o destinatário.

A cláusula citada nomeia objetos Whois. Ela não informa o destino das ROAs. Não se deve inventar que elas são apagadas. A omissão demarca duas decisões: retirar objetos e autoridade do lado de origem não é o mesmo que criar a autorização desejada pelo novo detentor.

Se o destinatário mantiver o mesmo origin AS, a titularidade muda e a intenção de rota talvez não. Se trocar de AS, pode ser prudente preparar a nova autorização antes de retirar o caminho anterior. Se a transferência cruzar registros, a remoção na origem e a visibilidade no destino seguirão controles diferentes. São cenários para testar o desenho, não relatos de incidentes.

Apagar tudo primeiro pode produzir uma janela evitável de Invalid ou NotFound. Preservar tudo sem prazo mantém autoridade obsoleta. Copiar uma rota BGP observada para uma ROA transforma comportamento em permissão. O sistema precisa de uma sequência condicionada, não de um reflexo único.

O estado aligned deveria ser decomposto. Prepared: a mudança autorizada existe, mas ainda não vale. Committed: o registro aceitou a escrita. Published: o objeto está disponível em sua superfície. Observed: uma verificação independente viu a mudança. Retired: o estado anterior deixou de produzir autoridade. Cada passo responde a uma questão própria.

Divergências que não devem ser “consertadas”

A primeira é o multihoming legítimo. IRR e RPKI permitem várias origens. O algoritmo precisa validar autoridade e escopo sem supor que cardinalidade maior que um seja erro. Uma limpeza que remova uma origem de reserva pode reduzir a robustez real.

A segunda é a diferença de propagação. Um objeto pode estar gravado e ainda não ser visível. A rota pode ser vista antes do cache novo. Se o motor reagir a cada defasagem como contradição persistente, criará novas mudanças enquanto a anterior ainda está viajando.

A terceira é a edição por outro canal autorizado. O manual antigo mostrava a opção entre aceitar e reverter uma alteração externa no Whois. A automação deverá avaliar quem editou, qual permissão foi usada, qual intenção é mais nova e se a edição realmente exige uma mudança RPKI. Fazer o template vencer sempre apaga correções legítimas; importar qualquer edição deixa o plano gerenciado sem autoridade.

A quarta fronteira é a desalocação. O roteiro cita esse gatilho, mas não publica sua sequência. Encerrar o direito sobre um recurso pode justificar retiradas, porém prazo, aviso, revisão e situação de recursos administrados por NIR não podem ser deduzidos de uma palavra. Um objeto num IRR externo permanece fora do alcance de uma escrita local da APNIC.

Uma autoridade específica para cada pergunta

O slogan single source of truth parece simplificar a arquitetura porque evita falar de conflitos. Neste caso, ele simplifica demais. A titularidade é autoridade para saber quem pode agir. Uma solicitação autenticada expressa a intenção do operador. O IRR publica política. A ROA comprova autorização de origem. BGP apresenta uma observação. Nenhum deve fabricar sozinho as respostas dos demais.

Uma matriz de precedência poderia ser curta. Nas linhas: transferência, desalocação, edição direta de Whois, alteração no modelo de rota, modificação de ROA e migração de sistema. Nas colunas: ator autorizado, pré-condição, registros afetados, diferenças permitidas, ação automática, condição de revisão e prazo para contestação.

Outra coluna desenharia a atomicidade. Quais escritas compartilham transação? Quais publicações são assíncronas? Onde começa a dependência de outra instituição? O que fica em quarentena quando apenas um passo termina? Quando o operador pode anunciar, retirar ou reconstruir filtros com segurança?

A matriz também separaria a revogação de autoridade antiga da criação de intenção nova. Uma transferência pode impedir que a conta de origem continue editando. Isso não autoriza a APNIC a adivinhar o AS do destinatário. Observar BGP pode criar um alerta; não deve assinar uma ROA.

O recibo que registra o caminho, não só a chegada

Cada tarefa consequente deveria gerar um recibo versionado. Ele teria identificadores de evento e tarefa, tipo e horário do gatilho, além da fotografia de titularidade usada para verificar a autoridade do solicitante. Depois mostraria separadamente o modelo de rota, os objetos Whois e as ROAs antes e depois.

Cada mudança traria uma regra de precedência por tipo e um código de razão. O recibo marcaria quais passos foram confirmados em conjunto, quais publicações continuaram pendentes e quais sistemas estavam fora do controle da APNIC. Em caso de resultado parcial, indicaria etapa bem-sucedida, etapa falha, último estado seguro, condição de nova tentativa, quarentena e ação compensatória.

Visibilidade ganharia horários próprios: quando o objeto Whois passou a responder, quando o objeto RPKI foi publicado e quando uma verificação independente o observou. BGP poderia aparecer como sinal, nunca como comando ou garantia de alcance.

Transferência, desalocação, NIR e IRR externo seriam flags de escopo. Avisos, confirmações, caminho de revisão, override e responsável pelo serviço seriam registrados sem expor credenciais pessoais ou chaves. Um rollback acrescentaria um novo resultado ligado à tarefa original; não apagaria a história.

Esse recibo é uma recomendação editorial, não uma função anunciada pela APNIC. Também não exige que todos os logs internos sejam públicos. Ele precisa apenas permitir que a parte afetada distinga diferença intencional, sucesso completo, espera de propagação e falha parcial.

A APNIC está certa em atacar a reconciliação manual. O cuidado necessário é não esconder a política dentro da automação. Antes de o código eleger o vencedor de um conflito, as regras e o resultado precisam ser legíveis.

Fontes