Rerattachement BGP : pourquoi un préfixe IPv4 change d’ASN d’origine
Pourquoi un préfixe IPv4 peut changer d’ASN d’origine sans changer de titulaire, et comment vérifier BGP, RPKI, IRR et les données du registre.
Le bloc d’adresses peut rester le même lorsque le réseau à l’origine de son annonce change. Le routage, les autorisations et les données relatives au titulaire remplissent des fonctions différentes.
Un préfixe IPv4 peut conserver les mêmes numéros et pourtant sembler passer sur un autre réseau. Dans BGP, ce changement se manifeste généralement par un nouvel ASN d’origine.
C’est ce qu’on appelle le rerattachement BGP, ou « BGP rehoming ». Il s’agit d’un constat sur l’état du routage. Ce constat ne prouve pas, à lui seul, que le titulaire enregistré a changé, que le préfixe a changé de pays ou qu’un transfert d’adresses a eu lieu.
Partir de la route
Si un collecteur observe 203.0.113.0/24 → AS64500, il constate qu’AS64500 est à l’origine de la route à cet instant. Si le même préfixe apparaît ensuite sous la forme 203.0.113.0/24 → AS64550, l’ASN d’origine a changé.
L’expression « ASN d’origine » désigne ici l’ASN situé à l’extrémité d’origine du chemin AS observé. Il ne faut pas le confondre avec l’attribut BGP ORIGIN, qui est un attribut distinct défini par la RFC 4271.
Ce que montrent les données récentes
En comparant des instantanés du routage du début de 2025 et du début de 2026, l’APNIC a dénombré 29 699 préfixes IPv4 dont l’ASN d’origine avait changé. Son tableau de comparaison avec les transferts recense 1 991 préfixes rerattachés figurant dans les enregistrements de transferts et 26 722 n’y figurant pas. Ces chiffres donnent un total de 28 713, soit 986 de moins que le nombre total de préfixes rerattachés annoncé. La légende du tableau mentionne par ailleurs des changements de routage en 2024 et des journaux de transferts pour 2023–2024, tandis que le texte qui l’entoure décrit des changements en 2025 et des journaux pour 2024–2025. Les chiffres et les indications de période publiés ne permettent donc pas d’établir un bilan annuel entièrement concordant.
Cette comparaison ne prouve pas que les préfixes sans correspondance ont fait l’objet de transferts irréguliers. Elle montre pourquoi l’historique du routage et celui du registre ne doivent pas être traités comme un seul et même jeu de données. De nombreux changements légitimes dans un réseau ne nécessitent aucun changement de titulaire enregistré.
Pourquoi un ASN d’origine change
Plusieurs situations opérationnelles courantes peuvent l’expliquer :
- une entreprise change de fournisseur de transit ou d’hébergement ;
- l’infrastructure est déplacée vers un autre centre de données ou un autre réseau cloud ;
- un client commence à émettre ses annonces depuis son propre ASN, qu’il vient d’obtenir ;
- un réseau d’entreprise fait l’objet d’une fusion, d’une scission ou d’une restructuration ;
- un titulaire délègue le routage à un autre opérateur ou hébergeur ; ou
- l’architecture de routage change, tandis que le rattachement consigné dans le registre reste stable.
Chaque explication doit être étayée. La route seule montre ce qui est annoncé, sans indiquer pourquoi cela a changé ni qui l’a autorisé.
Le rerattachement et le transfert IPv4 répondent à des questions différentes
Le rerattachement BGP pose la question : quel ASN est à l’origine de l’annonce de ce préfixe ?
Un transfert IPv4 pose la question : le rattachement reconnu par le registre a-t-il changé ?
Ces événements peuvent survenir en même temps. Ils peuvent aussi se produire séparément. Un titulaire peut changer de fournisseur sans transférer la ressource, et le rattachement au registre peut changer alors que le même fournisseur continue d’être à l’origine de la route.
BGP renseigne sur le routage, sans prouver à lui seul le contrôle
Constater qu’AS64550 est à l’origine de l’annonce d’un préfixe ne prouve pas automatiquement qu’AS64550 en est propriétaire, en est le titulaire enregistré, peut le transférer ou dispose d’une autorisation permanente de l’annoncer. Une location, un accord avec un client, une migration temporaire ou une erreur pourraient aboutir au même constat.
Pour comprendre qui exerce le contrôle, confrontez la route aux données du registre, aux autorisations opérationnelles et aux éléments qui expliquent cette relation. C’est pour cette raison pratique qu’il faut distinguer le contrôle du routage, le contrôle au niveau du registre et les relations commerciales.
RPKI apporte la dimension de l’autorisation
Une autorisation d’origine de route, ou Route Origin Authorization (ROA), indique qu’un ASN donné est autorisé à être à l’origine de l’annonce d’un préfixe dans le système RPKI. La RFC 9582 définit le profil ROA actuel.
Lorsque l’origine passe d’AS64500 à AS64550, le nouvel état visé doit être reflété dans la ROA correspondante. Une ROA valide ne prouve pas que la route est actuellement annoncée, et l’observation d’une route ne prouve pas que son annonce est autorisée. BGP et RPKI apportent des éléments de preuve complémentaires.
L’IRR et le DNS inverse font partie de la migration
Les fournisseurs peuvent utiliser les objets de route IRR pour construire des filtres. Les clients peuvent dépendre du DNS inverse, de listes d’autorisation, de la supervision et de systèmes de réputation. Une migration du routage peut donc nécessiter plusieurs mises à jour coordonnées, même si le titulaire enregistré reste le même.
Un dossier opérationnel utile précise chaque couche : état du registre, origine BGP, autorisation RPKI, politique IRR, responsabilité du DNS inverse, contacts et fiche de changement interne.
Que vérifier lorsque l’origine change ?
Avant le changement
- consigner les préfixes exacts et l’ASN d’origine actuel ;
- confirmer le nouvel ASN prévu et l’opérateur autorisé ;
- examiner les ROA, les objets IRR, le DNS inverse et l’état de préparation du fournisseur ; et
- conserver les éléments attestant l’état actuel de BGP et du registre.
Pendant la migration
- surveiller la propagation et les changements d’origine depuis plusieurs réseaux ;
- vérifier la validation RPKI et les annonces de préfixes plus spécifiques ; et
- surveiller la disparition de l’ancienne route là où le changement l’exige.
Après la migration
- vérifier que l’ASN attendu est bien à l’origine de l’annonce du préfixe ;
- confirmer que les ROA, l’IRR et le DNS inverse correspondent à l’état visé ;
- vérifier les données du registre et les contacts ; et
- conserver les éléments de preuve pour que l’opérateur suivant puisse reconstituer le changement.
Une origine inattendue signifie-t-elle un détournement ?
Pas nécessairement. Elle mérite une investigation, mais la première question à se poser est de savoir si le changement était autorisé. Les explications possibles comprennent un changement de fournisseur, une maintenance temporaire, le routage assuré par un client, un nouvel ASN, une délégation opérationnelle, une erreur de configuration ou une annonce non autorisée.
Avant d’attribuer une cause, utilisez l’historique BGP avec les données du registre, les ROA, les informations IRR, la documentation du fournisseur et les fiches de changement internes. Une qualification hâtive peut masquer le véritable problème opérationnel.
Pourquoi cela compte pour la portabilité
Les ressources IPv4 perdurent de plus en plus au-delà des changements de fournisseurs, de centres de données, de structures d’entreprise, d’ASN et d’utilisateurs opérationnels. La portabilité ne se limite donc pas à permettre de conserver le même numéro d’adresse. Les systèmes qui l’entourent doivent préserver l’unicité, les autorisations, l’exactitude des données, la sécurité et la continuité pendant que le réseau change.
La continuité des adresses IP publiques dépend de cette dimension pratique. Le DNS, les contrôles d’accès, les listes d’autorisation des partenaires, les VPN et la supervision peuvent tous dépendre d’une adresse, même lorsque les changements de registre et de routage semblent purement administratifs.
Le réseau en fonctionnement est l’épreuve décisive
Les données du registre, RPKI, les objets IRR et les observations BGP sont des instruments distincts au service d’un réseau en fonctionnement. L’objectif d’un rerattachement légitime est simple : effectuer le changement de routage nécessaire tout en maintenant le réseau joignable, en veillant à ce que son routage reste autorisé et en permettant d’en expliquer le fonctionnement.