Zusammenfassung

  • LISP trennt EID und RLOC semantisch, macht Erreichbarkeit aber von einer Kette abhängig: berechtigte ETR-Registrierung, Auflösung im Mapping System, gültiger ITR-Cache, zulässige Locator-Wahl, erreichbarer Underlay-Pfad und interne Zustellung nach der Entkapselung.
  • David Meyer ist einer von mehreren Autoren der ursprünglichen und aktuellen Spezifikation. Seine Rolle belegt keine persönliche Souveränität über LISP, sondern die langwierige Übersetzung einer Architektur in Ablaufzeiten, Vertrauensgrenzen und überprüfbare Betriebszustände.

Der Ort steht nicht mehr in der Adresse

Die herkömmliche IP-Adresse trägt zwei Aufgaben in einem Wert. Sie bezeichnet einen Kommunikationsendpunkt und hilft dem Netz, dessen topologischen Platz zu finden. Für einen Standort mit mehreren Providern ist diese Doppelrolle unbequem: Eine stabile Kennung soll bleiben, während Anschluss und bevorzugter Weg wechseln.

Der Routing and Addressing Workshop von 2006 betrachtete genau diese Überlastung. RFC 4984 berichtet, dass die Teilnehmer sie als einen Faktor der Routing-Skalierung verstanden und eine Trennung für nötig hielten. Der Workshop entwarf sie nicht abschließend; sein Bericht war auch keine offizielle IAB-Festlegung. Er stellte die Frage schärfer, als er die Antwort lieferte.

RFC 9299 beschreibt LISP als eine mögliche Antwort. EID und RLOC sehen syntaktisch wie IPv4- oder IPv6-Adressen aus, besitzen aber unterschiedliche Bedeutungen. Der EID identifiziert einen Knoten unabhängig von seiner interdomänen Topologie. Der RLOC bezeichnet einen Anschluss im Underlay. Das Mapping System speichert die Zuordnung, Tunnel Router kapseln zum gewählten Ort.

Damit wandert Topologie aus dem Identifier in eine Infrastruktur, die ihren eigenen Lebenszyklus hat. Der Ort ist nicht länger im Namen enthalten, sondern muss abgefragt werden.

Sechs Beweise nach der Eindeutigkeit

Ein öffentlicher EID muss laut RFC 9300 eindeutig sein und aus einem zum Standort gehörenden EID-Prefix stammen. Mehr sagt diese Bedingung nicht. Sie bestätigt weder Eigentum noch menschliche Identität, Anbieterunabhängigkeit, aktuelle Registrierung oder Erreichbarkeit.

Zuerst muss ein ETR den EID-Prefix mit einem oder mehreren RLOCs verbinden und per Map-Register an einen Map-Server übermitteln. Dafür benötigen beide ein vorab konfiguriertes Geheimnis. Der Server sollte zusätzlich wissen, welche Prefixe dieser ETR registrieren darf. Ohne diese Prüfung wäre eine einfache Übernahme fremder EID-Bereiche möglich.

Ein sendender ITR sucht anschließend den Ziel-EID per Longest Prefix Match im lokalen Map-Cache. Bei einem Treffer erhält er ein Locator-Set. Bei einem Fehlschlag fragt er über einen Map-Resolver das Mapping System. Während der Auflösung kann die Implementierung Pakete verwerfen oder puffern. Diese lokale Entscheidung beeinflusst Verfügbarkeit und Ressourcendruck.

Die Antwort bleibt nur bis zum TTL gültig. Null erzwingt sofortige Löschung; ein Sonderwert überlässt die Dauer dem Empfänger. Der Cache enthält zudem Erreichbarkeitszustand. Ein aktueller Eintrag beim Map-Server und eine aktuelle Kopie in jedem entfernten ITR sind folglich verschiedene Tatsachen.

Das Locator-Set trägt Priority und Weight. Die niedrigste Priority gewinnt, 255 schließt den RLOC von der Weiterleitung aus. Bei gleicher Priorität verteilt Weight den Verkehr. Ein Dienst kann unter demselben EID seinen realen Weg ändern, obwohl kein Identifier geändert wurde.

Schließlich muss das Underlay den äußeren Header zum RLOC bringen. Der ETR entkapselt und leitet den inneren Header im Zielstandort weiter. Korrekte Registrierung, frischer Cache und richtige Auswahl können dennoch an einem fehlenden Underlay-Pfad oder einer internen Störung scheitern.

Ein verteiltes Verfallsdatum

RFC 9301 trennt Map-Server und Map-Resolver. Der Server lernt autoritative Zuordnungen von ETRs, der Resolver beantwortet die Anfrage des ITR über das Mapping System. Registrierungen werden regelmäßig erneuert und dürfen entfernt werden, wenn gültige Map-Register ausbleiben.

Eine Negative Map-Reply ohne Locator kann einen nicht registrierten EID, eine Policy-Ablehnung oder einen Authentisierungsfehler bedeuten. Die angeordnete Aktion kann native Weiterleitung, erneute Anfrage, Inaktivität oder Verwerfen sein. Wer alle Fälle als „Map fehlt“ darstellt, verliert Ursache und Sicherheitsbedeutung.

Bei einer Änderung kann der ETR mit Solicit-Map-Request jene ITRs zur Aktualisierung bewegen, die den Eintrag tatsächlich cachen. Absender und Empfänger müssen die Nachrichten begrenzen; ohne vorhandenen Cache ist keine vorsorgliche Anfrage sinnvoll. Konvergenz folgt aktiven Kopien, nicht einem sofortigen globalen Löschen.

RFC 9302 ergänzt für geschlossene, vertrauenswürdige Umgebungen eine optionale zwölf Bit breite Map-Version. Änderungen an RLOCs, Priority, Weight oder lokaler Erreichbarkeit können die Version erhöhen. Weil der Nummernraum umläuft, muss verhindert werden, dass ein sehr alter Wert neu erscheint—etwa durch Warten mindestens eines alten TTL. Im öffentlichen Internet verbietet RFC 9300, Map-Versioning, Gleaning, Locator-Status-Bits oder Echo-Nonce als Aktualisierungs- oder Reachability-Abkürzung zu verwenden. Dort gilt der Kontrollpfad.

Vor der Technik steht die Berechtigung

Die Sicherheitsbetrachtung von RFC 9301 nimmt ein sicheres, vertrauenswürdiges Mapping System und eine vorkonfigurierte Vertrauensbeziehung zu den ETRs an. Das System kennt die EIDs, die ein ETR melden darf. Wie Schlüssel und Rechte entstehen, liegt außerhalb des Dokuments. Diese Grenze ist kein Detail: Ein Protokoll kann Legitimität prüfen, wenn eine Institution sie zuvor zugewiesen hat.

RFC 9303 verlangt für die einschlägigen öffentlichen Einsatzfälle LISP-SEC. Es schützt Ursprung und Integrität der Lookup-Daten, verhindert Replay und prüft die Autorisierung von EID-Prefix-Behauptungen. So sollen Umleitung und Prefix-Overclaiming erschwert werden. LISP-SEC setzt dennoch voraus, dass das Mapping System die Anfrage zum beabsichtigten ETR bringt und der Map-Server die Berechtigung bei der Registrierung prüft.

Der stabile EID ist daher kein kryptografischer Ausweis. Seine Bindung an wechselnde RLOCs kann sogar eine Topologiegeschichte offenlegen. Kontinuität und Privatsphäre müssen getrennt abgewogen werden.

Meyers Anteil an einem Gemeinschaftswerk

RFC 9300 nennt Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis und den Editor Albert Cabellos. Meyer war schon Mitautor von RFC 6830. Die wiederholte Autorschaft erlaubt eine Langzeitperspektive, aber keine Einzelerfinder-Erzählung. Standardsprozess, Implementierung und Betrieb bleiben bei unterschiedlichen Personen und Institutionen.

ONUGs historisches Profil verzeichnet Stationen bei Cisco und Brocade, Arbeit im IAB und im NANOG-Programmkomitee sowie RouteViews an der University of Oregon. Diese Angaben sind zeitgebunden und keine Aussage über Meyers heutige Beschäftigung. Sie zeigen jedoch seine Nähe zu einer wiederkehrenden Frage: Wie lässt sich abstrakter Kontrollzustand öffentlich oder betrieblich überprüfen?

Ein vorhandener Artikel über Meyer beantwortet sie anhand von RouteViews, RPSL und OpenDaylight. Dieser Beitrag behandelt einen anderen Gegenstand: die Schreibberechtigung für EID-RLOC-Beziehungen, ihre lokale Haltbarkeit und die verbleibende Beweislast nach einer erfolgreichen Auflösung.

RFC 7215 liefert dafür eine operative Gegenprobe. Der Experimental-Leitfaden prüft Plattform, Konfiguration, MTU, Prefix-Zuteilung, RLOC-Erreichbarkeit, Registrierung und Schlüssel, Proxy-Caches, BGP-Richtlinien, externe Sichtbarkeit und Verkehr. Manche Übergangstechniken stammen aus dem Jahr 2014. Die Erkenntniskette ist zeitlos: Eine Spezifikation beweist keine Konfiguration, eine Konfiguration keine Registrierung und eine Registrierung keine Zustellung.

LISP macht einen Identifier nicht unabhängig von Infrastruktur. Es ermöglicht Infrastruktur, den Identifier trotz Ortswechsel weiter anzuerkennen. Dafür muss die Ortsbehauptung berechtigt, aktuell und bis zum inneren Ziel nachprüfbar bleiben.

Quellen