Résumé

  • Le dossier RDAP d’APNIC couvre exactement l’AS136022 et associe l’objet administratif au nom Janani Technology. Son statut active renseigne le registre ; il ne mesure ni une route, ni une session BGP, ni un service.
  • La réponse PeeringDB contient une fiche pour l’ASN, mais aucune ligne netixlan et plusieurs champs vides. Ces absences décrivent ce que le participant n’a pas publié dans cette réponse, pas ce qui n’existe pas dans le réseau.
  • La photographie RIS datée du 7 août 2026 à 00 h 00 UTC rapporte une forte visibilité auprès des pairs listés, avec un seuil d’exclusion explicite. Elle ne prouve ni joignabilité universelle, ni autorisation des routes, ni capacité, résilience ou qualité de service.

Un numéro stable pour ne pas confondre les objets

Un système autonome est un réseau, ou un ensemble de réseaux, qui présente une politique de routage commune vers le reste d’internet. Son numéro de système autonome, l’ASN, sert d’identifiant unique lorsque les réseaux échangent des informations de joignabilité au moyen du protocole BGP, le Border Gateway Protocol.

L’AS136022 relie les trois couches publiques examinées ici. Il évite de dépendre seulement d’un nom commercial, qui peut être proche d’un autre nom ou couvrir plusieurs activités techniques. Cette précision est utile lorsqu’il faut attribuer une question de routage, comparer une configuration attendue à un dossier public ou choisir le bon contact administratif.

Le numéro ne remplace toutefois aucune mesure. Il ne révèle pas par lui-même si un préfixe est annoncé, si un voisin accepte la route ou si une application répond. Il constitue un point de jonction entre des preuves qui conservent chacune leur méthode, leur horloge et leur portée.

APNIC tient le registre administratif

RDAP, pour Registration Data Access Protocol, fournit une représentation structurée des informations publiques détenues par un registre de numéros internet. La réponse d’APNIC commence et se termine au numéro 136022 : elle porte donc exactement sur un seul ASN. Son handle est AS136022, le nom d’objet est JANANITECHNOLOGY-AS-AP et Janani Technology figure parmi les noms d’entités publiés.

Le dossier porte le statut active. Il mentionne un événement d’enregistrement le 3 février 2019 à 08 h 31 min 56 s UTC, puis un dernier changement le 18 janvier 2021 à 03 h 52 min 25 s UTC. Ces éléments rendent l’objet administratif identifiable et son historique vérifiable.

Ils ne constituent pas une télémétrie du réseau. Le mot active qualifie le dossier dans le registre. Il ne dit pas qu’un routeur est alimenté, qu’une route est reçue, qu’une interconnexion fonctionne ou qu’un service client est disponible. Les dates décrivent des événements du dossier, pas nécessairement le déploiement d’un équipement ou une modification de BGP.

Cette limite est précisément ce qui permet de bien utiliser le registre. Un grand livre fiable maintient l’unicité du numéro, son association administrative et un historique public. Une question portant sur le système en fonctionnement exige ensuite une source conçue pour observer ce système.

Le profil PeeringDB dit surtout ce qui n’est pas déclaré

PeeringDB est un répertoire de coordination alimenté par les participants du secteur de l’interconnexion. La réponse figée comprend une seule fiche pour l’ASN 136022, identifiée par le numéro de dossier 40097 et nommée Janani Technology. La fiche porte le statut ok et une date de mise à jour au 4 avril 2026 à 16 h 50 min 22 s UTC.

Son contenu est réduit. Aucune ligne netixlan, c’est-à-dire aucune déclaration de connexion à un LAN d’échange dans cette réponse, n’est présente. Les champs consacrés au site web, au type de réseau, à la politique générale de peering, à l’ensemble IRR et aux nombres de préfixes IPv4 et IPv6 sont vides ou nuls.

Il serait tentant de lire ces vides comme une description négative du réseau. Ce serait une erreur de méthode. Une ligne d’échange absente signifie seulement qu’aucune telle déclaration n’apparaît dans cette fiche capturée. Elle ne démontre ni l’absence d’interconnexion privée, ni l’absence de peering bilatéral, ni l’absence de présence dans un échange. De la même façon, un champ de politique vide ne permet pas de choisir entre une politique ouverte, sélective ou restrictive.

Le statut ok doit lui aussi rester attaché à la fiche. Il ne surveille pas en continu les sessions BGP et ne constitue pas un test de santé des équipements. PeeringDB peut donner des coordonnées et des déclarations utiles ; les informations non renseignées deviennent des questions à poser, pas des réponses à inventer.

La photographie RIS ajoute une observation, pas un verdict

Le Routing Information Service de RIPE, ou RIS, recueille des informations BGP auprès de points d’observation participants. La réponse routing-status conservée pour ce dossier possède un query_time fixé au 7 août 2026 à 00 h 00 UTC. Les chiffres suivants décrivent uniquement cette photographie datée.

Pour IPv4, des routes admissibles concernant la ressource 136022 apparaissaient auprès de 326 pairs full-feed RIS sur les 327 listés, soit 326/327. Pour IPv6, le rapport était de 320/320. Les champs d’espace annoncé comptaient un préfixe IPv4 représentant 256 adresses, ainsi que deux préfixes IPv6 représentant deux blocs /48.

La réponse indiquait également un voisin observé. Cette valeur vient du modèle du produit de collecte. Elle ne peut pas être renommée en un pair direct, un contrat, une session d’échange, un site physique ou un chemin indépendant. Un collecteur ne voit qu’une partie des relations possibles, et une relation visible dans le routage ne décrit pas automatiquement sa nature commerciale ou physique.

L’endpoint précise qu’il exclut les routes vues par moins de dix pairs RIS full-feed. Les ratios de visibilité s’appliquent donc aux routes qui franchissent ce seuil dans l’ensemble de pairs indiqué. Le résultat ne couvre pas toutes les observations possibles et n’évalue pas ce qui se passe derrière un préfixe.

Une visibilité élevée auprès de cet ensemble de collecteurs reste une information de routage utile. Elle n’est pas une garantie de joignabilité universelle, d’autorisation d’origine, de préférence de chemin, de faible latence, de capacité disponible ou de continuité applicative. Une route peut être visible tandis qu’un service échoue pour une raison que BGP ne mesure pas.

Les champs temporels ne forment pas une chronologie unique

La réponse contient plusieurs dates qu’il faut conserver sous leur propre étiquette. Le temps de requête est le 7 août 2026 à 00 h 00 UTC. Le champ de dernière observation désigne le préfixe 103.134.41.0/24, avec l’origine 136022, à la même heure. Un autre champ nomme 103.134.42.0/24 comme préfixe vu pour la première fois avec cette origine le 13 février 2019 à 16 h 00 UTC.

La coïncidence entre le temps de requête et celui du champ de dernière observation ne fusionne pas leur signification. Le premier décrit le contexte de la réponse ; le second appartient à un préfixe choisi par l’endpoint. Le champ de première observation concerne encore un autre préfixe et ne démontre ni propriété, ni autorisation, ni annonce continue depuis 2019.

Sans une série historique adaptée, il serait injustifié d’en déduire l’heure d’un changement de route ou la durée d’une annonce. La discipline consiste à rapporter chaque champ tel qu’il a été fourni, puis à chercher une source supplémentaire si la continuité devient la question centrale.

Une méthode de vérification proportionnée

La première étape est l’identité : confirmer l’AS136022 et vérifier que le dossier APNIC et l’entrée Janani Technology désignent bien le même objet. On réduit ainsi le risque d’attribuer un événement à une société ou à un réseau portant un nom similaire.

La deuxième étape consiste à lire le registre comme un registre. Le numéro exact, le nom d’objet, l’entité associée et les événements administratifs répondent à une question de coordination. Ils ne remplacent pas l’observation des routes.

La fiche PeeringDB sert ensuite de liste de déclarations. Dans ce cas, ses champs vides signalent les points qu’un opérateur autorisé ou un partenaire potentiel devrait faire préciser : politique, coordonnées techniques, préfixes déclarés et interconnexions. Aucun vide ne doit être rempli par une supposition publique.

Pour une question de routage, il faut noter le collecteur, l’heure, la famille d’adresses, le dénominateur des pairs, le seuil et les préfixes. Une décision sensible peut demander d’autres points d’observation. Une question d’autorisation nécessite les objets d’origine appropriés. Une question de service nécessite un test de bout en bout et des éléments applicatifs datés.

L’enregistrement APNIC, la fiche PeeringDB et la photographie figée de RIPE RIS sont donc des couches distinctes. Aucun de ces éléments ne prouve à lui seul une session de peering active, une joignabilité universelle, l’autorisation des routes, la capacité, la résilience ou le service rendu au client.

Ce que les sources ne permettent pas d’affirmer

Le dossier permet de décrire l’identité de l’ASN, le contenu d’une fiche de coordination peu renseignée et une observation de routage délimitée. Il ne permet pas de décrire les services de Janani Technology, sa géographie d’exploitation, ses clients, ses installations, ses équipements, ses fournisseurs amont ou sa position commerciale.

Il ne démontre pas non plus une présence dans un échange, une relation avec un serveur de routes, l’état d’une session, un volume de trafic, un débit, une latence, une diversité physique, une disponibilité ou un résultat client. L’absence de déclaration dans PeeringDB n’est pas une panne. Un ratio RIS n’est pas un test applicatif. Un nombre de préfixes n’est pas une mesure de capacité.

La conclusion défendable reste volontairement étroite : APNIC associe l’AS136022 à Janani Technology dans son dossier administratif ; la fiche PeeringDB capturée contient peu de déclarations ; et la réponse RIS figée rapporte des routes admissibles auprès de son ensemble de pairs, à une heure et selon un seuil précis.

Points à surveiller

  • une modification du nom d’objet, de l’entité, du statut administratif ou de l’historique de l’AS136022 chez APNIC ;
  • l’ajout de coordonnées, d’une politique, de nombres de préfixes ou de lignes d’échange dans la fiche PeeringDB ;
  • d’autres observations de routage qui publient clairement leur heure, leurs dénominateurs et leur seuil ;
  • des données d’origine de route lorsqu’une question d’autorisation se pose ;
  • une télémétrie de session ou des tests de service autorisés lorsque la question devient opérationnelle.

Sources