Zusammenfassung

  • RFC 9910 definiert rdap-down für unmittelbare Kinder, während rdap-bottom die spezifischsten Registerobjekte liefert, die den angefragten Bereich gemeinsam abdecken.
  • ARINs Live-Antwort für ein /21 enthielt ein aktives /22 und ein administratives /8; das /8 deckt den Rest ab und wird nicht zum Kind des /21.

Die scheinbar umgedrehte Schublade

Die Antwort wirkt zunächst hierarchisch unmöglich. Für 149.112.152.0/21 lieferte ARIN NET-149-112-152-0-1, eine aktive direkte Zuteilung als /22, und NET-149-0-0-0-0, ein administratives Objekt als /8.

Ein /8 kann kein spezifischeres Kind eines /21 sein. Das behauptet der Dienst auch nicht. Der Widerspruch entsteht, wenn „bottom“ als „alle Blätter unter diesem Knoten“ verstanden wird. RFC 9910 stellt eine andere Frage: Welche möglichst spezifischen registrierten Objekte decken den gesamten vom Client angegebenen INR-Wert gemeinsam ab?

Das /22 deckt nur die Hälfte des /21 ab. Für die übrigen Adressen ist das /8 in dieser Antwort das spezifischste verfügbare Registerobjekt. Deshalb überschneidet sich die Ergebnismenge. Sie partitioniert den Bereich nicht in disjunkte Nachfahren, sondern erklärt die registrierte Abdeckung.

Down ist nicht Bottom

Die Gegenprobe zeigt den Unterschied. rdap-down für dasselbe /21 lieferte ausschließlich die /22-Zuteilung. Diese Relation sucht die unmittelbar nächsten registrierten Objekte unterhalb des Eingabewerts. Das /8 ist kein unmittelbares Kind.

rdap-bottom berechnet dagegen Abdeckung. Decken spezifischere Objekte nur einen Teil ab, kann ein umfassenderes Objekt für die Restadressen in der Menge bleiben. RFC 9910 sagt ausdrücklich, dass Bottom-Objekte nicht disjunkt sein müssen und sogar weniger spezifisch als die Anfrage sein können. ARIN beschreibt dieselbe Regel: Reichen die gefundenen Bottom-Objekte nicht für den ganzen Wert, wird zusätzlich das spezifischste Netzwerkobjekt für den Rest zurückgegeben.

Damit muss ein Client den Registerbaum nicht selbst rekursiv aufbauen. Gefährlich wird erst eine falsche Darstellung. Nennt ein Dashboard jede Zeile „Unterzuteilung“, macht es aus dem Abdeckungsobjekt eine erfundene Kindbeziehung. Nicht das Präfix ist falsch, sondern das verlorene Auswahlmotiv.

Die tatsächliche Beweisgrenze

Die Ergebnisse sind ip network-Objekte mit Handles, Anfangs- und Endadressen, CIDR-Darstellung, RIR-spezifischem Typ und Status. Im Mitschnitt ist das /22 eine aktive DIRECT ALLOCATION; das /8 trägt den Status administrative.

Das sind Registereigenschaften. Sie beweisen weder BGP-Ankündigung noch Erreichbarkeit, Verkehr oder ROA-Autorisierung. Die optionalen ARIN-Arrays für Ursprungs-AS waren leer. Daraus folgt nicht, dass keine Route existiert; es ist nur der Zustand eines Feldes zu einem Abrufzeitpunkt.

RFC 9083 definiert das IP-Netzwerkobjekt als Registrierungsinformation. RFC 9082 beschreibt eine normale IP-Abfrage als Suche nach dem spezifischsten registrierten Netz, das den Anfragewert vollständig umfasst. Registergeometrie ist kein Betriebszustand.

Die Relation muss erhalten bleiben

Ein prüfbarer Datensatz speichert Relation, Eingabebereich, Abrufzeit, Handle, Grenzen, CIDR, Typ und Status. Dann ist das /8 verständlich: Es ist die Registerabdeckung für den Teil, den das /22 nicht erfasst.

BGP-Kollektoren, IRR-Routenobjekte, RPKI-Validierung und interne Adressverwaltung bleiben getrennte Beweisflächen. Bottom beschreibt Registerabdeckung, nicht Routerzugriff, Kontobeherrschung, Rechtstitel oder aktuell sichtbare Routen.

Ohne Relationsname wird eine korrekte Antwort zum erfundenen Delegationsbaum. Die sichere Bezeichnung ist wörtlich: Abdeckung durch die niedrigsten verfügbaren registrierten Objekte für den angefragten Bereich.

Quellen