Résumé

  • RIPE RDAP couvre exactement l’AS212483, utilise le handle AS212483, le nom d’objet level86 et relie l’organisation ORG-LECL2-RIPE à LEVEL EIGHTY-SIX COMMUNICATIONS LTD. Le statut active concerne le dossier administratif, pas l’état d’une route ou d’un service.
  • PeeringDB déclare onze lignes d’échange pour Level 86. RIPEstat rapporte, dans une observation RIS horodatée, une visibilité IPv4 et IPv6 très différente. Une déclaration de répertoire ne constitue pas une télémétrie de session, et une vue de collecteurs ne représente pas tout internet.
  • La méthode la plus sûre consiste à garder l’ASN comme identifiant commun, puis à distinguer identité enregistrée, présence déclarée, visibilité de routage et résultat de service. Aucun de ces documents ne prouve à lui seul trafic, capacité, diversité physique, résilience ou expérience client.

Un même ASN, plusieurs horloges

Un système autonome est un réseau, ou un ensemble de réseaux, qui présente une politique de routage commune. Son numéro de système autonome, l’ASN, permet d’identifier ce domaine lorsque les réseaux échangent des informations de joignabilité au moyen de BGP, le Border Gateway Protocol.

Dans ce dossier, l’AS212483 sert de point d’ancrage. Il permet de rapprocher le nom Level 86, un objet de registre et des informations d’interconnexion sans dépendre uniquement d’une marque commerciale. Cette précision est utile pour un opérateur, un client ou une équipe d’intervention qui doit confirmer qu’elle examine le bon réseau.

Le numéro n’est toutefois pas un capteur. Il ne dit pas si un préfixe est annoncé maintenant, si une autre politique l’accepte ou si une application répond. Le registre, le répertoire d’interconnexion et le collecteur de routes ont chacun leur propre méthode et leur propre horloge. Les regrouper sous une formule comme « état actuel du réseau » effacerait des différences essentielles.

RIPE RDAP fixe l’identité administrative

La réponse RDAP de RIPE porte exactement sur le numéro autonome 212483 : ses bornes de début et de fin sont toutes deux 212483. Elle utilise le handle AS212483, nomme l’objet level86 et lui attribue le statut administratif active. Parmi les entités de la réponse, le handle d’organisation enregistrée ORG-LECL2-RIPE porte le nom LEVEL EIGHTY-SIX COMMUNICATIONS LTD. C’est ce couple précis qui établit le lien d’identité avec l’entrée Level 86 du répertoire BTW.

Le dossier indique un événement d’enregistrement le 8 août 2022 à 13 h 34 min 13 s UTC et un dernier changement le 9 décembre 2025 à 10 h 25 min 29 s UTC. Ces dates décrivent la vie du dossier publié. Elles ne correspondent pas nécessairement à l’installation d’un routeur, à l’ouverture d’une session, à une modification de service ou à un événement vécu par un client.

Le mot active doit être lu avec la même retenue. Il signale l’état de l’objet administratif ; il ne teste ni BGP, ni une interface, ni une application. La réponse contient aussi d’autres entités auxquelles un rôle de registrant est associé. Il serait donc incorrect d’attribuer l’identité commerciale à chaque rôle : le lien pertinent est l’objet d’organisation nommé.

Cette limite n’affaiblit pas le registre. Son utilité est de tenir un grand livre du numéro ressource, de son identité et de son historique public. Une coordination fiable commence par cette unicité, puis se poursuit avec les systèmes qui observent le réseau en fonctionnement.

PeeringDB publie les déclarations du participant

PeeringDB retourne une ligne réseau pour l’ASN 212483. Elle nomme le réseau Level 86, donne 86 COMMUNICATIONS comme autre nom, classe le profil en Enterprise, affiche une politique générale de peering Open et l’ensemble IRR AS-86. Le profil déclare également 100 préfixes IPv4 et 120 préfixes IPv6.

Ces champs forment une déclaration publique maintenue par le participant. Ils peuvent être comparés à un inventaire, à une politique ou à une configuration attendue. Ils ne montrent pas quels préfixes sont effectivement visibles à la même seconde, quelles routes un voisin accepte ni si un paquet transporte du trafic utile.

Les données imbriquées comportent onze lignes d’échange. Dix sont marquées opérationnelles et une ne l’est pas ; les onze portent un indicateur de relation avec un serveur de routes. Les noms publiés incluent notamment NetIX, CHIX-CH, LOCIX à Francfort et Düsseldorf, Poema IX, FogIXP, NL-ix, Lambda-IX, BGP.Exchange à Zurich, FREMIX et ZXIX Hong Kong.

Les vitesses déclarées se répartissent entre deux lignes à 100 Mbps, une à 250 Mbps, une à 500 Mbps, six à 1 000 Mbps et une à 10 000 Mbps. Ce sont des valeurs de répertoire. Elles ne mesurent pas le trafic présent, la marge disponible ou un engagement contractuel. De même, l’indicateur opérationnel n’est pas une surveillance continue de session, et onze lignes logiques ne démontrent pas onze fibres, bâtiments, alimentations ou réseaux amont indépendants.

RIS fournit une observation de routage délimitée

L’endpoint routing-status de RIPEstat apporte une couche différente : une vue issue du Routing Information Service, ou RIS. Sa réponse donne un query_time fixé au 7 août 2026 à 00 h 00 UTC. Dans cette vue, aucun préfixe IPv4 ne franchissait le seuil de qualification parmi les 327 pairs RIS full-feed indiqués. Pour IPv6, la réponse comptait 16 préfixes annoncés, représentant 31 blocs /48, visibles auprès des 320 pairs full-feed listés sur 320.

L’endpoint précise qu’il exclut les routes vues par moins de dix pairs RIS full-feed. Le résultat IPv4 doit donc être formulé comme une absence dans cette vue après application de ce seuil. Il ne prouve pas qu’aucune route IPv4 n’existait ailleurs, que tout service IPv4 de Level 86 était indisponible ou qu’une panne avait eu lieu.

La visibilité IPv6 exige la même discipline. Le ratio 320/320 constitue un résultat fort pour l’ensemble de collecteurs indiqué, au moment indiqué. Il ne démontre ni une joignabilité universelle, ni une autorisation de route, ni une faible latence, ni la résilience ou le bon fonctionnement d’une application. Une route visible et un service fonctionnel sont deux objets d’observation différents.

La réponse rapporte aussi 2 964 voisins observés. Cette valeur appartient au modèle du collecteur. Elle ne doit pas être renommée en 2 964 pairs directs, contrats, installations ou chemins indépendants.

Le temps de requête et le dernier passage observé restent distincts

La même réponse associe au préfixe IPv6 2401:5a0:ff03::/48 un champ de dernière observation daté du 7 août 2026 à 00 h 00 UTC, à la même heure que son query_time. Ce sont néanmoins des champs distincts. Elle mentionne aussi 41.216.185.0/24 comme préfixe vu pour la première fois avec l’origine 212483 le 13 octobre 2021 à 00 h 00 UTC.

Il faut conserver les étiquettes de ces champs au lieu de fabriquer une chronologie opérationnelle. Le temps de requête décrit le contexte de la réponse ; le dernier passage et la première observation appartiennent aux préfixes concernés. Sans documentation supplémentaire sur le traitement interne de l’endpoint, leur valeur temporelle commune ne permet pas d’affirmer qu’une route a changé, ni de déduire une continuité d’annonce.

Une vérification utile avance couche par couche

La première étape consiste à confirmer l’identité : ASN exact, organisation enregistrée et entrée de répertoire correspondante. Ensuite, les données PeeringDB peuvent servir de liste de contrôle. Le nom, la politique, l’ensemble IRR et les lignes d’échange correspondent-ils encore au périmètre étudié ? Une concordance est un point de départ ; une divergence est une question précise à résoudre.

Pour une question de routage, il faut ensuite enregistrer le collecteur, l’heure, le seuil de visibilité, la famille d’adresses et les préfixes concernés. Une décision importante gagnera à comparer plusieurs points d’observation appropriés. Pour une question de service, il faut ajouter des tests de bout en bout et une télémétrie applicative autorisée. Pour une question de capacité, il faut des mesures d’interface ou de service sur une période définie.

Cette séquence empêche de demander au mauvais document une réponse qu’il ne mesure pas. RDAP identifie la ressource sans prouver une route. PeeringDB décrit une surface d’interconnexion déclarée sans prouver une session. RIS observe des routes sans mesurer l’expérience client.

Ce que le dossier public ne permet pas de conclure

Les quatre sources permettent d’identifier Level 86 et l’AS212483, de lire une présence d’interconnexion déclarée et d’examiner une observation de routage horodatée. Elles ne décrivent pas la topologie physique complète, les modalités commerciales d’une relation ni le chemin suivi par un client donné.

Elles ne prouvent pas non plus le volume de trafic, la capacité disponible, l’isolation des pannes, l’autorisation des routes, les contrôles de sécurité, la performance, la disponibilité ou la résilience. Aucun constat de panne ne découle du champ IPv4. Aucune garantie de portée mondiale ne découle du champ IPv6. Aucun décompte de diversité physique ne découle des onze lignes d’échange.

Le constat défendable reste volontairement étroit : RIPE associe l’AS212483 à l’organisation Level 86 nommée, PeeringDB publie un profil d’interconnexion déclaré, et RIS rapporte une visibilité IPv4 et IPv6 fortement différente dans ses conditions d’observation. Tout jugement sur un résultat de service exige une preuve opérationnelle supplémentaire et assortie d’une date.

Points à surveiller

  • les changements de l’organisation, du statut administratif ou des événements de l’AS212483 dans RIPE RDAP ;
  • les modifications du nom, de la politique, de l’ensemble IRR, des nombres de préfixes ou des lignes d’échange dans PeeringDB ;
  • de nouvelles observations de routage qui conservent l’heure de requête, la famille d’adresses, le dénominateur des pairs et le seuil de faible visibilité ;
  • des données autoritatives de session ou de route confirmant ou contredisant une déclaration précise du répertoire ;
  • une télémétrie propre au service lorsque la question porte sur disponibilité, performance ou impact client.

Sources