Zusammenfassung

  • Der Bhutan Internet Exchange (btIX) ist in PeeringDB als Eintrag 2355 mit einem einzigen Ethernet-LAN namens TTPL-LAN verzeichnet: MTU 1500, kein 802.1Q, Routerserver-ASN 0, IX-F-Mitgliederliste auf „Private“, während der IX-F-Import aktiviert ist.
  • Zwei APNIC-Organisationsobjekte tragen denselben Namen, eines davon als Local Internet Registry; beide werden von APNIC-HM verwaltet. Wer den Exchange rechtlich trägt, steht in keinem der vier geprüften Register.

Ein Internet Exchange ist ein technisch unspektakuläres Objekt: ein Switch, ein Adressbereich, ein paar Ports. Spannend wird er erst, wenn man fragt, wer ihn beschreibt. Denn die Beschreibung ist das, was ein potenzieller Teilnehmer, ein Regulierer oder ein Forscher tatsächlich zu sehen bekommt – und beim Bhutan Internet Exchange besteht diese Beschreibung aus einer Handvoll Felder, die sorgfältig gefüllt sind und an wenigen Stellen auffällig leer bleiben.

Der folgende Text ist keine Bestandsaufnahme des Fehlenden. Er liest die vorhandenen Felder so, wie ein Prüfer sie lesen würde: als Aussagen über Kontrolle, Verantwortlichkeit und Nachprüfbarkeit.

Ein Eintrag, zwei Namen, zwei Uhren

PeeringDB führt den Exchange unter der Kennung 2355. Der Kurzname lautet btIX, der Langname Bhutan Internet Exchange, der Ort ist Thimphu in Bhutan, die Region Asia Pacific, das Medium Ethernet. Unicast ist aktiviert, IPv6 ebenfalls, Multicast nicht. Der Status steht auf „ok“. Angelegt wurde der Eintrag am 22. September 2018 um 17:01:27 UTC; die letzte Änderung am Stammeintrag datiert vom 22. Januar 2020, 04:24:07 UTC (PeeringDB-IX-API, Länderfilter BT).

Auffällig ist nicht das Datum, sondern der Abstand zum Untereintrag. Das zum Exchange gehörende LAN trägt ein eigenes Änderungsdatum: den 30. Juni 2026, 01:34:08 UTC. Zwischen der letzten Änderung am Exchange-Stammsatz und der letzten Änderung an seiner LAN-Beschreibung liegen mehr als sechs Jahre. Das ist kein Skandal, aber es ist eine Struktur. Zwei Sätze, die dasselbe Objekt beschreiben, werden offenbar zu sehr unterschiedlichen Zeiten gepflegt – und wer den Eintrag liest, liest eine Momentaufnahme aus zwei Epochen.

Wer wissen will, ob ein Register aktuell ist, schaut üblicherweise auf das Änderungsdatum. Hier zeigt dieses Datum nicht auf den Betrieb, sondern auf die Verwaltung des Eintrags. Ein Stammsatz von 2020 bedeutet nicht, dass seit 2020 nichts passiert ist; er bedeutet, dass sich an den beschreibenden Feldern dieses Satzes seit 2020 nichts geändert hat.

Was ein einzelnes LAN verrät

Das LAN heißt TTPL-LAN. Der Name ist keine Marketingentscheidung, sondern eine Ortsangabe: TTPL ist der Standortcode, den PeeringDB auch dem Rechenzentrum Thimphu Techpark zuordnet. Der Exchange ist damit über seinen Namen an ein Gebäude gebunden, nicht nur über eine Adresse.

Technisch beschreibt der Eintrag eine flache Struktur: MTU 1500, kein 802.1Q-Support, Routerserver-ASN 0. Ein einzelnes LAN ohne VLAN-Tagging deutet auf eine einfache Vermittlungsdomäne – ein Fabrics, in dem alle Teilnehmer dieselbe Broadcast-Domäne teilen. Das ist für einen kleinen Exchange mit wenigen Teilnehmern eine völlig normale Architektur; es ist zugleich eine Architektur, die sich in einem Feld wie diesem nicht skalieren lässt, ohne dass jemand den Eintrag ändern müsste. Wer den Eintrag liest, sieht also nicht nur den heutigen Zustand, sondern eine Aussage, die bei jeder Erweiterung sichtbar nachgeführt werden müsste.

Die Null im Routerserver-Feld ist der interessanteste Wert des ganzen Datensatzes, gerade weil sie so harmlos aussieht. Ein Routerserver-ASN von 0 kann bedeuten, dass der Exchange keinen Routerserver betreibt. Er kann genauso gut bedeuten, dass das Feld nicht ausgefüllt wurde. Aus dem Register allein lässt sich das nicht entscheiden, und keine der anderen geprüften Quellen löst die Frage auf. Wer die Zahl als Betriebsfaktum zitiert, behauptet mehr, als der Datensatz hergibt.

Die stille Seite der Sichtbarkeit

Der aufschlussreichste Satz im ganzen Eintrag ist kein technischer. Er steht im LAN-Datensatz und lautet sinngemäß: Die Sichtbarkeit der IX-F-Mitgliederliste steht auf „Private“. Im selben Datensatz ist der IX-F-Import aktiviert.

Das ist eine Asymmetrie, und sie ist der Kern dieses Artikels. IX-F steht für einen Austausch von Metadaten zwischen Exchanges und PeeringDB: Ein Exchange kann Teilnehmerdaten importieren, und er kann seine Mitgliederliste veröffentlichen. Beim btIX ist beides nicht symmetrisch geschaltet. Der Import ist an, die Veröffentlichung nicht. Der Exchange nimmt also an dem gemeinsamen Metadatenraum teil, ohne in gleicher Weise zu ihm beizutragen.

Man kann das als Datenschutzentscheidung lesen. Mitgliederlisten enthalten mitunter Informationen, die Teilnehmer nicht öffentlich sehen wollen, und es ist legitim, sie nicht zu veröffentlichen. Man kann es aber auch als Kontrollentscheidung lesen: Wer Mitglieder hat, weiß, wer Mitglied ist. Wer nicht Mitglied ist, erfährt es nicht – jedenfalls nicht hier.

Für die Frage, die diesen Text antreibt, ist der Unterschied entscheidend. Ein Exchange, der seine Mitgliederliste veröffentlicht, liefert Dritten eine prüfbare Aussage. Ein Exchange, der dies nicht tut, liefert eine Aussage über seine Präferenz. Beides ist legitim; nur das eine ist überprüfbar.

Zwei Organisationen, ein Name

Die zweite Spur führt in ein Register, das nicht von Betreibern gepflegt wird, sondern von der Regionalstelle: das APNIC-Whois. Eine Abfrage nach dem Namen Bhutan Internet Exchange liefert dort zwei Organisationsobjekte – ORG-BIE1-AP und ORG-BIE2-AP. Beide sind an dieselbe Adresse in Thimphu gerichtet, beide tragen denselben Organisationsnamen. Das zweite Objekt ist zusätzlich als Local Internet Registry typisiert und trägt einen Zeitstempel vom 5. September 2023 (APNIC-Whois-Abfrage).

Zwei Objekte für einen Namen sind im RIR-Betrieb nichts Ungewöhnliches; sie entstehen bei Umstrukturierungen, bei Änderungen der Rolle oder bei Objekten, die nie zusammengeführt wurden. Interessant ist, was sie über die Selbstdarstellung aussagen. Eine Local Internet Registry ist mehr als ein Exchange: Sie ist eine Instanz, die Adressraum an ihre Mitglieder vergibt. Wer als LIR registriert ist, beansprucht eine institutionelle Rolle, nicht nur eine technische Funktion.

Bemerkenswert ist auch, wer diese Objekte pflegt. Beide werden von APNIC-HM verwaltet, also vom Hostmaster der Regionalstelle selbst. Das ist der Normalfall, wenn ein Objekt keinen eigenen Pflegekontakt hinterlegt hat. Es bedeutet aber auch: Die Registrierungsdaten dieser Organisation werden nicht von der Organisation selbst aktualisiert, sondern von der Stelle, die sie registriert hat. Ein Änderungswunsch muss über einen Dritten laufen.

Für einen Prüfer ist das eine relevante Information. Wenn ein Name zwei Objekte hat und beide vom Hostmaster gehalten werden, dann ist die Frage „Wer ist hier eigentlich der Betreiber?“ nicht durch einen Blick ins Register zu beantworten. Sie ist durch einen Blick ins Register zu stellen.

Die vier Ziffern von Hurricane Electric

Die dritte Spur ist die kürzeste. Die Ländertabelle von Hurricane Electric für Bhutan enthält eine Zeile: „AS7615 Bhutan Internet Exchange 2 3 2 3“, eingeordnet unter Spaltenüberschriften, die Adjazenz- und Routenzahlen benennen (Hurricane Electric BGP Toolkit, Länderübersicht BT).

Vier einstellige Zahlen. Es wäre ein Leichtes, daraus „zwei Peers, drei Routen“ zu machen, und genau das sollte man nicht tun. Die Überschriften benennen mehrere Kategorien – v4-Adjazenzen, v4-Routen, v6-Adjazenzen, v6-Routen –, und der Auszug bindet die vier Werte nicht eindeutig an die einzelnen Spalten. Wer sie zuordnet, produziert eine Präzision, die die Quelle nicht liefert.

Was die Zeile dennoch belegt, ist die Existenz des eigenen Autonomous System Number AS7615 für den Exchange und seine Sichtbarkeit in einem Routing-Datenaggregator. Das ist eine kleine, aber belastbare Aussage: Der Exchange ist nicht nur ein Verzeichniseintrag, er hat eine Routing-Identität.

Der leere Treffer

Die vierte Spur ist die lehrreichste, weil sie fast in die Irre führt. Eine PeeringDB-Abfrage mit dem Namensfilter „bhutan internet exchange“ liefert ein leeres Ergebnis: keine Daten, keine Metadaten (PeeringDB-IX-API, Namensfilter). Eine Abfrage mit dem Länderfilter BT liefert denselben Exchange unter seinem Langnamen.

Daraus folgt keine Aussage über den Exchange. Daraus folgt eine Aussage über Suchfilter. Wer aus einem leeren Treffer schließt, ein Objekt sei nicht verzeichnet, verwechselt die Abwesenheit eines Treffers mit der Abwesenheit des Objekts. Der Fehler ist bei Verzeichnisdaten besonders verführerisch, weil das Ergebnis so eindeutig aussieht: eine leere Liste.

Für die Frage der Nachprüfbarkeit ist das ein wichtiger Punkt, der über diesen Einzelfall hinausgeht. Ein Register, dessen Suchverhalten von der exakten Schreibweise abhängt, ist nur so gut wie die Kenntnis des Lesers. Wer den Kurznamen nicht kennt und den Langnamen nicht exakt trifft, sieht nichts – und schließt daraus möglicherweise auf das Gegenteil des tatsächlichen Zustands.

Was das für einen Betreiber bedeutet

Die vier Register zusammen ergeben kein Betriebsbild, aber sie ergeben ein Kontrollbild. Sie zeigen einen Exchange, der über eine stabile technische Identität verfügt: ein Name, eine Stadt, ein Standort, ein ASN, ein LAN. Sie zeigen zugleich eine Reihe von Feldern, die entweder offen oder nicht öffentlich sind: Serviceniveau und Geschäftsbedingungen stehen beide auf „Not Disclosed“, die Mitgliederliste ist nicht öffentlich, und die Frage nach dem rechtlichen Träger bleibt im Register offen.

Das ist der Punkt, an dem die übliche Erwartung an Transparenz und die übliche Erwartung an Diskretion aufeinandertreffen. Ein kleiner nationaler Exchange hat gute Gründe, Mitgliederdaten nicht öffentlich zu machen; er hat ebenso gute Gründe, potenziellen Teilnehmern und Aufsichtsinstanzen gegenüber belegen zu können, dass er funktioniert. Die Felder, die PeeringDB anbietet, sind genau die Felder, in denen beides verhandelt wird.

Für einen Betreiber heißt das: Die eigenen Angaben sind die Grenze der Nachprüfbarkeit durch Dritte. Wer als Exchange nicht beschreibt, wie viele Teilnehmer er hat, welche Dienste er anbietet und wie Konflikte entschieden werden, überlässt die Bewertung seiner Bedeutung denen, die aus Randdaten schließen. Das ist keine Kritik an der Entscheidung, sondern eine Beschreibung ihrer Kosten.

Die Grenze der Aussage dieses Textes ist eng gezogen: Es wurden vier öffentliche Datensätze geprüft, und keiner von ihnen enthält Verkehrsvolumen, Portgeschwindigkeiten, Teilnehmeridentitäten oder eine belastbare Aussage über die rechtliche Verfassung des Exchanges. Was hier über den Exchange steht, stammt aus diesen vier Datensätzen. Was über den Betrieb des Exchanges gilt, steht in keinem von ihnen.