Zusammenfassung

  • Ein LSI ist ein lokal interpretierter Verweis auf eine Host Identity, kein tragbarer IP-Locator; dieselben Bits können auf einem anderen Host ohne Bedeutung sein oder jemand anderen bezeichnen.
  • Resolverentscheidung, Mapping-Epoche, HIT, Locator, gewählter Pfad, HIP-Assoziation, geschützte Daten und Anwendungsergebnis brauchen getrennte Nachweise.

Die ausgeliehene Form täuscht über den Vertrag

Eine nicht angepasste Anwendung erwartet eine IP-Adresse. Das HIP-fähige System gibt ihr einen Wert, der in dieselbe Struktur passt. Die Anwendung reicht ihn an connect() zurück, und der Stack übersetzt ihn. Für diesen kurzen Rundweg ist die Illusion vollständig.

Die Anwendung weiß jedoch nicht, dass sie einen Local Scope Identifier hält. Sie kann ihn speichern, vergleichen, als Callback veröffentlichen oder an einen Dritten weiterreichen. Damit nutzt sie die alte Form außerhalb des lokalen Vertrags, der ihr Bedeutung verlieh.

RFC 5338 unterscheidet ausdrücklich zwischen kurzlebigem lokalem Handle, langfristiger Zuordnung, Callback, Referral und Identitätsvergleich. Diese Kategorien sind keine Wortwahl. Sie markieren verschiedene Autoritäten. Was als lokaler Zeiger sicher ist, kann als verteilte Identität falsch sein.

Ein LSI adressiert eine Tabelle, nicht das Netz

Der RFC beschreibt den LSI als 32- oder 128-Bit-Wert, der an einer IPv4- oder IPv6-API lokal eine Host Identity darstellt. RFC 9063 erläutert, dass der typische 32-Bit-LSI im HIP-Layer oder Socket-Handler in einen HIT übersetzt und nicht als Locator über die Leitung geschickt wird.

Damit benötigt jede Interpretation den zuteilenden Host und die Mapping-Generation. Ein LSI ohne diese Angaben ist wie ein Dateideskriptor aus einem fremden Prozess: numerisch gültig, semantisch unzuständig. Ein zweiter Host kann denselben Wert einer anderen Identität zugeordnet haben.

Der lokale Verbindungserfolg beweist nur, dass die ursprüngliche Maschine ihren Schlüssel zu diesem Zeitpunkt lesen konnte. Er beweist nicht die Dauer des Mappings, die Verständlichkeit auf einem anderen Host, die Aktualität der Locator oder das Ergebnis des Dienstes.

Der DNS-Agent eröffnet eine Kette, er schließt sie nicht

RFC 5338 sieht einen lokalen DNS-Agenten vor, der bei vorhandenen HIP-Informationen einen LSI oder HIT statt einer gewöhnlichen Adresse liefert. Das System hält die Zuordnung und wandelt den Wert an oder unterhalb der Systemaufrufschnittstelle um.

Aus dieser Bequemlichkeit darf kein Sammelnachweis entstehen. Die Namensauflösung fand Identitätsmaterial. Der Host wählte eine Darstellung. Die Tabelle vergab ein Handle. Danach mussten Locator gefunden, ein Pfad ausgewählt, eine HIP-Assoziation hergestellt, Daten geschützt und die Anwendung bedient werden.

Auch die Reihenfolge der Resolverliste ist kein Pfadbeweis. HIP-basierte Bezeichner können zuerst stehen, während eine Anwendung alle Ziele parallel versucht. Eine gewöhnliche IP-Verbindung kann gewinnen. Wer HIP zwingend verlangt, muss Kandidaten einschränken oder den Sieger beobachten, statt aus der Liste auf die Ausführung zu schließen.

Diagnoseprogramme bilden einen weiteren Grenzfall. Ein Werkzeug, das reale IP-Locator untersuchen will, erhält durch transparente Interposition möglicherweise lokale Handles. Die Messung ist dann nicht falsch ausgeführt; sie misst ein anderes Objekt als der Benutzer erwartet. Der Eingriff muss sichtbar bleiben.

Beim Referral bleibt der Namensgeber zurück

B erreicht A über einen LSI und gibt diesen „Adresswert“ an C weiter. C erhält weder die Host Identity von A noch B's Mappingtabelle. Es erhält eine lokale Schlüsselnummer ohne Namensgeber.

Ein sauberer Fehler ist noch die harmlose Variante. C kann die Bits als normale IPv4-Adresse behandeln oder denselben LSI selbst einer anderen Host Identity zugeordnet haben. Dann besteht die Syntaxprüfung, während das Ziel wechselt.

Ein verteiltes Referral braucht deshalb eine Referenz, die der Empfänger autoritativ auflösen kann: HIT plus Auflösungsmechanismus, geprüfter Name oder ein Objekt mit Identität, Aussteller, Geltungsbereich und Frist. Übersetzt ein Vermittler den lokalen Wert, muss der Nachweis die Vermittlung nennen. Der Vermittler erweitert den Kontext; er ändert nicht rückwirkend die Natur des LSI.

RFC 9063 vergleicht die Problematik mit hostbasierter NAT. Anwendungen, die lokale Adressen in Protokolle einbetten, waren bereits gegenüber Übersetzungsgrenzen empfindlich. HIP macht sichtbar, dass das alte Feld Ort, Identität und lokalen Zeiger unzulässig vereinte.

Wiederverwendung schreibt ohne Epoche die Geschichte um

Legacy-Anwendungen können Resolverergebnisse länger cachen, als der HIP-Stack das Mapping halten will. RFC 5338 nennt deshalb die schwierige Garbage Collection von LSI-Bindings. Freigabe und Wiederverwendung können einen alten Verbraucher mit einer neuen Identität verbinden.

Für Protokolle ist das ein Laufzeitfehler; für Logs ist es eine Beweisverwechslung. Wenn LSI 17 heute Y zugeordnet ist, folgt daraus nicht, dass ein gestriger Eintrag mit 17 Y meinte. Eine Abfrage gegen die aktuelle Tabelle erzeugt eine scheinbar präzise, aber falsche Attribution.

Der RFC empfiehlt, HITs, LSIs, zugehörige IP-Adressen und FQDN-Kontext gemeinsam zu protokollieren. Operativ gehören Host, Boot- oder Mapping-Epoche, Zeit, Prozess, Socket und Policyentscheidung hinzu. Nur diese Kombination bewahrt die damalige Interpretation.

Sie beweist dennoch keinen Anwendungserfolg. Mapping, Assoziation, geschützter Verkehr und fachliche Antwort bleiben unterschiedliche Ereignisse. Eine gute Korrelation verbindet sie, ohne ihre Aussagebereiche zu verschmelzen.

Der explizite HIT stärkt den Namen, nicht das Ergebnis

Bei connect(ip) kann die sichere Lesart lauten: Verbinde mit dem System, das derzeit unter dieser Adresse erreichbar ist. Lokale Policy kann HIP einsetzen, doch die ursprüngliche Anfrage hat die Host Identity möglicherweise nicht stark benannt.

Ein expliziter HIT trägt stärkere Identitätssemantik. Trotzdem braucht er Locatorauflösung, abgeschlossenen Austausch, Schutzstatus, Datenfluss und Anwendungsantwort. Der Name allein beweist weder gegenwärtigen Schlüsselbesitz noch Dienstberechtigung oder Kapazität.

Damit bleibt die These von bestehenden HIP-Artikeln getrennt. Es geht nicht um RVS-Relay, DNS-Frische, Mobility-Locator oder ESP-Pfad. Es geht um die Autorität eines adressförmigen Symbols an einer Legacy-Grenze.

Wildcard-Bind verschiebt die Identitätswahl nach unten

Ein alter Server bindet häufig an eine Wildcard. Besitzt der Host mehrere Host Identities und nennt die Anwendung keine bestimmte, trifft lokale Policy die Wahl. RFC 5338 beschreibt einen UDP-Fall, in dem recvfrom() und das folgende sendto() zu verschiedenen Server-HITs führen; der Client kann die Antwort verwerfen.

Ein erfolgreicher Bind ist damit ein Listener-Nachweis, kein Beleg für Identitätskontinuität. Telemetrie sollte eingehenden lokalen HIT, ausgehenden HIT und Auswahlregel festhalten. Kann der Dienst keine Mehrfachidentität verarbeiten, sollte nur die zum Standardausgang passende Identität veröffentlicht werden.

Quellen und Beweisgrenze

Die Quellen belegen Spezifikationen, Architektur und historische Versuchserfahrungen. Sie belegen kein aktuelles Produkt, keinen Einsatz, keinen Vorfall, keine betroffene Organisation und keine gemessene Fehlerhäufigkeit.