Zusammenfassung

  • ACSP-Vorschlag 2026.3 berichtete für einen bestehenden ROA /16 mit maxLength /24 eine klare Grenze: gleiche Origin AS und Längen /16 bis /24 seien redundant, /25 bis /32 dagegen weiterhin anlegbar.
  • ARIN erklärte die Anregung nach einer FAQ-Änderung für umgesetzt; das heutige Beispiel spricht nur von „any prefix covered“ und übernimmt weder das gesperrte Intervall noch den erlaubten Gegenfall.
  • Ein versionierter Beleg mit fünf Semantiktests könnte die gemeinsame Regel von Weboberfläche, REST und OT&E nachweisen, ohne Quellcode, Schlüssel oder Kundendaten offenzulegen.

Die schnelle Reaktion ist ein echter Pluspunkt

Chris Woodfield reichte am 13. Januar 2026 den ACSP-Vorschlag 2026.3 ein. Der Hinweis war ungewöhnlich gut prüfbar: Er zitierte die missverständliche Passage, beschrieb ein beobachtetes Verhalten, benannte die genaue Abweichung und bot eine neue Formulierung an.

Am 18. Februar teilte ARIN mit, die FAQ sei angepasst worden, um die Verwirrung zu beseitigen. Anschließend wurde der Vorgang als abgeschlossen markiert. Etwa fünf Wochen für eine öffentliche Dokumentationskorrektur sind ein gutes Ergebnis. Der Einreicher bleibt genannt, seine Begründung ist lesbar, und die Antwort verschwindet nicht hinter einer unverbindlichen internen Planung.

Auch die Produktentscheidung hat eine plausible Grundlage. Seit Hosted ROAs automatisch erneuert werden, muss ein Betreiber nicht länger vorsorglich ein zweites, inhaltsgleiches Objekt anlegen, bevor das erste ausläuft. Einträge ohne zusätzliche Ursprungsautorität können die Übersicht verstopfen und Änderungen oder Löschungen fehleranfälliger machen. Eine strengere Annahmeregel darf daher die Bedienung vereinfachen.

Die offene Frage lautet nicht, ob ARIN diese Regel anwenden darf. Ein gehosteter Dienst muss nicht jede Konstruktion akzeptieren, die das allgemeine RPKI-Objektformat zulässt. Es geht darum, ob die öffentliche Abschlussakte beweist, welche präzise Regel mit der Korrektur geliefert wurde.

Der Vorschlag brachte seinen Abnahmetest schon mit

Die im Vorgang zitierte alte FAQ begann mit einem ROA für /16 und maxLength /24. Danach sollte ein weiterer ROA mit derselben Origin AS für jeden innerhalb des /16 liegenden Präfix verhindert werden. Der Einreicher erklärte, seine Tests hätten eine engere Regel gezeigt.

Bei derselben AS seien neue Längen von /16 bis /24 bereits vom vorhandenen Objekt autorisiert und deshalb redundant. Präfixe von /25 bis /32 lägen zwar adressseitig ebenfalls innerhalb des /16, reichten aber über die bestehende Maximallänge hinaus. Dem gemeldeten Test zufolge konnten dafür neue ROAs angelegt werden.

Der vorgeschlagene Text ersetzte „overlapping“ durch „redundant“ und behielt beide Seiten der Grenze. Gerade der erlaubte /25-Fall war wichtig. Er trennte die geometrische Enthaltensein-Beziehung von der tatsächlich gewährten Autorität und machte die Aussage mit je einem Test vor und hinter /24 reproduzierbar.

Die aktuelle RPKI-FAQ erklärt, Auto-Renew habe Duplikate überflüssig gemacht, und ROAs dürften sich nicht mehr überlappen. Das Beispiel verwendet weiterhin /16, maxLength /24 und dieselbe Origin AS. Es fasst die abgelehnte Menge aber als „any prefix covered in the existing ROA“ zusammen. Das Intervall von /16 bis /24 fehlt; der Gegenfall von /25 bis /32 ebenfalls.

Dieser Textvergleich belegt keinen Implementierungsfehler. Für diese Analyse wurde weder ein Kundenkonto genutzt noch eine authentifizierte Produktionsoperation ausgeführt. Das Januarverhalten ist der Bericht des Einreichers. ARIN kann intern über vollständige und korrekte Tests verfügen; „covered in“ kann als alltagssprachliche Kurzform für „bereits autorisiert“ gemeint sein. Öffentlich lässt sich diese Lesart nur nicht eindeutig feststellen.

Im RPKI sind „Covered“ und „Matched“ verschiedene Prüfungen

RFC 6811 definiert einen Routenpräfix als von einem VRP Covered, wenn der VRP-Präfix gleich oder weniger spezifisch ist und die maßgeblichen Adressbits übereinstimmen. Die maximale Länge spielt bei dieser Prüfung keine Rolle. Matched ist die Route erst, wenn sie zusätzlich nicht länger als das VRP-Maximum ist und ihre Origin ASN mit der VRP-ASN übereinstimmt.

Die FAQ schreibt covered nicht als ausgewiesenen Normbegriff. Vermutlich ist gewöhnliches Englisch gemeint. Für technisch geschulte Leser stehen dennoch zwei plausible Bedeutungen nebeneinander. Ein /25 unterhalb eines /16 ist adressseitig Covered, wird aber von einem VRP mit maxLength /24 nicht Matched — auch nicht bei gleicher ASN. Das gestrichene Gegenbeispiel löste genau diese Mehrdeutigkeit.

RFC 6482 beschreibt die signierte Objektseite. maxLength bezeichnet den längsten Präfix, den die angegebene AS ankündigen darf; ohne dieses Feld gilt nur der exakte Präfix. Der RFC erlaubt in einem gültigen ROA zudem einen Präfix, der von einem anderen Eintrag umfasst wird, sowie sogar identische Präfixeinträge. Ein kürzeres maxLength, das keine zusätzliche Autorität erzeugt, wird lediglich nicht empfohlen.

Daraus folgt kein Verstoß ARINs. Objektgültigkeit, Routenvalidierung und Produktannahme sind unterschiedliche Ebenen. ARIN darf für seinen Dienst eine aufgeräumte Teilmenge wählen. Weil diese Grenze eine Produktregel und keine zwangsläufige RFC-Folge ist, sollte sie jedoch als solche testbar dokumentiert sein.

Drei Oberflächen nennen die Eingaben, nicht die Entscheidung

Der ARIN-Leitfaden zu ROAs nennt Origin AS, Präfix und maximale Länge als Bestandteile. Er wiederholt, Duplikate und Überlappungen seien nicht erlaubt, und verweist für mehr Informationen auf die FAQ. Eine Grenzfallmatrix enthält die Seite nicht.

Der RPKI-REST-Leitfaden dokumentiert einen einheitlichen Aufruf zum Erstellen, Ändern und Löschen von ROAs. Er lässt sich atomar mit ASPA-Operationen verbinden: entweder gelingt alles oder nichts. Im Payload stehen startAddress, cidrLength und optional maxLength. Fehler werden an die allgemeine Fehlerdokumentation verwiesen; die eingefrorene Seite formuliert das Redundanzprädikat nicht.

Gerade die Atomarität erzeugt einen zusätzlichen Testfall. Löscht eine Transaktion den alten ROA und legt den Ersatz an, wird die Redundanz gegen den Anfangszustand, den beabsichtigten Endzustand oder einen internen Zwischenschritt geprüft? Der Dienst muss dafür ein konsistentes Modell besitzen. Vorprüfende Clients brauchen dasselbe Modell, weil ein abgelehntes Element die gesamte Transaktion scheitern lässt.

ARIN stellt mit OT&E eine sichere Versuchsumgebung bereit. Nach eigener Beschreibung bietet sie denselben Funktionsumfang wie die Produktion, ermöglicht Test-ROAs und die Validierung von RPKI-Transaktions-Payloads, ist aber nicht mit dem Produktivsystem verbunden. Die Daten werden monatlich aus einem Snapshot ersetzt; E-Mail-Interaktionen fehlen, und das System wird nicht aktiv von ARIN-Mitarbeitern überwacht.

OT&E ist ein guter Reproduktionsort, aber kein dauerhafter Vertrag. Nach einem Refresh kann der Ausgangszustand wechseln, nach einem Release das Verhalten. Ohne Eingabetupel, Erwartung, Build und Datum bleibt ein erfolgreicher Test eine flüchtige Erfahrung.

Ein Fünf-Zeilen-Beleg würde die Lücke schließen

Der Beleg braucht nur Vorschlagsnummer, Dokumentrevision, Regelversion und Wirksamkeitsdatum. Pro Zeile genügen Kanal, vorhandene Origin AS, Präfix und maxLength, beantragte AS und Länge, erwartetes Ergebnis und stabiler Grundcode. OT&E-Version und Testdatum schaffen Wiederholbarkeit; spätere Änderungen verweisen auf die ersetzte Fassung.

Fünf Fälle decken den Kern ab: identischer Präfix und gleiche AS; spezifischer Präfix innerhalb von maxLength; spezifischer Präfix jenseits von maxLength; derselbe Adressraum mit anderer Origin AS; atomare Transaktion aus Löschung und Ersatz. Dokumentationsnetze und reservierte ASNs reichen aus. Kundendaten, Produktionsschlüssel und Quellcode bleiben geschützt.

Die FAQ darf kurz bleiben. Der verlinkte Beleg trägt die Präzision. Er trennt die redaktionelle Tatsache einer Textänderung, die technische Tatsache eines Annahmeverhaltens und die Governance-Aussage, dass der abgeschlossene Vorgang die beantragte Klärung geliefert hat.