Zusammenfassung

  • Im Beispiel von RFC 9735 fragt ietf.lisp mit 80 Bit an; zurück kommt das registrierte ietf mit 40 Bit. Die kürzere Mask-Len kennzeichnet eine weniger spezifische, nicht eine exakte Übereinstimmung.
  • Der AFI-17 Distinguished Name ist kein X.509-DN. Seine Bedeutung entsteht durch Instance-ID, Nutzungssyntax, Registrierungsprinzipal und Zulassungsregel.
  • Ein prüfbarer Ablauf bewahrt Rohbytes, NULL-Auswertung, beide Namen und Längen, Match-Klasse, Registrierungsautorität, Locator-Satz, Cache-Readback, Paketbeobachtung und Anwendungsergebnis getrennt.

Das System meldete Erfolg. Es hatte aber nicht denselben Namen zurückgegeben, nach dem gefragt worden war.

RFC 9735 macht daraus keinen Fehler. Eine DN-EID-Anfrage führt entweder zu einer exakten oder zu einer längsten Übereinstimmung. Gibt es nur eine weniger spezifische Registrierung, liefert der Map-Server deren Namen und deren kürzere Mask-Len.

ietf.lisp umfasst einschließlich NULL zehn Oktette und damit 80 Bit. ietf umfasst fünf Oktette und 40 Bit. Ein vollständiger Entscheidungsbeleg lautet daher ietf.lisp/80 → ietf/40, less_specific_match. Die Anzeige „Identität gefunden“ behauptet mehr.

Die Drahtidentität ist nicht der angezeigte Text

AFI 17 ist variabel lang und endet mit 0x00. Für ein EID zählt die Mask-Len das NULL mit; in LCAF kann ein explizites Oktettlängenfeld dasselbe leisten.

Erscheint NULL vor dem Feldende, darf eine Implementierung den Wert annehmen, muss aber spätere Oktette aus dem String ausschließen. Ein NULL unmittelbar nach AFI stellt den leeren String dar und muss syntaktisch angenommen werden.

Damit sind empfangene Bytes, deklarierte Länge, erstes NULL und interpretierter Text verschiedene Tatsachen. Ein normalisiertes Log mit nur role kann später nicht mehr zwischen role\0tail und role\0 unterscheiden. Es kann auch nicht zeigen, ob zwei Parser dieselbe Grenze angewandt haben.

Syntaktische Annahme ist keine Zulassung. Die lokale Nutzung darf leere Namen verbieten, Bereiche einschränken oder eine frühe Terminierung prüfen. Parser und Autorisierungsinstanz unterschreiben unterschiedliche Aussagen.

„Distinguished“ leiht keine Zertifikatsautorität

Der RFC schließt ausdrücklich eine Beziehung zum gleichnamigen PKIX/X.509-Feld aus. Ein LISP-DN kann Ressource, Funktion, Router, Ort, Public-Key-Hash-Format oder beschreibenden RLOC-Namen darstellen.

Lesbarkeit schafft weder globale Eindeutigkeit noch Eigentum. Der Schlüssel besteht aus Instance-ID, Anwendungsfall, Syntaxversion, codiertem Namen und Länge. Dazu kommen Registrierungsprinzipal, Zulassungsregel und Policy-Epoche.

Darum empfiehlt RFC 9735 getrennte Instance-IDs pro Anwendungsfall. Ein bloßes String-Register würde gleich geschriebene, aber institutionell getrennte Behauptungen zu einer scheinbaren Identität verschmelzen.

Eine gemeinsame Rolle kann viele Geräte enthalten

Die dokumentierte Betriebserfahrung beschreibt mehrere Proxy-ETRs, die einen gemeinsamen Rollen-DN mit eigenen Locators registrieren. Das Mapping System bildet daraus einen Locator-Satz und verteilt ihn auf Anfrage oder über RFC 9437.

Der Name bezeichnet damit absichtlich einen veränderlichen Pool. Ein Map-Reply belegt den publizierten Satz zu einem Zeitpunkt. Er belegt nicht die fortdauernde Rolle jedes Mitglieds, Pfadunabhängigkeit, Erreichbarkeit oder den Erfolg eines externen Dienstes.

Auch beim xTR-Onboarding hilft ein spezieller DN nur in einer bestimmten Stufe. Er kann die erste UDP-Registrierung und den Aufbau zuverlässigen Transports vorbereiten. Authentisierung, Zulassung, Session-Aufbau, Stabilität und Datenverkehr bleiben getrennte Belege.

Ein authentischer Kontrollsatz ist kein Betriebsnachweis

RFC 9735 übernimmt Sicherheitsbetrachtungen aus RFC 9301 und RFC 8060. Authentisierung kann den Absender einer Registrierung binden und die Schreibberechtigung im Namespace prüfen. Sie kann nicht den Cache eines ITR, die Hardwareprogrammierung, Locator-Erreichbarkeit oder die Anwendung vertreten.

Die Belegkette lautet: Bytes geparst; Registrierung zugelassen; Match klassifiziert; Antwort oder Notification empfangen; Cache geschrieben und gelesen; Locator gewählt; Paket beobachtet; Dienst abgeschlossen. Ein späterer Beleg erweitert die Aussage, ändert aber nicht den früheren Match-Typ.

Lu Hengs Reality Layers liefern dafür das Modell: Symbol, autorisierter Eintrag, laufender Zustand und beobachtetes Ergebnis sind verbunden, aber nicht austauschbar.

Die Minimum Initial Specification begrenzt außerdem institutionelle Ausdehnung. Interoperable Codierung kann gemeinsam sein, während Nutzungssyntax und spätere Entscheidungen lokal, sichtbar und austauschbar bleiben.

Quellen

Quellen