Number Resource Society
Registre IP et routage BGP : comprendre les écarts
Un bloc est enregistré au nom de votre entreprise, mais un autre réseau l’annonce. Avant de conclure à une erreur ou à un détournement, distinguez l’enregistrement, l’origine observée et l’autorisation. Voici comment reconstituer une situation vérifiable.
Sur cette page
Illustration conservée de l’article original en anglais.
Commencez par la question à laquelle chaque source peut répondre
Le nom de votre entreprise apparaît dans RDAP, tandis qu’un collecteur BGP affiche l’ASN d’un prestataire. Ce constat appelle une explication, pas un verdict. L’administration des adresses et l’exploitation du réseau peuvent relever d’organisations différentes, sans que l’une des deux observations soit fausse.
Le bon réflexe consiste à séparer cinq éléments : ce que le registre indique, ce que le réseau annonce, ce que RPKI autorise comme origine, ce qui a été déclaré dans un IRR et ce que votre entreprise a décidé. Les rapprocher permet de comprendre une situation ; les confondre conduit à des conclusions trop rapides.
| Source | Question à laquelle elle répond |
|---|---|
Registre / RDAP | À quelles entités, coordonnées et données d’enregistrement la ressource est-elle rattachée ? |
Observation BGP | Quel ASN apparaît à l’origine du préfixe, depuis ce point d’observation et à cet instant ? |
RPKI / ROA | Quel AS est autorisé à être à l’origine d’une annonce, pour quel préfixe et quelle longueur ? |
IRR | Quels objets de routage et quelles informations de politique ont été déclarés ? |
Inventaire et suivi internes | Quelle organisation doit exploiter la ressource, selon quel accord, et qui doit intervenir en cas de changement ? |
RDAP fournit des informations d’enregistrement sur les adresses IPv4, IPv6 et les ASN. Selon l’objet retourné, on y trouve notamment une plage, un identifiant, un nom, des entités, des statuts et des événements. Leur structure est définie dans le RFC 9083. Le guide Lire une fiche RDAP d’adresse IP aide à les interpréter. Un statut active ne prouve pas qu’un préfixe est actuellement joignable.
BGP échange des informations de joignabilité entre systèmes autonomes ; le RFC 4271 décrit le protocole. Dans le chemin simplifié ci-dessous, AS64500 est l’AS d’origine affiché. Il faut également relever le collecteur, ses points d’observation et l’heure : aucun relevé isolé ne constitue une vue exhaustive d’Internet.
Préfixe : 203.0.113.0/24
Chemin AS simplifié observé : AS64496 AS64497 AS64500
Origine affichée : AS64500Une annonce ne suffit pas à établir qui est enregistré, qui dispose de droits contractuels ou qui a autorisé l’exploitation. Pour examiner cette couche technique, consultez Identifier l’AS qui annonce un préfixe IP.
Les exemples de cette édition utilisent les ressources de documentation des RFC 5737 et RFC 5398. Ils illustrent des relations, sans attribuer des comportements fictifs à des opérateurs réels.
Six situations où des noms différents peuvent être parfaitement cohérents
Un opérateur de transit annonce le bloc pour son client
Votre entreprise administre les adresses, mais le fournisseur de connectivité les annonce depuis son propre ASN. L’enregistrement et le routage décrivent alors deux responsabilités distinctes. Vérifiez que cette organisation est prévue et autorisée ; chercher à faire coïncider les noms ne résout pas le problème.
L’hébergement inclut l’exploitation du réseau
Un hébergeur ou un prestataire d’infogérance peut annoncer les adresses d’un client depuis son infrastructure. Cela ne modifie pas automatiquement leur enregistrement. L’accord de service, les autorisations et la configuration doivent permettre de relier les deux organisations.
Un service de protection DDoS prend temporairement le relais
Lors d’une attaque, le trafic peut être acheminé vers un réseau de nettoyage. L’origine passe par exemple de AS64500 à AS64501, sans changement du registre. Cette bascule doit avoir été préparée : autorisation d’origine, filtres, fenêtre d’intervention et retour au fonctionnement habituel. L’étiquette « protection DDoS » ne dispense pas de vérifier ces éléments.
Une migration est en cours
Un changement de prestataire ou d’ASN peut faire apparaître l’ancien et le nouvel opérateur pendant une période de transition. La même entreprise conserve la relation d’enregistrement. Une fenêtre de migration documentée, un responsable et un retour arrière prévu rendent cette situation explicable.
Le service utilise l’anycast
Un même préfixe peut desservir plusieurs sites. Selon l’architecture, les annonces utilisent un seul ASN ou plusieurs. L’anycast décrit une organisation du service ; il ne signifie pas à lui seul qu’il existe plusieurs AS d’origine. Les observations doivent être replacées dans cette architecture.
L’entreprise a changé, mais le réseau poursuit son activité
Après une acquisition ou une réorganisation, les opérations continuent souvent sur l’infrastructure existante. Les changements juridiques, les mises à jour du registre et la migration réseau suivent des calendriers différents. Le dossier Adresses IP et fusion-acquisition détaille les points à examiner.
Une modification du registre n’est pas une bascule réseau
À la suite d’un transfert IPv4, le registre peut désigner la nouvelle entreprise tandis que le même prestataire continue d’annoncer le bloc. C’est parfois le choix le moins perturbant pour les clients. Encore faut-il que la transition soit acceptée, autorisée et connue des équipes qui devront la terminer.
Entité enregistrée après transfert : Entreprise B
Origine prévue pendant la transition : AS64500
Origine BGP observée : AS64500
À vérifier séparément : accord et autorisation de l’Entreprise BL’inverse est tout aussi courant. Nouveau transit, changement d’ASN, activation d’un service DDoS, ingénierie de trafic, déménagement ou externalisation : BGP peut évoluer alors que l’entité enregistrée reste la même. Un registre inchangé n’est donc pas la preuve d’un réseau inchangé.
Les champs startAddress, endAddress, name, status, entities et events décrivent l’objet d’enregistrement, pas l’état instantané du routage. De même, voir un ASN annoncer un préfixe ne suffit pas à conclure qu’il en est le titulaire, qu’il est autorisé ou qu’il agit de façon malveillante. Chaque affirmation exige la preuve qui lui correspond.
Examiner l’autorisation d’origine, puis les déclarations IRR
Un ROA est un objet signé qui autorise un AS à être à l’origine d’annonces pour des préfixes donnés. Le RFC 9582 en définit le format. Cette autorisation ne valide ni tout le chemin AS ni les droits contractuels. Dans les exemples, « longueur maximale effective 24 » signifie que seul le /24 est autorisé : le champ maxLength peut être omis ; il n’est pas recommandé d’encoder une valeur redondante égale à la longueur du préfixe.
L’annonce correspond à l’autorisation attendue
Entité enregistrée : Entreprise A
Origine attendue : AS64500
Autorisation : 203.0.113.0/24 ; longueur maximale effective 24 ; AS64500
BGP : 203.0.113.0/24 → AS64500L’annonce correspond à l’autorisation indiquée. Cela ne démontre pas pour autant que tous les éléments du chemin ou du transfert des paquets sont sûrs. L’entreprise et l’AS qui exploite le réseau peuvent aussi rester deux entités différentes.
L’ASN a changé, l’autorisation est restée ancienne
Autorisation : 203.0.113.0/24 ; longueur maximale effective 24 ; AS64500
BGP : 203.0.113.0/24 → AS64501
Hypothèse : aucune autre autorisation validée ne correspond à cette annonceDans ces conditions, l’état est Invalid. Une migration incomplète ou une erreur de configuration peut l’expliquer, tout comme une annonce non autorisée. L’écart établit un défaut de correspondance ; il ne prouve pas à lui seul un détournement intentionnel.
Le prestataire est différent de l’entité enregistrée, mais autorisé
Entité enregistrée : Entreprise A
Prestataire prévu : Réseau B, AS64501
Autorisation : 203.0.113.0/24 ; longueur maximale effective 24 ; AS64501
BGP : 203.0.113.0/24 → AS64501L’écart entre les noms se comprend ici par l’organisation de l’exploitation. Il reste à rapprocher cette preuve technique du contrat et du changement approuvé. Un ROA ne remplace pas ces pièces.
Ce que signifient les trois états de validation
- Valid : au moins une donnée d’autorisation validée couvre le préfixe annoncé et correspond à la fois à l’ASN d’origine et à la longueur.
- Invalid : des données validées couvrent le préfixe, mais aucune ne correspond à l’ensemble des critères. L’origine ou une longueur excessive peuvent être en cause.
- NotFound : aucune donnée d’autorisation validée ne couvre ce préfixe. Ce n’est ni une absence de droits sur la ressource ni une garantie de sécurité.
Conservez l’heure, le validateur et l’état de ses données. La validation décrite par le RFC 6811 et la politique de filtrage distinguée dans le RFC 8481 sont deux étapes différentes : Invalid ne signifie pas automatiquement une coupure partout dans le monde. Voir aussi Couverture ROA et adoption de ROV.
Un objet IRR peut être en retard sur l’exploitation
route: 203.0.113.0/24
origin: AS64500Certains opérateurs construisent leurs filtres à partir des IRR. Si l’objet indique AS64500 mais que le réseau annonce désormais depuis AS64501, recherchez une déclaration périmée, une migration inachevée ou une erreur. Le RFC 2622 présente RPSL et le RFC 7454 le contexte d’exploitation. Un IRR reste un registre de déclarations, pas une observation du trafic ni un substitut à RPKI.
Une origine AS64502 inattendue mérite une enquête, surtout si l’inventaire, les autorisations et les objets IRR désignent tous AS64500. Confrontez la chronologie, les décisions internes et les réglages du prestataire avant de qualifier l’événement. Une divergence inexpliquée est un signal à traiter, pas encore un diagnostic.
Une enquête en sept étapes
1. Délimiter exactement le préfixe
Notez le CIDR et sa longueur. Un enregistrement couvrant un /20 et des annonces portant sur plusieurs /24 ne décrivent pas des objets identiques. Avant toute comparaison, établissez quelles plages contiennent lesquelles.
2. Relever les données RDAP
Consignez la plage, les entités associées, le registre, les statuts et les événements disponibles. Ajoutez la source et l’heure de consultation. Ne transformez pas un champ absent en information supposée.
3. Observer les annonces BGP
Relevez les préfixes, les origines, les chemins AS, les routes plus spécifiques et les éventuelles origines multiples. Précisez les points d’observation et les heures. Pour un incident important, croisez plusieurs vues : une route non visible depuis un endroit n’est pas nécessairement absente partout.
4. Vérifier RPKI pour l’annonce précise
Examinez le couple préfixe–origine observé. Derrière Valid, Invalid ou NotFound, vérifiez les données qui couvrent le préfixe, les ASN, les longueurs maximales et leur actualité. Le seul libellé ne suffit pas à expliquer le résultat.
5. Consulter les objets IRR
Repérez les objets route ou route6 et leur origin. Cherchez les déclarations anciennes, contradictoires ou oubliées lors du dernier changement.
6. Retrouver l’organisation prévue par l’entreprise
Quel ASN devait annoncer ? Quel prestataire devait intervenir ? Une migration ou un service DDoS a-t-il été activé ? Les données publiques montrent une partie des faits ; l’architecture, les contrats et les tickets de changement expliquent l’intention.
7. Attribuer l’écart à une cause étayée
Ne désignez pas arbitrairement une base comme référence absolue. Reconstituez la situation attendue, les décisions prises, les opérations réalisées et celles qui restent à faire. Consignez la conclusion, le responsable de la correction et le contrôle suivant : c’est ce qui rend l’enquête réutilisable lors d’un autre incident.
Regarder aussi les sous-préfixes et la chronologie
Une plage enregistrée peut recouvrir plusieurs routes
Multihébergement, implantation géographique, affectation à des clients et ingénierie de trafic peuvent conduire à exploiter différemment plusieurs sous-ensembles d’un bloc. L’exemple suivant montre uniquement une décomposition d’adresses. Il ne recommande pas d’annoncer des /25 sur Internet et ne présume pas de leur propagation mondiale.
Plage d’exemple : 203.0.113.0/24
Première moitié : 203.0.113.0/25
Seconde moitié : 203.0.113.128/25
Chaque sous-plage doit être rapprochée de sa propre organisation d’exploitationPlusieurs AS d’origine : un constat à expliquer
Observation A : 203.0.113.0/24 → AS64500
Observation B : 203.0.113.0/24 → AS64501Cette situation est couramment appelée MOAS, pour Multiple Origin AS. Elle peut être liée à une migration, à l’anycast, à une protection DDoS, à une architecture partagée ou à une annonce indésirable. Comparez les lieux et dates d’observation, les autorisations et l’organisation du service avant de trancher.
Le changement peut avoir une histoire documentée
AS64500 apparaissait en janvier, AS64501 apparaît en octobre. Le début du changement coïncide-t-il avec une acquisition, un déménagement, une migration ou l’activation d’un nettoyage DDoS ? Cette proximité fournit une piste ; seuls les éléments de changement permettent d’établir le lien.
Les mouvements d’entreprise expliquent parfois le décalage administratif
Changement de nom, fusion, réorganisation de filiales ou regroupement d’entités : les données du registre peuvent ne pas avoir suivi. Ce n’est pas une raison pour les laisser inexactes. Identifiez le responsable et la procédure de correction. Ces informations comptent pour la récupération des comptes, les transferts, les vérifications préalables et la réponse aux incidents.
Une adresse utilisée n’est pas forcément une ressource directement administrée
Si un fournisseur affecte des adresses à son client, RDAP et BGP peuvent tous deux désigner ce fournisseur. Avant d’en changer, déterminez les conditions de poursuite d’utilisation et de migration. Le fait d’utiliser une plage depuis longtemps ne suffit pas à établir qu’on pourra l’emporter chez un autre opérateur.
Documenter séparément les droits, les autorisations et la maîtrise opérationnelle
L’enregistrement est un élément important du dossier de gestion d’une ressource. Il ne permet pas, à lui seul, de tirer une conclusion juridique universelle sur la propriété. Contrats, transferts, documents d’entreprise, politiques applicables et droit concerné peuvent aussi entrer en jeu. BGP n’est pas davantage un registre de propriété : il décrit le routage observé.
Une entreprise peut garder la responsabilité administrative tout en confiant les équipements à un prestataire. Pour préparer une intervention ou une reprise, distinguez qui est enregistré, qui est autorisé comme origine, qui annonce effectivement et qui peut modifier les comptes ou les configurations.
| Préfixe | Entité enregistrée | ASN attendu | ASN observé | RPKI | Origin IRR | Suite à donner |
|---|---|---|---|---|---|---|
203.0.113.0/24 | Entreprise A | AS64500 | AS64500 | Valid | AS64500 | Éléments présentés cohérents ; surveillance habituelle |
198.51.100.0/24 | Entreprise A | AS64500 | AS64501 | Invalid | AS64500 | Rechercher un changement ou un défaut d’autorisation |
La seconde ligne suppose qu’une autorisation validée couvre le préfixe pour AS64500 et qu’aucune ne correspond à l’annonce de AS64501. Dans un vrai inventaire, ajoutez les horaires, le validateur, les accords avec le prestataire, les références de changement, le responsable et la date de réexamen. Sans ce contexte, un simple état peut donner une impression trompeuse de certitude.
Faire du rapprochement une pratique de continuité d’activité
Réexaminez ces relations lors d’un audit annuel, d’une acquisition, d’un transfert IPv4, d’un changement de prestataire ou d’ASN, du déploiement de RPKI, d’une perte de joignabilité inexpliquée, d’une intervention DDoS ou d’une réorganisation. Une situation de référence entretenue se révèle plus utile qu’un historique reconstitué dans l’urgence.
Un transfert administratif peut laisser plusieurs opérations techniques ouvertes
Le registre est à jour ; BGP, RPKI, IRR ou DNS peuvent encore nécessiter une intervention. Chaque étape doit avoir un responsable, un ordre de réalisation et une vérification. Le dossier Données 2026 sur les transferts IPv4 replace ces changements dans leur contexte : la circulation des ressources rend la coordination plus importante, pas moins.
La cohérence n’impose pas de tout changer le même jour
Après une acquisition, maintenir le réseau existant quelques mois peut protéger le service. L’objectif est que chaque couche soit comprise, documentée, conforme à la situation réelle et récupérable. Aligner toutes les opérations à une date unique pour obtenir une apparence d’uniformité peut au contraire créer un risque inutile.
Un réseau qui fonctionne a aussi besoin de données fiables
Savoir quelles ressources existent, à quelle entité elles sont rattachées, quel ASN doit les annoncer, quels ROA et objets IRR les accompagnent et qui tient les comptes facilite les migrations, le dépannage et la reprise après incident. La joignabilité actuelle ne rend pas les dossiers administratifs facultatifs ; leur exactitude ne garantit pas non plus le bon routage.
Ce sont les réseaux en fonctionnement qui acheminent les paquets, pas une ligne dans un registre. Une gouvernance solide rend vérifiables les liens entre enregistrement, autorisation, exploitation et responsabilité. Elle doit permettre d’expliquer les écarts et de corriger les erreurs, au lieu de demander à une seule base de données de répondre à toutes les questions.
Avant de clore l’enquête
| Point de contrôle | Question à résoudre |
|---|---|
Préfixe | Compare-t-on exactement la même plage CIDR ? |
RDAP | Quelle entité apparaît dans l’enregistrement ? |
BGP | Quelle origine est observée, où et quand ? |
RPKI | Une autorisation validée correspond-elle au préfixe, à sa longueur et à l’origine ? |
IRR | Quelle origine a été déclarée, et est-elle toujours pertinente ? |
Routes plus spécifiques | Des sous-préfixes sont-ils annoncés séparément ? |
Origines multiples | Plusieurs origines sont-elles visibles et expliquées ? |
Historique | Quand le routage a-t-il changé, et pourquoi ? |
Prestataire | Un tiers est-il chargé de l’annonce ou de l’exploitation ? |
Dossier interne | L’état observé correspond-il à l’organisation prévue ? |
Justificatifs | Peut-on vérifier les relations et décisions avancées ? |
Continuité | Qui peut corriger, mettre à jour ou rétablir chaque couche ? |
Sept raccourcis à éviter
Déclarer toute différence anormale : un tiers peut annoncer un bloc conformément à l’accord prévu.
Prendre la concordance des noms pour une garantie de sécurité : elle ne couvre pas tous les risques de routage.
Lire RDAP comme une vue BGP en temps réel : les données d’enregistrement ont un autre rôle.
Déduire la propriété de l’annonce BGP : le comportement technique ne suffit pas à établir les droits.
Oublier RPKI : on perd alors un élément essentiel sur l’autorisation d’origine.
Négliger les dossiers internes : les sources publiques ne décrivent pas toute l’intention d’exploitation.
Ne pas revenir sur les données après un changement : migrations, transferts et acquisitions peuvent laisser des mises à jour inachevées.
La question utile n’est pas « quelle base détient toute la vérité ? », mais « que décrit chacune, et peut-on expliquer leurs relations ? ». Un registre ne route pas les paquets, BGP ne prouve pas l’autorisation, un ROA ne décrit pas toute l’architecture et un IRR ne garantit pas la configuration du jour. Respecter ces limites permet d’exploiter, de transférer et de rétablir les ressources avec de meilleurs éléments de décision.
Questions fréquentes
Pourquoi RDAP et BGP ne désignent-ils pas la même organisation ?
Ils décrivent des fonctions différentes. RDAP expose l’enregistrement ; BGP révèle l’origine observée d’une annonce. Un prestataire peut annoncer les adresses de son client. Il faut rapprocher cette observation des autorisations et de l’accord d’exploitation.
L’ASN d’origine est-il nécessairement celui du titulaire du préfixe ?
Non. Il identifie l’origine de l’annonce observée, sans établir à lui seul la relation d’enregistrement, les droits contractuels ou la situation juridique de la ressource.
Un autre réseau peut-il annoncer les adresses enregistrées au nom de mon entreprise ?
Une telle organisation existe notamment pour le transit, l’hébergement ou la protection DDoS. Pour le bloc concerné, vérifiez l’accord entre les parties, l’autorisation d’origine et la configuration réelle ; la possibilité générale ne valide pas chaque cas particulier.
RDAP permet-il de consulter le routage BGP en temps réel ?
RDAP fournit avant tout des données d’enregistrement. Consultez les observations BGP pour le routage, en notant leur origine et leur heure, puis rapprochez-les des autorisations et du dossier interne.
À propos de cette édition
Ann Yong a publié l’article anglais le 16 octobre 2026. Cette édition française suit le déroulement d’une enquête d’exploitation : situations courantes, vérifications, tableaux de travail et questions fréquentes. Le texte anglais historique est conservé. Les précisions sur les points d’observation, les limites de la validation RPKI et les ressources de documentation sont des ajouts éditoriaux du 31 octobre 2026 ; elles ne sont pas attribuées rétroactivement à l’autrice. Les adresses, ASN et noms d’organisations des exemples sont fictifs ou réservés à la documentation. Il ne s’agit ni de mesures de réseaux réels ni de configurations à déployer.
Des faits vérifiables, des responsabilités identifiables
Précision ajoutée par NRS le 31 octobre 2026. Les indications ci-dessous sur la représentation et la participation sont de NRS et ne font pas partie du texte original d’Ann Yong.
Les utilisateurs de ressources doivent pouvoir comprendre les décisions qui les affectent, faire corriger les erreurs et participer à leur gouvernance. NRS Shield présente l’accompagnement proposé face aux risques liés aux ressources et à leur gouvernance. Si vous envisagez de confier une représentation à NRS, examinez séparément le mandat POA : mandataire, périmètre, durée, pouvoirs de décision et modalités de révocation. Le POA est un mandat de représentation, pas un ROA. Il ne donne pas à NRS le contrôle du routage et ne garantit pas la continuité du service. Lire ces informations, demander conseil ou adhérer ne vaut pas signature de ce mandat.
Découvrir NRS Shield · Comprendre le mandat POA · Voir les actions en cours