Rehoming BGP: por que um prefixo IPv4 muda de ASN de origem
Por que um prefixo IPv4 pode mudar de ASN de origem sem mudar de titular e como verificar o BGP, a RPKI, o IRR e a situação cadastral.
O bloco de endereços pode permanecer o mesmo quando muda a rede que origina sua rota. O roteamento, a autorização e os registros de titularidade têm funções diferentes.
Um prefixo IPv4 pode manter os mesmos números e ainda assim parecer ter passado para outra rede. No BGP, essa mudança costuma aparecer como um novo ASN de origem.
Isso é chamado de rehoming BGP. Trata-se de uma observação sobre o estado do roteamento. Por si só, ela não comprova que o titular registrado mudou, que o prefixo mudou de país ou que houve uma transferência de endereços.
Comece pela rota
Se um coletor observa 203.0.113.0/24 → AS64500, ele está vendo o AS64500 originar a rota naquele momento. Se o mesmo prefixo aparecer depois como 203.0.113.0/24 → AS64550, o ASN de origem mudou.
O termo ASN de origem significa, aqui, o ASN na extremidade de origem do caminho de sistemas autônomos observado. Ele não deve ser confundido com o atributo ORIGIN do BGP, que é um atributo distinto definido pela RFC 4271.
O que os dados recentes mostram
Ao comparar retratos do roteamento do início de 2025 e do início de 2026, o APNIC contou 29.699 prefixos IPv4 cujo ASN de origem mudou. Sua tabela de comparação com transferências lista 1.991 prefixos com mudança de origem presentes nos registros de transferência e 26.722 ausentes desses registros. Esses números somam 28.713, ou seja, 986 a menos que o total informado de prefixos com mudança de origem. A legenda da tabela também menciona mudanças de roteamento em 2024 e registros de transferência de 2023–2024, enquanto o texto ao redor descreve mudanças em 2025 e registros de 2024–2025. Portanto, os números e as indicações de período publicados não oferecem um detalhamento anual plenamente conciliado.
A comparação não é evidência de que os prefixos sem correspondência tenham sido transferidos indevidamente. Ela mostra por que o histórico de roteamento e o histórico cadastral não devem ser tratados como o mesmo conjunto de dados. Muitas mudanças legítimas de rede não exigem uma alteração do titular registrado.
Por que um ASN de origem muda
Há várias explicações operacionais corriqueiras:
- uma empresa troca de provedor de trânsito ou de hospedagem;
- a infraestrutura é migrada para outro data center ou outra rede de nuvem;
- um cliente começa a originar rotas por meio de seu próprio ASN, obtido recentemente;
- uma rede corporativa é fundida, dividida ou reestruturada;
- um titular delega o roteamento a outro operador ou provedor de hospedagem; ou
- a arquitetura de roteamento muda, enquanto a relação cadastral permanece estável.
Cada explicação precisa de evidências. A rota, por si só, mostra o que está sendo anunciado, mas não por que houve uma mudança nem quem a autorizou.
Rehoming e transferência de IPv4 respondem a perguntas diferentes
O rehoming BGP pergunta: qual ASN está originando este prefixo?
Uma transferência de IPv4 pergunta: a relação reconhecida pelo registro mudou?
Esses eventos podem acontecer ao mesmo tempo. Também podem acontecer separadamente. Um titular pode mudar de provedor sem transferir o recurso, e uma relação cadastral pode mudar enquanto o mesmo provedor continua originando a rota.
O BGP fornece evidências de roteamento, mas não comprova integralmente o controle
Ver o AS64550 originar um prefixo não comprova automaticamente que ele seja seu proprietário ou titular registrado, que possa transferi-lo ou que tenha autorização permanente para anunciá-lo. Uma locação, um acordo com um cliente, uma migração temporária ou um erro poderiam produzir a mesma observação.
Para entender o controle, compare a rota com os dados cadastrais, a autorização operacional e as evidências que explicam a relação. Esse é o motivo prático para manter distintos o controle do roteamento, o controle cadastral e as relações comerciais.
A RPKI acrescenta autorização
Uma autorização de origem de rota (ROA, de Route Origin Authorization) declara que um determinado ASN está autorizado a originar um prefixo no sistema RPKI. A RFC 9582 define o perfil atual de ROA.
Quando a origem muda do AS64500 para o AS64550, o novo estado pretendido deve estar refletido na ROA correspondente. Uma ROA válida não comprova que a rota esteja sendo anunciada naquele momento, e uma rota observada não comprova que o anúncio seja autorizado. BGP e RPKI fornecem evidências complementares.
IRR e DNS reverso fazem parte da migração
Os provedores podem usar objetos de rota do IRR para criar filtros. Os clientes podem depender de DNS reverso, listas de permissões, monitoramento e sistemas de reputação. Por isso, uma migração de roteamento pode exigir várias atualizações coordenadas, mesmo quando o titular registrado permanece o mesmo.
Um registro operacional útil identifica cada camada: situação cadastral, origem BGP, autorização RPKI, política no IRR, responsabilidade pelo DNS reverso, contatos e registro interno da mudança.
O que verificar quando a origem muda
Antes da mudança
- registre os prefixos exatos e o ASN de origem atual;
- confirme o novo ASN pretendido e o operador autorizado;
- revise as ROAs, os objetos do IRR e o DNS reverso e verifique se o provedor está preparado; e
- preserve as evidências atuais do BGP e do cadastro.
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
- verifique se a rota antiga deixa de aparecer onde a mudança exige isso.
Após a migração
- verifique se o ASN esperado está originando o prefixo;
- confirme que as ROAs, o IRR e o DNS reverso correspondem ao estado pretendido;
- verifique os dados cadastrais e os contatos; e
- salve as evidências para que o próximo operador possa reconstituir a mudança.
Uma origem inesperada significa um sequestro de rota?
Não necessariamente. A situação merece investigação, mas a primeira pergunta deve ser se a mudança foi autorizada. Entre as possíveis explicações estão uma migração de provedor, uma manutenção temporária, o roteamento pelo cliente, um novo ASN, uma delegação operacional, um erro de configuração ou um anúncio não autorizado.
Use o histórico do BGP em conjunto com os dados cadastrais, as ROAs, as informações do IRR, a documentação do provedor e os registros internos de mudanças antes de atribuir uma causa. Uma classificação precipitada pode ocultar o verdadeiro problema operacional.
Por que isso importa para a portabilidade
Os recursos IPv4 cada vez mais permanecem em uso ao longo de mudanças de provedores, data centers, estruturas corporativas, ASNs e usuários operacionais. Portanto, a portabilidade vai além de permitir que o número do endereço permaneça o mesmo. Os sistemas ao redor precisam preservar a unicidade, a autorização, a precisão dos registros, a segurança e a continuidade enquanto a rede muda.
A continuidade do IP público depende dessa camada prática. DNS, controles de acesso, listas de permissões de parceiros, VPNs e monitoramento podem depender de um endereço, mesmo quando as mudanças cadastrais e de roteamento parecem administrativas.
A rede em funcionamento é o teste final
Os dados cadastrais, a RPKI, os objetos do IRR e as observações do BGP são instrumentos diferentes em torno de uma rede em funcionamento. O objetivo de um rehoming legítimo é simples: fazer a mudança de roteamento necessária mantendo a rede acessível, autorizada e com seu funcionamento passível de explicação.