Zusammenfassung

  • RFC 9962 lässt beteiligte xTR das EID-zu-RLOC-Mapping von LISP gemeinsam führen. Push repliziert Registrierungen über Multicast; Pull findet Map-Server-Mengen mit einer konsistenten Umformung und DNS.
  • Karte, authentisierte Registrierung und Verarbeitungsbestätigung sind begrenzte Belege der Kontrollebene. RFC 9301 sagt ausdrücklich, dass RLOC-Status nicht die Pfaderreichbarkeit aus Sicht des Anfragenden ausdrückt.

LISP trennt den Endpoint Identifier, der einen adressierten Endpunkt im Overlay benennt, vom Routing Locator, der eingekapselten Verkehr trägt. Dazwischen braucht es ein Mapping-System. Im üblichen Modell betreibt ein Mapping System Provider Map-Resolver und Map-Server; xTR der Datenebene registrieren oder fragen dort Zuordnungen ab. RFC 9962 macht die Zuordnung nicht zu einer herrenlosen Tatsache. Es verändert, wer diesen begrenzten Datensatz speichert und ausliefert: xTR, die die Karte nutzen, können zugleich die Peers sein, die sie halten.

Das ist eine Änderung der Abhängigkeitsstruktur, keine Gesamtbehauptung über das Ergebnis. Nach RFC 9301 schickt ein ETR einem Map-Server in einem Map-Register ein EID-Präfix und eine Menge von RLOCs. Fordert er Map-Notify an, erhält er die Bestätigung, dass der Server die Registrierung empfangen und verarbeitet hat. Empfangen, verarbeitet und bestätigt bezeichnen konkrete Kontrollhandlungen. Sie bedeuten nicht, dass jeder Anfragende den Weg zu diesem RLOC erreichen kann, dass der Rückweg funktioniert oder dass der Dienst hinter der Adresse weiterhin zu einer betrieblichen Verpflichtung passt.

RFC 9301 zieht eine entscheidende Grenze: RLOC-Status kann Erreichbarkeit mitteilen, nicht aber Pfaderreichbarkeit aus der Perspektive des Anfragenden; dafür bleibt ein separater Pfadtest nötig. Ausgangspunkt, Kapselung, Filter, Rückweg, Überlastung, Umschaltung und Dienstpolitik können dieselbe Zuordnung unterschiedlich wirken lassen. Eine korrekte Karte kann daher auf einen unbrauchbaren Pfad führen. Auch ein an einer Adresse eingetroffenes Paket löst keine Frage der Endpunktidentität, geschäftlichen Berechtigung oder betrieblichen Annahme.

Die beiden Entwürfe in RFC 9962 machen die Grenze sichtbar. Im Push-Modell treten xTR derselben Multicast-Gruppe bei, und ein Map-Register kann an alle Map-Server der Gruppe gehen, die registrierten Zustand repliziert halten. Das schafft Redundanz, verlangt aber ein tatsächlich funktionierendes Multicast-Unterlager. Im Pull-Modell wandelt eine deterministische Funktion den EID in einen DNS-Namen um und findet so die zugehörige Map-Server-Menge. Es repliziert weniger Zustand, verlangt jedoch anhaltende Übereinstimmung über Funktion, Namen, Modulus und Skalierung. Beides sind nicht frei mischbare Bausteine.

RFC 9962 verlangt eine Wahl; bei Koexistenz bleiben es getrennte Mapping-Systeme ohne gegenseitige Kompatibilitätszusage.

Auch Authentisierung hat einen Umfang. RFC 9962 verweist für Vertrauen zwischen xTR auf RFC 9301 und ECDSA-AUTH. RFC 9301 schützt Herkunft und Integrität eines Map-Registers, nutzt Nonces gegen Wiederholung und erlaubt dem Map-Server, Registrierungen abzulehnen, die Schlüssel oder Politik nicht erfüllen. Damit wird die Frage zurechenbar: Wer legte welche Registrierung vor und was tat das System? Es beweist nicht die Identität des Endpunkts, das Recht zur Kundenbedienung, die Pfadqualität oder zukünftige Lieferung. Ein Schlüsselnachweis deckt eine Protokollhandlung ab, nicht alle Folgen.

Aus Lu Hengs Perspektive minimaler Anfangsmechanismen und lokal verbleibender späterer Entscheidungen liegt der Wert von RFC 9962 darin, Koordination näher an Teilnehmer zu bringen, ohne ihr die Macht zu geben, für sie zu entscheiden. Eine gemeinsame Karte kann Entdeckungs- und Registrierungskosten senken. Sie darf nicht allein dadurch Verkehr, Kundenexposition, Fehlertoleranz oder Ausstieg wählen. Die Leitungsfrage lautet nicht, ob „dezentral“ gut klingt, sondern welche Abhängigkeit sich änderte, welcher Eintrag prüfbar bleibt und wer das letzte Urteil behält.

Quellen