Resumo

  • A APNIC pode estabelecer a mudança do titular registrado, mas isso não comprova automaticamente o estado de todas as políticas, credenciais e autorizações ligadas ao ASN.
  • O registro de passagem deve separar fatos registrais, atos autenticados, objetos publicados e observações BGP, conectando-os por horários e hashes.
  • As fontes não demonstram que todo ASN transferido esteja ativo, possua aut-num ou conste de uma ROA; “não aplicável”, “não observado” e “desconhecido” são estados necessários.

A RFC 1930 define um sistema autônomo por uma política de roteamento única e claramente definida. Portanto, o ASN não é apenas um número portátil: ele identifica um domínio de política perante outras redes.

A política atual da APNIC permite transferências de ASN entre titulares da região e, com política compatível, entre RIRs. A fonte deve ser o titular registrado e não estar em disputa; o destinatário deve satisfazer os critérios atuais. A APNIC descreve a transferência como movimento do recurso entre entidades jurídicas e atualiza o Whois. No fluxo entre contas, a fonte inicia e o destinatário confirma no MyAPNIC.

Esses fatos respondem à titularidade reconhecida pelo registro. Não provam que um ASN esteja em uso, que exista um objeto IRR, que contatos e mantenedores tenham mudado ou que titulares de prefixos tenham ajustado suas ROAs. Uma observação BGP prova presença em certo ponto e horário, não titularidade ou autorização.

O primeiro bloco do registro deve guardar identificador da transferência, ASN, contas reconhecidas, versão da política, recibos de início e confirmação, decisão e horário efetivo. Em uma transferência inter-RIR, inclui a contraparte, a base de compatibilidade e as duas referências de conclusão.

O segundo bloco preserva leituras RDAP autnum antes e depois, conforme a RFC 9082, com consulta, horário, serviço e hash da resposta. Correções posteriores viram novas observações. O terceiro registra a política: continuidade, transição ou retirada, além de base, chave, mantenedor e hashes do aut-num, quando ele existir.

O quarto bloco trata de ROAs. Receber o ASN não transfere a autoridade dos titulares de prefixos. As RFCs 6907 e 8206 mostram por que transições podem exigir sequência make-before-break e novas autorizações. Cada dependência precisa de autoridade, estado anterior e posterior, publicação e validação. O quinto bloco mantém observações BGP delimitadas, sem convertê-las em prova jurídica.

Estados como REQUESTED, SOURCE_CONFIRMED, RECIPIENT_ACKNOWLEDGED, REGISTRY_EFFECTIVE, DEPENDENCIES_IN_TRANSITION, HANDOVER_OBSERVED e EXCEPTION_OPEN impedem que a eficácia registral preencha automaticamente as etapas seguintes. Para ASN inativo, várias dependências podem ser não aplicáveis; para ASN ativo, o fechamento pode exigir credenciais, política, objetos usados, ROAs e janela de observação.

Cada autoridade continua no seu domínio: a APNIC decide o registro, titulares de prefixos controlam ROAs, IRRs publicam objetos, operadores controlam roteadores e coletores fornecem observações. O registro de passagem liga essas afirmações sem misturá-las.

Fontes