Zusammenfassung

  • Das RDAP-Objekt von RIPE führt AS200427 und Proximity Data Centres Limited in einem administrativen Register. Der Status active gilt dem Registerobjekt; er belegt weder laufende Routen noch Geräte, BGP-Sitzungen oder Dienste.
  • PeeringDB enthält genau eine Zeile für AS200427 mit dem Namen nLighten - IX ASN. Die gemeinsame ASN verknüpft die Einträge technisch, doch die vier Quellen belegen keine Übernahme, Umbenennung, Eigentumsbeziehung oder betriebliche Kontinuität zwischen den Namen.
  • Die eingefrorene RIS-Antwort mit Query time 7. August 2026, 00:00 UTC weist für qualifizierende Routen IPv4-Sichtbarkeit von 0/325 und IPv6-Sichtbarkeit von 0/320 aus. Diese Nullen sind auf Produkt, Zeitpunkt und aufgeführte Peers begrenzt; sie beweisen weder einen Ausfall noch universelle Routenabwesenheit.

Die ASN verknüpft Datensätze, nicht ihre Aussage

Ein autonomes System ist ein Netz oder eine Gruppe von Netzen, die gegenüber dem öffentlichen Internet eine gemeinsame Routing-Policy vertritt. Seine Autonomous System Number, kurz ASN, dient als eindeutige Kennung. Über das Border Gateway Protocol (BGP) tauschen Netze Informationen darüber aus, welche Adressbereiche über welche autonomen Systeme erreichbar sein können.

AS200427 ist damit der stabile Bezug zwischen dem Verzeichniseintrag, dem RIPE-Registerobjekt, der PeeringDB-Zeile und der Routing-Antwort. Für eine Recherche ist die Nummer verlässlicher als ein Name allein, weil sie ähnlich benannte Unternehmen oder andere Routing-Domänen auseinanderhalten hilft.

Die gemeinsame Nummer vereinheitlicht jedoch nicht die Bedeutung der Felder. RDAP stellt administrative Registerdaten bereit. PeeringDB ist ein vom Teilnehmer gepflegtes Koordinationsverzeichnis. Der Routing Information Service (RIS) von RIPE sammelt BGP-Informationen an Beobachtungspunkten und veröffentlicht daraus abgeleitete Produkte. Jede Quelle kann innerhalb ihrer Aufgabe korrekt sein, ohne die Fragen einer anderen Ebene zu beantworten.

RIPE RDAP führt den administrativen Datensatz

Das Registration Data Access Protocol (RDAP) macht Registrierungsdaten zu Internet-Nummernressourcen strukturiert abrufbar. Die betrachtete RIPE-Antwort umfasst exakt die autonome Systemnummer 200427: Start- und Endnummer lauten beide 200427, der Handle ist AS200427, der Objektname PROXIMITY-AS. Als Registrant ist Proximity Data Centres Limited eingetragen.

Sowohl das Registrierungsereignis als auch das letzte Änderungsereignis tragen den 19. Dezember 2022, 15:15:02 UTC. Der Objektstatus lautet active. Diese Angaben sind nützlich, wenn eine Frage dem richtigen Nummernobjekt und dem dort geführten Namen zugeordnet werden soll.

Active ist aber ein administrativer Zustand des Registerobjekts. Er ist keine Telemetrie eines Routers und sagt nicht, ob eine BGP-Sitzung besteht, eine Route sichtbar ist, eine Ankündigung autorisiert wurde oder ein Dienst erreichbar ist. Ein Register kann Identität, Eindeutigkeit und Kontaktinformationen erhalten, während der Zustand laufender Systeme unabhängig davon wechselt.

Der abweichende PeeringDB-Name bleibt eine offene Unternehmensfrage

PeeringDB ist ein öffentliches Koordinationsverzeichnis, in das Netzteilnehmer ihre Angaben selbst eintragen. Die erfasste Antwort enthält eine Zeile für ASN 200427, Datensatz-ID 31834, mit dem Namen nLighten - IX ASN. Der Profilstatus ist ok, der Informationstyp Enterprise, die allgemeine Policy Selective; als Aktualisierungszeit ist der 28. März 2024, 13:05:57 UTC angegeben.

Dieser Name unterscheidet sich von Proximity Data Centres Limited im Verzeichnis und im RIPE-RDAP-Registranteneintrag. AS200427 erlaubt die technische Zuordnung zum selben Nummernobjekt. Die vier Quellen erklären aber nicht, warum die Namen voneinander abweichen. Sie enthalten keine ausreichenden Unternehmensbelege für eine Übernahme, Umbenennung, Eigentumskette oder betriebliche Kontinuität. Deshalb müssen beide Namen sichtbar bleiben, statt einen davon stillschweigend als Alias des anderen zu behandeln.

Auch die übrigen Profilfelder brauchen eine enge Lesart. Das Profil deklariert null IPv4-Präfixe und null IPv6-Präfixe, lässt das IRR-AS-Set leer und enthält keine netixlan-Zeilen. Verkehrsband und Website sind ebenfalls vom Teilnehmer eingetragene Profilangaben. Sie sind keine laufende Messung sämtlicher Routen, Verbindungen oder Verkehrsströme.

Null deklarierte Präfixe beweisen nicht, dass die ASN keinen Adressraum bekanntgibt. Fehlende Exchange-LAN-Zeilen beweisen keine Abwesenheit von allen Internetknoten, Route-Servern, privaten Zusammenschaltungen oder bilateralen Sitzungen. Selective beschreibt eine allgemeine Policy, nicht das Bestehen oder die Ablehnung einer bestimmten Sitzung. Auch ok ist der Zustand einer Datenbankzeile und kein Gesundheitscheck für Netz oder Dienst.

Die RIS-Nullwerte gelten nur innerhalb einer eingefrorenen Beobachtung

Die für diesen Beitrag verwendete routing-status-Antwort wurde mit der Query time 7. August 2026, 00:00 UTC eingefroren. Sie meldet, dass null von 325 aufgeführten IPv4-RIS-Peers und null von 320 aufgeführten IPv6-RIS-Peers qualifizierende Routen sahen. Die Felder für angekündigten Adressraum nennen null IPv4-Präfixe und Adressen, null IPv6-Präfixe und /48-Äquivalente sowie null beobachtete Nachbarn.

RIS arbeitet mit BGP-Daten aus Beobachtungspunkten. Das Ergebnis bleibt deshalb an das konkrete Produkt, seine Methode, den Zeitpunkt und die enthaltene Peer-Menge gebunden. 0/325 und 0/320 bedeuten, dass diese Antwort unter ihren Bedingungen keine qualifizierende Sichtbarkeit zurückgab. Sie bedeuten nicht, dass nirgends im Internet eine Route existierte oder dass AS200427 ausgefallen war.

Kollektorsicht beantwortet auch keine Autorisierungsfrage. Ob eine Route sichtbar ist, sagt nicht, ob der Ressourceninhaber ihren Ursprung autorisiert hat. Aus den Nullwerten folgen außerdem keine Aussagen über Verkehr, Latenz, Kapazität, Topologie, physische Vielfalt, Resilienz, Verfügbarkeit oder Kundenerfahrung. Ohne Produktname, Query time, Adressfamilie und Peer-Nenner würde ein begrenztes Ergebnis fälschlich zu einer universellen Behauptung.

Die Felder von 2017 bilden kein Ausfallfenster

Dieselbe Antwort enthält historische Felder. first_seen nennt das Präfix 185.94.255.0/24 mit Origin 200427 am 18. Dezember 2017, 00:00 UTC. last_seen nennt dasselbe Präfix und denselben Origin am 18. Dezember 2017, 16:00 UTC. Diese Werte gehören zu Feldern der abgefragten Antwort; ihre Query time liegt dagegen am 7. August 2026.

Aus den beiden Zeitpunkten folgt weder, dass die ASN nur sechzehn Stunden betrieben wurde, noch dass nach 2017 keine Ankündigung mehr existierte oder ein Ausfall bis 2026 anhielt. Für Kontinuität wäre eine gezielt erstellte Routing-Zeitreihe nötig, die Abdeckung, Schwellenwerte, Beobachtungspunkte und Lücken offenlegt. Ein Ausfallurteil bräuchte zusätzlich Nachweise für die betroffenen Systeme und das betreffende Zeitfenster.

So lässt sich die nächste Frage prüfen

Eine belastbare Prüfung beginnt mit der Identität. Im Verzeichnis und in RIPE RDAP sollten AS200427, Nummernbereich, Handle und Registrantenname abgeglichen werden. Danach zeigt PeeringDB, welcher Name und welche Erklärungen tatsächlich unter derselben ASN veröffentlicht sind. Eine Namensabweichung löst eine Unternehmensfrage aus; sie beantwortet sie nicht. Dafür wären autorisierte Unternehmensquellen erforderlich.

Bei einer Routing-Frage sollten Produktname, Query time, Adressfamilie, Peer-Nenner und zurückgegebene Präfixe erhalten bleiben. Wenn eine Entscheidung breitere Gewissheit verlangt, hilft eine zweite zeitlich begrenzte Beobachtungsmethode. Kontinuität erfordert eine Routing-Historie. Für Route-Origin-Autorisierung sind die passenden Autorisierungs- und Registerdaten nötig. Eine Dienstfrage verlangt zeitlich abgestimmte Ende-zu-Ende-Tests und Systemnachweise.

RIPE-Registrierung, das vom Teilnehmer gepflegte PeeringDB-Profil und die eingefrorene RIPE-RIS-Antwort sind verschiedene Belegebenen. Keine davon beweist allein eine laufende Peering-Sitzung, Routenabwesenheit, betriebliche Kontinuität, universelle Erreichbarkeit, Route-Origin-Autorisierung, Kapazität, Resilienz oder Kundendienst.

Grenzen der öffentlichen Quellen

Die Quellen tragen drei begrenzte Aussagen: RIPE RDAP führt Proximity Data Centres Limited bei AS200427; PeeringDB enthält eine Zeile für dieselbe ASN unter einem anderen Namen; die eingefrorene RIS-Antwort gibt innerhalb ihrer aufgeführten Peer-Mengen Nullwerte zurück. Diese Tatsachen können gleichzeitig gelten, ohne Widerspruch, Ausfall oder Unternehmensbeziehung zu belegen.

Nicht belegt sind Eigentum, Übernahmegeschichte, Umbenennung, betriebliche Kontinuität, Dienste, Kunden, Betriebsregionen, Einrichtungen, Geräte, Upstreams, kommerzielle Größe oder Marktstellung. Ebenso wenig belegt sind aktuelle Exchange-Präsenz, Route-Server-Teilnahme, bilaterale Sitzungen, Verkehr, Durchsatz, Latenz, Reservekapazität, physische Vielfalt, Resilienz, Verfügbarkeit oder Auswirkungen auf Kunden.

Worauf künftig zu achten ist

  • Änderungen an Nummernbereich, Registrantenname, administrativem Status oder Ereignishistorie von AS200427 in RIPE RDAP;
  • Änderungen am Namen, an der Policy, an Präfixzahlen oder Exchange-LAN-Angaben der PeeringDB-Zeile;
  • autorisierte Unternehmensbelege, die eine Beziehung zwischen Proximity Data Centres Limited und nLighten - IX ASN ausdrücklich erklären;
  • spätere Routing-Beobachtungen, die Produkt, Query time, Adressfamilie, Peer-Nenner und Methode ausweisen;
  • zweckgeeignete Routing-Historie und Autorisierungsdaten, wenn Kontinuität oder Route-Origin-Autorisierung untersucht werden;
  • autorisierte Betriebsdaten und zeitlich abgestimmte Tests, wenn eine Live-Sitzung oder Kundenerfahrung Gegenstand der Frage ist.

Quellen