Zusammenfassung

  • Beobachtung vom 26. Oktober 2026: AS139620 meldet zwei IPv4-Präfixe mit 512 Adressen und ein /48; Sichtbarkeit 269/269 und 257/257; sieben beobachtete Nachbarn, zwei links und fünf rechts im Pfad.
  • In der Akte steht im Namen PUBLIC COMPANY, im Feld für die Rechtsform private_company, und die 0,95 ruht auf zwei Belegen von je 0,82 – wobei der Eintrag bei rdap.org diesmal nicht aufging. Der eigene Text unter data_gaps bittet weiterhin darum, das Land der juristischen Person zu prüfen.
  • Was das für eine Entscheidung bedeutet: Die Akte belegt, dass die AS-Nummer existiert, dass das Routingsystem sie seit dem 4. September 2019 sieht und dass sie am Morgen des 26. Oktober weiter angekündigt wurde. Sie belegt nicht Größe, Eigentümer, Geschäftsführung oder gesellschaftsrechtliche Verflechtung. Und 512 Adressen messen die Breite einer einzigen Transitkante, nicht das ganze Netz des Unternehmens.

Was die Router am Morgen des 26. Oktober sahen

Zuerst die Zahlen. Die Routing-Status-Abfrage von RIPEstat datiert die Abfrage auf 2026-10-26T00:00:00 und das Beobachtungsfenster auf 2026-10-26T08:00:00 (RIPEstat Routing-Status). Zwei Werte darin verdienen einen Moment: Die IPv4-Sichtbarkeit lag bei 269 von 269 RIS-Peers, die IPv6-Sichtbarkeit bei 257 von 257. Volle Punktzahl.

Volle Punktzahl ist für sich genommen nichts Besonderes. Ein Ursprung mit zwei Präfixen, dessen Upstream die Routen ordentlich weiterreicht, entgeht keinem Beobachter. Informativ ist der nächste Satz: Der angekündigte Adressraum umfasst zwei IPv4-Präfixe mit 512 Adressen sowie ein IPv6-Präfix der Länge /48; beobachtet wurden sieben Nachbarn. Diese drei Angaben zusammen ergeben kein nationales Telekommunikationsnetz, sondern eine nach außen gehängte Transitkante.

Die Präfixliste lautet (RIPEstat angekündigte Präfixe): 103.142.144.0/24, 103.142.145.0/24 und 2001:df1:4780::/48. Jedes trägt eine Zeitlinie vom 2026-10-12T08:00:00 bis zum 2026-10-26T08:00:00. Hier ist genaues Lesen nötig: Ein Hinweis in der Antwort selbst besagt, dass Routen, die von weniger als zehn RIS-Full-Feed-Peers gesehen werden, nicht enthalten sind. Die Zeitlinie sagt also, dass diese drei Präfixe über vierzehn Tage durchgehend auf dieser Liste standen; sie belegt nicht, dass am 12. Oktober irgendetwas umgestellt wurde.

Von einem /23 zu zwei /24

Derselbe Statusdatensatz liefert die erste und die letzte Beobachtung. Die erste war das Präfix 103.142.144.0/23 am 2019-09-04T16:00:00. Die jüngste war 103.142.145.0/24 am 2026-10-26T08:00:00.

Verbindet man die beiden Punkte, steht dort ein konkreter technischer Sachverhalt: Im September 2019 war zu sehen ein Aggregat von 512 Adressen; am Morgen des 26. Oktober 2026 sind zu sehen zwei /24 mit je 256 Adressen, getrennt angekündigt. Die Arithmetik geht auf. Ein /23 ist genau die Vereinigung der beiden /24, keine Adresse mehr und keine weniger.

Warum aufgeteilt wurde, beantwortet die Messung nicht. Das Aufteilen von Präfixen kann Präfix-Traffic-Engineering sein, eine Trennung nach Upstream oder Standort, oder schlicht eine alte Konfiguration, die niemand wieder zusammengeführt hat. Umgekehrt wäre es eine ebenso protokollierenswerte Änderung, wenn die zwei /24 eines Tages wieder zu einem /23 zusammenfinden – und nicht „nichts passiert“. Die richtige Haltung ist, die Form der Ankündigung als Form zu lesen und nicht als Motiv.

Sieben Nachbarn, zwei Richtungen, und die Versuchung, sie Kunden zu nennen

Die Adjazenzdaten (RIPEstat AS-Nachbarn) verteilen sieben beobachtete Nachbarn auf zwei Gruppen.

Links zwei: AS38082 mit Power 568, 1007 IPv4-Peers und 0 IPv6-Peers; AS4651 mit Power 1109, 1230 IPv4-Peers und 499 IPv6-Peers. Rechts fünf: AS139595 (Power 248, 318, 0), AS139692 (248, 562, 0), AS139719 (44, 162, 0), AS151482 (248, 319, 0) und AS154481 (309, 275, 205).

„Links“ und „rechts“ sind Etiketten, die RIPEstat nach der Position im beobachteten AS-Pfad vergibt. Das ist Topologie, kein Vertrag. Die fünf rechten sind Netze, für die AS139620 in beobachteten Pfaden als Upstream auftauchte. Sie Kunden, Käufer oder Vertragspartner zu nennen, schiebt in eine Messung hinein, was sie nicht enthält. Was die Daten hergeben, ist lediglich: In diesen fünf Richtungen existierten Pfade, und die Peer-Zahl der jeweiligen Gegenseite ist bekannt.

Die Identität der beiden linken Netze ließ sich in den öffentlichen Registern, die ich bei dieser Prüfung lesen konnte, nicht feststellen. Deshalb nennt dieser Text nur Nummern und keine Firmennamen. Das ist keine stilistische Zurückhaltung, sondern Evidenzdisziplin: Dass eine AS-Nummer existiert, bestätigt nicht, wer sie betreibt.

Die Zeilen, die das Register zeichnet

Der WHOIS-Text von APNIC (APNIC WHOIS) zeichnet es so: aut-num AS139620, as-name MTNPCL-AS-AP, descr MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY LIMITED, country MM. Dieselbe Abfrage (APNIC-Abfrageantwort) gibt zusätzlich den Organisations-Handle ORG-MTNP1-AP zurück.

Die AS-Übersicht von RIPEstat (RIPEstat AS-Übersicht) liefert dieselbe Halter-Zeichenkette, ordnet die Nummer dem Block 139578-140601 zu, dessen Beschreibung „Assigned by APNIC“ lautet, unter dem IANA-Register für 32-Bit-Autonomous-System-Nummern, und meldet announced true für das Fenster 2026-10-26T08:00:00.

Bemerkenswert ist der Weg, der nicht durchgeht. Das RDAP-Objekt von APNIC selbst (APNIC RDAP autnum) lieferte bei dieser Prüfung keinen lesbaren Datensatz. Damit sind Zuteilungsdatum, Objektstatus und remarks – was man normalerweise in RDAP liest – hier in keinem Feld verfügbar. Wer fragt, an welchem Tag die Nummer zugeteilt wurde, bekommt von diesem Text die Auskunft, dass es keine Antwort gibt; kein geschätztes Jahr.

Zwei Dokumente, eine Note

Nun die BTW-Akte selbst. Sie zeigt einen confidence_score von 0,95. Ihre evidence_basis enthält genau zwei Einträge mit jeweils 0,82: das autnum-Dokument bei rdap.org, ausgewiesen als Public registry record, und die AS-Übersicht von RIPEstat, ausgewiesen als public routing data.

Das Problem ist nicht, zwei Quellen zu zitieren. Zwei Quellen zu zitieren ist ehrlich. Das Problem ist, wie aus 0,82 und 0,82 eine 0,95 wird. Die Akte nennt die Aggregationsregel nicht. Und für Leser ist der praktischere Punkt ein anderer: Das bei rdap.org verlinkte Dokument (rdap.org autnum) löste bei dieser Prüfung nicht auf; das Abrufergebnis war inaccessible, der Auszug leer.

Von zwei zitierten Dokumenten wurde eines gelesen und das andere nicht, und trotzdem stieg die Gesamtnote von 0,82 auf 0,95. Das ist kein Betrugsvorwurf, sondern ein Reproduzierbarkeitsproblem. Die Zahl 0,95 liest sich wie „zwei unabhängige Dokumente wurden geprüft“, tatsächlich geschah: „zwei Eingaben von 0,82, eine davon diesmal nicht zu öffnen“. Eine ehrliche Darstellung würde entweder die Aggregationsregel nennen oder die Note am Boden halten, solange ein Beleg nicht aufgeht.

Der Zusammenstoß von Name und Feld

Die Zeichenketten der Akte lauten: legal_name ist MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L; Alias TELECOMMUNICATION NETWORK PUBLIC COMPANY L; legal_type ist private_company; hq_country und registration_jurisdiction beide Myanmar (Burma), hq_country_code MM.

Der Name trägt PUBLIC COMPANY, das Feld trägt private_company. Das ist eine Abweichung zwischen zwei Zeichenketten. Mehr sage ich nicht. Ich habe weder Gründungsurkunde noch Handelsregisterauszug noch Nachweis der Rechtsform erhalten; deshalb ist nicht zu entscheiden, welche der beiden Zeichenketten von den Tatsachen abweicht – und nicht einmal auszuschließen, dass beide unter irgendeiner juristischen Definition zutreffen. Zu schreiben, das Unternehmen „gebe sich als börsennotiert aus“, ist genau das, was dieser Text verweigert.

Auf derselben Karte liegt eine zweite Naht. Sie trägt als Jurisdiktion Myanmar (Burma) ein und bittet unter data_gaps zugleich darum, „das Land der juristischen Person“ zu prüfen – danach folgen aktuelle Dienste, sichtbare Vermögenswerte, Mutter- oder Tochterverhältnisse und verantwortliche Ansprechpartner. Den Wert eingetragen und im selben Dokument eingeräumt, ihn nicht geprüft zu haben. Das ist kein Indiz für ein Vergehen, sondern die Reihenfolge der Kartenerstellung, die im Endprodukt überlebt hat.

Die dritte Naht ist feiner. Der juristische Name der Karte endet mit einem einzelnen L, das descr bei APNIC schreibt LIMITED. Es sind zwei Schreibweisen desselben Halters, daran zweifle ich nicht. Welche zur Gründungsurkunde passt, weiß ich jedoch nicht. Firmensuffixe werden in internationalen Namen gern abgekürzt und gern ausgeschrieben; beides ist für sich kein Problem. Ein Problem wird es erst dort, wo der Name in das Feld für die Vertragspartei eines Vertrags soll.

Eine AS, als virtuell klassifiziert

Die Akte führt genau eine Ressource: AS139620, resource_type asn, resource_class virtual, status observed, service ip_transit, Land Myanmar (Burma).

Ein Wort hier lasse ich nicht aus: virtual. Eine AS-Nummer ist in URL, Abfrage und Routentabelle ein greifbarer Gegenstand, doch diese Akte klassifiziert die Ressource als virtuell. Was virtual in diesem Verzeichnissystem bedeutet, war bei dieser Prüfung nicht zu ermitteln. Man kann es lesen als „diese Ressource ist kein eigener Adressblock“, und man kann es als irgendeine andere Klassifizierung lesen. Ohne Definition berichtet dieser Text den Feldwert und interpretiert nicht an ihrer Stelle.

Die Dienstebene ist ebenfalls eine einzige: roles als provider, Region MM, Dienste ip_transit und managed_network. Von beiden findet nur ip_transit eine Entsprechung in der Routing-Evidenz, die ich lesen konnte: Präfixe werden angekündigt, Nachbarn reichen sie weiter, das ist Transit. managed_network existiert als Feld der Akte, hat im hier gelesenen öffentlichen Material aber keine nachprüfbare Entsprechung. Als Registereintrag besteht es; als zitierfähige Dienstleistungsfähigkeit noch nicht.

Das Leere ist lauter als das Geschriebene

In dieser Akte nehmen die leeren Felder mehr Raum ein als die gefüllten: relationships ist ein leeres Array, leadership_contacts ein leeres Array, related_events ein leeres Array, contextual_references ein leeres Array; first_seen_at ist null, external_id null, source_system null, website null, primaryDomain null. Der Status lautet queued_for_profile_article, last_updated_at ist 2026-06-17T00:04:15.536Z.

Diese Leerstellen sind kein Skandal, sondern Reihenfolge: zuerst wird die AS-Nummer beobachtet, danach kommen Personen, Beziehungen und Website. Die Verzeichnisseite steht hier: BTW-Verzeichniseintrag Nur für den Strategischen Kreis. Aber für jemanden, der damit entscheiden will, bestimmen die Leerstellen, welche Fragen überhaupt möglich bleiben. Ohne leadership_contacts lässt sich nicht fragen, wer bei einer Störung ans Telefon geht. Ohne relationships lässt sich nicht fragen, mit wem das Unternehmen verwandt ist. Mit first_seen_at null lässt sich nicht einmal sagen, wann die Einheit ins Verzeichnis kam; sagen lässt sich nur, dass die Nummer am 4. September 2019 bereits im Routingsystem zu sehen war.

Was eine entscheidende Person tatsächlich braucht

Ich mache die Leserschaft konkret. Drei Typen bleiben vor einer solchen Akte stehen: der Betreiber, der an diesen Transit anbinden will; der Einkauf, der eine Lieferantenliste füllen muss; die Analystin, die einen Länder- oder Regionalbericht schreibt.

Die vier Dinge, die sie brauchen, sind unspektakulär: Ob das Unternehmen noch operiert; ob jene 512 Adressen ihm gehören; wer die Upstreams sind; wer haftet, wenn etwas ausfällt.

Was diese Prüfung liefert: Die AS-Nummer existiert; das Routingsystem sieht sie seit 2019-09-04T16:00:00; im Fenster 2026-10-26T08:00:00 wurde sie weiter angekündigt; die Sichtbarkeit war nahezu vollständig; der angekündigte Raum umfasst 512 IPv4-Adressen und ein /48; es gibt sieben beobachtete Nachbarn, zwei links und fünf rechts im Pfad.

Was sie nicht liefert: Gründungsurkunde, Eigentümerstruktur, Namen der Geschäftsführung, Kundenliste, Gesamtgröße des Netzes. Der letzte Punkt gehört ohne Umschweife gesagt: 512 Adressen sind die Breite dieser Transitkante. Ein Betreiber kann das ganze Backbone anderswo betreiben und hier nur dieses kleine Stück anhängen; das Gegenteil ist ebenso wenig auszuschließen. Mit dieser Akte allein fällt keine der beiden Möglichkeiten weg.

Der richtige Gebrauch ist deshalb: die Akte als Spur behandeln, nicht als Beleg. Die Spur zeigt, wo als Nächstes zu fragen ist: beim APNIC den Zuteilungsnachweis anfordern, ein prüfbares Registerdokument verlangen, eine Kontaktliste mit SLA erfragen. Beleg ist Papier mit Unterschrift, nicht eine Note, die jemand vergeben hat.

Was dieses Urteil umwerfen würde

Ein Text über Evidenzgrenzen sollte seine eigenen Widerlegungsbedingungen nennen.

Erstens: Wird das RDAP-Objekt von APNIC wieder lesbar und nennt Zuteilungsdatum und Objektstatus, fällt die Aussage „kein Zuteilungsdatum verfügbar“ sofort, und die Diskussion über die Chronologie muss neu geschrieben werden.

Zweitens: Ändert das Verzeichnis legal_type auf public_company, oder legt jemand eine Gründungsurkunde vor, ist die Spannung zwischen Name und Feld erklärt – in welche der beiden Richtungen auch immer.

Drittens: Taucht ein neues Präfix auf, oder finden die zwei /24 wieder zu einem /23 zusammen, ist 512 nicht mehr „aktuell“, sondern „Momentaufnahme“.

Viertens: Öffnet das Dokument bei rdap.org wieder, bleibt das Rechenproblem zwischen 0,95 und 0,82 bestehen, aber die Feststellung, dass es nicht aufging, entfällt.

Fünftens: Ändert sich die Nachbarmenge, muss die Beschreibung der linken und rechten Seite neu gemessen werden. Messungen haben ein Datum; Beschreibungen haben ein Haltbarkeitsdatum.