Zusammenfassung

  • ARIN beschreibt /rest/net/NETHANDLE/routes als Liste der Route-Objekte für das direkte NET; Subnetze werden ausdrücklich nicht einbezogen.
  • reassignments=true erweitert den Registrierungsbereich auf nachgelagerte NET-Einträge. Keine der beiden Sammlungen ist eine Live-BGP-Messung oder ein RPKI-Urteil.

Die leere Schublade des übergeordneten Blocks

Der Fehlschluss beginnt mit einem sauberen Ergebnis. Ein Betreiber fragt einen NET handle ab und erhält eine leere collection. Im Dashboard wird daraus schnell ein roter Status: keine Route, kein Origin-AS, vielleicht kein betriebenes Netz.

Die Abfrage hat jedoch nicht den ganzen Adressbaum durchsucht. ARIN legt fest, dass /rest/net/NETHANDLE/routes die durch Präfix und Origin gekennzeichneten Route-Objekte des direkten NET zurückgibt. Subnetze gehören nicht dazu. Geöffnet wird eine bestimmte Registrierungsschublade, nicht der gesamte darunter liegende Bestand.

Der Inhaber einer Direktzuteilung kann Adressraum an Kunden weiterzuweisen und diese Zuweisungen registrieren. Solche untergeordneten Einträge haben eigene handles und können mit eigenen IRR-Objekten verbunden sein. Eine leere Elternliste kann deshalb korrekt sein, während im nicht abgefragten Zweig sehr wohl Daten liegen.

Ein Parameter verschiebt den Rand

Für das NET und seine nachgelagerten Reassignments dokumentiert ARIN /rest/net/NETHANDLE/routes?reassignments=true. Der Parameter macht kein einzelnes Objekt wahrer. Er verändert die Menge der Registrierungen, die in der Antwort erscheinen können.

Beide Sammlungen verlangen außerdem, dass eine Route im IRR-System sichtbar und autorisiert ist. Sichtbar bedeutet hier nicht global in BGP beobachtet, von jedem Netz erreichbar oder verkehrsführend. Autorisiert im IRR bedeutet weder rechtliches Eigentum noch operative Kontrolle oder eine kryptografisch validierte aktuelle Origin-Aussage.

Die Antwortfelder halten die Behauptung eng: Eintragstyp, Organisations-handle, Origin-AS und Präfix. Collector, AS-Pfad, Beobachtungszeit, Verbreitungsgrad, Verkehr und RPKI-Status fehlen. Das ist kein Mangel, sondern die Grenze dieser Schnittstelle.

Registrierungsbaum und Routingbaum sind verschieden

RDAP bildet die administrative Hierarchie mit einem eigenen handle und einem möglichen parentHandle ab. Eine Direktzuteilung und eine nachgelagerte Zuweisung sind damit getrennte Registrierungsobjekte, auch wenn ihre Adressbereiche ineinander liegen. ARINs zwei Listenvarianten folgen dieser Grenze.

RPSL strukturiert eine andere Ebene. RFC 2622 definiert das Präfix und das Origin-AS gemeinsam als Schlüssel eines route-Objekts. Die Erklärung kann in den Bau von Filtern einfließen. Sie transportiert aber kein Paket, konfiguriert keinen Router und beweist keine derzeitige Ankündigung.

Eine ROA ist nochmals etwas anderes. ARIN und RFC 9582 beschreiben sie als kryptografisch signiertes Objekt, das einem AS die Originierung bestimmter Präfixe erlaubt. Eine gültige ROA stärkt eine Autorisierungsfeststellung, beweist jedoch nicht, dass die Route gerade angekündigt wird. Ebenso wenig wird eine IRR-Sammlung zu einem BGP-Feed.

Die Frage zusammen mit der Antwort speichern

Eine nachvollziehbare Prüfung hält NET handle, endpoint, Parameter und Abrufzeit fest. Die direkte Liste beantwortet eine Frage zum direkten Eintrag. Die Reassignment-Variante erweitert die administrative Hierarchie. Whois oder RDAP erklären Eltern- und Kindeinträge. RPKI behandelt kryptografische Autorisierung. Zeitgestempelte Routing-Collector zeigen, was bestimmte Beobachter tatsächlich gesehen haben.

Ist die direkte Liste leer, lautet die nächste Frage daher, ob der untergeordnete Zweig Teil der Abfrage war. Enthält die erweiterte Liste ein Objekt, muss weiter geprüft werden, welcher Eintrag und welches Präfix-Origin-Paar zugelassen wurden und welche unabhängigen Daten die heutige Nutzung belegen. Verlässlich bleibt das Ergebnis, solange sein Rand in der Schlussfolgerung erhalten bleibt.

Quellen