Résumé

  • Le Bhutan Internet Exchange apparaît dans trois couches publiques indépendantes — une fiche d'échange dans PeeringDB, deux objets d'organisation dans APNIC et une ligne pays de Hurricane Electric pour AS7615 — et ces trois couches s'accordent sur le nom, la ville et le numéro de système autonome de l'échange.
  • Lu de près, le dossier décrit un unique LAN Ethernet plat nommé TTPL-LAN au Thimphu Techpark, avec une unité de transmission maximale de 1500 octets, la prise en charge 802.1Q déclarée inactive, un numéro de système autonome de serveur de routes égal à zéro, et des champs de niveau de service et de conditions qui affichent tous deux Not Disclosed.

La première chose à comprendre sur le Bhutan Internet Exchange, c'est que son identité publique est mince, et que cette minceur est structurelle plutôt qu'accidentelle. PeeringDB héberge une fiche d'échange portant l'identifiant 2355, le nom court btIX, le nom long Bhutan Internet Exchange, à Thimphou, pays BT, région Asie-Pacifique, sur support Ethernet (fiche PeeringDB de l'échange bhoutanais). Toute la géographie tient là. Pas de deuxième ville, pas de deuxième site, pas de point de secours. Pour un pays dont la connectivité internationale passe historiquement par l'Inde, un point d'échange domestique unique dans la capitale n'est pas un détail : c'est toute la couche de commutation nationale, du moins telle que ce dossier la décrit.

C'est l'objet enfant de la fiche qui contient réellement l'ingénierie. Le LAN de l'échange s'appelle TTPL-LAN. Son unité de transmission maximale est déclarée à 1500 octets. Son champ de prise en charge 802.1Q indique faux. Son numéro de système autonome de serveur de routes indique 0. Il a été créé le 22 septembre 2018 à 17:01:27 UTC, à la même minute que la fiche parente, et sa dernière mise à jour date du 30 juin 2026 à 01:34:08 UTC. Son statut est ok.

Ces cinq champs, pris ensemble, décrivent une architecture et non une intention. Une MTU de 1500, c'est de l'Ethernet ordinaire : rien ici ne suggère des trames géantes, rien ne suggère une matrice taillée pour de gros débits. L'absence de prise en charge 802.1Q signifie que le LAN est présenté, dans les termes du dossier, comme un seul domaine de diffusion plat : un opérateur qui lit cette fiche ne doit donc pas attendre une remise par VLAN comme fonction documentée.

Un numéro de système autonome de serveur de routes à zéro est la valeur la plus lourde de conséquence de tout le jeu de données, et il faut le dire simplement : le champ qui nommerait un serveur de routes exploité par l'échange ne contient aucun numéro exploitable. Quelle que soit la fonction de serveur de routes que btIX assure réellement, le dossier public ne la nomme pas comme un service numéroté.

Ce zéro change le sens même de l'adhésion. Dans un échange doté d'un serveur de routes, un membre configure une seule session BGP vers l'échange et reçoit la table collective ; l'échange devient partie technique aux décisions de routage de chaque membre, et la compétence opérationnelle de l'échange entre dans le rayon d'impact de tous. Sans serveur de routes, chaque paire de membres qui veut échanger des routes doit négocier et configurer une session bilatérale.

Le peering bilatéral coûte plus de travail par paire mais garde le contrôle à la périphérie : pas de cerveau de routage partagé, pas de processus unique dont la panne dégrade tout le monde, et pas d'opérateur d'échange tenant la plume politique sur les préfixes annoncés à qui. Le zéro dans ce champ n'est donc pas une lacune du dossier. C'est une indication sur l'endroit où se trouve le contrôle.

La correspondance avec le site confirme la topologie physique. PeeringDB rattache l'échange à un seul équipement, l'identifiant 5806, nommé Thimphu Techpark, exploité par une organisation enregistrée comme Bhutan Data Centre Services, avec un code CLLI TTPL et des coordonnées de 27,427781 nord et 89,650988 est (fiche PeeringDB de l'échange bhoutanais). L'adresse se lit Thimphu Techpark, Wangchuktaba, Thimphou, État de Thimphou, code postal 11001. L'équipement a été créé le 22 septembre 2018 à 16:43:21 UTC — vingt minutes avant la fiche de l'échange — et mis à jour pour la dernière fois le 26 septembre 2025 à 22:51:32 UTC. Son statut est ok.

Les compteurs de cet équipement offrent le contraste le plus net du jeu de données. Il déclare deux réseaux, un échange et zéro opérateur de transport. Deux réseaux dans un point d'échange national, selon la fiche de l'échange lui-même, c'est un nombre assez petit pour être retenu sans aide. C'est aussi le nombre qui rend toute question en aval sur l'effet concurrentiel facile à poser et difficile à trancher : avec deux réseaux déclarés sur le site, la valeur marginale de l'échange dépend entièrement de savoir lesquels, s'ils s'interconnecteraient autrement, et quel est le prix de l'interconnexion.

Le dossier ne répond pas du tout à la première question, pas du tout à la deuxième, et répond à la troisième par la mention Not Disclosed.

Le problème de nom, qui est en réalité un problème de détection

La pièce la plus instructive de ce jeu de données ne porte pas sur le Bhoutan. C'est l'écart entre deux requêtes adressées à la même API. Une requête filtrée sur la chaîne littérale bhutan internet exchange a renvoyé un tableau de données vide et des métadonnées vides (réponse du filtre par nom dans PeeringDB). Une requête filtrée sur le pays BT a renvoyé une fiche dont le nom long est Bhutan Internet Exchange et le nom court btIX (fiche PeeringDB de l'échange bhoutanais).

Les deux réponses sont exactes. La fiche s'appelle btIX, et son nom long est un champ distinct que le filtre par nom n'a manifestement pas interrogé dans la forme fournie. Quiconque cherchait l'échange sous son nom anglais complet — c'est-à-dire un chercheur, un journaliste ou un opérateur étranger — a reçu une réponse négative propre. Quiconque cherchait par pays l'a trouvé immédiatement.

En termes de risque, cela compte plus qu'il n'y paraît. La valeur d'un registre pour le public réside dans sa fonction de détection : c'est ainsi qu'un tiers établit qu'un échange existe, qui s'y trouve et à quoi il sert. Quand une recherche par nom échoue sur une fiche qui existe, le registre ne souffre pas d'une simple bizarrerie d'indexation : il a produit un faux négatif pour exactement le public qui en dépend. Le mode de défaillance est asymétrique. Un acteur de la communauté réseau bhoutanaise connaît le nom court local, parce que c'est ainsi qu'on appelle la chose. Un acteur extérieur, non.

Le registre fonctionne donc pour les initiés et échoue pour les autres, ce qui est l'inverse de la mission d'un registre de divulgation.

La fiche du LAN contient un signal voisin. Son champ de visibilité de l'URL de la liste des membres au format IX-F indique Private, tandis que son champ d'import IX-F indique true. IX-F est le format d'échange normalisé par lequel les points d'échange publient des listes de membres lisibles par machine, afin que d'autres registres et outils puissent les reprendre. Une visibilité privée sur l'URL de la liste, avec l'import actif, décrit un échange disposé à ingérer le format d'échange mais ayant choisi de ne pas publier sa propre liste par ce canal.

La liste des membres n'est pas seulement non publiée : elle est marquée comme délibérément retenue.

Cette distinction mérite d'être conservée, car elle sépare deux explications très différentes d'un dossier public mince. La première est la négligence : personne ne s'en est occupé. La seconde est une politique : l'exploitant a décidé que la liste n'était pas publique. La première est un problème de maintenance, avec un remède évident et aucune justification défendable. La seconde est un choix de gouvernance, et un choix de gouvernance peut être interrogé. Une visibilité privée est un réglage que quelqu'un a sélectionné.

Cela signifie que l'échange, ou celui qui tient sa fiche, a pris position sur la publication de la liste de ses membres, et que cette position est : pas par ce canal.

La conséquence pratique est directe. Un tiers qui veut savoir quels réseaux sont présents à btIX n'a plus qu'une voie au niveau du registre : lire les fiches de participants de chaque réseau dans PeeringDB, ou passer par les données de routage. Les deux voies sont plus faibles qu'une liste de membres, parce qu'elles décrivent ce que les réseaux disent d'eux-mêmes plutôt que ce que l'échange confirme de sa propre composition.

Ce que la couche registre confirme, et ce qu'elle ne peut pas confirmer

PeeringDB n'est pas un régulateur et ne prétend pas l'être. Ses fiches sont alimentées par la foule et modifiables par les opérateurs, ce qui les rend précieuses pour la cartographie et insuffisantes pour la vérification. Un statut ok signifie que la fiche est intacte, non que le site est sous tension ou que le LAN fait passer des trames. Un échange peut être référencé, à jour et en statut ok tout en portant un trafic que personne hors de Thimphou n'a jamais mesuré.

C'est pourquoi la couche APNIC compte. Le dossier de registre n'est pas auto-déclaré de la même manière ; c'est un objet d'allocation formel, avec un mainteneur et une piste d'audit. Le service Whois d'APNIC renvoie deux objets d'organisation au nom Bhutan Internet Exchange (requête Whois APNIC sur l'échange). Le premier, ORG-BIE1-AP, porte le pays BT et une adresse libellée Bhutan Internet Exchange, Thimphu Techpark, Post Box 633, Wanghcuktaba, Babesa. Le second, ORG-BIE2-AP, est typé Local Internet Registry, porte l'adresse Thimphu Techpark, Wangchuktaba, Post Box 633, est maintenu par APNIC-HM, référence ce même mainteneur, et porte une date de dernière modification au 5 septembre 2023 à 02:17:38 UTC avec la source APNIC.

Deux objets d'organisation pour un seul échange n'ont rien d'inhabituel : les objets de registre s'accumulent à mesure des demandes d'adresses et des changements de contacts, et l'objet le plus ancien reste souvent en place. Ce qui importe pour la responsabilité, c'est de savoir quel objet fait autorité et ce que signifie son typage. Le type LIR est le champ déterminant. Un registre internet local est une organisation qui reçoit de l'espace d'adressage du registre régional et le sous-alloue à ses propres clients.

Un échange typé LIR n'est donc pas seulement un commutateur dans un bâtiment : c'est un point de distribution de ressources de numérotation, avec les obligations qui en découlent — tenue de registres, objets de contact, maintenance des affectations.

Le champ du mainteneur précise cela. Les deux objets sont maintenus par APNIC-HM, qui est le mainteneur interne du registre régional pour les objets de niveau supérieur. Un échange qui détient des objets de registre sous le mainteneur maison du registre est arrimé à la structure administrative de celui-ci plutôt que d'agir comme un membre de registre pleinement indépendant. C'est un arrangement courant pour les petites organisations et ce n'est pas une critique.

Cela signifie que la trace documentaire des ressources de numérotation de l'échange s'arrête dans l'administration d'APNIC elle-même, exactement là où un enquêteur s'attendrait à la trouver et exactement là où un tiers ne peut pas regarder plus loin.

La date de dernière modification du second objet est le 5 septembre 2023. Les objets sont modifiés quand quelque chose change ; une date figée atteste d'une stabilité administrative plutôt que d'une activité opérationnelle. Lue aux côtés des horodatages de PeeringDB, une configuration apparaît, et elle mérite d'être nommée. La fiche parente de l'échange a été mise à jour pour la dernière fois le 22 janvier 2020. L'objet APNIC a été modifié pour la dernière fois en septembre 2023. La fiche du LAN a été mise à jour le 30 juin 2026, et celle du site le 26 septembre 2025.

Quatre objets, quatre millésimes, et le plus récent est l'objet technique enfant plutôt que le parent politique. Celui qui tient ce dossier met à jour le LAN et le site tout en laissant la description de l'échange — la couche qui porterait les conditions, les niveaux de service et les contacts de politique — figée depuis les premières semaines de 2020. C'est un schéma de maintenance, et les schémas sont des indices. Il dit que la cartographie technique est vivante et que la description commerciale ne l'est pas.

Quatre nombres, et la discipline de ne pas les surinterpréter

Les données de routage ajoutent une troisième couche, venue d'une direction entièrement différente. La boîte à outils BGP de Hurricane Electric publie une table par pays pour le Bhoutan. On y lit une ligne libellée exactement : AS7615 Bhutan Internet Exchange 2 3 2 3 (vue pays de Hurricane Electric pour le Bhoutan). L'en-tête de colonne au-dessus de cette ligne énumère, dans l'ordre, l'ASN, le nom, les adjacences IPv4, les routes IPv4, les adjacences IPv6 et les routes IPv6.

La ligne établit ce que les deux autres couches n'établissent pas : que l'échange détient son propre numéro de système autonome, AS7615, et que ce numéro est visible dans une agrégation mondiale de données de routage. L'échange n'est pas seulement une entrée de registre et un locataire de site ; c'est une entité adressable du système de routage, avec son propre numéro de système autonome porté dans une table que consultent les ingénieurs réseau.

Les quatre chiffres sont le point où la discipline s'impose. Deux, trois, deux, trois. Il est tentant de traduire cette ligne en une phrase du type « l'échange a deux pairs et trois routes », et cette phrase serait fausse d'une manière qui compte. L'extrait conserve l'en-tête et la ligne mais ne rattache pas chaque valeur à une colonne de façon non ambiguë, et une ligne de quatre valeurs extraite d'un tableau large peut perdre son alignement.

La lecture honnête est que la ligne porte quatre petites valeurs en face de colonnes nommant des adjacences et des comptages de routes, et que ces quatre valeurs sont à un chiffre.

Ce que l'on peut affirmer sans excès, c'est qu'un nombre d'adjacences à un chiffre pour le système autonome d'un échange national est petit. Un serveur de routes ou un grand point d'échange affiche typiquement des comptages en dizaines ou en centaines. Un comptage de cet ordre est cohérent avec un petit nombre de réseaux membres, ce qui est cohérent avec les deux réseaux de la fiche du site, ce qui est cohérent avec l'idée que deux réseaux constituent toute l'histoire de l'interconnexion nationale selon ces dossiers.

Trois couches indépendantes produisent de petits nombres qui pointent dans la même direction ; chacune est faible seule, mais leur accord informe.

Ce que l'on ne peut pas affirmer, c'est la présence ou l'absence de tel réseau bhoutanais. L'existence d'une ligne pour AS7615 ne dit rien des autres systèmes autonomes avec lesquels elle échange des routes, et la table pays n'énumère pas les appariements. Affirmer que l'opérateur historique est présent à btIX, ou qu'un opérateur mobile ne l'est pas, exigerait une liste de membres ou des données de sessions, et ni l'une ni les autres ne sont en main.

Le champ des conditions est le champ de la responsabilité

De tous les champs de la fiche d'échange, les deux qui affichent Not Disclosed sont ceux qu'un conseil d'administration devrait remarquer. Niveau de service et conditions. Tous deux vides au sens de la divulgation.

Les conditions commerciales d'un échange déterminent qui peut se connecter et sur quelle base. Un forfait annuel par port, une facturation au mégabit, un modèle sans règlement financier, une structure par paliers selon la vitesse de port — chacun produit un marché différent. Un échange sans règlement financier ramène le coût marginal de l'interconnexion nationale au prix d'un raccordement physique, ce qui favorise les nouveaux entrants et les petits réseaux. Un échange payant le relève, ce qui favorise celui qui a déjà du volume et peut absorber le droit.

Le choix entre ces modèles est une décision de gouvernance aux conséquences distributives, et elle est invisible dans un dossier qui affiche Not Disclosed.

Pour un acheteur, les conséquences sont pratiques. Un réseau qui envisage un port ne peut pas modéliser le coût du peering national à partir du dossier public, puisque le prix n'y est pas. Il ne peut pas comparer btIX au transport de ce trafic à l'international, puisque la comparaison exige un chiffre. Il ne peut pas juger si le niveau de service de l'échange est adapté au trafic qu'il déplacerait, puisque le niveau de service n'y est pas non plus.

Il en résulte que la décision d'adhérer se prend sur la base de relations et de conversations plutôt que de conditions publiées — ce qui est normal dans les petits marchés et constitue aussi exactement la condition dans laquelle les initiés ont l'avantage.

Le réglage de visibilité IX-F se rattache directement à cela. Un membre potentiel qui cherche à savoir si l'adhésion en vaut la peine voudrait savoir qui est déjà là. L'échange a marqué cette liste privée. La combinaison — liste de membres privée et conditions non divulguées — signifie qu'un tiers évaluant btIX peut confirmer que l'échange existe et à peu près où, et ne peut confirmer ni avec qui il s'apparierait ni ce que cela coûterait. C'est une posture de divulgation précise et descriptible, et cette posture est conservatrice.

Il existe une raison défendable. Les listes de membres et les prix peuvent être commercialement sensibles dans un marché à deux ou trois acteurs, parce que leur publication révèle les volumes relatifs et les positions de négociation. Un échange qui publie sa liste de membres dans un marché à deux réseaux publie la situation concurrentielle de ses membres. Un petit exploitant peut raisonnablement conclure que la discrétion sert mieux ses membres que la transparence ne sert le public. Cet argument est cohérent.

C'est aussi un choix qui échange de la responsabilité externe contre de la souplesse interne, et il faut le décrire comme tel plutôt que comme un accident.

Le bit multicast, et pourquoi les petits champs portent de grandes conséquences

La fiche active l'unicast et l'IPv6 et désactive le multicast. De ces réglages, celui de l'IPv6 est celui qui comptera le plus avec le temps, et celui du multicast est celui qui révèle le plus l'intention.

La prise en charge d'IPv6 activée signifie que la fiche affirme que l'échange peut transporter du trafic IPv6. Pour un pays comptant peu de réseaux, un échange qui transporte IPv6 est le chemin le moins coûteux vers l'interconnexion nationale en IPv6 : sans lui, deux réseaux bhoutanais qui veulent tous deux de l'IPv6 doivent soit tunnelliser, soit router nationalement via un fournisseur de transit international, soit ne pas s'interconnecter du tout. Un échange dont la fiche active IPv6 réduit le coût de ce chemin au prix d'un port.

Le multicast désactivé est une affirmation plus précise. Le multicast dans un échange est le moyen par lequel les réseaux de diffusion de contenu et les opérateurs de télévision sur internet livrent un flux unique à de nombreux réseaux d'accès sans le répliquer par membre. Le désactiver signifie que la fiche ne revendique pas cette capacité. Pour un marché où la distribution vidéo compte — et dans tous les marchés elle compte — l'absence de multicast limite les usages possibles de l'échange. Elle pousse ce trafic vers l'unicast, et l'unicast le renvoie vers le chemin international ou vers l'interconnexion privée.

C'est ici que le dossier cesse d'être une entrée d'annuaire et devient la description d'un goulot d'étranglement. Un échange national qui transporte de l'IPv4 et de l'IPv6 en unicast, sur un seul LAN plat, à 1500 octets, sans serveur de routes nommé et sans multicast, est un point d'interconnexion fonctionnel pour le trafic général. Ce n'est pas une matrice de distribution. Cette distinction détermine lequel des problèmes de trafic d'un pays l'échange peut résoudre et lequel il ne peut pas, et elle est entièrement visible dans des champs que quelqu'un a choisis.

Qui rend des comptes, et sur quoi

Ici, le dossier public s'arrête, et il s'arrête d'une manière assez précise pour être décrite plutôt que simplement déplorée. Sur les quatre dossiers examinés pour cet article, aucun n'identifie la forme juridique de l'échange, ses propriétaires, son organe de gouvernance, ses règles d'adhésion ni la procédure de règlement d'un litige d'admission (requête Whois APNIC sur l'échange).

C'est une affirmation bornée, et ses bornes doivent être énoncées : quatre dossiers publics, interrogés un seul jour, ne contiennent pas ces champs. Une couverture antérieure de cet échange dans le répertoire de BTW a relevé une date de fondation, un lancement annoncé, une instance de serveur racine hébergée et une liste de participants avec des numéros de systèmes autonomes (entrée de répertoire BTW de l'échange bhoutanais). Ces faits ne sont pas repris ici et ne sont contredits par rien dans ces quatre dossiers ; ils se situent à un niveau que cet article n'a pas interrogé.

Ce que cet article a interrogé, c'est la couche qu'un tiers atteint sans relation préalable : l'inscription au registre, l'objet d'enregistrement d'adresses et la table de routage. Dans cette couche, l'échange est lisible comme institution sous exactement deux aspects — il détient un numéro de système autonome et il détient un objet de registre internet local. Les deux sont réels. Les deux ont des conséquences administratives. Aucun ne dit qui décide.

Aux fins du contrôle, c'est là le constat. Le dossier public décrit la plomberie d'un échange avec un luxe inhabituel de détails mécaniques — nom du LAN, MTU, marquage, champ du serveur de routes, coordonnées du site, horodatages de création et de mise à jour à la seconde — et ne décrit pas du tout sa gouvernance. Un régulateur qui demanderait si le point d'interconnexion nationale agit dans l'intérêt public devrait s'adresser à l'exploitant. Un réseau qui se demande s'il doit adhérer devrait s'adresser à l'exploitant.

Un chercheur qui demande si le trafic national reste national devrait s'adresser à l'exploitant. Dans chaque cas, le registre confirme l'existence de la chose sur laquelle porte la question et ne fournit aucune des réponses.

Il y a ici une question de conception qui mérite d'être nommée pour quiconque administre un régime de divulgation. Les champs remplis sont ceux dont un ingénieur réseau a besoin pour configurer une session : le nom du LAN, la MTU, le fonctionnement du marquage, la présence d'un serveur de routes. Les champs non remplis sont ceux dont un tiers a besoin pour tenir l'institution responsable : conditions, niveau de service, liste des membres, identité juridique. Les registres se peuplent avec les gens qui exploitent l'infrastructure, et les exploitants peuplent ce dont ils ont besoin.

Les champs de responsabilité arrivent en dernier, quand ils arrivent.

Ce qui changerait ce classement

Un classement n'est utile que s'il peut être mis à jour, et celui-ci le peut, par des changements précis et observables.

Si la fiche du LAN se mettait à nommer un numéro de système autonome de serveur de routes autre que zéro, ce serait un changement structurel de l'architecture de l'échange, et non cosmétique. Cela signifierait qu'une fonction de routage exploitée par l'échange existe, et cela déplacerait une part significative du contrôle de la politique de routage des paires bilatérales vers l'échange lui-même.

Si le champ de visibilité de la liste des membres IX-F passait de Private à Public, la question des participants deviendrait répondable à partir de données lisibles par machine plutôt que par inférence. Ce seul changement convertirait la partie la plus faible de la base probatoire de cet article en la plus solide, et il ne coûterait à l'exploitant qu'une décision de divulgation.

Si les champs de niveau de service et de conditions cessaient d'afficher Not Disclosed, un acheteur pourrait modéliser le coût et un régulateur pourrait évaluer si la structure tarifaire favorise les acteurs en place. Si l'horodatage de mise à jour de la fiche parente de l'échange se déplaçait au-delà de janvier 2020 — ce n'est pas le cas dans la fiche saisie ici — la description commerciale apparaîtrait comme maintenue plutôt qu'abandonnée.

Si un dépôt réglementaire national décrivait la propriété de l'échange, ses règles d'admission ou sa procédure de règlement des litiges, la couche de gouvernance existerait dans un document citable plutôt que dans l'écart entre deux champs de registre. D'ici là, le résumé honnête est celui que les champs eux-mêmes soutiennent : btIX est un échange réel, enregistré et adressable à Thimphou, sur un seul LAN Ethernet plat, sans serveur de routes nommé, sans conditions publiées et sans liste de membres publique. La plomberie est documentée à la seconde.

La responsabilité n'est documentée nulle part, et cette asymétrie est l'histoire.