Zusammenfassung

  • RFC 3102 ließ einen Host eine ganze öffentliche Adresse oder eine geteilte Adresse mit Ports verwenden; Ressourcenpool, bind, Lease und Policy blieben unter Kontrolle des Gateways.
  • Sichtbare öffentliche Parameter lösten den Pfad nicht. Der Host musste lokale Ziele vom öffentlichen Tunnel unterscheiden, und für realmübergreifende Mehrparteienanwendungen gab es keine allgemeine Lösung.

Die öffentliche Adresse wurde Hostzustand

Traditionelles NAT traf seine Entscheidung am Rand. Der Host baute ein Paket mit privater Quelladresse, der Übersetzer änderte Adresse oder Port und suchte für die Rückrichtung die passende Abbildung. Das schonte den Host, scheiterte aber an Protokollen, die Adressen im Inhalt transportierten oder unveränderte Header verlangten.

Die im Oktober 2001 veröffentlichten RFCs 3102 bis 3105 verteilten die Arbeit anders. Ein RSIP-Host verhandelte zuerst mit einem Gateway zwischen zwei Adressräumen. Er installierte die gewährten öffentlichen Parameter in seinem Stack, baute das innere Paket mit der geliehenen Quelle und tunnelte es zum Gateway. Dort wurde die äußere Kapsel entfernt, ohne die innere Quelle erneut zu übersetzen.

RSA-IP verlieh für eine bestimmte Zeit eine vollständige öffentliche Adresse exklusiv an einen Host. RSAP-IP teilte eine Adresse unter mehreren Hosts und gab jedem eigene Ports. Im ersten Fall erhielt der Host vorübergehend die ganze Anschrift, im zweiten nur bestimmte Eingänge derselben Anschrift.

Beide Verfahren machten den Parameter sichtbar. Keines übertrug dauerhaftes Eigentum oder vollständige Kontrolle. Das Gateway verwaltete den Pool, entschied über Zuteilung und konnte eine Nutzung begrenzen oder beenden.

Eine Zuteilung bestand aus mehreren Belegen

RFC 3103 beschrieb Registrierung und Lebenszyklus. Ein Host erhielt eine Client-ID. Eine Zuteilungsantwort konnte Adresse, Ports, Bind-ID, Lease-Dauer, Tunneltyp und Flow-Policy enthalten. Weitere Nachrichten verlängerten, fragten ab, beantragten eingehenden Dienst, gaben frei oder meldeten ab.

Jede Aufzeichnung hatte eine enge Aussage. Registrierung bedeutete, dass das Gateway die Clientsitzung kannte. Die Zuteilung genehmigte bestimmte Ressourcen unter Bedingungen. Das bind verband private Hostinformation und öffentliche Parameter. Das Lease setzte eine Zeitgrenze. Die Policy beschränkte Gegenstellen.

Keine dieser Tatsachen bewies die nächste. Eine Antwort bewies keine installierte Route. Ein bind bewies keinen funktionierenden Tunnel. Ein ausgesendetes Paket bewies keine Zulassung am Gateway. Ein weitergeleitetes Paket bewies keine Rückkehr. Erst Beobachtungen über die gesamte Kette belegten den Dienst.

Der Host durfte eine Adresse oder einen Port vorschlagen, das Gateway aber wegen Belegung, Knappheit oder Policy ablehnen. Pakete mit nicht zugeteilten Adressen, Tupeln, Gegenstellen oder Tunneln mussten verworfen werden. Der Host schrieb die öffentliche Quelle; das Gateway entschied, ob sie zu einem gültigen Grant gehörte.

Lokalität musste vor jedem Pfadentscheid bekannt sein

Mit dem öffentlichen Parameter kam eine neue Pflicht: Der Host musste entscheiden, ob das Ziel direkt im privaten Netz lag oder über RSIP-Interface und Tunnel erreicht werden sollte. In einem einfachen Subnetz reichte die Maske. In größeren Netzen konnte das Gateway Listen privater Netze führen und Anfragen beantworten.

Diese Auskunft alterte mit dem Routing. Änderte sich die Topologie schneller als die Sitzung, konnte für jedes Ziel eine neue Anfrage nötig werden. RFC 3102 hielt ausdrücklich fest, dass eine robuste allgemeine Lösung schwer zu entwickeln war und die praktische Schwere des Problems nicht feststand.

Mehrparteienanwendungen verschärften den Konflikt. Ein Teilnehmer konnte eine IP-Adresse als globalen Endpoint weitergeben, ohne den Blickwinkel des Empfängers zu kennen. Die private Adresse war außen unbrauchbar; die öffentliche konnte lokale Partner unnötig über das Gateway führen. Eine bekannte allgemeine Lösung gab es nicht.

Eine Adresse allein trug also zu wenig Kontext. Standort des Beobachters, aktuelle Route und Hostpolicy gehörten zur Bedeutung. RSIP machte die Leihe ausdrücklich, nicht die Lokalität universell.

Das Lease endete früher als mancher Protokollzustand

Die Zeitbegrenzung gab Ressourcen zurück und begrenzte Hostbefugnisse. Ein Host konnte verlängern oder freigeben; das Gateway konnte auslaufen lassen oder entziehen. Der administrative Zeitpunkt löschte Transportzustand jedoch nicht automatisch.

TCP konnte ein altes Tupel in TIME_WAIT halten. Wurde dieselbe Adresse-Port-Kombination sofort neu verliehen, konnten verspätete Pakete oder Schutzmechanismen der alten Verbindung die neue Nutzung berühren. Lease-Ende und sichere Wiederverwendung waren verschiedene Ereignisse.

Ausfälle trennten auch die Erinnerungen. Nach einem Hostneustart konnte das Gateway Bindings kennen, die der Host vergessen hatte. Nach einem Gatewayneustart konnte der Host Zuteilungen verwenden wollen, die der Server verloren hatte. RFC 3103 definierte Austausch zur Rekonstruktion, machte aber keine Seite allein zur Wahrheit.

Eine belastbare Chronik bewahrt Beginn, Verlängerung, Freigabe oder Ablauf, beide Neustarts und das erste nach dem Abgleich akzeptierte Paket. Dieselbe Adresse kann zu verschiedenen Generationen von Autorität gehören.

Geteilte Adresse und Identität fielen auseinander

Bei RSA-IP ähnelte dynamisches DNS dem DHCP-Fall: Ein Host hielt für eine Zeit die ganze Adresse. Bei RSAP-IP konnten mehrere Namen auf eine Adresse zeigen, obwohl unterschiedliche Ports zu unterschiedlichen Hosts führten. Ein externer Partner konnte fälschlich alle Dienste einem logischen Host zuschreiben. RFC 3102 riet zur Vorsicht bei der Verbindung mit dynamischem DNS.

RFC 3104 zog dieselbe Grenze bei IPsec. Mehrere RSIP-Clients konnten eine öffentliche Adresse teilen und IKE/IPsec zu einem RSIP-unwissenden Partner beginnen. Die sichtbare Quelladresse durfte nicht als Identität des Peers gelten; IKE-Identifikatoren mussten den tatsächlichen Client bezeichnen.

Eingehende IKE-Antworten ließen sich über Zielport, Initiator-Cookie und Zieladresse trennen. AH oder ESP verwendeten Protokoll, SPI und Zieladresse. Der SPI musste sowohl beim Client als auch im gemeinsamen Gatewayraum eindeutig sein. Die Adresse blieb Locator, nicht kryptografisches Subjekt.

Auch das war begrenzt. Die Erweiterung behandelte vor allem clientinitiierte Sitzungen, verlangte Anpassungen der IPsec-Implementierung und versprach keine unveränderte Funktion von bump-in-the-stack. Headertransparenz war nicht Anwendungstransparenz.

Auffinden war keine Berechtigung

RFC 3105 veröffentlichte per SLP eine service:rsip-URL, Fähigkeiten, Lebensdauer und optional Last. Scopes lenkten Clientgruppen zu Servern; ein Client konnte das Gateway mit weniger gemeldeten Verbindungen wählen.

Ein SLP-Scope war ausdrücklich keine Zugriffskontrolle. Eine Anzeige beschrieb ein Angebot, nicht den Anspruch des Clients. Lastwerte konnten vor der Verbindung veralten. Nach dem Auffinden folgten weiterhin Registrierung, Zuteilung, Pfadinstallation und Paketbeobachtung.

Damit blieben die Rollen unterscheidbar. Administratoren beeinflussten Discovery. Das Gateway gewährte Ressourcen. Der Host wählte Lokalität und baute Pakete. Der entfernte Partner akzeptierte Identität und Sitzung. Das Ergebnis gehörte der beidseitigen Beobachtung.

Der ehrliche Wert eines Experiments

RFC 3102–3105 waren Experimental, keine Internet Standards. Die IESG-Notiz warnte vor erheblichen Änderungen an Host und Gateway, Problemen durch wandernde Ports und betrieblicher Komplexität. Der Rahmen selbst nannte RSIP keine langfristige Antwort auf IPv4-Knappheit. Die Quellen belegen weder breite Einführung noch eine Ablösung von NAT.

Historisch ist gerade die Offenlegung wertvoll. RSIP zerlegte den verborgenen Zustand eines Translators in Registrierung, Allocation, bind, Lease, Policy, Discovery, Recovery und Lokalitätswahl. Sobald der öffentliche Parameter in den Host gelangte, wurde Adressteilung sichtbar zu einer Aufgabe verteilter Zustände.

Eine geliehene Adresse zeigte, in welchem Realm ein Paket erscheinen sollte. Sie bewies weder dauerhaftes Recht noch eindeutige Identität, korrekten Pfad, Authentisierung oder Zustellung. Das Gateway verlieh den Locator; erst übereinstimmende Kontrolle, laufender Zustand und Pakete in beiden Richtungen machten ihn wirksam.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3102.html
  2. https://www.rfc-editor.org/info/rfc3102
  3. https://datatracker.ietf.org/doc/rfc3102/
  4. https://www.rfc-editor.org/rfc/rfc3103.html
  5. https://www.rfc-editor.org/info/rfc3103
  6. https://datatracker.ietf.org/doc/rfc3103/
  7. https://www.rfc-editor.org/rfc/rfc3104.html
  8. https://www.rfc-editor.org/info/rfc3104
  9. https://datatracker.ietf.org/doc/rfc3104/
  10. https://www.rfc-editor.org/rfc/rfc3105.html
  11. https://www.rfc-editor.org/info/rfc3105
  12. https://www.rfc-editor.org/rfc/rfc1631.html
  13. https://www.rfc-editor.org/rfc/rfc2663.html
  14. https://www.rfc-editor.org/rfc/rfc2993.html
  15. https://www.rfc-editor.org/rfc/rfc3022.html