Résumé

  • L'enregistrement routing-status de RIPEstat pour AS211386, à query_time 2026-10-17T16:00:00, indique que 0 pair IPv4 sur 328 et 0 pair IPv6 sur 318 du RIS voient ce numéro d'AS, avec 0 préfixe IPv4 et IPv6 annoncé et 0 voisin observé.
  • La couche d'identité renvoie en revanche quelque chose : une chaîne de titulaire LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. et un enregistrement de réseau PeeringDB d'id 26805 et org_id 791 au nom LINX MAPS.
  • L'objet aut-num, son rendu RDAP et une requête d'objets de route n'ont renvoyé aucun texte le 2026-10-18 : ces enregistrements sont illisibles, non vides.

Un numéro, deux noms attachés

L'appel AS-overview de RIPEstat pour AS211386 renvoie un unique champ d'attribution, holder, qui se lit LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. (enregistrement AS-overview). PeeringDB, interrogé séparément sur le même numéro, renvoie un objet réseau avec id 26805, org_id 791, name LINX MAPS, asn 211386 et status ok (requête réseau PeeringDB). Cette seconde réponse est arrivée tronquée, les points de suspension remplaçant des champs que cet article n'utilise pas ; les cinq valeurs citées ici sont tout ce que l'enregistrement apporte.

Deux catalogues, un numéro, des noms qui renvoient tous deux à London Internet Exchange et dont l'un ajoute Azure. C'est là toute la base sur laquelle ce numéro peut être décrit comme lié à un exploitant de point d'échange et à une plateforme cloud. Une chaîne de titulaire est une attribution à l'intérieur d'un produit de données ; ce n'est ni une description de service, ni un document de structure d'entreprise, ni l'affirmation qu'une fonction tourne. Aucun document obtenu pour cet article ne décrit une relation entre London Internet Exchange et Microsoft, et aucune n'est affirmée ici. La fiche de répertoire AZURE London Internet Exchange Ltd. reprend le nom ; la répétition entre catalogues ne corrobore pas l'exploitation.

Ce que les collecteurs ont mesuré

L'enregistrement routing-status de RIPEstat pour AS211386 porte query_time 2026-10-17T16:00:00 (enregistrement routing-status). Il rapporte 0 pair IPv4 du RIS sur 328 voyant ce numéro d'AS et 0 pair IPv6 sur 318. L'espace annoncé est de 0 préfixe IPv4 et 0 adresse IPv4, 0 préfixe IPv6 et 0 /48 IPv6. Les objets first_seen et last_seen sont vides, et observed_neighbours vaut 0. Un objet first_seen vide signifie que le système RIS ne détient aucune première observation de cette origine ; c'est une affirmation sur l'archive du collecteur, non sur le monde.

L'appel announced-prefixes pour le même numéro renvoie une liste vide pour la fenêtre 2026-10-03T16:00:00 à 2026-10-17T16:00:00, avec latest_time 2026-10-17T16:00:00 et un earliest_time d'archive de 2000-08-01T00:00:00 (enregistrement announced-prefixes). Cette réponse porte sa propre limite dans son corps : les résultats excluent les routes de très faible visibilité, définies comme vues par moins de 10 pairs RIS à flux complet. La liste vide est donc bornée deux fois, par une fenêtre de deux semaines et par un plancher de visibilité, et elle ne peut pas être lue comme la preuve qu'aucune annonce n'a jamais été faite. Ce qu'elle établit est plus étroit et reste utile : sur un réseau de collecte de 328 points de vue IPv4 et 318 IPv6, dans la fenêtre enregistrée, aucun préfixe originaire d'AS211386 n'a franchi ce plancher.

L'adjacence confirme la même forme. L'appel asn-neighbours de RIPEstat renvoie des neighbour_counts de left 0, right 0, unique 0 et uncertain 0, avec un tableau neighbours vide (enregistrement asn-neighbours). Un locuteur sans voisin observé n'a aucun chemin observé dans un sens ou dans l'autre ; il ne participe pas à la topologie que les collecteurs peuvent voir.

Où la lecture s'arrête

Trois lectures de registre ont échoué le 2026-10-18, et leur échec fait partie de la conclusion plutôt que d'une note de bas de page. La requête REST de la base RIPE pour l'aut-num AS211386 n'a renvoyé aucun texte d'objet (requête aut-num), si bien que le statut de l'objet, son organisation de rattachement, son mainteneur, ainsi que ses attributs de création et de dernière modification restent non établis. Le rendu RDAP du même objet était inaccessible au moment de la récupération (requête RDAP). La requête REST des objets de route d'origine AS211386 a renvoyé un échec d'accès (requête objets de route). L'existence d'objets route ou route6 sous cette origine est donc non vérifiée, et cet article n'affirme ni leur présence ni leur absence.

Deux autres absences relèvent de la même section. Aucun certificat de ressource RPKI ni aucune ROA couvrant AS211386 n'a été obtenu, et aucun as-set IRR, texte de politique d'aut-num ou entrée de politique de peering n'a été obtenu : rien n'est donc dit des intentions de sécurité de routage ou de politique attachées au numéro. Aucun document publié par London Internet Exchange ou par Microsoft décrivant un serveur de routes exploité dans Azure n'a été obtenu non plus ; la fonction qu'implique la chaîne de titulaire reste non confirmée.

Ce sont des lacunes de cette lecture, datées du 2026-10-18, et non des constats sur les enregistrements sous-jacents.

Ce que la lacune change

La conséquence pratique porte sur la question à laquelle un enregistrement de registre répond. Une inscription aut-num dit qui est habilité à agir pour un numéro ; elle ne dit pas que du trafic existe. Pour un exploitant qui applique des filtres de préfixes fondés sur l'IRR ou une validation RPKI, ce sont des entrées distinctes avec des modes de défaillance distincts, et un numéro présent dans un registre sans rien annoncer est un cas courant plutôt qu'une contradiction.

La distinction ne coûte cher que lorsqu'un processus d'achat ou de diligence traite la présence d'un enregistrement comme la preuve d'une surface en exploitation — une présence en point d'échange, un raccordement cloud, un serveur de routes — et s'arrête là.

Pour AS211386, les deux enregistrements divergent d'une manière précise et mesurable : la couche d'identité renvoie un nom et une entrée PeeringDB, la couche d'observation renvoie des zéros avec leurs dénominateurs. Rien de ce qui a été obtenu ne montre le numéro portant du trafic à 2026-10-17T16:00:00, et rien de ce qui a été obtenu ne montre qu'il n'en a jamais porté.

Ce qui changerait cette lecture

La lecture est réfutable par des moyens ordinaires, et c'est la propriété utile d'une mesure. Une liste announced-prefixes non vide, un ris_peers_seeing non nul, un first_seen ou un last_seen renseigné, ou un nombre de voisins non nul suffiraient chacun à la briser, et l'un d'eux pourrait apparaître dans la prochaine fenêtre sans contredire quoi que ce soit d'observé ici. Ce qui ne la changerait pas, c'est une entrée de catalogue supplémentaire : une deuxième fiche de répertoire, une description dans une base tierce, ou un nom qui se lit comme un déploiement. Ceux-là ajoutent des noms, pas des chemins.

Pour l'instant, le numéro est une inscription avec une attribution, un enregistrement PeeringDB et aucun chemin observé à 2026-10-17T16:00:00. La question à laquelle l'enregistrement ne peut pas répondre est celle qu'un acheteur veut d'ordinaire voir tranchée — si la chose nommée dans le champ holder a déjà fonctionné — et la forme honnête de la réponse est que la lecture s'est arrêtée à trois requêtes en échec le 2026-10-18 et à un plancher de visibilité de 10 pairs à flux complet.