Résumé

  • Les registres, les annonces BGP, les historiques de première et dernière observation, les voisinages et les bases opérateur ne mesurent pas la même réalité.
  • Une conclusion défendable sur la continuité exige une fenêtre temporelle définie et la convergence de plusieurs couches de preuve; une réponse vide ou indisponible ne prouve ni arrêt, ni retrait, ni relocalisation.

La continuité d’un réseau est souvent décrite comme si elle possédait un indicateur unique. Un ASN existe ou n’existe plus. Des préfixes sont annoncés ou ne le sont pas. Une fiche apparaît dans une base opérateur ou en disparaît. Cette présentation est commode, mais elle mélange des mécanismes différents : l’identité administrative, la propagation d’une route, la visibilité depuis des collecteurs, la relation observée avec d’autres ASN et la capacité réelle à fournir un service à des clients.

Le cas de ROYA Communications and Internet Services Company Ltd., associé dans cette commission à l’AS210837, rend cette distinction particulièrement concrète. Une couverture antérieure a rappelé qu’une observation historique de juillet 2022 associait 22 préfixes IPv4 et 29 préfixes IPv6 au réseau. Elle a aussi souligné que la visibilité historique, l’identité du registre et la mesure actuelle ne répondaient pas à la même question. Cette nouvelle analyse ne transforme pas cette observation passée en mesure actuelle.

Elle pose une question différente : comment construire un test de continuité qui puisse être répété, comparé dans le temps et réfuté par les données ?

Le premier piège : une identité qui survit à son activité observable

Une fiche de registre établit une identité administrative ou une délégation de ressources selon les données publiées par l’autorité concernée. Elle ne prouve pas que les routeurs associés à cette identité transmettent actuellement des paquets, que les clients disposent d’un accès fonctionnel ou qu’une entreprise exploite encore la même infrastructure. La base pertinente pour une telle vérification est le registre et ses services d’observation, notamment les points d’accès RIPEstat utilisés dans ce dossier (vue d’ensemble RIPEstat).

Cette séparation est importante parce qu’un état administratif peut changer plus lentement qu’un état opérationnel. Une ressource peut rester documentée pendant une période où les annonces cessent, où un fournisseur de transit change, où un opérateur migre ses adresses ou où la visibilité publique devient incomplète. À l’inverse, une route peut être annoncée par une organisation différente, ou depuis une topologie différente, sans que cela suffise à démontrer une continuité commerciale de l’entreprise initialement associée à l’ASN.

Le registre répond donc à une question étroite : quelle identité ou quelle allocation est publiquement associée à la ressource ? Il ne répond pas directement à la question : le service est-il disponible aujourd’hui, et qui en contrôle la continuité ?

Le deuxième piège : traiter une mesure de routage comme une mesure de service

Les données d’annonces et de statut de routage observent la présence d’informations de routage dans les systèmes mesurés. Les résultats peuvent indiquer qu’un préfixe a été annoncé, qu’un origin ASN a été observé ou qu’une route est visible depuis certains collecteurs. Les interfaces RIPEstat d’annonces et de statut utilisées pour le test sont donc essentielles (préfixes annoncés; statut de routage). Mais elles ne constituent pas un test complet de joignabilité des clients.

Une annonce BGP signifie qu’un chemin a été proposé ou observé dans le plan de contrôle. Elle ne garantit pas que les paquets atteignent un équipement de bord, que les routes de retour soient correctes, que les services applicatifs répondent ou que les clients continuent de payer et d’utiliser la connexion. Un réseau peut annoncer une plage tout en connaissant une panne d’accès, une mauvaise configuration, une défaillance d’alimentation ou une rupture de capacité en amont.

La relation inverse est également importante. L’absence d’une valeur dans une réponse donnée ne prouve pas nécessairement l’absence de route dans l’ensemble de l’Internet. Les collecteurs n’ont pas tous la même couverture, les API peuvent avoir des retards ou des erreurs, et une route peut être visible à certains endroits sans apparaître dans une vue particulière. C’est pourquoi un résultat de routage doit être daté, contextualisé et comparé à d’autres mesures plutôt que converti en verdict binaire.

Le temps est une couche de preuve, pas un simple champ de métadonnées

Une photographie instantanée répond mal à une question de continuité. Ce qui compte souvent est la persistance : une route est-elle réapparue après une interruption ? Depuis quand est-elle observée ? La dernière observation est-elle récente ou ancienne ? Les données de première et de dernière visibilité de RIS peuvent contribuer à cette chronologie (historique de première et dernière observation).

Une série temporelle bien définie permet de distinguer plusieurs scénarios. Une annonce actuelle accompagnée d’observations récentes et répétées est cohérente avec une visibilité de routage persistante. Une dernière observation ancienne, combinée à l’absence d’annonces pendant une fenêtre suffisamment longue, est cohérente avec une discontinuité de routage. Mais même ce second scénario ne révèle pas automatiquement la cause. Il peut correspondre à un arrêt, une migration, un changement d’ASN, une réorganisation de l’annonce, un filtre, une panne prolongée ou une limite de mesure.

La fenêtre d’observation doit donc être explicitement fixée avant l’interprétation. Dire qu’un réseau est « absent » sans préciser de quelle API, de quels collecteurs, de quelle date et de quelle durée il s’agit transforme une limite méthodologique en affirmation opérationnelle.

Les voisinages révèlent une topologie observée, pas un contrat commercial

Les vues de voisins, d’amonts et de pairs apportent une couche supplémentaire. Elles peuvent montrer que certains ASN ont été observés à proximité dans le graphe BGP ou qu’un chemin de transit est apparu dans les données disponibles (voisins ASN; amonts BGPView; pairs BGPView). Cette information aide à comprendre comment une route pouvait être propagée ou par quels points une visibilité a été obtenue.

Elle ne suffit toutefois pas à établir la nature commerciale de la relation. Un voisin observé peut être un fournisseur, un pair, un intermédiaire, un client, un échange indirect ou le résultat d’une structure de propagation qui ne correspond pas à un contrat direct. Le mot « upstream » dans une API ou dans une vue technique doit donc rester attaché à la définition de cette source. Il ne doit pas être reformulé en « fournisseur contractuel » sans preuve distincte.

Cette prudence est particulièrement importante lorsque l’on cherche à comprendre le contrôle de la continuité. La topologie observée peut identifier un point de dépendance technique, mais elle ne démontre pas qui possède l’équipement, qui paie la capacité, qui peut modifier l’annonce ou qui a l’autorité juridique de maintenir le service.

Le rôle limité des bases opérateur

PeeringDB peut fournir un contexte sur la présence déclarée d’un réseau, ses points d’interconnexion ou les informations qu’un participant a choisi de publier (entrée PeeringDB). Cette base peut aider à orienter une enquête et à comparer les informations fournies par l’opérateur avec les observations de routage. Elle ne constitue pas, par elle-même, une preuve de forwarding actuel, de reachability client ou de continuité commerciale.

Une entrée absente peut signifier que le réseau n’a pas publié d’information, que l’identifiant recherché ne correspond pas à la structure utilisée, que la donnée n’est pas à jour ou que le réseau ne participe pas à la base. Une entrée présente peut être ancienne ou descriptive. Dans les deux cas, elle doit être traitée comme une couche de contexte, non comme le dernier mot sur l’activité opérationnelle.

La même règle s’applique aux résultats BGPView concernant les préfixes, les amonts ou les pairs (préfixes BGPView). Ils peuvent corroborer ou contredire une autre observation, mais leur valeur dépend de la date, de la couverture et de la comparaison avec les sources parallèles.

Le test de continuité : une conjonction datée de mesures

Le test défendable pour AS210837 devrait être construit comme une matrice, et non comme une recherche d’un chiffre magique. À une date de début et une date de fin déterminées, il faudrait recueillir au moins cinq couches :

  1. Identité administrative. Vérifier l’association publique entre l’ASN, l’organisation et les ressources, en notant les dates et les éventuelles divergences de registre.
  2. Annonces observées. Mesurer les préfixes et l’état de routage depuis les mêmes sources ou depuis un ensemble documenté de collecteurs.
  3. Persistance temporelle. Comparer les dates de première et de dernière observation avec la fenêtre actuelle, plutôt que de juxtaposer une archive ancienne et une réponse récente.
  4. Topologie visible. Examiner les voisins, pairs et amonts comme des relations observées dans le plan de contrôle, sans les convertir en relations commerciales.
  5. Contexte opérateur. Comparer les données publiées par PeeringDB ou d’autres sources de l’opérateur, tout en conservant leur statut déclaratif.

La conclusion doit ensuite être formulée au niveau que les données autorisent. La convergence de plusieurs collecteurs, une activité récente de première et dernière observation, une identité d’origine cohérente et des relations de routage répétées soutiendraient l’existence d’une visibilité de routage actuelle. Cela ne prouverait toujours pas la continuité du service client.

À l’inverse, l’absence d’annonces dans une fenêtre définie, une dernière observation ancienne et l’absence de corroboration opérateur soutiendraient une hypothèse de discontinuité de routage. La cause resterait ouverte. Il faudrait encore distinguer arrêt, retrait, migration, changement d’identité, filtrage et défaillance de mesure.

Ce que le dossier actuel permet et ne permet pas de dire

Le dossier de recherche utilisé ici identifie les points d’accès publics nécessaires à cette comparaison, mais il n’a pas obtenu de valeurs actuelles vérifiées pour les réponses RIPEstat, BGPView ou PeeringDB. Il ne permet donc pas d’annoncer un nombre actuel de préfixes, de confirmer une annonce, de dater une première ou dernière visibilité, d’identifier des voisins ou amonts actuels, de confirmer une présence PeeringDB ou de déduire le statut opérationnel de ROYA Communications and Internet Services Company Ltd.

Cette limite n’est pas un résultat nul. Elle définit la prochaine expérience observable. Une collecte répétée doit conserver les URL, les horodatages, les réponses brutes et la définition exacte de chaque indicateur. Les résultats doivent être comparés sur la même fenêtre, avec les erreurs d’API et les changements de couverture consignés séparément. Une réponse vide isolée ne doit pas être interprétée comme un retrait. Un registre inchangé ne doit pas être interprété comme une activité continue.

Le point central est donc méthodologique : la continuité devient testable lorsque les couches sont alignées dans le temps. L’identité administrative peut persister pendant que la surface de routage change. Une annonce peut exister sans garantir le service. Une relation BGP peut être visible sans révéler le contrat. Une base opérateur peut contextualiser sans prouver le forwarding. La divergence entre ces couches est un signal d’enquête, pas un verdict.

Pour AS210837, la conclusion responsable demeure bornée : une observation historique de routage a été rapportée, mais les données disponibles dans ce dossier ne mesurent pas l’état actuel. La prochaine réponse utile ne sera pas une nouvelle affirmation fondée sur une seule API. Ce sera une série d’observations synchronisées, répétées et suffisamment documentées pour montrer soit une visibilité de routage persistante, soit une rupture de cette visibilité, tout en laissant explicitement ouverte la question plus exigeante de la continuité réelle du service.