Zusammenfassung

  • Ein am 29. Oktober veröffentlichter individueller Internet-Draft schlägt sechs RDAP-Pfade für Internet-Routing-Registry-Daten vor. Drei SET-Klassen und ein Feld für Routing-Policies sind ausdrücklich optional.
  • Die aktuelle /help-Antwort von RIPE NCC führt die Erweiterung irr0 nicht auf. Wer Whois ablösen will, muss deshalb die tatsächlich gelieferten Objekte je Server nachweisen.

Das Ausstiegsschild hat einen Stern

Auf der RIPE 93 sagte ein Netzbetreiber, die Unterstützung von RIR-Routing-Registry-Objekten sei das letzte fehlende Merkmal, auf das er vor dem Abschied von Whois warte. Jetzt liegt ein Entwurf vor. Auf dem Weg nach draußen steht weiterhin ein Sternchen: Drei der dort skizzierten Objektklassen muss kein Server anbieten.

Am 29. Oktober veröffentlichte der IETF Datatracker draft-aggarwal-regext-rdap-irr-00. Zu den vier Autoren gehören Mahesh Aggarwal von RIPE NCC und Jasdip Singh von ARIN. Der Titel verspricht eine RDAP-Erweiterung für Internet Routing Registry (IRR)-Objekte. Die Idee: RPSL-Daten über strukturierte JSON-Antworten und HTTPS zugänglich machen, damit Clients nicht länger zwischen verschiedenen Abfragewegen springen müssen.

Der Entwurf definiert sechs Pfadsegmente: irr0_route, irr0_routeSet, irr0_autnumSet, irr0_rtrSet, irr0_peeringSet und irr0_filterSet. Eine route-Abfrage nutzt Präfix und Origin-ASN als Schlüssel. Eine autnum-Antwort kann Import- und Export-Policies in Reihenfolge enthalten, darunter Mehrprotokollvarianten sowie import-via und export-via.

Dann kommt der Haken, direkt im Normtext. Die Unterstützung von peering-set, rtr-set und filter-set bleibt dem Implementierer überlassen. Auch das Feld irr0_policies in einer autnum-Antwort ist optional. Ein Client kann die neue RDAP-Sprache beherrschen und trotzdem an einem Server landen, der genau die Objektklasse nicht ausgibt, die ein täglicher Filter braucht. Sechs Namen im Entwurf sind noch keine sechs laufenden Dienste.

Das ist mehr als eine Frage des JSON-Formats. ARIN beschreibt seine IRR-Datenbank als getrennt von den öffentlichen Whois-Daten: Ressourceninhaber reichen RPSL-Objekte ein; andere IRRs rufen sie für Routingentscheidungen ab. ARIN nennt drei Abrufwege: Near Real-Time Monitoring (NRTM), Dateidownload und Whois über Port 43. Für den eigenen NRTM-Datenstrom bezeichnet ARIN bestimmte Objekte als „authorized“ und erläutert dafür Bedingungen rund um Ressourcenregistrierung und Objektpflege. Diese Beschreibung gilt für ARINs eigenen Datenstrom; sie ist kein Gütesiegel für jede IRR-Datenbank.

Die RIPE-Database-Dokumentation führt derzeit vier RDAP-Typen auf: autnum, domain, ip und entity. Die geprüfte /help-Antwort kündigt mehrere andere Erweiterungen an, aber kein irr0. Das ist ein zeitgebundener Blick auf den RIPE-NCC-Endpunkt; für ARIN und andere Server wäre eine eigene Abfrage nötig. Für RIPE lässt sich der Abstand zwischen Entwurf und Dienst immerhin konkret benennen.

Auch der Status des Dokuments ist eindeutig. Der Datatracker kennzeichnet es als individuellen Internet-Draft, der nicht von der IETF unterstützt wird und im IETF-Standardisierungsprozess keinen formalen Status besitzt. Der IESG-Status lautet I-D Exists. Der nächste Beleg muss aus einem funktionierenden Endpunkt kommen, nicht aus einer weiteren Zeichnung.

JSON ist nur die halbe Migration

Ein gemeinsamer Antworttyp kann Parser vereinheitlichen und wiederkehrende Abfragen vereinfachen. Er nimmt den Daten aber nicht ihre Herkunft. Ein IRR-route-Objekt dokumentiert Routing-Policy-Daten; es beweist nicht, dass ein Präfix gerade über BGP angekündigt oder von Netzen angenommen wird. Bleiben beim Umbau die Mitglieder einer SET-Klasse oder die Reihenfolge einer Policy auf der Strecke, ist die Antwort zwar gültiges JSON. Der Betrieb hat trotzdem ein schlechteres Werkzeug.

Der Entwurf verlangt, dass ein Server mit Erweiterungsunterstützung irr0 in rdapConformance und in seiner Hilfe-Antwort bekannt gibt. Clients können diese Angabe auswerten. Sie ersetzt keinen Klassentest. Betreiber müssen die verwendeten Objekte einzeln abfragen und die RDAP-Felder mit den RPSL-Ausgaben desselben Servers vergleichen: Mitglieder, geordnete Policies, Entity-Verweise sowie Erstellungs- und Änderungsereignisse.

Der Datenschutzabschnitt weist darauf hin, dass solche Abfragen Personen in der Datenbank betreffen können und Betreiber die geltenden Einschränkungen berücksichtigen sollen. Ein einheitlicher Lesezugang entscheidet noch nicht, welche Kontaktdaten offenliegen.

Für die Ablösung von Whois braucht es deshalb einen Umsetzungsnachweis je Server: beworbene Erweiterung, gelieferte Objektklassen, Verhalten optionaler Felder und Abweichungen von RPSL. Bis dieser Vergleich reproduzierbar ist, bleibt der alte Abfrageweg Teil des Betriebs. Whois nach einem erfolgreichen Test mit einem Standard-route-Objekt abzuschalten, wäre so, als schlösse man das Lager, weil die Eingangstür aufgeht.

Auf der RIPE 93 bat der Betreiber die Kollegen, gerade die Objekte aus ihrem täglichen Betrieb zu prüfen. Damit lässt sich anfangen. „Wir haben RDAP“ beantwortet die Frage nach dem Protokoll. Ein tragfähiger Abschied von Whois verlangt den Nachweis, dass die benötigten Datensätze vollständig ankommen.

Quellen