AS45637 macht UniFones Dual-Stack-Routing sichtbar – nicht jedoch die Belastbarkeit des Zugangsnetzes

Zusammenfassung

• APNIC RDAP führt AS45637 mit dem Namen UNIFONENETWORKS-AS-AP, dem Ländercode NZ, dem Status „active“ und UniFone New Zealand Ltd als exakter registrierter Organisation.
• Der Status „active“ beschreibt den Zustand des Registerobjekts. Er beweist weder, dass Routen gegenwärtig sichtbar sind, noch dass Dienste, Standorte oder Ausfallschutz funktionieren.
• In der RIPEstat-Erfassung vom 2. August 2026 um 16:00 UTC war AS45637 als angekündigt verzeichnet. Alle Aussagen zum Routing beziehen sich auf diesen datierten Beobachtungszeitpunkt.
• Die Erfassung weist drei IPv4-Präfixe, zwei IPv6-Präfixe, 6.144 IPv4-Adressen, 65.537 IPv6-/48-Äquivalente und 17 beobachtete Nachbarn aus.
• Innerhalb der erfassten RIS-Stichprobe war das Netz bei 328 von 328 IPv4-Full-Feed-Peers und 321 von 321 IPv6-Full-Feed-Peers sichtbar. Diese vollständige Sichtbarkeit innerhalb der Stichprobe ist keine Aussage über universelle Erreichbarkeit.
• Die fünf sichtbaren Präfixe machen eine konkrete Dual-Stack-Präsenz nachvollziehbar. Sie belegen jedoch weder Verkehrsmenge und Kapazität noch erfolgreiche Ausweichschaltungen, Verfügbarkeit oder Kundenerfahrung.
• Der von einem Betreiber gepflegte PeeringDB-Eintrag ordnet UniFone New Zealand AS45637 und APNIC::AS-UNIFONENZ zu. Angaben zu Netztyp, Reichweite, IPv6, Unicast und selektivem Peering bleiben Betreiberdeklarationen.
• UniFone beschreibt sich als in Otago ansässigen Anbieter mit Standorten in Dunedin und Balclutha, mehr als 100 Funkstandorten, einem weite Teile Otagos abdeckenden WiFi-Netz sowie Glasfaser- und Festfunkzugängen. Diese Angaben stammen vom Betreiber und sind keine unabhängige Abdeckungsmessung.
• Die veröffentlichte Abdeckungskarte ist laut UniFone nur indikativ und verändert sich mit dem Ausbau von Türmen und Infrastruktur. Eine Kartendarstellung kann deshalb keine Verfügbarkeit an einer bestimmten Adresse garantieren.
• UniFone warnt selbst, dass Breitbanddienste bei einem Ausfall der Netzstromversorgung am Teilnehmerstandort möglicherweise nicht funktionieren. Damit liegt eine wesentliche Kontinuitätsgrenze außerhalb dessen, was ASN- und BGP-Daten zeigen können.
• Angaben über Verbindungen zu Rechenzentren in Dunedin, Christchurch, Auckland und Sydney, Übergaben an andere Anbieter sowie vollständige Redundanz der neuseeländischen Verbindungen sind Aussagen des Betreibers. Die verfügbaren öffentlichen Beobachtungen messen weder die genannten Pfade noch den tatsächlichen Failover-Erfolg.
• Die belastbarste Lesart trennt drei Ebenen: die administrative Zuordnung von Nummernressourcen, die datierte Sichtbarkeit laufender Routen und die davon verschiedene Funktionsfähigkeit des regionalen Zugangs- und Übergabenetzes.

Ein ASN als überprüfbarer Ausgangspunkt

Ein autonomes System ist zunächst eine öffentliche Routing-Identität. AS45637 bietet einen stabilen Bezugspunkt, an dem mehrere unterschiedliche Arten von Nachweisen zusammengeführt werden können, ohne ihre jeweilige Aussagekraft zu vermischen. Der APNIC-Eintrag beantwortet die administrative Frage, wem die Nummernressource zugeordnet ist. RIPEstat zeigt, ob und in welcher Form das autonome System zu einem bestimmten Zeitpunkt im beobachteten BGP sichtbar war. PeeringDB ergänzt eine vom Betreiber gepflegte Beschreibung der Netzidentität.

Die eigenen Seiten von UniFone verschieben den Blick schließlich vom öffentlichen Routing auf die regionale Zugangsebene.

Für UniFone ist die öffentlich beobachtbare Kette ungewöhnlich konkret. Der Registereintrag nennt die exakte juristische Bezeichnung UniFone New Zealand Ltd. Der Netzname UNIFONENETWORKS-AS-AP und AS45637 schaffen eine eindeutige administrative Bindung. RIPEstat zeigt in der datierten Erfassung nicht nur einen allgemeinen Status, sondern fünf konkrete Präfixe über IPv4 und IPv6. PeeringDB verbindet dieselbe ASN mit UniFone New Zealand und dem Routing-Policy-Bezeichner APNIC::AS-UNIFONENZ. Damit lässt sich die Netzidentität aus mehreren Perspektiven nachvollziehen.

APNIC als Register: exakte Zuordnung mit begrenzter Reichweite

APNIC RDAP führt AS45637 unter dem Namen UNIFONENETWORKS-AS-AP. Als Ländercode ist NZ eingetragen, der Status lautet „active“, und als registrierte Organisation erscheint exakt UniFone New Zealand Ltd. Zusätzlich trägt der Registerbestand eine übereinstimmende Identität für die Netzwerkadministration sowie IRT-UNIFONE-NZ-LTD für die Reaktion auf Vorfälle. Zusammen bilden diese Felder eine starke administrative Verbindung zwischen der Unternehmensidentität und der autonomen Systemnummer.

Ein Register führt jedoch Aufzeichnungen; es misst keinen laufenden Dienst. Der Status „active“ bedeutet deshalb nicht, dass jede zugehörige Route aktuell sichtbar ist. Er bestätigt auch keinen Internetzugang, keine Funkabdeckung und keine funktionierende Übergabe. Aus ihm lassen sich weder Kundenzahl noch Marktanteil, Verkehr oder Kapazität ableiten. Ebenso wenig belegt er Standorte, Eigentum an Kabeln, Glasfaserstrecken oder Rechenzentren. Die administrative Präzision des Eintrags darf nicht in eine technische Reichweite umgedeutet werden, die das Register nicht besitzt.

Auch der Ländercode NZ ist eine Registereigenschaft. Er ordnet das Objekt in seinem administrativen Kontext ein, zeichnet aber keine physische Topologie. Er zeigt nicht, wo Pakete tatsächlich übertragen werden, welche Übergabepunkte genutzt werden oder über welche Wege ein Dienst eine bestimmte Adresse erreicht. Eine geografische oder technische Karte des Netzes kann daraus nicht erstellt werden.

Ähnlich verhält es sich mit der Netzwerkadministrations- und Incident-Response-Identität. Dass die Einträge auf UniFone verweisen, verbessert die Konsistenz der Zuordnung. Es beweist jedoch nicht, dass Kontaktdaten zu einem bestimmten Zeitpunkt erfolgreich geprüft wurden oder dass ein konkreter Vorfall nach einem bestimmten Verfahren bearbeitet würde. Die Rollen sind Teile des Registerbestands, keine Leistungsmessung.

Die datierte Routingaufnahme von RIPEstat

In der RIPEstat-Erfassung für den 2. August 2026 um 16:00 UTC wurde AS45637 als announced=true ausgewiesen. Alle daraus folgenden Aussagen sind Momentaufnahmen dieses festgehaltenen Zeitpunkts. Sie beschreiben, was die verwendeten Routingdaten damals erkennen ließen. Sie sollten weder zeitlich unbegrenzt fortgeschrieben noch als Zusicherung eines dauerhaften Zustands gelesen werden.

Die Routingstatusdaten weisen drei IPv4-Präfixe und zwei IPv6-Präfixe aus. Zusammen entsprechen die IPv4-Ankündigungen 6.144 Adressen. Für IPv6 nennt die Erfassung 65.537 /48-Äquivalente. Außerdem verzeichnet sie 17 beobachtete Nachbarn. Diese Werte geben dem abstrakten Status „angekündigt“ eine konkrete Form: AS45637 war nicht lediglich als Nummer vorhanden, sondern erschien mit einem bestimmten Satz sichtbarer Netzressourcen in beiden Internetprotokollfamilien.

Die IPv4-Präfixe waren 182.54.160.0/20, 123.253.56.0/22 und 103.91.172.0/22. Für IPv6 wurden 2402:ff00::/32 und 2001:df5:b000::/48 erfasst. Die fünf Präfixe sind der deutlichste öffentliche Nachweis der Dual-Stack-Routing-Präsenz von UniFone zu diesem Zeitpunkt. Sie zeigen, dass sowohl IPv4- als auch IPv6-Ressourcen unter AS45637 in der datierten Beobachtung sichtbar waren.

Die Zahlen beschreiben Routingressourcen, nicht deren Nutzung. Aus 6.144 IPv4-Adressen folgt nicht, wie viele davon belegt waren, welchen Diensten sie dienten oder wie viel Verkehr über sie floss. Das Maß von 65.537 IPv6-/48-Äquivalenten ist ebenfalls eine Adressraumdarstellung und keine Zählung aktiver Anschlüsse. Ein Vergleich beider Werte als unmittelbares Maß für Netzgröße oder Kundennutzung wäre irreführend, weil IPv4 und IPv6 unterschiedlich strukturiert und adressiert werden.

Auch die 17 beobachteten Nachbarn verlangen eine vorsichtige Lesart. Ein in Routingdaten sichtbarer Nachbar ist kein Beweis für eine bestimmte wirtschaftliche Beziehung. Die Zahl unterscheidet nicht automatisch zwischen bezahltem Transit, Peering oder anderen Formen der Routenausbreitung. Sie sagt nicht, welche Verbindung Verkehr trug, wie viel Kapazität verfügbar war oder ob eine Sitzung zum fraglichen Zeitpunkt für einen bestimmten Dienst genutzt wurde. Ebenso wenig bildet sie die physische Topologie oder Eigentumsverhältnisse an Infrastruktur ab.

RIPEstat nennt als erstes Auftreten den 4. August 2011 um 16:00 UTC und als letztes Auftreten den Beobachtungszeitpunkt am 2. August 2026 um 16:00 UTC. „First seen“ und „last seen“ sind Beschreibungen innerhalb der Routingbeobachtung. Das erste Datum ist weder zwingend ein Gründungsdatum noch der Beginn sämtlicher Dienste. Das letzte Datum bedeutet nicht, dass die Ankündigung danach unverändert weiterbestand. Beide Werte erhalten ihre Bedeutung nur im Rahmen des verwendeten Datensatzes.

Die Aufnahme enthält außerdem besonders starke Stichprobensignale zur Sichtbarkeit. Für IPv4 wurde AS45637 von 328 der 328 erfassten RIS-Full-Feed-Peers gesehen. Für IPv6 waren es 321 von 321. Innerhalb dieser Stichprobe war die Sichtbarkeit damit vollständig. Das ist ein präziser und aussagekräftiger Befund, solange der Nenner erhalten bleibt: vollständig unter den jeweils erfassten Peers, nicht notwendigerweise bei jedem Netz, Router oder Nutzer im Internet.

Diese Unterscheidung zwischen vollständiger Stichprobensichtbarkeit und universeller Erreichbarkeit ist mehr als eine methodische Feinheit. BGP-Sichtbarkeit zeigt, dass Routinginformationen an den erfassten Beobachtungspunkten vorhanden waren. Sie führt keinen Verbindungstest aus, misst keine Paketverluste und prüft keine Anwendung. Sie sagt auch nicht, ob Rückwege funktionierten oder ein lokaler Anschluss Strom hatte. Ein Präfix kann im Kontrollsystem des Routings sichtbar sein, während auf anderen Ebenen Einschränkungen bestehen, die diese Daten nicht erfassen.

Was 328 von 328 und 321 von 321 tatsächlich bedeuten

Bruchzahlen mit identischem Zähler und Nenner wirken auf den ersten Blick absolut. Für AS45637 zeigen 328 von 328 IPv4-Peers und 321 von 321 IPv6-Peers, dass jeder in der jeweiligen RIPEstat-Erfassung berücksichtigte RIS-Full-Feed-Peer die relevante Routingpräsenz sah. Innerhalb der Stichprobe gab es damit keine beobachtete Lücke. Das ist ein klarer Hinweis auf eine breit sichtbare Ankündigung zum festgehaltenen Zeitpunkt.

Die Aussage wird jedoch ungenau, sobald der Nenner verschwindet. „Überall sichtbar“ wäre eine andere Behauptung als „bei allen erfassten RIS-Full-Feed-Peers sichtbar“. Der erste Satz würde eine universelle Reichweite unterstellen; der zweite benennt die tatsächliche Messgrenze. Nur die zweite Form ist durch die Erfassung gedeckt. Die RIS-Peers stellen Beobachtungspunkte dar, nicht die Gesamtheit aller denkbaren Netzpfade und Endpunkte.

Die Werte erlauben dennoch eine wichtige Feststellung: IPv6 war in der erfassten Stichprobe nicht bloß als Betreiberangabe vorhanden. AS45637 erschien mit zwei konkreten IPv6-Präfixen und wurde von allen 321 berücksichtigten IPv6-Peers gesehen. Das schafft einen beobachteten Gegenpol zur PeeringDB-Deklaration, in der IPv6-Unterstützung angegeben wird. Beide Signale stimmen in ihrer Richtung überein, haben aber unterschiedlichen Beweischarakter: PeeringDB ist eine Betreiberangabe, RIPEstat eine datierte Routingbeobachtung.

Fünf Präfixe machen Dual Stack konkret

182.54.160.0/20 ist das größte der drei erfassten IPv4-Präfixe. Hinzu kommen 123.253.56.0/22 und 103.91.172.0/22. Zusammen ergeben sie laut Routingstatus 6.144 IPv4-Adressen. Der Befund beschreibt angekündigten Adressraum. Er sagt nicht, wie die Adressen intern aufgeteilt wurden, welche davon aktiv waren oder welche Zugangsprodukte sie unterstützten.

Auf der IPv6-Seite wurden 2402:ff00::/32 und 2001:df5:b000::/48 erfasst. RIPEstat fasst den sichtbaren IPv6-Raum als 65.537 /48-Äquivalente zusammen. Auch diese Zahl ist eine Routing- und Adressraumgröße. Sie darf nicht als Anzahl von Kunden, Anschlüssen, Standorten oder aktiven Geräten gelesen werden. Ihre Bedeutung liegt darin, die Größenordnung des angekündigten IPv6-Raums in einer einheitlichen Präfixeinheit auszudrücken.

Dass sowohl ein /32 als auch ein /48 sichtbar war, liefert keine Karte der Verwendung. Die Routingdaten zeigen nicht, ob der kleinere Block einem bestimmten Dienst, Ort oder Übergabepunkt diente. Ohne zusätzliche belastbare Nachweise wäre jede solche Zuordnung spekulativ. Präfixe sind auf dieser Ebene Netzressourcen und Routingobjekte, keine Belege für physische Anlagen.

Die fünf Präfixe belegen auch keine universelle Ende-zu-Ende-Erreichbarkeit. Eine Ankündigung kann von den RIS-Beobachtungspunkten gesehen werden, ohne dass jede Adresse im Präfix antwortet. Viele Adressen können absichtlich ungenutzt sein oder Dienste betreiben, die von außen nicht sichtbar sind. Routingpräsenz und Host-Erreichbarkeit sind deshalb verschiedene Aussagen.

Das gilt ebenso für Widerstandsfähigkeit. Zwei Protokollfamilien sind keine zwei unabhängigen Ausfallpfade. IPv4 und IPv6 können gemeinsame Infrastruktur, Stromversorgung oder Übergaben nutzen, doch über eine solche gemeinsame oder getrennte Nutzung liegen keine Messungen vor. Die Dual-Stack-Präsenz erhöht die beobachtbare Protokollbreite, beweist aber keine physische Diversität.

PeeringDB als vom Betreiber gepflegte Netzbeschreibung

Der PeeringDB-Datensatz mit der Netzwerk-ID 16667 nennt UniFone New Zealand und ordnet den Eintrag AS45637 zu. Als IRR-Set ist APNIC::AS-UNIFONENZ angegeben. Der Eintrag verweist außerdem auf den Webauftritt von UniFone und beschreibt das Netz als „Cable/DSL/ISP“ mit Geltungsbereich „Asia Pacific“. IPv6 und Unicast werden als unterstützt ausgewiesen, die Peering-Policy als „Selective“.

Diese Angaben passen zur Identität in APNIC und zur in RIPEstat beobachteten ASN. Insbesondere die Zuordnung von UniFone New Zealand zu AS45637 und APNIC::AS-UNIFONENZ ergänzt die administrative und routingbezogene Kette um eine operative Selbstdarstellung. Der PeeringDB-Eintrag ist damit nützlich, um zu verstehen, wie der Betreiber sein Netz gegenüber der Interconnection-Gemeinschaft beschreibt.

Sein Beweischarakter unterscheidet sich jedoch von einer unabhängigen Messung. PeeringDB-Daten werden vom Betreiber gepflegt. Sie zeigen, welche Eigenschaften und Richtlinien angegeben wurden, nicht ob jede Angabe extern geprüft wurde. Der Netzwerktyp ist eine Klassifizierung, kein vollständiges Produktinventar. Der regionale Geltungsbereich beschreibt die eingeordnete Reichweite, nicht universelle Abdeckung oder physische Präsenz an jedem Ort im asiatisch-pazifischen Raum.

Die IPv6-Angabe gewinnt dadurch an Gewicht, dass RIPEstat zum datierten Zeitpunkt tatsächlich zwei IPv6-Präfixe unter AS45637 beobachtete. Dennoch bleiben beide Aussagen getrennt. PeeringDB erklärt die Unterstützung aus Betreiberperspektive; RIPEstat zeigt Routingpräsenz in einer bestimmten Erfassung. Keine der beiden Quellen prüft, ob ein individueller Teilnehmeranschluss IPv6 erhielt oder wie zuverlässig eine konkrete Anwendung darüber funktionierte.

Auch „Selective“ darf nicht überinterpretiert werden. Eine selektive Peering-Policy beschreibt die erklärte Haltung des Betreibers. Sie benennt keine abgeschlossene Sitzung und keinen konkreten Partner. Daraus lässt sich weder eine bezahlte noch eine unentgeltliche Beziehung ableiten. Die Richtlinie sagt außerdem nichts über Verkehrsvolumen, Kapazitätszusagen oder den Zustand einer Verbindung.

Der IRR-Bezeichner APNIC::AS-UNIFONENZ bietet einen weiteren wiedererkennbaren Namen für die Routing-Policy-Sphäre. Er ist jedoch ebenfalls keine Topologiekarte. Aus ihm folgt nicht, welche sichtbaren Präfixe über welchen Nachbarn geführt wurden, welche Filter aktiv waren oder welche Übergabe im Fehlerfall gewählt würde. Solche Aussagen würden eine tiefere, zeitbezogene Betriebsbeobachtung erfordern.

Facility- oder Exchange-Angaben in einem operatorgepflegten Datensatz wären grundsätzlich Deklarationen und keine Eigentumsnachweise. Für AS45637 liegt in den verwendeten Beobachtungen keine unabhängige Bestätigung von Einrichtungen, Peering-Sitzungen oder Kapazitäten vor. Deshalb sollte der PeeringDB-Eintrag als Identitäts- und Policy-Signal gelesen werden, nicht als geprüfte Bestandsaufnahme physischer Anlagen.

Diese nüchterne Einordnung schmälert seinen Wert nicht. PeeringDB macht die beabsichtigte Netzrolle sichtbar: UniFone beschreibt AS45637 als regional ausgerichtetes ISP-Netz mit Dual-Stack- und Unicast-Unterstützung sowie selektiver Peering-Politik. Zusammen mit APNIC und RIPEstat entsteht ein konsistentes Bild der öffentlichen Netzidentität. Die Konsistenz erweitert aber nicht automatisch die Reichweite jeder einzelnen Aussage.

Generische redaktionelle Illustration einer öffentlichen Routingkante, die auf einen getrennten regionalen Zugangspfad trifft. Sie zeigt keine UniFone-Einrichtung, keinen UniFone-Funkturm, keine reale Route, kein Abdeckungsgebiet, keinen Ausfall, kein Kundennetz und kein gemessenes Ergebnis zur Belastbarkeit.

Vom global sichtbaren Routing zum regionalen Zugang

UniFone beschreibt sich als in Otago ansässigen und betriebenen Internetanbieter mit Standorten in Dunedin und Balclutha. Nach eigenen Angaben betreibt das Unternehmen mehr als 100 Funkstandorte auf der Südinsel und ein eigenes WiFi-Netz, das weite Teile Otagos abdeckt. Zusätzlich nennt der Betreiber Glasfaser und Festfunk als Zugangsmöglichkeiten.

Diese Selbstdarstellung bringt eine Schicht ins Blickfeld, die in ASN-Registern und BGP-Daten nicht erscheint. Das öffentliche Routing kann zeigen, dass AS45637 Präfixe ankündigt. Es zeigt nicht, wie ein Haushalt oder Betrieb die erste Verbindung in dieses Netz erhält. Bei einem regionalen Zugangsnetz können Funkabdeckung, örtliche Gegebenheiten, Teilnehmertechnik und Stromversorgung die praktische Nutzbarkeit prägen, ohne dass eine Änderung an der globalen Routenankündigung erkennbar sein muss.

Die Angabe von mehr als 100 Funkstandorten ist eine Betreiberbehauptung. Sie erlaubt weder eine unabhängige Zählung noch einen Rückschluss auf die genaue Platzierung, Kapazität oder aktuelle Verfügbarkeit einzelner Standorte. Ebenso wenig zeigt sie, welche Nutzer über welchen Standort versorgt werden. Die Zahl beschreibt den vom Betreiber dargestellten Umfang, ersetzt aber keine Messung des realen Dienstes.

Auch die Aussage, das WiFi-Netz decke weite Teile Otagos ab, ist keine universelle Abdeckungsgarantie. „Weite Teile“ lässt Raum für lokale Unterschiede und sagt nichts über eine konkrete Adresse. Die eigene Abdeckungsseite von UniFone macht diese Grenze ausdrücklich sichtbar: Die Karte ist demnach indikativ und verändert sich, wenn Türme und Infrastruktur ausgebaut werden. Eine solche Karte dient der Orientierung, nicht dem Nachweis eines funktionsfähigen Anschlusses an jedem dargestellten Punkt.

Das Nebeneinander von Glasfaser und Festfunk bedeutet ebenfalls nicht, dass beide Zugangstechniken überall verfügbar sind oder als unabhängige Ersatzwege bereitstehen. Die öffentlichen Angaben benennen Optionen, aber keine adressgenaue Verfügbarkeit und keine automatische Redundanz zwischen ihnen. Ohne zusätzliche Nachweise wäre es unzulässig, aus mehreren Produktarten auf einen belastbaren Ausweichpfad für einen bestimmten Anschluss zu schließen.

Hier liegt der zentrale Übergang zwischen Routing- und Zugangsebene. AS45637 kann für IPv4 und IPv6 breit sichtbar sein, während ein lokaler Zugang dennoch von Bedingungen abhängt, die BGP nicht erfasst. Ein Funkpfad kann andere Begrenzungen haben als eine Glasfaserverbindung. Die vorhandenen Daten messen diese Unterschiede nicht. Sie erlauben lediglich, die global beobachtete Netzpräsenz von den betreiberbeschriebenen Zugangstechniken zu unterscheiden.

Die Unterscheidung schützt zugleich vor dem gegenteiligen Fehler. Lokale Abhängigkeiten bedeuten nicht, dass ein Ausfall stattgefunden hat. Es liegt kein Beleg für eine konkrete Störung, eine beeinträchtigte Region oder einen betroffenen Kunden vor. Die Quellen benennen mögliche Grenzen und Abhängigkeiten, keine beobachteten Schadensereignisse.

Für die Beurteilung der Netzidentität bleibt daher eine zweistufige Lesart sinnvoll. Auf der öffentlichen Routingebene ist die Präsenz von AS45637 zum angegebenen Zeitpunkt stark belegt. Auf der regionalen Zugangsebene stehen Betreiberangaben zu Funkstandorten, WiFi-Abdeckung, Glasfaser und Festfunk. Diese Angaben erklären, welche technischen Bereiche zwischen dem sichtbaren autonomen System und dem Teilnehmer liegen können; sie messen deren tatsächliche Leistung nicht.

Die präzise Grenze lautet: Die fünf Präfixe zeigen, dass UniFones autonomes System im beobachteten Routing als Dual Stack erschien. Sie sagen nicht, ob ein bestimmter Standort innerhalb Otagos versorgt wurde, welche Zugangstechnik dort eingesetzt wurde oder wie der Dienst auf eine lokale Unterbrechung reagierte. Routingtransparenz und Zugangsresilienz bleiben getrennte Eigenschaften.

Netzstrom am Teilnehmerstandort als ausdrückliche Kontinuitätsgrenze

Eine besonders klare Grenze benennt UniFone selbst: Breitbanddienste funktionieren bei einem Ausfall der Netzstromversorgung am Teilnehmerstandort möglicherweise nicht. Der Hinweis macht sichtbar, dass die Kontinuität eines Internetzugangs nicht allein vom Zustand des öffentlichen Routings abhängt. Selbst wenn AS45637 weiterhin angekündigt und bei sämtlichen erfassten RIS-Peers sichtbar wäre, könnte ein lokaler Anschluss ohne die erforderliche Stromversorgung unbrauchbar sein.

Diese Abhängigkeit liegt außerhalb dessen, was APNIC und RIPEstat prüfen. Das Register kennt weder die Stromlage an einer Adresse noch den Betriebszustand der dortigen Geräte. BGP-Beobachter sehen Präfixe und Pfadinformationen, nicht die Energieversorgung eines Teilnehmerendpunkts. Ein unverändertes Routingbild kann deshalb mit einer lokalen Unterbrechung vereinbar sein, ohne sie zu beweisen oder zu widerlegen.

Der Betreiberhinweis berührt auch einen möglichen angeschlossenen Festnetztelefoniedienst: Bei fehlendem Breitband könne gegebenenfalls ein über den Anschluss verbundenes Telefon für Notrufe nicht funktionieren. Diese Aussage unterstreicht die praktische Bedeutung der lokalen Stromgrenze. Sie ist jedoch als allgemeiner Warnhinweis zu lesen, nicht als Nachweis eines konkreten Ausfalls oder einer erfolglosen Notrufverbindung.

Es wäre ebenso falsch, aus dem Hinweis eine pauschale Aussage über alle Anschlüsse abzuleiten. „Möglicherweise nicht funktionieren“ beschreibt ein Risiko beziehungsweise eine technische Abhängigkeit. Es sagt nicht, dass jeder Dienst bei jedem Stromausfall sofort ausfällt oder dass keine lokale Sicherung vorhanden sein kann. Über die Ausstattung einzelner Standorte liegen keine belastbaren Angaben vor.

Gerade diese vorsichtige Formulierung zeigt, warum Kontinuität schichtweise betrachtet werden muss. Ein autonomes System kann weiterhin Routen verbreiten. Übergaben zu anderen Netzen können weiterhin vorhanden sein. Ein regionaler Backhaul kann weiterhin arbeiten. Trotzdem kann die letzte Zugangsstrecke am Nutzerort von lokaler Energie abhängen. Umgekehrt würde eine lokale Stromversorgung allein weder die Verfügbarkeit des Backhauls noch die globale Erreichbarkeit sichern.

Für Resilienzbehauptungen reicht deshalb kein einzelner Datenpunkt. Eine aktive ASN bestätigt die administrative Aufzeichnung. Sichtbare Präfixe bestätigen beobachtetes Routing. Ein Betreiberhinweis benennt eine lokale Abhängigkeit. Keiner dieser Befunde beweist das Verhalten der gesamten Kette während einer realen Störung.

Die Stromgrenze verdeutlicht außerdem, warum der Begriff „Netzausfall“ zu grob sein kann. Mehrere technische Ebenen können unabhängig oder gemeinsam betroffen sein. Ohne konkrete Messdaten wäre nicht festzustellen, ob eine Einschränkung am Teilnehmergerät, auf dem Funkpfad, im Backhaul, an einer Übergabe oder im Routing entstand. Hier liegt kein Ereignisnachweis vor; sichtbar ist lediglich die vom Betreiber erklärte Abhängigkeit.

Der Hinweis ist deshalb wertvoll, weil er Erwartungen begrenzt. Er verhindert, dass eine breit sichtbare ASN mit einem garantiert verfügbaren Dienst verwechselt wird. Die BGP-Aufnahme zeigt, dass AS45637 am 2. August 2026 um 16:00 UTC in der erfassten Stichprobe präsent war. Sie beantwortet nicht, ob ein einzelner Anschluss bei einem lokalen Stromausfall funktionierte.

Auch die Angabe verschiedener Zugangsarten löst diese Grenze nicht automatisch auf. Glasfaser und Festfunk können unterschiedliche Übertragungsmedien sein, doch beide benötigen aktive Technik. Ob es an einem bestimmten Standort unabhängige Energieversorgung oder alternative Wege gibt, ist nicht belegt. Mehrere Produktnamen sind daher kein Ersatz für eine gemessene Ende-zu-Ende-Resilienz.

Backhaul, Rechenzentren und Übergaben: Aussagen des Betreibers

Auf der Seite zu Managed Services beschreibt UniFone eine weitere Ebene seines Netzes. Demnach ist das WiFi-Netz mit Rechenzentren in Dunedin, Christchurch, Auckland und Sydney verbunden. Der Betreiber erklärt außerdem, Verkehr über branchenübliche Zusammenschaltungen an andere Anbieter zu übergeben. Für die Verbindungen innerhalb Neuseelands beansprucht UniFone vollständige Redundanz.

Diese Aussagen helfen, das vom Betreiber beschriebene Betriebsmodell zwischen regionalem Zugang und externen Netzen zu verstehen. Sie deuten auf eine Kette aus WiFi-Zugang, Rückführung zu mehreren städtischen Punkten und Übergaben zu anderen Anbietern. Doch die Angaben bleiben Selbstauskünfte. Keine der vorhandenen Routing- oder Registerbeobachtungen bestätigt die physische Lage, Eigentumsstruktur oder exakte Führung dieser Verbindungen.

Die Nennung eines Rechenzentrumsstandorts beweist insbesondere kein Eigentum an der Einrichtung. Sie bestätigt auch nicht, dass ein bestimmtes Präfix, ein bestimmter Kunde oder ein konkreter Dienst über diesen Standort geführt wurde. Eine Verbindung „zu“ einem Rechenzentrum kann verschiedene technische und vertragliche Formen annehmen; darüber enthalten die verfügbaren Fakten keine weitergehenden Details.

Ähnlich begrenzt ist die Aussage über Übergaben an andere Anbieter. Dass UniFone solche Übergaben nach eigener Darstellung über branchenübliche Zusammenschaltungen vornimmt, benennt einen allgemeinen Interconnection-Mechanismus. Es identifiziert keine Gegenpartei, keinen Übergabepunkt und keine kommerzielle Beziehung. Die 17 von RIPEstat beobachteten Nachbarn dürfen nicht als direkte Liste solcher Anbieter oder als Nachweis bezahlter Transitverhältnisse gelesen werden.

PeeringDB ergänzt diese Perspektive durch die angegebene selektive Peering-Policy. Auch hier entsteht ein konsistentes, aber nicht vollständiges Bild: Der Betreiber beschreibt Interconnection und eine selektive Haltung zu Peering; RIPEstat beobachtet Nachbarschaften im Routing. Die beiden Ebenen belegen weder identische Beziehungen noch konkrete Sitzungen. Eine Routingnachbarschaft kann nicht ohne zusätzliche Nachweise einer bestimmten geschäftlichen oder physischen Verbindung zugeordnet werden.

Besondere Vorsicht verlangt der Begriff „vollständige Redundanz“. In der Betreiberbeschreibung bezieht er sich auf neuseeländische Verbindungen. Ohne unabhängige Messung bleibt offen, wie Redundanz definiert ist, welche Komponenten sie umfasst und unter welchen Ausfallbedingungen sie greifen soll. Die Aussage beweist weder physisch getrennte Wege noch eine erfolgreiche Umschaltung. Sie erlaubt auch keine Zusicherung von Verfügbarkeit oder Wiederherstellungszeit.

Eine belastbare Prüfung von Redundanz müsste das Verhalten bei einem konkreten Fehler beobachten. Sie müsste unterscheiden, ob alternative Wege lediglich geplant, betriebsbereit oder tatsächlich unter Last übernommen haben. Die vorliegenden Daten enthalten keinen solchen Test. Die RIPEstat-Aufnahme zeigt einen normalen beobachteten Routingzustand zu einem Zeitpunkt; sie dokumentiert keinen Ausfall und keinen Failover.

Auch breite RIS-Sichtbarkeit kann die Redundanzbehauptung nicht bestätigen. Wenn alle erfassten Peers die Präfixe sehen, ist die Routenausbreitung innerhalb der Stichprobe stark. Daraus folgt jedoch nicht, wie viele unabhängige physische Komponenten an dieser Sichtbarkeit beteiligt sind. Mehrere logische Wege können Infrastruktur teilen; ein einzelner logischer Weg kann über komplexe physische Systeme laufen. Über diese Architektur liegen keine unabhängigen Nachweise vor.

Die Betreiberangaben sollten daher weder verworfen noch als Messwerte behandelt werden. Sie beschreiben, welche Kontinuitäts- und Übergabestruktur UniFone öffentlich beansprucht. APNIC und RIPEstat bestätigen separat, dass die zugehörige ASN administrativ zugeordnet und im datierten Routing sichtbar war. Der Abstand zwischen diesen Befunden bleibt die entscheidende Prüfgrenze.

Drei Ebenen von Kontinuität

Die öffentlichen Informationen zu UniFone lassen sich in drei voneinander abhängige, aber nicht austauschbare Ebenen gliedern: Registerkontinuität, Routingkontinuität und Dienstkontinuität. Jede Ebene trägt zur Nachvollziehbarkeit bei. Keine kann allein die beiden anderen ersetzen.

Registerkontinuität bedeutet, dass die Nummernressource nachvollziehbar einer Organisation zugeordnet ist. APNIC führt AS45637 als aktiv und verbindet sie exakt mit UniFone New Zealand Ltd. Die passenden Rollen für Netzwerkadministration und Incident Response erhöhen die Konsistenz. Diese Ebene beantwortet die Identitätsfrage: Welcher Organisation ist die ASN im Register zugeordnet?

Routingkontinuität betrifft die tatsächliche Sichtbarkeit von Ankündigungen. RIPEstat zeigte AS45637 am 2. August 2026 um 16:00 UTC als angekündigt. Fünf Präfixe waren sichtbar, und die erfassten RIS-Full-Feed-Peers sahen die Präsenz in IPv4 und IPv6 vollständig innerhalb ihrer jeweiligen Stichproben. Diese Ebene beantwortet eine operative, aber eng gefasste Frage: War die Netzidentität zum Beobachtungszeitpunkt im Routing sichtbar?

Dienstkontinuität beginnt dort, wo Nutzer tatsächlich auf den Anschluss angewiesen sind. Sie umfasst die Zugangsstrecke, Stromversorgung, Funk- oder Glasfaserpfade, Backhaul, Übergaben und betriebliche Reaktion. UniFone beschreibt Teile dieser Kette und weist selbst auf die mögliche Abhängigkeit von der Netzstromversorgung am Teilnehmerstandort hin. Die vorhandenen Beobachtungen messen jedoch nicht, ob diese gesamte Kette unter einer Störung weiterfunktioniert.

Zwischen den Ebenen bestehen Beziehungen, aber keine Gleichheit. Eine falsche oder veraltete Registerzuordnung würde die Interpretation des Routings erschweren. Fehlende Routingpräsenz könnte die externe Erreichbarkeit beeinträchtigen. Ein lokales Zugangsproblem kann einen Anschluss unterbrechen, während Register und globale Routen unverändert bleiben. Umgekehrt kann eine lokale Funkstrecke technisch intakt sein, obwohl eine Störung auf einer weiter entfernten Ebene besteht.

Diese Struktur erklärt auch, warum der Ausdruck „im Netz sichtbar“ präzisiert werden muss. AS45637 war in RIPEstat sichtbar. Das bedeutet nicht, dass jeder Dienst von UniFone sichtbar, erreichbar oder funktionsfähig war. Es bedeutet ebenso wenig, dass jeder Ort innerhalb einer betreiberbeschriebenen Abdeckung tatsächlich verbunden war. Die Sichtbarkeit gehört zur Routingebene.

Für betriebliche Transparenz ist die Trennung produktiv. Das Register liefert eine dauerhafte Referenz, die ASN. Routingbeobachtungen versehen diese Referenz mit Zeitstempeln und konkreten Präfixen. Betreiberangaben beschreiben Zugang und Interconnection. Werden diese Signale in ihrer eigenen Kategorie gehalten, entsteht ein überprüfbares Bild ohne die Illusion vollständiger Einsicht.

Das gleiche Prinzip gilt für Veränderungen. Wenn sich die registrierte Organisation änderte, wäre das ein Registerereignis. Wenn sich Präfixe oder Peer-Sichtbarkeit änderten, wäre das ein Routingereignis. Wenn sich eine Abdeckungskarte, ein Zugangsdienst oder ein Redundanzhinweis änderte, wäre das zunächst eine Änderung der Betreiberbeschreibung. Erst zusätzliche Messungen könnten zeigen, welche tatsächlichen betrieblichen Folgen damit verbunden waren.

Kontinuität lässt sich daher nicht aus einem statischen Feld ableiten. Sie muss auf der Ebene beobachtet werden, auf der die relevante Funktion stattfindet. AS45637 bietet eine ausgezeichnete Grundlage für Routingbeobachtung. Die Zugangskontinuität an einer Adresse verlangt andere Nachweise, die hier nicht vorliegen.

Diese dreistufige Betrachtung verhindert sowohl Übertreibung als auch Unterbewertung. Es wäre zu wenig, die ASN nur als Verwaltungsnummer zu behandeln, denn RIPEstat zeigt ihre laufende Routingpräsenz. Es wäre zu viel, diese Präsenz als Beweis belastbarer Versorgung zu verwenden. Der genaue Befund liegt dazwischen: eine stark belegte öffentliche Netzidentität mit klar benannten, aber nicht gemessenen Grenzen auf der Zugangsebene.