Rehoming BGP: porque muda o ASN de origem de um prefixo IPv4
Porque pode um prefixo IPv4 mudar de ASN de origem sem mudar de titular e como verificar o BGP, o RPKI, o IRR e o estado no registo.
O bloco de endereços pode manter-se quando muda a rede que o anuncia como origem. O encaminhamento, a autorização e os registos do titular desempenham papéis distintos.
Um prefixo IPv4 pode manter os mesmos números e, ainda assim, parecer ter passado para outra rede. No BGP, essa mudança manifesta-se geralmente através de um novo ASN de origem.
A isto chama-se rehoming BGP. Trata-se de uma observação sobre o estado do encaminhamento. Por si só, não prova que o titular registado tenha mudado, que o prefixo tenha mudado de país ou que tenha ocorrido uma transferência de endereços.
Começar pela rota
Se um coletor observar 203.0.113.0/24 → AS64500, está a ver o AS64500 a anunciar a rota como origem nesse momento. Se, mais tarde, o mesmo prefixo surgir como 203.0.113.0/24 → AS64550, o ASN de origem mudou.
A expressão ASN de origem designa aqui o ASN situado na extremidade de origem do caminho de sistemas autónomos observado. Não deve ser confundida com o atributo ORIGIN do BGP, que é um atributo distinto definido no RFC 4271.
O que mostram os dados recentes
Na comparação entre os retratos do encaminhamento no início de 2025 e no início de 2026, a APNIC contou 29 699 prefixos IPv4 cujo ASN de origem mudou. A sua tabela de comparação com as transferências indica 1 991 prefixos com mudança de origem presentes nos registos de transferências e 26 722 ausentes desses registos. Estes valores somam 28 713, menos 986 do que o total de prefixos com mudança de origem apresentado. A legenda da tabela também menciona mudanças de encaminhamento em 2024 e registos de transferências de 2023–2024, enquanto o texto que a acompanha descreve mudanças em 2025 e registos de 2024–2025. Os valores e as indicações temporais publicados não permitem, portanto, obter uma discriminação anual inteiramente coerente.
A comparação não constitui prova de que os prefixos sem correspondência tenham sido transferidos indevidamente. Mostra porque não se deve tratar o histórico de encaminhamento e o histórico do registo como se fossem o mesmo conjunto de dados. Muitas alterações legítimas na rede não exigem uma mudança do titular registado.
Porque muda um ASN de origem
Existem várias explicações operacionais comuns:
- uma empresa muda de fornecedor de trânsito ou de alojamento;
- a infraestrutura é deslocada para outro centro de dados ou outra rede na nuvem;
- um cliente começa a anunciar rotas através de um ASN próprio que acabou de obter;
- uma rede empresarial é objeto de fusão, divisão ou reestruturação;
- um titular delega o encaminhamento noutro operador ou fornecedor de alojamento; ou
- a arquitetura de encaminhamento muda, mantendo-se estável a relação com o registo.
Cada explicação precisa de elementos que a sustentem. A rota, por si só, mostra o que está a ser anunciado, não a razão da mudança nem quem a autorizou.
O rehoming e a transferência de IPv4 respondem a perguntas diferentes
O rehoming BGP coloca a pergunta: que ASN está a anunciar este prefixo como origem?
Uma transferência de IPv4 coloca a pergunta: mudou a relação reconhecida pelo registo?
Os dois acontecimentos podem ocorrer ao mesmo tempo. Também podem ocorrer separadamente. Um titular pode mudar de fornecedor sem transferir o recurso, e a relação com o registo pode mudar enquanto o mesmo fornecedor continua a anunciar a rota como origem.
O BGP fornece indícios sobre o encaminhamento, não uma prova completa de controlo
Ver o AS64550 a anunciar um prefixo como origem não prova automaticamente que o AS64550 seja o seu proprietário ou titular registado, que o possa transferir ou que tenha autorização permanente para o anunciar. Um aluguer, um acordo com um cliente, uma migração temporária ou um erro podem produzir a mesma observação.
Para compreender quem detém o controlo, compare a rota com os dados do registo, a autorização operacional e os elementos que explicam a relação. É esta a razão prática para distinguir o controlo do encaminhamento, o controlo no registo e as relações comerciais.
O RPKI acrescenta a autorização
Uma autorização de origem de rota (Route Origin Authorization, ou ROA) declara que um determinado ASN está autorizado a anunciar um prefixo como origem no sistema RPKI. O RFC 9582 define o perfil ROA atual.
Quando a origem muda de AS64500 para AS64550, o novo estado pretendido deve estar refletido no ROA correspondente. Um ROA válido não prova que a rota esteja a ser anunciada nesse momento, e uma rota observada não prova que o anúncio esteja autorizado. O BGP e o RPKI fornecem elementos complementares.
O IRR e o DNS inverso fazem parte da migração
Os fornecedores podem utilizar objetos de rota do IRR para criar filtros. Os clientes podem depender do DNS inverso, de listas de permissões, da monitorização e de sistemas de reputação. Uma migração de encaminhamento pode, por isso, exigir várias atualizações coordenadas, mesmo quando o titular no registo se mantém.
Um registo operacional útil identifica cada camada: estado no registo, origem BGP, autorização RPKI, política IRR, responsabilidade pelo DNS inverso, contactos e registo interno da alteração.
O que verificar quando a origem muda
Antes da alteração
- registe os prefixos exatos e o ASN de origem atual;
- confirme o novo ASN pretendido e o operador autorizado;
- reveja os ROA, os objetos do IRR e o DNS inverso e verifique se o fornecedor está preparado; e
- preserve os elementos atuais relativos ao BGP e ao registo.
Durante a migração
- acompanhe a propagação e as mudanças de origem a partir de várias redes;
- verifique a validação RPKI e os anúncios de prefixos mais específicos; e
- confirme que a rota antiga desaparece onde a alteração o exige.
Após a migração
- verifique se o ASN esperado está a anunciar o prefixo como origem;
- confirme que os ROA, o IRR e o DNS inverso correspondem ao estado pretendido;
- verifique os dados do registo e os contactos; e
- guarde os elementos de prova para que o próximo operador possa reconstituir a alteração.
Uma origem inesperada significa um sequestro de rota?
Não necessariamente. Merece investigação, mas a primeira pergunta deve ser se a alteração foi autorizada. As explicações possíveis incluem uma migração de fornecedor, manutenção temporária, encaminhamento pelo cliente, um novo ASN, delegação operacional, um erro de configuração ou um anúncio não autorizado.
Utilize o histórico BGP em conjunto com os dados do registo, os ROA, a informação do IRR, a documentação do fornecedor e os registos internos de alterações antes de atribuir uma causa. Uma classificação precipitada pode ocultar o verdadeiro problema operacional.
Porque é isto relevante para a portabilidade
Os recursos IPv4 sobrevivem cada vez mais a mudanças de fornecedores, centros de dados, estruturas empresariais, ASN e utilizadores operacionais. A portabilidade é, por isso, mais do que permitir que o número do endereço se mantenha. Os sistemas envolventes têm de preservar a unicidade, a autorização, a exatidão dos registos, a segurança e a continuidade enquanto a rede muda.
A continuidade do IP público depende desta camada prática. O DNS, os controlos de acesso, as listas de permissões dos parceiros, as VPN e a monitorização podem depender de um endereço, mesmo quando as mudanças no registo e no encaminhamento parecem meramente administrativas.
A rede em funcionamento é o teste final
Os dados do registo, o RPKI, os objetos do IRR e as observações BGP são instrumentos distintos ao serviço de uma rede em funcionamento. O objetivo de um rehoming legítimo é simples: efetuar a alteração de encaminhamento necessária, mantendo a rede acessível, autorizada e com um funcionamento que possa ser explicado.