Zusammenfassung

  • Die APNIC-Ankündigung nennt für den 29. September 2026 von 10 bis 12 Uhr UTC+10 Arbeiten an einer GCP-Netzwerkumgebung. Betroffen sind DASH, notification.apnic.net, REx und der AS0-ROA-Dienst; Ausfallzeit wird nicht erwartet. Das beschreibt eine künftige Wartung, keinen bereits beobachteten Ausfall und keine Zusage zur Aktualität jedes Datenobjekts.
  • Nach der geltenden APNIC-Ressourcenrichtlinie, Abschnitt 5.1.4, decken AS0-ROAs als Available oder Reserved geführten, noch nicht delegierten Adressraum unter APNIC-Verwaltung ab. Bei einer Delegation entfernt APNIC den Präfix aus dem AS0-ROA. Ein Zeitwert für 2026 steht dort nicht.
  • Bei der Einführung 2020 beschrieb APNIC unter normalen Umständen ein Ziel von weniger als fünf Minuten bis zur Entfernung und erneuten Veröffentlichung. Das ist ein historischer Implementierungsbefund, kein nachgewiesener aktueller SLA und keine Messung der bevorstehenden Arbeiten.
  • Für AS0 gilt ein separater Trust Anchor Locator. APNIC empfiehlt, das Ergebnis zu Beratung oder Alarmierung zu nutzen, nicht automatisch BGP-Routen zu filtern. Wie ein Netz mit einer Validierung umgeht, bleibt seine eigene Entscheidung.

Eine gemeinsame Wartungsliste ist keine gemeinsame Messgröße

Die Service-Übersicht datiert den Hinweis auf den 24. September. Die angekündigte Wartung liegt fünf Tage später. APNIC beschreibt eine zweistündige Änderung der GCP-Netzwerkumgebung und erwartet dabei keine Unterbrechung. Eine am Ende stehende allgemeine Entschuldigung für mögliche Probleme durch eine „outage“ ist kein Betriebsprotokoll. Sie macht aus der ausdrücklich vorausschauenden Formulierung keine Meldung über einen eingetretenen Vorfall.

Vier Produktnamen in einer Spalte laden zum selben grünen Prüfsignal ein: Antwortet die Adresse? Für eine Oberfläche ist das eine sinnvolle erste Frage. Bei Benachrichtigungen kommt ihre Zustellung oder Abrufbarkeit hinzu; bei REx die Nutzbarkeit der bereitgestellten Daten. AS0 hat einen anderen kritischen Zustandswechsel. Wenn sich im Register der Status eines Präfixes ändert, muss die signierte Aussage über ihn folgen. Ein erreichbarer Veröffentlichungsort kann grundsätzlich noch eine ältere Fassung ausliefern. Damit wird kein solches Verhalten bei APNIC behauptet.

Es zeigt nur, weshalb Verfügbarkeit nicht als Ersatzmessung für Aktualität taugt.

Dasselbe Quartett erscheint bereits in einer Ankündigung vom 31. Juli 2025, damals für ein Kubernetes-Upgrade und ebenfalls ohne erwartete Ausfallzeit. Diese Wiederholung zeigt, dass AS0 seit mindestens diesem früheren Hinweis zum kommunizierten Wartungsumfang gehört. Sie zeigt nicht, ob Datenbank, Netzwerkpfad, Signierprozess oder Ausfallbereich 2026 identisch geblieben sind. Eine Liste von Diensten ist kein Architekturplan.

Ein neuer Inhaber beendet die alte Aussage

Ein ROA mit Origin AS 0 bekräftigt nicht das Recht eines bestimmten Netzes, einen Präfix anzukündigen. RFC 6483, Abschnitt 4, beschreibt ihn als Zurückweisung von Routing-Ursprung für den genannten Präfix und seine spezifischeren Präfixe. APNIC nutzt das für von ihr verwalteten IPv4- und IPv6-Raum, der im erweiterten Delegationsdatensatz als Available oder Reserved erscheint. Das ist eine begrenzte Registeraussage über nicht delegierten Raum, keine universelle Befehlsgewalt über Routing.

Mit der Delegation an einen Kontoinhaber verliert der bisherige AS0-Eintrag seine Grundlage. Die aktuelle Richtlinie verlangt, den entsprechenden Präfix aus dem ROA zu entfernen. Das ist nicht bloß Datenpflege. Ein Dienst, der „hier sollte keine Route entstehen“ signiert, muss aufhören, dies über einen jetzt delegierten Block zu sagen. Der notwendige Übergang führt vom maßgeblichen Registereintrag über die Neuberechnung des AS0-Inhalts zur veröffentlichten signierten Fassung.

Die damalige Umsetzung beschrieb APNIC ungewöhnlich konkret. Im Bericht für APNIC 50 sollten laufende Delegationsänderungen binnen fünf Minuten sowohl im gewöhnlichen als auch im AS0-RPKI-Zustand ankommen. Eine intern an Registerereignisse gekoppelte Komponente und ein Cloud-Publikationsort wurden genannt. Der Blogbeitrag von 2020 beschreibt die Entfernung und erneute Veröffentlichung in weniger als fünf Minuten unter normalen Umständen als umgesetztes Entwurfsziel. Dieser Zeitwert erklärt, was APNIC damals für relevant hielt. Er darf nicht ohne aktuelle Belege als Grenzwert dieser Wartung ausgegeben werden. Die heute geltende Richtlinie enthält die Entfernungspflicht, aber keine hier belegte Frist.

Eine saubere Prüfung würde Zeitpunkte trennen. Wann wurde eine relevante Delegation im autoritativen Register wirksam? Welche vorherige AS0-Fassung erfasste den Präfix noch, welche nächste nicht mehr? Wann war die neue signierte Fassung öffentlich verfügbar? Wann sah ein unabhängiger Prüfer sie erstmals? Ein Validierer, der den AS0-TAL freiwillig eingebunden hat, besitzt schließlich seinen eigenen Abrufrhythmus. Eine späte Beobachtung bei ihm beweist allein noch keine verspätete Publikation. Eine interne Publikationszeit beweist allein noch keine externe Sichtbarkeit.

Erst die Verbindung der Versionen und Uhren kann die Stelle einer möglichen Verzögerung zeigen.

Vielleicht findet während der zwei Stunden überhaupt keine passende Delegation statt. Dann kann ein unverändertes Objekt genau richtig sein. Zwei gleiche Prüfsummen vor und nach der Wartung beweisen weder, dass ein historisches Fünf-Minuten-Ziel eingehalten wurde, noch dass es verletzt wurde. Ohne Zustandswechsel hat es für diesen Übergang keine Probe gegeben. Die Ankündigung sagt nicht, dass ein solcher Übergang eintreten wird.

Getrenntes Vertrauen bleibt eine Entscheidung des Netzes

APNIC stellt für AS0 einen eigenen TAL bereit, damit diese Aussage nicht unbemerkt über den üblichen Vertrauensanker ausgewertet wird. Wer sie verwenden will, muss die zusätzliche Quelle ausdrücklich aufnehmen. Daraus folgt keine physische Trennung der Publikationssysteme. Der Cloud-Veröffentlichungsort von 2020 und die GCP-Netzwerkarbeiten von 2026 sind zwei belegte Aussagen aus verschiedenen Zeiten; daraus lässt sich die heutige Topologie nicht rekonstruieren.

Wäre ein frisch delegierter Präfix hypothetisch noch von einem älteren AS0-Objekt erfasst, könnte ein Nutzer dieses TAL weiterhin eine signierte Zurückweisung sehen. Daraus folgt nicht automatisch, dass jede Route Invalid wäre: Die Gesamtheit der einschlägigen ROAs und die Validierung zählen. Noch weniger folgt daraus, dass ein Router Pakete verwirft. Ob eine Validierungsentscheidung zur Ablehnung einer Route führt, legt der Betreiber fest. APNIC warnt selbst vor möglichen Unterbrechungen bei entsprechenden Konfigurationen und empfiehlt einen Hinweis- oder Alarmierungsbetrieb.

Aus der jetzigen Ankündigung lässt sich weder eine veraltete AS0-Fassung noch ein Schaden nachweisen.

Ein knapper Bericht nach der Wartung könnte diese Ebenen auseinanderhalten: Waren die benannten Dienste von außen erreichbar? Gab es für AS0 eine passende Delegation, welche die Aktualisierungskette beanspruchte? Welche Register- und Objektversionen lassen sich verbinden, und welchen aktuellen Zeitmaßstab verwendet APNIC gegebenenfalls? Wenn es kein Ereignis gab, wäre „Aktualisierungspfad nicht durch einen Delegationswechsel geprüft“ eine präzise Aussage. Das ist ein redaktioneller Vorschlag, keine von APNIC bereits zugesagte Berichtspflicht und kein Vorwurf fehlender interner Überwachung.

Eine störungsfreie Wartung wäre ein gutes Ergebnis. Sie beantwortet aber nur einen Teil der Frage bei einem Dienst, dessen signierter Inhalt den Zustand knapper Nummernressourcen beschreibt. Erreichbarkeit soll belegbar sein; die Korrektur nach einer Delegation ebenso.

Quellen