Zusammenfassung

  • Der IRR Auto-Manager kann beim Anlegen einer ROA ein IRR-Routenobjekt erzeugen oder verknüpfen, lässt beiden Datensätzen danach aber bewusst getrennte Lebenszyklen.
  • ACSP 2026.9 verlangt für IRR-Objekte eine mit dem ROA-Verlauf vergleichbare Aktionshistorie. Zwei ähnliche Listen zeigen mehr, beweisen aber noch nicht, welche Einträge zu derselben Absicht gehören.
  • Ein begrenzter registerübergreifender Operationsbeleg kann Vorzustand, Wahl, Zuordnung, Ergebnis und Korrektur verbinden, ohne ROA-Autorisierung und RPSL-Deklaration zu vermischen.

ARIN hat mit dem IRR Auto-Manager ein unspektakuläres, aber häufiges Betriebsproblem gelöst. Eine Route Origin Authorization und ein Routenobjekt in einer Internet Routing Registry werden auf unterschiedlichen Oberflächen gepflegt und erfüllen verschiedene Zwecke. Wer dasselbe Präfix und dieselbe Ursprungs-AS zweimal erfasst, schafft zugleich eine zweite Gelegenheit, eine Änderung zu vergessen. Der Auto-Manager holt das passende route- oder route6-Objekt in den Ablauf der ROA-Erstellung und kann beide Datensätze verknüpfen.

Eine faire Analyse beginnt mit den Vorzügen. Die Automatisierung verringert Doppelarbeit, ohne die Wahl des Ressourceninhabers abzuschaffen. Der Dienst lässt sich für eine Org ID abschalten. Auch bei eingeschalteter Grundeinstellung kann der Nutzer die IRR-Erstellung in einem einzelnen Vorgang ablehnen. Findet das System bereits ein passendes, nicht automatisch verwaltetes Objekt, kann es ersetzt oder unverändert gelassen werden. Das Sync-Up-Werkzeug kann für bestehende ROAs fehlende Objekte anlegen oder vorhandene Objekte nachträglich verknüpfen.

Ebenso wichtig ist der eingebaute Ausgang. Ein IRR-Objekt kann unabhängig gelöscht werden, ohne die ROA anzutasten. Wird die ROA gelöscht, kann der Nutzer die verknüpften Objekte mitlöschen oder als nicht verwaltete Datensätze stehen lassen. Enthält eine ROA mehrere Präfixe, entsteht für jedes Präfix ein IRR-Objekt. Die Verbindung ist also weder unauflöslich noch immer eins zu eins.

Beide Datensätze sind auch inhaltlich nicht austauschbar. Eine ROA ist eine signierte Ursprungsermächtigung und kann mit maxLength festlegen, bis zu welcher Präfixlänge spezifischere Ankündigungen autorisiert sind. Ein IRR-Routenobjekt ist eine RPSL-Deklaration aus Präfix und Ursprungs-AS. Der Auto-Manager übersetzt maxLength nicht mechanisch in eine Reihe spezifischerer IRR-Objekte, sondern verwendet den Präfixeintrag. Diese Grenze schützt die unterschiedliche Bedeutung der Nachweise.

Auch die APIs zeigen die Trennung. Bei der Erstellung steuert roaSpec:autoLink, ob die Ressourcen der ROA mit passenden route- oder route6-Objekten verknüpft und diese bei Bedarf angelegt werden. autoLinked informiert in der Antwort über das Ergebnis. Die IRR-API erlaubt daneben eigenständige Objektoperationen. Ein gemeinsamer Arbeitsablauf macht aus zwei Datenmodellen nicht eines.

Damit lässt sich der bestehende Ansatz überzeugend verteidigen: ARIN automatisiert eine begrenzte Koordination, erhält Ablehnung und Ausstieg und behauptet keine semantische Gleichheit. Offen bleibt, ob der sichtbare Nachweis denselben Umfang hat wie der Vorgang, den das Produkt nun ermöglicht.

Was die ROA-Historie bereits leistet

ARIN beschreibt einen Origin AS/Prefix Pair Change Log für neue und geänderte ROAs einer Organisation in den vergangenen 365 Tagen. Mehr als 100 Einträge werden auf mehrere Seiten verteilt. Die Tabelle enthält Zeitpunkt, Operation, Quelle, Ursprungs-AS, Präfix, maximale Länge und Changed By. Als Operation erscheint Added oder Removed; als Quelle Web User, API User oder ARIN System. Ein vollständiges CSV kann per Ticket angefordert werden. ARIN will die Anfrage binnen zwei Arbeitstagen prüfen und beantworten; anschließend bleibt die Datei 90 Tage abrufbar.

Das ist mehr als eine Bestandsliste. Der Verlauf ordnet das Hinzufügen oder Entfernen eines AS-Präfix-Paares zeitlich ein und unterscheidet eine Webaktion von einem API-Aufruf oder einer Systemaktion. Eine Änderung kann durch die entfernten und hinzugefügten Paare dargestellt werden. Man sollte deshalb keinen zusätzlichen öffentlichen Operationswert Modified erfinden, den die Dokumentation nicht nennt.

Für IRR-Objekte beschreibt die geprüfte öffentliche Dokumentation keine gleichartige sichtbare Historie. Randal Kohutek reichte am 11. Mai 2026 den Vorschlag ACSP 2026.9 ein und bat um eine IRR-Aktionsprotokollierung auf dem Niveau der ROA-Protokollierung. Die Formulierung blieb vorsichtig: Das IRR-System „scheint“ eine solche Funktion nicht zu enthalten. Daraus folgt nicht, dass ARIN intern keine Datenbankhistorie, Sicherheitslogs oder Supportwerkzeuge besitzt.

Am 19. Mai stimmte ARIN zu, dass die Funktion Kunden helfen würde, die IRR-Aktionen verfolgen müssen. Der Vorschlag kam auf die Routing-Security-Roadmap für künftige Entwicklung, wurde an den internen Prozess zur Priorisierung und Umsetzungsplanung verwiesen und geschlossen. Eine Anerkennung und Zuordnung binnen acht Tagen ist konstruktiv. Sie ist jedoch weder Veröffentlichungstermin noch Schema, Lieferzusage oder Beleg einer bereits laufenden Funktion.

Gleiche Spalten ergeben noch keine gemeinsame Herkunft

Ein künftiger IRR-Verlauf mit Zeit, Quelle, Nutzer und Aktion würde die offensichtlichste Asymmetrie beseitigen. Der Betreiber hätte zwei Zeitleisten. Die entscheidende Diagnosefrage bliebe: Welche Zeilen gehen auf dieselbe Entscheidung zurück?

Beim Anlegen einer ROA kann ein passendes, nicht verwaltetes Objekt bereits existieren. Der Nutzer kann es ersetzen oder stehen lassen. Mehrere Präfixe führen zu mehreren Objekten. Später lässt sich das IRR-Objekt allein löschen. Beim Löschen der ROA können die IRR-Objekte verschwinden oder als nicht verwaltet fortbestehen. Sync Up kann neu erstellen oder nur verknüpfen. Jeder Zweig kann einen Endzustand hinterlassen, dessen Entstehung nicht mehr sichtbar ist.

Zeitliche Nähe ist ein Suchhinweis, kein Kausalitätsbeweis. Zwei Zeilen in derselben Sekunde können aus verschiedenen Anfragen stammen. Zwei zeitlich getrennte Zeilen können Teil eines Vorgangs mit Bestätigungsschritt sein. Ein fehlendes Objekt verrät nicht, welche Löschoption gewählt wurde. Ein vorhandenes Objekt verrät nicht, ob es absichtlich behalten oder später neu erzeugt wurde.

Selbst aktuelle Übereinstimmung beweist keine durchgehende gemeinsame Herkunft. Wird ein IRR-Objekt unabhängig gelöscht und später durch Sync Up neu erstellt, sehen die Datensätze am Ende wieder konsistent aus. Ein Wertevergleich zeigt den gegenwärtigen Zustand. Eine Operationslinie erklärt, wie er entstanden ist. Beides hat eine andere Aufgabe.

Diese Erklärung ist auch ohne bekannten Zwischenfall betrieblich relevant. ROAs können als signierte Eingaben der RPKI-Ursprungsvalidierung dienen. IRR-Daten können in die Erzeugung oder Prüfung von Routing-Policy-Filtern einfließen. Keiner der Datensätze beweist, was tatsächlich in BGP angekündigt oder von einem Router akzeptiert wurde. Bei einer Abweichung muss ein Ingenieur dennoch ausdrückliche Ablehnung, Altobjekt, unabhängige Löschung, Eins-zu-viele-Zuordnung, Teilergebnis und Korrektur unterscheiden.

Dafür braucht es keinen öffentlichen Strom sämtlicher Organisationsaktivitäten. Es braucht einen begrenzten Beleg für die autorisierte Organisation, auswertbar mit einem öffentlichen Schema.

Ein Beleg, der dem Vorgang folgt

Der Beleg beginnt mit einer opaken Operations-ID und einem Zeitpunkt. Er nennt die auslösende Oberfläche — ARIN Online, RPKI API, IRR API, Sync Up oder ARIN System — sowie eine Akteursklasse und die autorisierte Organisation, ohne unnötig einen persönlichen Namen zu veröffentlichen. Die Absicht wird strukturiert: ROA erstellen oder ändern, ROA löschen, IRR-Objekt erstellen oder verknüpfen, nicht verwaltetes Objekt ersetzen, IRR-Objekt separat löschen, als nicht verwaltet behalten oder neu synchronisieren.

Danach werden Vor- und Nachzustand verbunden. Auf der ROA-Seite gehören Handle, Ursprungs-AS, Präfix und maxLength dazu. Auf der IRR-Seite route- oder route6-Schlüssel, Präfix, Ursprung, Verwaltungsstatus und Verknüpfungsstatus. Bei mehreren ROA-Präfixen wird die Kardinalität festgehalten. Existierte ein Objekt schon, steht dort ausdrücklich, ob es wiederverwendet, ersetzt oder unverändert gelassen wurde.

Die Ausstiegsentscheidung braucht ein eigenes Feld. „ROA und verknüpfte Objekte löschen“ ist nicht dasselbe wie „ROA löschen und Objekte als nicht verwaltet behalten“. Abwesenheit darf nicht der einzige Nachweis sein. Gelingt eine Seite und scheitert die andere, sollte der Beleg beide Ergebnisse nennen und zeigen, ob der beabsichtigte Endzustand erreicht wurde. Eine spätere Korrektur verweist auf den ersetzten Beleg, statt den früheren Grund lautlos zu überschreiben.

API-Schlüssel, dauerhafte Personennamen oder die Historie einer fremden Organisation müssen dafür nicht öffentlich werden. ARIN kann intern detailliertere Sicherheitsdaten behalten, der autorisierten Partei einen strukturierten Beleg liefern und Schema, Aufbewahrungsregeln, Export und Versionsänderungen veröffentlichen. Prüfbarkeit in einer authentifizierten Beziehung ist keine grenzenlose Offenlegung.

Der Auto-Manager enthält bereits die richtige institutionelle Zurückhaltung: koordinieren, ohne zu verschmelzen; automatisieren, ohne den Ausgang zu versperren. ACSP 2026.9 markiert den nächsten Schritt. Die stärkste Umsetzung kopiert nicht nur Spalten. Sie macht nachweisbar, wann zwei Änderungen aus einem Vorgang stammen und wann sie unabhängige Entscheidungen waren, ohne einem Zeitstempel eine Aussage aufzubürden, die er nicht tragen kann.

Quellen