Zusammenfassung

  • APNIC führt „Route management alignment“ als Registry-Vorhaben für das dritte Quartal 2026. Nach Transfers, Deallokationen und Systemänderungen sollen Routenverwaltung, Ressourcenbestände, Whois und RPKI automatisiert aufeinander abgestimmt werden.
  • Die Oberflächen beantworten unterschiedliche Fragen: Der Bestand begründet Registerbefugnis, ein IRR-Routenobjekt veröffentlicht Policy oder Absicht, eine ROA autorisiert einen Ursprung, und BGP zeigt eine beobachtete Route unter lokaler Netzpolitik.
  • Der öffentliche Eintrag nennt weder Vorrangregeln noch Transaktionsgrenze, Zustand eines Teilerfolgs, Benachrichtigung oder Rollback-Nachweis. Das belegt eine öffentliche Dokumentationslücke, nicht das Fehlen einer internen APNIC-Architektur.
  • Eine typbezogene Vorrangmatrix und ein versionierter Vorgangsbeleg könnten manuelle Abstimmung verringern, ohne legitime Unterschiede, den Vorzustand oder den Weg zum letzten sicheren Zustand zu löschen.

Der Unterschied ist manchmal das wichtigste Datum

Produktteams nennen Unterschiede zwischen Datenbanken häufig Inkonsistenzen. Das Wort legt nahe, dass eine Seite falsch sein muss. Im Routing stimmt das nicht. Ein Ressourceninhaber kann zwei Ursprünge absichtlich autorisieren. Ein Whois-Objekt kann während eines Providerwechsels weiterbestehen. Eine neue ROA kann veröffentlicht sein, bevor jeder Validator sie abgeholt hat. Das Abweichende ist dann kein Fehler, sondern der Hinweis auf eine noch nicht abgeschlossene oder bewusst mehrdeutige Lage.

Genau in dieses Feld fällt APNICs Roadmap-Eintrag „Route management alignment“. Er gehört zum Registry-Team, ist auf Q3 2026 terminiert und nennt ARMS, RPKI und Whois. Die geplante Lösung soll Routenverwaltung und Ressourcenbestände ausrichten sowie Whois- und RPKI-Informationen mit dem Routenmanagement synchronisieren. Nach Transfers, Deallokationen und Systemänderungen sollen weniger mühsame, fehleranfällige Handabgleiche nötig sein.

Das Ziel ist vernünftig. Mehrfach dieselbe betriebliche Absicht in verschiedenen Masken einzutragen, schafft keinen Wert. Bei knappen Migrationsfenstern sind zusätzliche manuelle Schritte eine Fehlerquelle.

Doch Abgleich ist nicht neutral. Sobald die Systeme verschiedene Werte tragen, entscheidet Software, was bestehen bleibt, was verschwindet, was wartet und was ein Mensch prüfen muss. Diese Entscheidung beeinflusst Bearbeitungsrechte, Routenfilter, RPKI-Validierung und die Beweislage nach einem Vorfall.

Der erfasste strukturierte Roadmap-Datensatz enthält Jahr, Quartal, Team, Produkte, Zusammenfassung und Lösung. Sein Changelog ist leer. Der öffentliche Text beschreibt keine Präzedenz, keine Grenze einer systemübergreifenden Transaktion, keinen Zustand für teilweises Gelingen, keine Rückabwicklung, keine Benachrichtigung und keine Grenze zu NIRs oder externen IRRs. APNIC kann diese Fragen intern bereits bearbeitet haben. Aus dem öffentlichen Schweigen folgt nicht, dass es keinen Entwurf gibt. Es folgt, dass der sichtbare Anspruch noch nicht überprüfbar genug ist.

Vier Beweise für vier verschiedene Sachverhalte

Der Ressourcenbestand beantwortet eine Registerfrage: Welches Konto oder welche Organisation erkennt APNIC als Inhaber eines Adressblocks oder einer ASN an? Daraus folgen Befugnisse zur Verwaltung zugeordneter Dienste. Daraus folgt nicht automatisch, welcher AS heute jedes Präfix originieren soll.

Ein Routenobjekt im Internet Routing Registry beantwortet eine Policy-Frage. APNIC beschreibt das IRR als verteilte Sammlung von Datenbanken, in denen Netzbetreiber Routing-Policies und Ankündigungen veröffentlichen. Andere Netze können daraus Filter und Konfigurationen erzeugen. RFC 2725 verlangt beim Anlegen eines route object eine Autorisierung sowohl für das Präfix als auch für den Ursprungs-AS. Der Standard berücksichtigt mehrere Ursprünge, überlappende spezifischere Präfixe, Providerwechsel und Übergangsfristen bei Umnummerierungen.

Mehrere Werte können damit beabsichtigt sein. Eine zweite Herkunft kann Redundanz bieten. Ein älteres Objekt kann während einer kontrollierten Übergabe noch gebraucht werden. Ein Algorithmus, der für jedes Präfix genau einen AS erwartet, kann betriebliche Widerstandsfähigkeit als Datenfehler behandeln.

RPKI beantwortet eine engere kryptografische Frage. RFC 9582 definiert eine Route Origin Authorization als signiertes Objekt, mit dem der Inhaber von Adressraum einen AS zur Originierung bestimmter Präfixe berechtigt. Sollen mehrere ASes berechtigt sein, gibt es mehrere ROAs. Das Objekt belegt Erlaubnis innerhalb einer Zertifikatskette. Es belegt weder eine gegenwärtige Ankündigung noch Erreichbarkeit oder die Auswahl eines bestimmten Routers.

BGP liefert Beobachtung. RFC 6483 erläutert, wie Präfix und Ursprung einer empfangenen Route mit gültigen ROAs verglichen werden, um Valid, Invalid oder Unknown zu bestimmen. Ob ein Netz Unknown oder Invalid verwirft, bleibt lokale Routing-Policy. Ein Register kann Autorisierungen veröffentlichen; es kann nicht die Auswahl aller fremden Netze verfügen.

Auch die Uhren unterscheiden sich. RFC 6483 warnt, dass RPKI-Objekte und Routen verschieden schnell propagieren können. Ein lokaler Cache kann eine gültig veröffentlichte neue ROA noch nicht kennen. Eine Route kann früher sichtbar sein. Ein Reserveursprung kann autorisiert sein, ohne gerade anzukündigen. Abweichung kann Übergang sein.

Bestand, IRR-Objekt, ROA und BGP sind somit Beweise für Befugnis, Absicht, Erlaubnis und Verhalten. Sie hängen zusammen, sind aber keine vier Kopien derselben Wahrheit.

Das alte Werkzeug kannte einen wertvollen Konfliktzustand

APNICs Route Management Guide von 2017 dokumentiert einen Vorgänger des heutigen Problems. Wegen seines Alters ist er kein aktueller Vertrag für das Vorhaben 2026. Er zeigt jedoch, dass APNIC einen verwalteten MyAPNIC-Zustand und das veröffentlichte Whois-Routenobjekt bereits ausdrücklich trennte.

Im damaligen Modell war eine „route“ in MyAPNIC eine Vorlage für ein tatsächliches route object in Whois. Beide konnten unabhängig existieren: Vorlage ohne Whois-Objekt oder Whois-Objekt ohne verwaltete Vorlage. Wurde das Whois-Objekt über einen anderen Weg geändert, übernahm die Vorlage die Änderung nicht still. Das Werkzeug zeigte einen conflict. Der Nutzer konnte die fremde Änderung akzeptieren oder das Whois-Objekt auf den Vorlagenzustand zurücksetzen.

Die Abweichung blieb als Ereignis sichtbar. Vielleicht hatte ein berechtigter Maintainer eine dringende Korrektur durchgeführt; vielleicht war ein alter Eintrag zurückgeblieben. Das System entschied nicht durch bloßes Überschreiben, bevor der Nutzer diese Möglichkeiten unterscheiden konnte.

Der Guide nennt außerdem pending-Zustände bei der Synchronisierung mehrerer Objekte. Berechtigte Nutzer konnten beim Erstellen einer Route optional passende ROAs erzeugen. In einem beschriebenen Löschfall wurde beim Deaktivieren einer verwalteten Subroute auch die aktivierte ROA gelöscht. Hinter einer Oberfläche lagen also getrennte Zustände, verschiedene Rechte, asynchrone Verarbeitung und optionale Kopplung.

Die neue Architektur kann anders aussehen. Bewahrenswert ist die Sichtbarkeit des Konflikts. Eine außen vorgenommene Änderung ist ein Signal mit Herkunft und Zeit. Automatisierung sollte seine Bedeutung prüfen, nicht nur seine Existenz beenden.

Eine Transaktion endet an institutionellen Grenzen

APNICs Ankündigung der Registry API im Oktober 2024 liefert einen aktuelleren Ausführungskontext. Die API kann Delegationsinformationen abrufen und Whois-Datensätze, Reverse DNS, ROAs sowie Routenobjekte verwalten. Als Beispiel nennt APNIC die automatische Erstellung einer ROA und eines route object beim Hinzufügen einer BGP-Ankündigung.

Die Beschreibung formuliert ihre Grenze sorgfältig. Abstrakte Routenverwaltungs- und Reverse-DNS-Vorgänge lassen sich als Batch einreichen; diese Batches wirken „transactionally where possible“. Sämtliche Updates sind asynchrone task objects: Nach Einreichung erhält der Client einen Link, fragt den Status ab und bekommt am Ende Ergebnisdetails.

„Wo möglich“ bedeutet nicht globale Atomizität. Mehrere Schreibvorgänge in derselben Datenbank können gemeinsam committen. Die Veröffentlichung eines RPKI-Objekts, sein Abruf durch unabhängige Validatoren, ein Update bei einem anderen RIR, ein Objekt in einem externen IRR und neu erzeugte Filter bei einem Transitnetz gehören nicht zu derselben Transaktion.

Darum muss das neue Vorhaben das Unmögliche neben dem Möglichen beschreiben. Was passiert, wenn Whois geschrieben wurde, die vorgesehene RPKI-Aktion aber scheitert? Ein pauschales Failed zeigt nicht, ob eine Wiederholung ungefährlich ist. Der Beleg muss den erfolgreichen Teilschritt, den Fehler, den letzten sicheren Zustand, eine Wiederholungsbedingung und gegebenenfalls Kompensation oder Quarantäne nennen.

Ebenso darf Completed nicht behaupten, alle Caches und Netze hätten die Änderung gesehen. Es kann heißen, dass APNIC seine kontrollierten Schritte beendet hat. committed, published und observed sind unterschiedliche Zustände.

Diese Analyse weist keinen aktuellen Fehler der API nach. Die Ankündigung ist relevant, weil APNIC bereits öffentlich mit Batch, bedingter Transaktion, asynchronem Task und Ergebnis arbeitet. Das Vokabular für einen präzisen Abgleichsbeleg ist vorhanden.

Beim Transfer wechselt das Recht, nicht automatisch die Route

APNICs aktuelle Transfer Conditions bestimmen für ausgehende Inter-RIR-Transfers, dass zugehörige Unterzuweisungen, route objects und domain objects aus der APNIC-Whois-Datenbank gelöscht werden. Nach Abschluss verliert die Quellpartei ihre Rechte an den IP-Adressen und ASN-Ressourcen; der Empfänger wird registriert.

Die zitierte Klausel nennt Whois-Objekte. Sie sagt nicht, was mit ROAs geschieht. Aus dieser Lücke darf keine behauptete RPKI-Löschung entstehen. Gerade die Trennung zeigt, welche Reihenfolge die neue Automatisierung erklären muss.

Der Bestandswechsel beendet eine Verwaltungsbefugnis. Die Whois-Regel säubert die Veröffentlichungsfläche des Quellregisters. Welchen Ursprung der Empfänger wählt und welche ROA er autorisiert, ist eine neue Entscheidung. Der tatsächliche Cutover hängt zusätzlich von Veröffentlichung, Cache, Filter und BGP ab.

Behält der Empfänger denselben origin AS, ändert sich die Inhaberschaft, aber nicht zwingend die Routenabsicht. Wechselt er den AS, kann es sinnvoll sein, die neue Autorisierung vor dem Rückzug des alten Pfads vorzubereiten. Bei einem Inter-RIR-Transfer können Löschung auf der Quellseite und Sichtbarkeit am Ziel verschiedenen Zeitplänen folgen. Das sind analytische Testszenarien, keine Berichte über APNIC-Vorfälle.

Alles zuerst zu löschen, kann ein vermeidbares Invalid- oder NotFound-Fenster schaffen. Alles auf unbestimmte Zeit zu bewahren, verlängert veraltete Autorität. Das beobachtete BGP in eine ROA zu kopieren, verwandelt Verhalten ohne Inhaberentscheidung in Erlaubnis. Ein universeller Ablauf reicht nicht.

Der Status aligned müsste daher zerlegt werden: prepared für eine autorisierte, noch nicht wirksame Änderung; committed für den Registerschreibvorgang; published für öffentliche Verfügbarkeit; observed für eine unabhängige Sicht; retired für die beendete alte Befugnis. Jede Stufe braucht einen Beleg.

Drei Differenzen, die eine Maschine nicht glätten darf

Die erste ist legitimes Multi-Origin-Routing. IRR und RPKI können mehrere Ursprünge abbilden. Der Abgleich sollte Rechte und Präfixumfang prüfen, nicht Mehrzahl als Fehler werten. Sonst wird eine Ausweichroute der Sauberkeit geopfert.

Die zweite ist Propagationsverzug. Ein Datensatz kann committed, aber noch nicht published sein; er kann published sein, aber noch nicht observed. Reagiert die Engine auf jeden Zwischenzustand wie auf einen dauerhaften Konflikt, wiederholt oder widerruft sie womöglich eine Änderung, die sich noch ausbreitet.

Die dritte ist eine Änderung über einen anderen berechtigten Kanal. Das alte Werkzeug ließ den Nutzer eine externe Whois-Änderung akzeptieren oder zurücksetzen. Künftig muss geklärt werden, wer mit welchem Recht änderte, ob die Änderung eine neuere Absicht trägt und ob sie RPKI überhaupt berührt. Gewinnt stets die MyAPNIC-Vorlage, verschwindet möglicherweise eine Notfallkorrektur. Gewinnt stets die externe Änderung, verliert der verwaltete Plan seine Wirkung.

Die Roadmap nennt auch Deallokationen, beschreibt aber keinen Ablauf. Das Ende der Ressourcenbefugnis kann Rücknahmen erfordern; Benachrichtigung, Frist, Widerspruch und NIR-Konstellationen folgen nicht aus einem einzelnen Wort. Externe IRR-Objekte liegen ohnehin außerhalb eines lokalen APNIC-Commits.

Nicht eine Wahrheit, sondern eine Zuständigkeit je Frage

Das Schlagwort single source of truth ist hier irreführend. Der Bestand ist maßgeblich für die Frage, wer handeln darf. Ein authentifizierter Auftrag belegt betriebliche Absicht. Das IRR veröffentlicht Policy. Die ROA belegt Origin-Autorisierung. BGP zeigt Verhalten. Kein Datensatz sollte die Antworten der anderen erzeugen dürfen.

APNIC könnte eine kurze Präzedenzmatrix veröffentlichen. Zeilen: Transfer, Deallokation, direkte Whois-Änderung, Änderung der Routenvorlage, ROA-Änderung, Systemmigration. Spalten: berechtigte Rolle, Vorbedingung, betroffene Datensätze, zulässige Unterschiede, automatische Schritte, Review-Auslöser und Einspruchsfrist.

Eine weitere Spalte zieht die Transaktionsgrenze. Welche Schreibvorgänge committen gemeinsam? Welche Veröffentlichungen folgen asynchron? Wo beginnt die Abhängigkeit von einer anderen Institution? Was wird isoliert, wenn nur ein Teil gelingt? Wann kann der Betreiber sicher ankündigen, zurückziehen oder Filter neu bauen?

Vor allem muss der Entzug alten Rechts von der Erzeugung neuer Absicht getrennt werden. Ein Transfer kann der Quellpartei die Änderungsbefugnis nehmen. Er ermächtigt APNIC nicht, den gewünschten Ursprungs-AS des Empfängers zu erraten. Eine BGP-Beobachtung darf warnen, aber nicht eigenständig eine ROA signieren.

Der Beleg muss einen Rollback überleben

Jeder folgenreiche Vorgang sollte einen versionierten Beleg erzeugen. Am Anfang stehen Ereignis- und Task-ID, Auslöser, Zeitpunkt und der Bestands-Snapshot, anhand dessen die Befugnis des Auftraggebers geprüft wurde. Danach folgen getrennte Vorher- und Nachher-Zustände für Routenvorlage, Whois-Objekte und ROAs.

Jede Änderung trägt eine typspezifische Vorrangregel und einen Reason Code. Der Beleg zeigt, welche Schritte gemeinsam committed wurden, welche Publikation pending blieb und welche Systeme außerhalb der APNIC-Kontrolle lagen. Bei Teilerfolg nennt er erfolgreichen und gescheiterten Schritt, letzten sicheren Zustand, Wiederholungsbedingung, Quarantäne und Kompensation.

Sichtbarkeit erhält eigene Zeitpunkte: Wann war das Whois-Objekt abfragbar? Wann wurde das RPKI-Objekt veröffentlicht? Wann sah eine unabhängige Validierung die Änderung? BGP kann als Hinweis beigefügt werden, nicht als Anweisung oder Erreichbarkeitsgarantie.

Inter-RIR, NIR, Deallokation und externes IRR erscheinen als Scope-Flags. Versandte Hinweise, Bestätigung, Review-Weg, Override und Serviceverantwortung werden festgehalten, ohne Schlüssel oder unnötige personenbezogene Daten offenzulegen. Ein Rollback löscht den Ursprungsvorgang nicht, sondern ergänzt ein verbundenes Ergebnis.

Dieser Beleg ist ein Vorschlag dieses Artikels, keine von APNIC angekündigte Funktion. Er verlangt auch nicht die Veröffentlichung jedes internen Logs. Er soll Betroffenen erlauben, beabsichtigte Differenz, laufende Propagation, vollständigen Erfolg und Teilerfolg auseinanderzuhalten.

Automatisierung ist nicht das Problem. Unsichtbare Entscheidungspolitik ist es. APNIC kann den manuellen Abgleich verringern. Bevor die Software jedoch einen Gewinner bestimmt, sollten Regeln und Ergebnis des Konflikts lesbar sein.

Quellen