AS9245 zeigt den Dual-Stack-Routing-Fußabdruck hinter Compass – nicht dessen Dienstresilienz

Zusammenfassung

• APNIC RDAP führt AS9245 unter dem Namen COMPASS-NZ-AP, dem Ländercode NZ und dem Registerstatus „active“. Als Registrant ist Compass Communications Ltd verzeichnet. Damit besteht eine präzise administrative Verbindung zwischen der Nummernressource und dem Unternehmen, jedoch kein Beweis für aktuelle Dienste, Reichweite, Anlagen, Lizenzumfang oder Belastbarkeit.

• Zum Beobachtungszeitpunkt 3. August 2026 um 00:00 UTC meldete RIPEstat AS9245 als angekündigt. Die Routing-Statusdaten zählten zwölf IPv4-Präfixe mit zusammen 25.600 Adressen sowie ein IPv6-Präfix, das 65.536 /48-Äquivalenten entspricht.

• In der erfassten RIS-Stichprobe war der Ursprung bei 329 von 329 aufgeführten IPv4-Peers und 321 von 321 aufgeführten IPv6-Peers sichtbar. Diese Nenner sind für die Interpretation unverzichtbar: Sie beschreiben die Sicht der abgefragten Peers, nicht eine universelle Erreichbarkeit des gesamten Internets.

• Die begrenzte Präfixabfrage für den Zeitraum vom 20. Juli bis zum 3. August 2026 enthielt genau 13 Ankündigungen: zwölf IPv4-Präfixe und das IPv6-Aggregat 2405:8400::/32. Die Liste zeigt einen beobachteten Dual-Stack-Routing-Fußabdruck, aber weder Verkehrsmengen noch Kapazität, Pfadvielfalt oder erfolgreiche Umschaltungen.

• Als zuerst beobachtete Route nennt RIPEstat 203.98.24.0/24 mit dem Zeitpunkt 18. August 2000 um 08:00 UTC. Die jüngste Route in der erfassten Antwort ist 202.90.56.0/21 zum Abfragezeitpunkt. Diese Zeitangaben dokumentieren Beobachtungen in den verwendeten Daten und dürfen nicht als lückenlose Betriebsgeschichte verstanden werden.

• PeeringDB ordnet sein betreibergepflegtes Netzwerkprofil Compass Communications Ltd und AS9245 zu. Dort stehen der Typ Cable/DSL/ISP, der Geltungsbereich Asia Pacific, eine offene allgemeine Policy sowie jeweils 50 deklarierte IPv4- und IPv6-Präfixe. Das sind Angaben des Betreibers und keine unabhängigen Messungen aktiver Sitzungen oder Routen.

• Compass beschreibt sich auf eigenen Seiten als 1995 gegründeten, neuseeländischen und unabhängigen Anbieter mit landesweitem Netz. Genannt werden Glasfaser, VDSL, ADSL, ländliche Konnektivität, Sprachdienste, Cloud PBX, Managed Services und Rechenzentrumsprodukte. Diese Aussagen liefern kommerziellen Kontext, verbinden aber kein einzelnes Produkt mit einem bestimmten AS9245-Präfix.

• Die Unternehmensseite zu Rechenzentren nennt Auckland und Hamilton, Interkonnektionsbeziehungen sowie ein SLA von 99,99 Prozent. Diese betreibereigenen Aussagen belegen weder rechtliches Eigentum an Anlagen noch aktuelle physische Topologie, aktive Verbindungen, tatsächliche Verfügbarkeit oder erfolgreiche Redundanz.

• Eine Statusseite ist eine selbst gemeldete Momentaufnahme. Selbst ein unauffälliger Zustand zu einem bestimmten Zeitpunkt kann weder frühere Verfügbarkeit noch die Widerstandsfähigkeit einer Route, eines Standorts, eines Anschlusses oder eines Kundendienstes nachweisen.

• Die belastbarste Lesart trennt vier Ebenen: APNIC dokumentiert administrative Identität, RIPEstat beobachtet Routing, PeeringDB sammelt Betreiberangaben und Compass beschreibt sein Leistungsangebot. Erst diese Trennung verhindert, dass ein sichtbarer BGP-Ursprung fälschlich als Qualitäts- oder Resilienznachweis behandelt wird.

Eine Netzidentität mit klaren Grenzen

COMPASS-NZ-AP COMPASS ist die genaue Bezeichnung des bestehenden Verzeichniseintrags. Dahinter steht keine beliebige Ähnlichkeit zwischen einem Unternehmensnamen und einer Routing-Kennung, sondern eine überprüfbare Kette: Der Eintrag verweist auf AS9245, während APNIC RDAP den Autonomes-System-Eintrag unter COMPASS-NZ-AP führt und Compass Communications Ltd als Registranten nennt. Diese Verbindung reicht aus, um über den öffentlichen Routing-Fußabdruck von AS9245 im Zusammenhang mit Compass zu sprechen. Sie reicht nicht aus, um aus jeder beobachteten Route automatisch eine bestimmte kommerzielle Leistung, Anlage oder Kundenverbindung abzuleiten.

Diese Unterscheidung wirkt zunächst formal, ist aber für eine sachgerechte Bewertung von Internetinfrastruktur zentral. Ein Autonomes System ist eine Routing-Identität. Es kann in BGP-Beobachtungen als Ursprung von Präfixen erscheinen und mit administrativen Datensätzen verbunden sein. Die Tatsache, dass eine solche Identität sichtbar ist, sagt dennoch nicht, wer einen konkreten physischen Leitungsweg besitzt, welche Kapazität darüber verfügbar ist oder welche vertragliche Leistung ein Kunde erhält. Auch die rechtliche Reichweite des Unternehmens lässt sich nicht allein aus einem Registereintrag ableiten.

Die Bezeichnung COMPASS-NZ-AP und der Registrant Compass Communications Ltd erfüllen unterschiedliche Funktionen. Der Name des Netzobjekts identifiziert die Ressource im Registerkontext. Der Registrant stellt die administrative Unternehmensbindung her. Daraus folgt keine zweite Gesellschaft hinter dem Netzalias, aber ebenso wenig eine vollständige Aussage über Konzernstruktur, wirtschaftliches Eigentum oder einzelne Vermögenswerte. Das Register dient als präzises Verzeichnis der Nummernressource, nicht als umfassendes Unternehmens-, Lizenz- oder Anlagenregister.

Auch der Ländercode NZ muss eng gelesen werden. Er gehört zum APNIC-Datensatz von AS9245. Er ist kein technischer Beweis dafür, dass jede Route ausschließlich innerhalb Neuseelands geführt wird, dass sämtliche Dienste landesweit verfügbar sind oder dass alle Komponenten des Netzes in einer bestimmten Rechtsordnung liegen. Geografische Dienstabdeckung, physische Wege und Standortzuordnungen benötigen andere, unmittelbar dafür geeignete Belege. Der Registercode allein kann diese Fragen nicht beantworten.

Der Wert der administrativen Identität liegt gerade in dieser Begrenztheit. Er ermöglicht eine saubere Zuordnung der untersuchten Nummernressource, ohne aus einer Namensübereinstimmung eine umfassendere Geschichte zu konstruieren. Für AS9245 lässt sich belastbar festhalten, wer im APNIC-Datensatz als Registrant erscheint und unter welchem Namen das System geführt wird. Alles Weitere muss aus einer anderen Evidenzschicht kommen und ausdrücklich als solche gekennzeichnet bleiben.

Was APNIC festhält – und was „active“ nicht bedeutet

APNIC RDAP führt die Ressource als AS9245, nennt COMPASS-NZ-AP als Namen, NZ als Land und „active“ als Status. Der Datensatz verzeichnet Compass Communications Ltd als Registranten. Zusätzlich erscheinen Network Operations in der technischen und administrativen Kontaktfunktion sowie IRT-COMPASSCOM-NZ als Incident-Response-Eintrag. Diese Angaben schaffen eine strukturierte administrative Zuordnung. Sie zeigen, welche Namen und Rollen im Register mit der Nummernressource verbunden sind.

Der Status „active“ ist dabei leicht zu überschätzen. Im Registerkontext bedeutet er, dass das Objekt den entsprechenden Status trägt. Er besagt nicht, dass alle damit verbundenen Dienste in Betrieb sind, dass jedes Präfix weltweit erreichbar ist oder dass ein bestimmter Zugang gerade funktioniert. Er bestätigt weder die Güte von Routing-Entscheidungen noch die Leistungsfähigkeit einer Infrastruktur. Vor allem ist „active“ kein Synonym für Verfügbarkeit, SLA-Erfüllung, Redundanz oder kontinuierliche Kontrolle unter allen Betriebsbedingungen.

Ebenso wenig lässt sich aus dem Status auf einen Lizenzumfang schließen. Ein Nummernressourcenregister dokumentiert keine vollständige regulatorische Stellung eines Telekommunikationsunternehmens. Es erklärt auch nicht, welche Produkte in welcher Region angeboten werden dürfen, welche Verträge bestehen oder wem Anlagen wirtschaftlich gehören. Solche Aussagen würden den Zweck des Datensatzes überschreiten. Die belastbare Aussage bleibt enger: APNIC bindet AS9245 administrativ an Compass Communications Ltd und führt das Objekt als aktiv.

Die Kontaktbezeichnungen verdienen dieselbe Disziplin. „Network Operations“ bezeichnet im Datensatz eine technische und administrative Funktion. Daraus folgt nicht, wie groß ein Betriebsteam ist, wie es organisiert ist, welche Reaktionszeiten gelten oder welche Systeme überwacht werden. IRT-COMPASSCOM-NZ zeigt, dass ein Incident-Response-Eintrag zugeordnet ist. Das ist weder ein Beleg für konkrete Sicherheitsvorfälle noch ein Audit der Sicherheitsfähigkeit. Kontaktstrukturen und tatsächliche Betriebsleistung sind verschiedene Kategorien.

Diese Grenzen mindern den Nutzen von APNIC nicht. Im Gegenteil: Ein Register ist besonders wertvoll, wenn seine Aussage präzise genutzt wird. Für eine Untersuchung von AS9245 liefert APNIC die stärkste direkte Bindung zwischen Nummernressource und registriertem Unternehmen. Es verhindert, dass Routing-Beobachtungen ohne klaren Betreiberbezug im Raum stehen. Zugleich schützt die enge Lesart davor, administrative Metadaten zu einem Ersatz für technische Messung oder rechtliche Prüfung zu machen.

Die administrative Ebene beantwortet somit die Frage „Welche Identität ist bei dieser Nummernressource verzeichnet?“. Sie beantwortet nicht „Wie gut funktioniert der Dienst?“, „Welche Route nimmt der Verkehr?“, „Welche Anlage trägt einen Anschluss?“ oder „Welche Ausfallvorsorge greift?“. Erst wenn diese Fragen getrennt bleiben, kann der öffentliche Datenbestand sinnvoll zusammengesetzt werden.

Der beobachtete Routing-Zustand am 3. August 2026

RIPEstat markierte AS9245 bei der erfassten Abfrage am 3. August 2026 um 00:00 UTC als angekündigt. Das ist eine technische Beobachtung mit eindeutigem Zeitpunkt. Sie bedeutet, dass das Autonome System in den verwendeten Routing-Daten als angekündigt erschien. Die Zeitbindung ist entscheidend, denn BGP ist ein laufendes System. Routen können sich ändern, Beobachtungspunkte können andere Sichten haben und eine spätere Abfrage kann einen anderen Zustand zeigen.

Der Routing-Status fasste zwölf IPv4-Präfixe mit insgesamt 25.600 IPv4-Adressen zusammen. Für IPv6 wurde ein Präfix ausgewiesen, dessen Größe 65.536 /48-Äquivalenten entspricht. Damit ist für die erfasste Beobachtung ein Dual-Stack-Fußabdruck sichtbar: AS9245 erschien sowohl als Ursprung von IPv4- als auch von IPv6-Routen. „Dual Stack“ beschreibt in diesem Zusammenhang die gleichzeitige Präsenz beider Adressfamilien in den Routing-Daten, nicht die Erfahrung eines beliebigen Endnutzers.

Die Angabe von 25.600 IPv4-Adressen ist eine Zusammenfassung des angekündigten IPv4-Raums in dieser Antwort. Sie sagt nichts darüber, wie viele Adressen tatsächlich vergeben, genutzt oder aus Kundennetzen erreichbar waren. Ebenso darf die IPv6-Größe nicht mit der Zahl angeschlossener Kunden, aktiver Geräte oder angebotener Anschlüsse gleichgesetzt werden. Adressraum ist eine Nummernressource; seine beobachtete Ankündigung und seine konkrete Nutzung sind unterschiedliche Tatsachen.

RIPEstat meldete außerdem acht beobachtete Nachbarn. Auch dieser Wert braucht einen klaren Rahmen. Beobachtete BGP-Nachbarschaften können Hinweise auf den routingseitigen Kontext eines Autonomen Systems geben. Sie beweisen jedoch keine bezahlte Transitbeziehung, keine aktive private Peering-Sitzung und keine bestimmte Vertragsform. Sie zeigen auch nicht automatisch, über welche Verbindung realer Kundenverkehr läuft oder welche Nachbarschaft im Fehlerfall als Ersatzpfad dient.

Als zuerst beobachtete Route wird 203.98.24.0/24 mit dem Zeitpunkt 18. August 2000 um 08:00 UTC genannt. Diese Angabe bezieht sich auf die in der Antwort dargestellte Beobachtungsgeschichte. Sie ist kein Beweis dafür, dass die Route seit diesem Zeitpunkt ohne Unterbrechung sichtbar war. Zwischen „erstmals in den verfügbaren Daten beobachtet“ und „seitdem kontinuierlich betrieben“ liegt ein großer methodischer Unterschied.

Die jüngste Route in der erfassten Antwort ist 202.90.56.0/21 zum Abfragezeitpunkt am 3. August 2026 um 00:00 UTC. Auch hier darf „jüngste“ nur innerhalb der Antwort verstanden werden. Daraus folgt weder, dass der Präfixraum neu geschaffen wurde, noch dass eine bestimmte Dienstmigration stattfand. Die Angabe ordnet lediglich eine Route zeitlich in die verwendete Datensicht ein.

Die Kombination aus angekündigtem Status, Präfixanzahl, Adressraum, Nachbarn und Zeitmarken bietet dennoch eine aussagekräftige technische Momentaufnahme. Sie zeigt, dass AS9245 in der erfassten öffentlichen Routing-Sicht nicht nur als administratives Objekt existierte. Für den festgelegten Zeitpunkt wurden tatsächlich Routen mit diesem Ursprung beobachtet. Genau dort liegt die Stärke der Routing-Evidenz: Sie ergänzt das Register durch einen sichtbaren Betriebszustand, ohne daraus eine umfassende Dienstbewertung zu machen.

Dreizehn beobachtete Präfixe und ihre richtige Lesart

Die begrenzte Abfrage der angekündigten Präfixe deckte den Zeitraum vom 20. Juli bis zum 3. August 2026 ab und enthielt genau 13 Einträge. Der einzige IPv6-Eintrag war 2405:8400::/32. Hinzu kamen zwölf IPv4-Präfixe: 202.90.47.0/24, 202.174.6.0/23, 117.104.180.0/22, 160.238.80.0/22, 202.90.56.0/21, 117.104.176.0/22, 175.176.216.0/22, 103.211.120.0/22, 202.36.121.0/24, 182.48.128.0/19, 203.152.96.0/19 und 103.9.216.0/22.

Diese Liste ist die konkreteste Darstellung des beobachteten Routing-Fußabdrucks. Sie macht sichtbar, welche Präfixe in der zeitlich begrenzten Antwort AS9245 zugeordnet waren. Die Präfixlängen reichen bei IPv4 von /24 und /23 über mehrere /22-Blöcke und ein /21 bis zu zwei /19-Blöcken. Das IPv6-Aggregat besitzt die Länge /32. Die unterschiedlichen Größen beschreiben den Umfang der jeweiligen Adressblöcke, nicht ihre Auslastung oder kommerzielle Bedeutung.

Zwei /24-Präfixe stehen in der Liste: 202.90.47.0/24 und 202.36.121.0/24. Der /23-Block ist 202.174.6.0/23. Fünf /22-Einträge sind 117.104.180.0/22, 160.238.80.0/22, 117.104.176.0/22, 175.176.216.0/22, 103.211.120.0/22 und zusätzlich 103.9.216.0/22, womit es insgesamt sechs /22-Einträge sind. Dazu kommen 202.90.56.0/21, 182.48.128.0/19 und 203.152.96.0/19. Zusammen ergeben die zwölf IPv4-Präfixe die in der Routing-Zusammenfassung genannten 25.600 Adressen.

Die Aufzählung erlaubt keine Zuordnung zu einzelnen Produkten. Es wäre unzulässig, etwa einen bestimmten Block mit Glasfaser, VDSL, ADSL, ländlicher Konnektivität, Sprachdiensten, Cloud PBX, Managed Services oder einem Rechenzentrumsangebot zu verbinden. Dafür fehlen produktbezogene Belege. Ein Präfix kann in einer Routing-Beobachtung sichtbar sein, ohne dass aus dieser Beobachtung hervorgeht, welche Systeme oder Kundenadressen darin liegen.

Auch geografische Schlüsse bleiben begrenzt. Die Ressource ist in einem APNIC-Kontext mit NZ verbunden, und Compass beschreibt ein landesweites Netz. Daraus lässt sich aber nicht der physische Weg eines einzelnen Präfixes rekonstruieren. Die Routing-Liste enthält keine Leitungspläne, keine Standorte von Routern, keine Kabeltrassen und keine belastbare Zuordnung zu Auckland oder Hamilton. Ein BGP-Präfix ist kein Lageplan.

Die Liste beweist ferner nicht die Autorisierung jeder Route. Ob eine Ankündigung durch eine bestimmte RPKI-ROA gedeckt war, ist in den festgehaltenen Tatsachen nicht beantwortet. Deshalb darf die Sichtbarkeit nicht mit RPKI-Gültigkeit oder formaler Routing-Korrektheit gleichgesetzt werden. Ein beobachteter Ursprung ist zunächst genau das: ein Ursprung, den die verwendeten Beobachtungspunkte in ihren Routing-Daten sahen.

Dass alle 13 Präfixe innerhalb der begrenzten Antwort erscheinen, liefert auch keinen Nachweis universeller oder ununterbrochener Erreichbarkeit. Ein Präfix kann von den beobachteten Peers gesehen werden, während einzelne Netze, Pfade oder Endpunkte andere Bedingungen aufweisen. BGP-Sichtbarkeit sagt zudem nichts darüber, ob Anwendungen antworten, ob Namensauflösung funktioniert oder ob ein Zugang für einen bestimmten Kunden nutzbar ist.

Die Präfixliste besitzt dennoch hohe praktische Aussagekraft. Sie schafft eine überprüfbare Grundlage für die Größenordnung und die Adressfamilien des beobachteten Fußabdrucks. Anstelle einer vagen Aussage, Compass sei „im Internet präsent“, lässt sich konkret sagen, dass RIPEstat im festgelegten Zeitraum zwölf IPv4-Präfixe und ein IPv6-Präfix mit Ursprung AS9245 auswies. Die Genauigkeit entsteht nicht durch größere Behauptungen, sondern durch das Festhalten der Grenzen.

RIS-Sichtbarkeit: starke Stichprobe, keine universelle Garantie

Für IPv4 meldete der Routing-Status Sichtbarkeit bei 329 von 329 aufgeführten RIS-Peers. Für IPv6 waren es 321 von 321. Innerhalb dieser Stichprobe ist das ein starkes Ergebnis: Jeder in der jeweiligen Antwort berücksichtigte Peer sah den Ursprung. Es wäre jedoch methodisch falsch, die Nenner zu entfernen und nur von „vollständiger Sichtbarkeit“ zu sprechen. Vollständig war die Sicht innerhalb der genannten Menge, nicht zwangsläufig aus jedem Netz und an jedem Ort.

Routing-Kollektoren erhalten Informationen von bestimmten Peers. Diese Peers bieten einen breiten Blick auf das globale Routing, stellen aber nicht jede denkbare Verbindung, jedes autonome System oder jeden Nutzerpfad dar. Eine Beobachtung bei 329 von 329 IPv4-Peers sagt daher mehr aus als eine einzelne Sicht, doch sie bleibt eine definierte Beobachtungsmenge. Dasselbe gilt für die 321 von 321 IPv6-Peers.

Die Unterscheidung zwischen Sichtbarkeit und Erreichbarkeit ist besonders wichtig. Ein Peer kann eine Route sehen, während Datenverkehr aus einem bestimmten Netz aufgrund anderer Faktoren dennoch nicht erfolgreich am Ziel ankommt. Routing-Policy, Rückwege, Filter, lokale Störungen, Namensauflösung, Anwendungszustand und Zugangstechnik können das Ergebnis beeinflussen. Die erfassten Daten messen diese Ebenen nicht.

Ebenso wenig erfasst der Nenner die Qualität der Pfade. Aus der Sichtbarkeit geht nicht hervor, welche Latenz, welcher Paketverlust oder welche verfügbare Kapazität auf einem Pfad bestand. Die Daten enthalten auch keinen Leistungstest für Endkundenanschlüsse. Sie zeigen weder Spitzenlasten noch Überbuchung noch die Reaktion auf den Ausfall einer Verbindung. Deshalb kann die breite RIS-Sicht nicht als Qualitätsnote für Compass-Produkte verwendet werden.

Die IPv4- und IPv6-Nenner unterscheiden sich. Das ist kein Widerspruch, sondern spiegelt die jeweils erfassten Peer-Mengen wider. Ein Vergleich darf nicht so formuliert werden, als sei IPv6 wegen der kleineren absoluten Zahl weniger sichtbar gewesen. Innerhalb der jeweiligen Stichprobe lagen beide Werte bei allen aufgeführten Peers. Entscheidend ist, dass die Grundgesamtheiten getrennt bleiben.

Auch zeitlich ist die Aussage begrenzt. Die Sichtbarkeit gehört zur erfassten Antwort am 3. August 2026 um 00:00 UTC. Sie beweist keinen identischen Zustand in jeder Minute des vorherigen oder folgenden Zeitraums. Wer eine Aussage über langfristige Stabilität treffen wollte, müsste eine geeignete Zeitreihe untersuchen und zusätzlich definieren, welche Veränderungen als relevant gelten. Eine einzelne Abfrage kann diesen Nachweis nicht ersetzen.

Als Betriebssignal ist die Beobachtung gleichwohl substanziell. Sie zeigt, dass der Dual-Stack-Ursprung AS9245 in allen aufgeführten IPv4- und IPv6-Sichten vorhanden war. Gemeinsam mit der Präfixliste ergibt sich ein kohärentes Bild öffentlicher Routing-Präsenz. Der sachliche Schluss lautet jedoch nicht „Compass war überall erreichbar“, sondern „AS9245 war zum angegebenen Zeitpunkt in allen aufgeführten RIS-Peer-Sichten beider Adressfamilien sichtbar“.

Diese Formulierung schützt vor zwei entgegengesetzten Fehlern. Sie spielt die Daten nicht herunter, denn die vollständige Sicht innerhalb der Stichproben ist relevant. Gleichzeitig verwandelt sie die Daten nicht in eine universelle Garantie. Gute Infrastrukturanalyse besteht häufig darin, einen starken Messwert genau dort enden zu lassen, wo sein Messbereich endet.

PeeringDB beschreibt eine Betreiberposition, keine gemessene Topologie

Das PeeringDB-Netzwerkprofil mit der Kennung 6849 nennt Compass Communications Ltd und ordnet das Profil AS9245 zu. Als Netzwerktyp ist Cable/DSL/ISP angegeben, als geografischer Geltungsbereich Asia Pacific. Die allgemeine Policy wird als offen beschrieben. Außerdem deklariert das Profil 50 IPv4- und 50 IPv6-Präfixe. Diese Felder liefern nützlichen Kontext dafür, wie der Betreiber sein Netzwerk gegenüber der Interconnection-Gemeinschaft beschreibt.

Der entscheidende Zusatz lautet „betreibergepflegt“. PeeringDB ist hier kein unabhängiger Messsensor. Die Angaben stammen aus einem Profil, das der Betreiber verwaltet. Das macht sie nicht wertlos, aber es bestimmt die Art der Evidenz. Ein deklarierter Netzwerktyp beschreibt die Einordnung des Angebots. Er beweist nicht, wie viel Verkehr über eine bestimmte Zugangstechnologie läuft oder wie viele Anschlüsse bestehen.

Auch eine offene allgemeine Policy darf nicht mit einer aktiven Sitzung verwechselt werden. „Open“ beschreibt eine erklärte Grundhaltung gegenüber Peering. Es sagt nicht, dass jeder Interessent akzeptiert wird, dass an jedem Standort eine Sitzung besteht oder dass ein bestimmtes Netz aktuell Daten mit AS9245 austauscht. Technische, wirtschaftliche und betriebliche Bedingungen können zusätzlich gelten, ohne dass sie aus dem einzelnen Feld hervorgehen.

Die jeweils 50 deklarierten IPv4- und IPv6-Präfixe lassen sich nicht direkt mit den zwölf IPv4-Präfixen und dem einen IPv6-Präfix der RIPEstat-Beobachtung verrechnen. Die Zahlen beantworten unterschiedliche Fragen und können unterschiedlichen Definitionen, Pflegezeitpunkten oder Zählweisen folgen. RIPEstat berichtet die in einer datierten Routing-Sicht beobachteten Präfixe. PeeringDB gibt eine vom Betreiber eingetragene Profilangabe wieder.

Gerade die Abweichung zeigt, warum Quellenrollen nicht vermischt werden dürfen. Wäre die PeeringDB-Zahl eine unabhängige Routing-Messung, müsste eine Differenz technisch untersucht werden. Als Betreiberdeklaration ist sie zunächst eine Aussage über das Profil, nicht über jeden aktuell sichtbaren BGP-Eintrag. Ohne zusätzliche Daten wäre es spekulativ, aus dem Unterschied auf Fehler, verborgene Routen, mangelnde Pflege oder betriebliche Veränderungen zu schließen.

PeeringDB beweist auch keine physische Topologie. Aus Netzwerktyp, Geltungsbereich und Policy folgt nicht, wo Router stehen, welche Leitungen benutzt werden oder wie Wege abgesichert sind. Selbst Informationen über Interconnection-Orte oder Teilnehmerbeziehungen würden nicht automatisch zeigen, welche Sitzung zu einem bestimmten Zeitpunkt aktiv war und welchen Verkehr sie trug. Die hier festgehaltenen Profilfelder gehen noch weniger weit.

Trotz dieser Grenzen ergänzt PeeringDB die anderen Ebenen sinnvoll. APNIC zeigt die administrative Ressourcenzuordnung. RIPEstat zeigt die beobachtete BGP-Präsenz. PeeringDB zeigt, wie Compass Communications Ltd AS9245 im Interconnection-Kontext beschreibt. Zusammen entsteht ein differenziertes Bild, solange keine Ebene die Aufgaben der anderen übernimmt.

Für die Bewertung von Peering und Transit ist diese Quellenhygiene besonders wichtig. Öffentliche Profile können Ausgangspunkte für weitere Prüfung sein. Sie dürfen jedoch nicht als Beweis bezahlter Transitverträge, laufender Peering-Sitzungen oder tatsächlicher Verkehrsverteilung dienen. Der nachweisbare Kern bleibt: Compass Communications Ltd führt ein PeeringDB-Profil für AS9245 mit den genannten Betreiberangaben.

Vom Routing-Fußabdruck zum Leistungsangebot ist es ein weiter Weg

Compass erklärt auf der eigenen Unternehmensseite, 1995 begonnen zu haben, in neuseeländischem Besitz und unabhängig zu sein sowie ein landesweites Netz zu betreiben. Das Unternehmen nennt Glasfaser, VDSL, ADSL, ländliche Konnektivität, Sprachdienste, Cloud PBX, Managed Services und Rechenzentrumsprodukte. Diese Selbstdarstellung beschreibt eine breite kommerzielle Oberfläche, die über reines BGP-Routing hinausgeht.

Die Angaben erklären, warum AS9245 für die Beurteilung des Unternehmens relevant sein kann. Ein Anbieter von Internet- und Telekommunikationsleistungen benötigt betriebliche Netzidentitäten und öffentliche Routing-Beziehungen. Dennoch darf der Zusammenhang nicht umgedreht werden: Die Sichtbarkeit eines AS beweist nicht die Eigenschaften jedes angebotenen Produkts. Zwischen einem angekündigten Präfix und einem funktionierenden Endkundendienst liegen zahlreiche technische und organisatorische Schichten.

Bei einem Glasfaser- oder DSL-Zugang gehören dazu beispielsweise die lokale Zugangsstrecke, Geräte, Authentisierung, Adresszuweisung, interne Transportwege, Namensauflösung und die Erreichbarkeit externer Ziele. Die erfassten Routing-Daten messen diese Kette nicht. Sie weisen weder Geschwindigkeiten noch Verfügbarkeit aus. Deshalb lässt sich aus dem Dual-Stack-Fußabdruck nicht ableiten, ob ein konkreter Anschluss IPv6 erhält oder welche Leistung dort verfügbar ist.

Dasselbe gilt für ländliche Konnektivität. Eine unternehmenseigene Produktbeschreibung kann belegen, dass Compass eine solche Leistung anbietet. Sie beweist jedoch keine garantierte geografische Abdeckung und keine bestimmte Zugangstechnik an einem Ort. Der APNIC-Ländercode und der PeeringDB-Geltungsbereich schließen diese Lücke nicht. Für belastbare Aussagen zur lokalen Verfügbarkeit wären produkt- und ortsspezifische Informationen erforderlich.

Sprachdienste und Cloud PBX hängen zwar von Netzinfrastruktur ab, sind aber keine unmittelbare Folge eines sichtbaren BGP-Ursprungs. Ein AS kann Routing-Präsenz besitzen, ohne dass daraus der Zustand einer Sprachplattform hervorgeht. Ebenso wenig lässt sich aus der Präfixliste erkennen, welche Anwendungen in welchem Block betrieben werden. Jede direkte Zuordnung wäre eine unbelegte Annahme.

Managed Services umfassen potenziell noch mehr Ebenen, doch die festgehaltenen Tatsachen erlauben keine Detailaussage über deren Umfang, Vertragsbedingungen oder Betriebsmodell. Die sichere Formulierung bleibt, dass Compass diese Kategorie in seinem Angebot nennt. Weder Kundenanzahl noch Umsatz, Marktanteil oder konkrete Service-Level lassen sich daraus ableiten.

Die Rechenzentrumsseite nennt Einrichtungen in Auckland und Hamilton, Interkonnektionsbeziehungen und ein SLA von 99,99 Prozent. Diese Angaben stammen vom Betreiber und beziehen sich auf sein Angebot. Sie sind keine unabhängige Bestätigung rechtlichen Eigentums an Gebäuden oder Anlagen. Auch zeigen sie nicht, dass ein bestimmtes AS9245-Präfix an einem dieser Standorte verwendet wird.

Die Nennung von Interkonnektionsbeziehungen kann kommerziellen und technischen Kontext liefern, ist aber kein Sitzungsnachweis. Eine Beziehung kann verschiedene Formen haben, und eine Webseite zeigt nicht zwingend den Echtzeitstatus jeder Verbindung. Ohne aktuelle Mess- oder Konfigurationsdaten darf daraus weder eine konkrete Topologie noch ein bestimmter Verkehrsweg konstruiert werden.

Auch das beworbene SLA muss als Betreiberangabe behandelt werden. Ein Wert von 99,99 Prozent beschreibt eine zugesagte oder beworbene Leistung im Angebotskontext, nicht die gemessene historische Verfügbarkeit. Welche Bedingungen, Ausschlüsse, Messmethoden oder betroffenen Produkte gelten, ist aus den festgehaltenen Tatsachen nicht abzuleiten. Ein SLA ist zudem nicht automatisch ein Nachweis erfolgreicher Redundanz.

Die Betreiberseiten und die Routing-Daten ergänzen einander daher nur, wenn ihre Grenzen sichtbar bleiben. Die Unternehmensseiten erklären, was Compass nach eigener Aussage anbietet. RIPEstat zeigt, was in der erfassten Routing-Sicht für AS9245 beobachtet wurde. Keine der beiden Ebenen beweist allein, wie ein konkreter Dienst technisch umgesetzt wird.

Warum Dual Stack kein Resilienznachweis ist

Dual-Stack-Präsenz ist betrieblich relevant. Ein sichtbares IPv4- und IPv6-Origin zeigt, dass beide Adressfamilien im erfassten Routing-Zustand vertreten waren. Für ein Netzwerk, das sich im asiatisch-pazifischen Raum als Cable/DSL/ISP einordnet, ist diese Beobachtung aussagekräftiger als ein reiner Registereintrag. Sie zeigt laufendes Routing statt ausschließlich administrativer Metadaten.

Resilienz ist jedoch eine andere Eigenschaft. Sie betrifft die Fähigkeit eines Dienstes oder Systems, Störungen zu verkraften, alternative Wege zu nutzen und ein erwartetes Leistungsniveau aufrechtzuerhalten oder wiederherzustellen. Um sie nachzuweisen, wären Informationen über Abhängigkeiten, Redundanz, Fehlerdomänen, Umschaltmechanismen, Tests und reale Betriebsereignisse nötig. Die vorhandenen Daten enthalten diese Nachweise nicht.

Zwei Adressfamilien sind keine zwei unabhängigen physischen Wege. IPv4 und IPv6 können gemeinsame Router, Leitungen, Standorte, Stromversorgung oder betriebliche Systeme nutzen. Umgekehrt können sie unterschiedlich geführt werden. Ohne Topologiedaten ist keine dieser Varianten bewiesen. Die bloße Koexistenz beider Protokollfamilien sagt daher nichts über gemeinsame oder getrennte Ausfallrisiken.

Auch mehrere beobachtete Nachbarn sind nicht automatisch Redundanz. Die acht von RIPEstat erfassten Nachbarn können auf einen vielfältigen Routing-Kontext hindeuten, doch ihre Rollen und physischen Abhängigkeiten sind nicht festgelegt. Mehrere BGP-Nachbarschaften können über gemeinsame Infrastruktur laufen. Außerdem zeigt eine beobachtete Nachbarschaft nicht, ob sie im Fehlerfall ausreichend Kapazität trägt oder nach der beabsichtigten Policy übernimmt.

Breite RIS-Sichtbarkeit beweist ebenfalls keine erfolgreiche Umschaltung. Wenn 329 von 329 IPv4-Peers und 321 von 321 IPv6-Peers den Ursprung sehen, ist die Route in den jeweiligen Stichproben breit sichtbar. Ob eine alternative Verbindung nach einem Ausfall schnell und korrekt aktiviert würde, wurde damit nicht getestet. Sichtbarkeit im Normalzustand und Verhalten unter Störung sind getrennte Fragen.

Die Präfixanzahl darf nicht als Zahl unabhängiger Dienste oder Pfade gelesen werden. Zwölf IPv4-Präfixe und ein IPv6-Präfix können organisatorisch, technisch und physisch auf vielfältige Weise genutzt werden. Eine größere Zahl von Präfixen bedeutet nicht automatisch höhere Ausfallsicherheit. Sie kann auch aus Adresshistorie, Aggregation, Policy oder anderen Faktoren resultieren, die in den erfassten Daten nicht erklärt werden.

Ein beworbenes SLA von 99,99 Prozent schließt die Evidenzlücke ebenfalls nicht. Ein SLA ist eine kommerzielle Aussage mit definiertem Anwendungsbereich. Ohne Messdaten lässt sich nicht prüfen, ob der Wert erreicht wurde. Ohne Vertragsdetails lässt sich nicht bestimmen, welche Dienste, Standorte oder Ereignisse einbezogen sind. Und ohne technische Informationen bleibt offen, welche Architektur das Leistungsziel stützen soll.

Eine Statusseite liefert nur eine Momentaufnahme. Sie kann anzeigen, wie der Betreiber den Zustand seiner Dienste zu einem Zeitpunkt meldet. Selbst eine vollständig grüne Anzeige beweist nicht, dass es zuvor keine Störungen gab oder dass ein nicht dargestellter Fehler ausgeschlossen ist. Sie misst auch nicht notwendigerweise die Erfahrung jedes Kunden. Für historische Resilienz wäre eine einzelne Aufnahme ungeeignet.

Die korrekte Schlussfolgerung ist deshalb positiv, aber schmal: AS9245 besaß in der erfassten RIPEstat-Sicht einen sichtbaren Dual-Stack-Routing-Fußabdruck. Diese Aussage ist technisch konkret und durch Zahlen gestützt. Sie darf nicht in die weitergehende Behauptung verwandelt werden, Compass-Dienste seien dadurch nachweislich resilient.

Generische redaktionelle Illustration zur Grenze zwischen Dual-Stack-Routingsicht und Dienstevidenz; sie zeigt weder Compass-Infrastruktur oder -Topologie noch Zugangsqualität, Kapazität, Kundendienst oder gemessene Resilienz.