Zusammenfassung

  • Eine historische Sichtbarkeit von AS210837 und ein aktueller Messfehler beantworten unterschiedliche Fragen; weder ein alter Datensatz noch eine leere Abfrage beweist für sich genommen eine Abschaltung.
  • Ein verantwortbarer Kontinuitätstest muss administrative Identität, angekündigte Routen, zeitliche Persistenz, beobachtete BGP-Nachbarschaften und Betreiberdaten innerhalb eines definierten Beobachtungsfensters zusammenführen.

Die erste Trennung: administrative Identität und beobachtbare Oberfläche

Der Ausgangspunkt ist die Unterscheidung zwischen dem, was ein Netzwerk administrativ ist, und dem, was es im Routing tatsächlich sichtbar macht. Das eingefrorene Directory-Ziel dieser Untersuchung ist ROYA Communications and Internet Services Company Ltd., in dieser Recherche mit AS210837 verbunden. Diese Zuordnung beschreibt den Gegenstand der Untersuchung, nicht den aktuellen Betriebszustand. Eine Einordnung in einem Verzeichnis sagt weder, dass ein Autonomous System heute Präfixe ankündigt, noch dass seine Kunden erreichbar sind.

Für die administrative und routingbezogene Prüfung sind mehrere öffentliche Messpunkte relevant. Die RIPEstat-Übersicht liefert den Rahmen für das untersuchte ASN (RIPEstat AS-Übersicht). Die angekündigten Präfixe und der Routingstatus adressieren die Frage, ob Beobachter Routen sehen (RIPEstat angekündigte Präfixe; RIPEstat Routingstatus). Nachbarschaftsdaten können zeigen, welche ASNs aus Sicht eines Messsystems in Beziehung zur Route erscheinen (RIPEstat ASN-Nachbarn). Sie beweisen jedoch keine Verträge, Transitkäufe oder Kundenbeziehungen.

Was die bisherige Evidenz tatsächlich trägt

Die frühere veröffentlichte Berichterstattung verzeichnete für Juli 2022 eine historische Beobachtung von 22 IPv4- und 29 IPv6-Präfixen. Diese Zahlen sind ein zeitgebundener Referenzpunkt, keine aktuelle Messung. Sie zeigen, dass die betreffende Netzwerkidentität in diesem historischen Beobachtungsfenster mit einer bestimmten Routingoberfläche verbunden war. Sie zeigen nicht, ob dieselben Präfixe heute angekündigt werden, ob die Ursprungsidentität unverändert ist oder ob die damalige Sichtbarkeit auf dauerhaften Betrieb schließen lässt.

Die aktuelle Recherche konnte keine verifizierten Live-Antwortkörper oder aktuellen Werte der abgefragten RIPEstat-, BGPView- und PeeringDB-Endpunkte sichern. Deshalb lassen sich aus diesem Durchlauf keine gegenwärtigen Präfixzahlen, Ankündigungsstatus, First- oder Last-Seen-Zeitpunkte, Nachbarn, Upstreams, Peers, kommerziellen Beziehungen oder das Vorhandensein eines PeeringDB-Datensatzes ableiten. Diese Grenze ist selbst ein Ergebnis der Untersuchung: Eine nicht verfügbare Messung darf nicht als Nullwert behandelt werden.

BGPView bietet weitere Perspektiven auf Präfixe (BGPView Präfixe), Upstreams (BGPView Upstreams) und Peers (BGPView Peers). Das PeeringDB-Netzwerk-API kann ergänzenden Betreiberkontext liefern (PeeringDB-Netzwerkdatensatz). Keine dieser Quellen beweist allein, dass ein Dienst aktiv betrieben wird. Selbst eine sichtbare Route belegt primär eine beobachtete Ankündigung, nicht die erfolgreiche Weiterleitung jeder Kundenverbindung.

Der Kontinuitätstest als zeitabgestimmte Messkette

Ein belastbarer Test braucht zunächst ein Beobachtungsfenster: etwa mehrere Abfragen an festgelegten Tagen und zu festgelegten Zeiten, ergänzt um den Zeitpunkt jeder gespeicherten Antwort. Danach müssen die Messschichten getrennt und anschließend miteinander verglichen werden.

Erstens prüft die Registry- oder ASN-Ebene die administrative Identität. Sie beantwortet, welcher Nummernraum und welche ASN dem Untersuchungsgegenstand zugeordnet sind. Zweitens prüft die Routingebene, ob unabhängige Kollektoren aktuelle Ankündigungen beobachten. Drittens liefern First-Seen- und Last-Seen-Daten eine zeitliche Dimension: Sie können anzeigen, ob eine Sichtbarkeit neu, fortlaufend oder lange nicht mehr beobachtet wurde (RIPEstat First-/Last-Seen-Daten). Viertens beschreiben Nachbarschafts-, Upstream- und Peer-Ansichten beobachtete BGP-Adjazenzen. Sie dürfen nicht ohne zusätzliche Belege in kommerzielle Beziehungen übersetzt werden. Fünftens kann ein Betreiberverzeichnis Kontext liefern, bleibt aber ein Kontextsignal und kein Beweis für aktuelle Weiterleitung.

Die Aussage entsteht aus der Übereinstimmung dieser Schichten, nicht aus einem einzelnen Endpunkt. Wenn Registry-Identität, aktuelle Ankündigungen und zeitnahe First-/Last-Seen-Aktivität zusammenpassen, stützt das die Aussage, dass Routing-Sichtbarkeit fortbesteht. Es beweist weiterhin weder Kundenreichweite noch physische Betriebsfähigkeit. Wenn mehrere unabhängige Messsysteme innerhalb desselben Fensters keine Ankündigungen sehen, ein Last-Seen-Zeitpunkt weit zurückliegt und kein aktueller Betreiberkontext hinzukommt, stützt das eine Hypothese der Routingunterbrechung. Die Ursache bleibt dann offen.

Divergenz ist ein Signal, kein Urteil

Die wichtigste analytische Regel lautet: Divergenz zwischen Messschichten ist diagnostisch, aber nicht abschließend. Eine Registry kann fortbestehen, während ein ASN nicht mehr routet. Ein Routingdatensatz kann leer sein, weil ein Endpunkt nicht antwortet, ein Filter greift oder die Abfrage nicht den erwarteten historischen Zeitraum abbildet. Eine PeeringDB-Lücke kann bedeuten, dass kein Datensatz vorhanden ist; sie beweist weder Aufgabe noch Verlagerung. Eine sichtbare Präfixankündigung kann bestehen, während einzelne Kunden nicht erreichbar sind.

Deshalb darf eine einzelne leere API-Antwort nicht als Shutdown, Withdrawal, Transfer oder Relocation beschrieben werden. Ebenso darf ein alter Registry-Eintrag nicht als Beleg für laufenden Betrieb gelten. Die richtige Schlussfolgerung aus unvollständigen Messungen ist eine begrenzte Unsicherheit: Der aktuelle Zustand konnte im vorliegenden Beobachtungsdurchlauf nicht verifiziert werden.

Welche nächsten Messungen die Unsicherheit verkleinern würden

Der nächste Durchlauf sollte dieselben Endpunkte in einem klaren Zeitfenster abfragen und die Rohantworten mit Abrufzeit, HTTP-Status und Quellen-URL unverändert speichern. Für RIPEstat sollten Übersicht, angekündigte Präfixe, Routingstatus, ASN-Nachbarn und First-/Last-Seen-Daten gemeinsam erhoben werden. Für BGPView sollten Präfixe, Upstreams und Peers in demselben oder einem möglichst nahen Zeitfenster abgefragt werden. PeeringDB sollte als unabhängiger Kontextdatensatz geprüft werden, nicht als Ersatz für Routingmessungen.

Die Auswertung sollte mindestens fünf Fragen getrennt beantworten: Bleibt die administrative Identität bestehen? Werden Präfixe aktuell beobachtet? Wie alt oder neu ist die Beobachtung? Welche BGP-Adjazenzen sind sichtbar? Gibt es unabhängigen Betreiberkontext? Erst danach kann eine Aussage über fortbestehende Routing-Sichtbarkeit oder eine plausible Unterbrechung formuliert werden. Aussagen über Kundenbetrieb, physische Standorte, rechtliche Kontinuität oder kommerzielle Verträge benötigen weitere Belege.

Für Leser, die den Gegenstand der Untersuchung und seine verknüpfte Directory-Aufzeichnung nachvollziehen wollen, ist der Directory-Eintrag von ROYA Communications and Internet Services Company Ltd. der maßgebliche Referenzpunkt. Auch dieser Eintrag ist vom aktuellen Routingzustand zu unterscheiden.

Schlussfolgerung

AS210837 ist kein Fall, bei dem eine einzelne Zahl die Betriebsrealität entscheidet. Die historische Beobachtung von 22 IPv4- und 29 IPv6-Präfixen beschreibt einen früheren Zeitpunkt. Die aktuelle Recherche belegt keine gegenwärtigen Werte. Belastbare Kontinuität erfordert eine zeitabgestimmte Konjunktion unabhängiger Beobachtungen: administrative Identität, Route, zeitliche Persistenz, beobachtete Adjazenz und Betreiberkontext.

Bis diese Kette erneut erhoben und verglichen ist, bleibt die verantwortbare Aussage enger: Die Kontinuität der Netzwerkoberfläche ist nicht verifiziert, und ihr Mechanismus kann aus einer einzelnen fehlenden oder leeren Messung nicht bestimmt werden.