Zusammenfassung

  • Die vorgeschlagene Kennung irr0 umfasst sechs Abfragepfade; ein Route-Objekt wird mit Präfix und Ursprungs-AS gesucht.
  • Peering-, Router- und Filter-Sets darf die Implementierung weglassen. Auch die Policy-Liste in einer autnum-Antwort ist freiwillig.

Das neue Verfahren hätte eine schöne URL für ein Route-Objekt: irr0_route/192.0.2.0/24/64500. Es könnte Präfix und Ursprung in strukturiertem JSON zurückgeben. Der nächste Abruf einer Policy-Gruppe liefert vielleicht nichts. Wer daraus sofort einen Filter berechnet, müsste zuerst klären, ob die Gruppe leer ist oder die zuständige Objektklasse auf diesem Server gar nicht angeboten wird.

Der am 29. Oktober eingereichte Entwurf zur IRR-Erweiterung von RDAP stammt von Mahesh Aggarwal, Jasdip Singh, Andy Newton und Sasha Romijn. Er ist ein individueller Internet-Draft und kein verabschiedeter IETF-Standard. Heute beschreibt das RDAP-Abfrageformat zentrale Registrierungsobjekte; IRR-Routen und Routing-Policies werden häufig als RPSL-Text über WHOIS abgefragt. Der Entwurf will dafür einheitliche JSON-Klassen und HTTPS-Abfragen schaffen.

Vorgesehen sind route, route-set, autnum-set, rtr-set, peering-set und filter-set. Die zweigeteilte Route-Abfrage ist sachlich wichtig: Präfix und Ursprungs-AS bilden gemeinsam den Schlüssel. Das IRR-Handbuch von ARIN trennt Route-Objekte von Route-Sets; Letztere enthalten Präfixe oder andere Sets, nicht einfach eine Sammlung gespeicherter Route-Objekte. Diese Struktur darf ein RDAP-Client nicht glattbügeln.

Die Lücke steckt im Grad der Verbindlichkeit. Abschnitt 6 stellt es Implementierern frei, peering-set, rtr-set und filter-set anzubieten. Abschnitt 7 erlaubt ein optionales irr0_policies-Feld in bestehenden autnum-Antworten. Darin können Import- und Exportregeln stehen, einschließlich Multiprotokoll- und -via-Varianten; ihre Reihenfolge ist bei der Verarbeitung zu beachten. Ein fehlendes Feld belegt, dass diese Antwort keine Liste enthielt. Es belegt keine leere Routing-Policy im zugrunde liegenden IRR.

Unterstützende Server müssen irr0 in rdapConformance und in der Hilfe melden. Diese Kennung nennt die Erweiterung, nicht den Lieferumfang jeder optionalen Klasse. Die aktuelle RDAP-Dokumentation von RIPE NCC führt autnum, domain, ip und entity als unterstützte Grundtypen auf. Der Entwurf enthält weder eine Zahl laufender Installationen noch einen Vergleich der Vollständigkeit zwischen Registern. Ein Betreiber braucht deshalb einen Klassentest am konkreten Endpunkt, bevor er aus dessen Antworten Filter ableitet.

IRR-RDAP-Entwurf · RFC 9082 · RIPE NCC · ARIN