Résumé

  • Dans l’objet observé, cidr0_cidrs exprime sous forme de préfixe la plage enregistrée de 196.1.0.0 à 196.1.0.255.
  • Cette donnée appartient au registre RDAP : elle ne révèle aucune annonce BGP, aucun AS d’origine, aucun chemin et aucune mesure de trafic.
  • Un système qui rapproche registre et routage doit conserver pour chaque fait sa source, son horodatage et son périmètre de preuve.

Une écriture commune, deux faits différents

Le point de départ est un objet d’enregistrement. Lors de la capture du 28 août 2026, le service RDAP public d’AFRINIC a renvoyé un objet de classe ip network. Son identifiant reprend la plage inclusive 196.1.0.0 - 196.1.0.255, son type est ASSIGNED PI et le tableau cidr0_cidrs contient une seule entrée : 196.1.0.0/24. Les deux écritures désignent ici les mêmes adresses.

Le contexte donne son sens à l’information. Les adresses de début et de fin, le parent, le code pays, le statut et les événements décrivent l’objet tenu par le registre. La valeur active qualifie cet objet dans RDAP. Elle ne transforme pas la réponse en table de routage, pas plus que le parent n’établit une relation de transit entre réseaux.

La documentation d’AFRINIC précise la fonction de la requête. Une recherche portant sur une adresse ou un préfixe retourne le réseau enregistré le plus spécifique qui l’englobe complètement. La question est donc : quel objet du registre contient cette ressource ? Ce n’est pas : quelle route est actuellement préférée par un routeur, ou quel chemin les paquets empruntent-ils ?

La proximité visuelle entretient pourtant l’ambiguïté. Dans un collecteur BGP, 196.1.0.0/24 pourrait apparaître comme destination d’une route. Dans la réponse RDAP observée, la même chaîne de caractères est une représentation compacte d’une plage enregistrée. Le préfixe est identique ; la proposition qu’il soutient ne l’est pas.

BGP associe une information de joignabilité à des attributs de chemin échangés entre systèmes autonomes. Pour affirmer qu’une route existe, il faut une observation située dans le temps et dans un point de vue : un pair ou un collecteur l’a vue, avec une origine et des attributs déterminés. Le document RDAP ne contient pas cette observation.

Le rapprochement entre les deux univers reste utile. Le préfixe peut servir de clé pour comparer l’enregistrement avec des mesures de routage indépendantes. Mais une clé de jointure n’est pas une preuve. Tant qu’aucune ligne de routage sourcée n’existe, la colonne « route observée » doit rester vide.

Ce que cidr0_cidrs apporte réellement

Le modèle RDAP de base décrit un réseau IP par une adresse de début et une adresse de fin. Ce choix permet de représenter précisément des plages qui ne correspondent pas à un seul bloc CIDR. Une plage dite « off-bit » peut traverser plusieurs frontières de préfixes ; il faut alors plusieurs expressions CIDR pour la couvrir sans inclure d’adresses supplémentaires.

L’extension cidr0 répond à ce besoin. Elle ajoute un tableau dont chaque élément contient un préfixe IPv4 ou IPv6 et une longueur. Le tableau complet constitue la traduction en notation CIDR des limites de l’objet enregistré. Sa forme en liste n’indique pas la présence de plusieurs routes : elle permet simplement d’exprimer une plage avec autant de blocs qu’il est nécessaire.

Dans le cas observé, l’alignement est exact. Les 256 adresses de 196.1.0.0 à 196.1.0.255 se résument en un /24. La simplicité du résultat est pratique pour un inventaire, une liste de contrôle ou une comparaison avec une autre base. Elle n’élargit pas le contenu probant de la source.

La liste rdapConformance apporte une garantie complémentaire. Elle annonce notamment cidr0, ce qui permet au client de rattacher le champ à une spécification enregistrée plutôt que d’en déduire le sens à partir de son seul nom. Un logiciel qui reconnaît l’extension sait comment lire la structure. Il ne reçoit pour autant aucune autorisation d’inventer des propriétés absentes.

La transformation sûre est donc limitée. On peut produire un champ « préfixes de la plage enregistrée » à partir de cidr0_cidrs. On ne peut pas en déduire automatiquement « préfixes annoncés », « AS d’origine » ou « réseau joignable ». Ces étiquettes nécessitent d’autres sources et d’autres observations.

Ce qui manque pour parler d’une route

La réponse d’AFRINIC ne dit pas si 196.1.0.0/24 figurait dans une table BGP au moment de la capture. Elle n’indique aucun système autonome d’origine, aucun AS_PATH, aucun nombre de pairs observateurs et aucune date d’annonce ou de retrait. Elle ne permet pas non plus de savoir si la plage est couverte par un agrégat plus large ou si des préfixes plus spécifiques sont visibles.

Ces absences sont constitutives, non accessoires. Une route BGP combine une destination portée par l’information de joignabilité et des attributs de chemin. Sans observation de ce couple, il n’y a pas de preuve de route. La notation CIDR présente dans le registre ne remplace ni le message BGP ni la vue du collecteur.

Même une annonce confirmée ne répondrait pas à toutes les questions. Elle pourrait montrer qu’un point d’observation a reçu une route donnée à un instant donné. Elle ne démontrerait pas à elle seule le passage effectif du trafic, la qualité du service, l’existence d’un contrat de transit, l’accès aux routeurs ou le contrôle juridique de l’organisation. Chaque conclusion demande une preuve adaptée.

Le temps doit également rester visible. Une fiche de registre peut demeurer stable pendant que le routage change. À l’inverse, les métadonnées du registre peuvent être corrigées sans modification de l’annonce. Une analyse qui juxtapose deux captures de dates différentes doit le dire, faute de quoi une simple coïncidence devient un récit causal.

Les affirmations négatives exigent encore plus de prudence. L’absence d’une route dans un collecteur n’établit pas son absence partout. La visibilité dépend du point d’observation, de la fenêtre temporelle et de la méthode de collecte. La bonne formulation reste bornée : telle source a vu, ou n’a pas vu, telle route à tel moment.

Une méthode de preuve au niveau du champ

Une chaîne de données robuste conserve d’abord le fait RDAP tel qu’il a été observé : URL, heure de capture, identifiant de l’objet, bornes de la plage, indicateurs de conformité et contenu du tableau CIDR. Elle lui associe ensuite une interprétation étroite : le tableau exprime la plage enregistrée sous forme de préfixes.

Les faits de routage entrent dans une collection distincte. Ils portent leur propre source, leur propre horodatage, le point de vue, le préfixe, l’origine et les attributs disponibles. Une couche de rapprochement peut alors signaler un accord, une divergence ou l’absence de mesure. Elle ne doit jamais créer la donnée manquante.

Cette séparation rend les contradictions analysables. Une plage enregistrée peut être couverte par un agrégat. Un préfixe plus spécifique peut apparaître à l’intérieur. Plusieurs collecteurs peuvent rapporter des chemins différents. Une origine peut changer après la capture RDAP. Aucun de ces cas n’annule le fait d’enregistrement ; il décrit une autre dimension ou un autre instant.

La même discipline vaut pour la rédaction. « AFRINIC enregistre cette plage sous la forme 196.1.0.0/24 » est soutenu par la réponse capturée. « Le préfixe est annoncé » réclame une mesure BGP citée. « Le détenteur contrôle le réseau » réclame encore d’autres éléments. Quelques mots de qualification évitent de transformer une donnée traçable en conclusion sans source.

Périmètre de preuve et sources

Cette analyse repose sur une capture limitée des champs supérieurs de la réponse RDAP d’AFRINIC à 2026-08-28T06:35:54Z. Aucun relevé BGP n’a été ajouté au dossier. Le texte ne formule donc aucune affirmation sur l’annonce actuelle du préfixe, son origine, son chemin, sa joignabilité ou son trafic.

Les limites sémantiques viennent de la documentation d’AFRINIC, du registre des extensions RDAP de l’IANA, de la spécification cidr0 du NRO et des RFC consacrées aux réponses RDAP et à BGP. Ensemble, ces sources montrent à la fois ce que le champ établit et ce qu’il laisse à mesurer.