Zusammenfassung

  • RFC 2185 behandelte IPv4- und IPv6-Erreichbarkeit als getrennte Berechnungen, selbst wenn der Tunnel wie eine gewöhnliche Verbindung wirkte.
  • Das Einspeisen von IPv6-Erreichbarkeit war eine Platzierungsentscheidung: Die Route bestimmte den Kapselungsrouter, bevor IPv4 die Verantwortung übernahm.
  • Sichtbare Route, Ersatzendpunkt, erfolgreiche Entkapselung oder einseitiger Empfang waren begrenzte Belege, keine Nachweise für Autorisierung, symmetrische Rückkehr oder vollständigen Dienst.

Die Route musste den richtigen Übergabepunkt finden

RFC 2185 erschien im September 1997 und beschrieb eine lange Übergangsphase mit parallelen IPv4- und IPv6-Infrastrukturen. Route Leaking bedeutete darin, Netzwerkerreichbarkeit über die Grenzen von Routingregionen hinweg anzukündigen. IPv4-Routen stammten aus IPv4-Protokollen, IPv6-Routen aus IPv6-Protokollen; auch ein integrierter Prozess änderte nichts an der doppelten Berechnung.

Der Eintrag beim RFC Editor und der IETF-Datatracker setzen eine wichtige Beweisgrenze: Das Dokument ist informativ und kein Internetstandard. Es beschreibt einen aus ngtrans-Arbeit hervorgegangenen Entwurf, belegt aber weder Verbreitung noch Feldleistung oder einen abgeschlossenen Übergang.

Ein manuell konfigurierter Tunnel vereinfachte die IPv6-Sicht. Seine Endpunkte bildeten eine Nachbarschaft, und die Gegenstelle erschien einen Hop entfernt. Das äußere Paket folgte dennoch dem unabhängig gewählten IPv4-Pfad. Die virtuelle Nachbarschaft belegte die Vereinbarung zweier Endpunkte, nicht den Zustand der Zwischenrouter, Filter, Kapazität oder Rückrichtung.

RFC 1933 beschrieb die damalige Übergangsmechanik einschließlich MTU, Fragmentierung und ICMP-Fehlerrückgabe. RFC 2003 spezifizierte IP-in-IP und setzte die Entkapselungsfähigkeit der Gegenstelle voraus. Diese Texte erklärten die Hülle. RFC 2185 stellte die Kontrollfrage, welche Route das Paket überhaupt zur richtigen Hülle brachte.

Die Ankündigung bestimmte den Kapselungsrouter

Beim automatischen Host-zu-Host-Tunnel konnten die äußeren IPv4-Adressen aus IPv4-kompatiblen IPv6-Adressen gewonnen und am Ursprung gekapselt werden. Beim konfigurierten Standardrouter sandte der Host das äußere Paket an die IPv4-Adresse eines mit dem IPv6-Backbone verbundenen Dual-Routers. Dieser entfernte den äußeren Header, danach setzte natives IPv6-Routing ein. Die konfigurierte Adresse wählte also den Ort des Verantwortungswechsels.

Der Router-zu-Host-Fall zeigte die Autorität besonders deutlich. Der Dual-Router musste passende IPv4-kompatible IPv6-Erreichbarkeit in die IPv6-Region einspeisen. IPv6 führte das Paket zu dem Router, der dieses Versprechen angekündigt hatte. Erst dort begann der letzte IPv4-Abschnitt.

Die Skalierung erzwang eine Wahl. Für ein kleines IPv4-Stubnetz konnte ein Summenpräfix genügen. An einer großen Backbone-Grenze ließ sich die gesamte IPv4-Tabelle in IPv6 einspeisen, was den Tabellenumfang ungefähr verdoppelte, oder eine manuelle Auswahl vermeintlich IPv6-fähiger Ziele treffen. Die erste Variante bezahlte mit Zustand und Fehlerfläche, die zweite mit menschlichem Urteil und Alterungsrisiko.

Auch der Fallback war kein gleichwertiger Dienstnachweis. RFC 2185 beschrieb individuelle Hostrouten für bevorzugte Endpunkte und ein umfassenderes Präfix, das bei Ausfall der spezifischen Route zu einem anderen Router führen konnte. Das zeigte lediglich, dass irgendein Ankündiger des Deckpräfixes das äußere Paket annahm. Gleiche Richtlinien, Tunnelzustand, Filter, MTU, Kapazität oder IPv6-Fortsetzung folgten daraus nicht.

Hin- und Rückrichtung durften unterschiedliche Tunnelformen verwenden. Ein erfolgreicher Hinweg war daher kein Modell des Rückwegs. Der Sicherheitsabschnitt warnte nur, dass Tunnel Firewalls der darunterliegenden Infrastruktur verletzen könnten, und behandelte keine weiteren Probleme. Routingzustellung war keine Authentisierung.

Belege müssen auf ihrer jeweiligen Ebene bleiben

Ein Tabelleneintrag belegt die Auswahl eines Kontrollprozesses. Ein geleaktes Präfix belegt die Behauptung einer Region gegenüber einer anderen. Eine virtuelle Nachbarschaft belegt Kontrollaustausch. Entkapselung belegt, dass ein äußeres Paket eine funktionsfähige Gegenstelle erreicht hat. Eine Anwendungsantwort liefert mehr, gilt aber nur für die beobachtete Richtung und Zeit.

Keiner dieser Befunde beweist allein die Autorisierung des Exports, Schleifenfreiheit, symmetrische Rückkehr, dauerhafte Kapazität, vollständige Zustellung oder einen vollendeten Übergang.

Diese Grenze trennt RFC 2185 von verwandten Geschichten. RFC 1955 schlug ENCAPS vor und verlagerte eine andere Abstraktion in autonome Domänenheader, DNS und Grenzrouter. RFC 4213 dokumentierte später grundlegende Übergangsmechanismen und behielt das aufschlussreiche Modell: ein IPv6-Hop, aber ein eigener äußerer IPv4-TTL und -Pfad. RFC 2185 zeigte vor allem, wer beide Ebenen zusammenführen musste.

Lu Hengs Primat laufenden Codes dient hier als ausdrücklich zugeschriebene Perspektive: Veröffentlichung und Konfiguration sind keine Ausführung. Seine minimale Anfangsspezifikation hält gemeinsame Invarianten klein und spätere Entscheidungen lokal. Das Argument der dauerhaften Dual-Stack-Steuer deutet parallele Betriebsflächen wirtschaftlich, ist aber kein Beleg für eine RFC-2185-Einführung. Der Text über Realitätsebenen trennt schließlich Ankündigung, ausgeführten Pfad und gelieferten Dienst.

Das Memo bewies nicht den Erfolg der Migration. Seine bleibende Leistung war die klare Eigentumsgrenze: IPv6 versprach den richtigen Kapselungsrouter, IPv4 die äußere Gegenstelle. Nur ein beobachtetes Ende-zu-Ende-Ergebnis konnte zeigen, dass beide Versprechen gehalten wurden.