Zusammenfassung

  • RFC 1241 legte ein unverändertes „Clear Datagram“ hinter einen äußeren IP-Header und einen acht Oktette langen Protokollheader und leitete es durch einen getrennten Encapsulation Space.
  • Die 32-Bit-Flow-ID galt nur lokal. Eine nicht definierte höhere Instanz musste Tabellen, nächste Ziele und Rückübersetzungen pflegen.
  • ICMP aus dem Tunnel zitierte den äußeren IP-Header und den vollständigen Encapsulation-Header, aber nichts vom Clear Datagram. Damit konnte der Fehler seinen ursprünglichen Auslöser verlieren.

Ein unsichtbarer Umweg verlangte sichtbaren Zustand

RFC 1241 erschien im Juli 1991 als experimentelles Protokoll von Robert Woodburn und David L. Mills. Der Text unterschied zwei Welten. Vor der Kapselung lag das Clear Datagram im User Space. Kapselungs- und Entkapselungsknoten verwendeten dagegen Adressen und Routen eines eigenen Encapsulation Space.

Der Umweg sollte Routingfehler, kaputte Gateways oder problematische Domänen umgehen. Er konnte auch virtuelle Netze und Experimente tragen, ohne dass die Quelle die Zwischentopologie kannte. Der Eintritt setzte einen neuen Header davor, der Austritt entfernte ihn und ließ die innere Quelladresse bestehen.

Was die Quelle nicht wissen musste, musste die Tunnelkante verwalten. Ein Knoten wählte anhand des Clear Header den passenden Pfad und den nächsten Entkapseler. RFC 1241 nannte diesen Pfad Flow oder Tunnel. Mehrere Kapseler/Entkapseler-Paare konnten beteiligt sein, ohne dass der Flow die durchlaufenen Gateways des User Space bezeichnete.

Die Flow ID war absichtlich nur lokal eindeutig. Dieselbe logische Strecke konnte am nächsten Knoten eine andere 32-Bit-Zahl tragen. Für einen Fehlerweg zurück brauchte eine Tabelle daher die Adresse des vorherigen Kapselers und dessen lokale ID. Jeder Rückwärtsschritt war eine Übersetzung, keine Fortsetzung eines globalen Namens.

Wie die Tabellen entstanden oder aktuell blieben, ließ das Protokoll offen. Eine höhere Schicht sollte sie verwalten; für Versuche konnten ASCII-Dateien genügen. Ein erfolgreicher lokaler Lookup belegte also keine aktuelle End-to-End-Konfiguration und keinen funktionierenden Rückweg.

Der innere Inhalt blieb gleich, die Netzlast nicht

Zum Paket kamen ein äußerer IP-Header und acht Oktette für Version, Nachrichtentyp, Grundcode, Prüfsumme und Flow ID. Danach folgte das unveränderte Clear Datagram. Der äußere Absender und Empfänger waren nun Kapseler und Entkapseler. Priorität und Dienstqualität konnten übernommen werden; Timestamp, Record Route und Source Route nicht.

Auch TTL-Verantwortung verschob sich. Der innere Wert wurde nicht in den äußeren Header kopiert, musste aber vor der Kapselung sinken. Übersprang ein Entkapseler mittels Flow ID die normale IP-Weiterleitung, musste er die TTL-Behandlung selbst vor der nächsten Kapselung durchführen.

Vor allem verbrauchte die Verpackung MTU. Ein an der Quellschnittstelle passendes Datagramm konnte nach dem Zusatz zu groß sein. Äußere Fragmentierung war erlaubt, galt aber als ineffizient. Verbot der Kapseler die Fragmentierung, wurde die effektive MTU des Tunnels kleiner als die physische und die innere Quelle brauchte eine sinnvolle Rückmeldung.

Bereits fragmentierte Pakete beschädigten zudem die Auswahl. Die Mapping-Funktion durfte TCP-Ports oder eine Verbindung auswerten. Nur das erste IP-Fragment enthält jedoch den TCP-Header. Eine Portregel konnte deshalb das erste Fragment erkennen und die folgenden nicht. Das dokumentiert eine Klassifikationsgrenze, keinen gemessenen Ausfall.

RFC 1191 hatte Path MTU Discovery über DF und „fragmentation needed“ ICMP beschrieben. Im Encapsulation Space war die sichtbare Quelle aber der Kapseler. Der äußere Router schickte seine Meldung folgerichtig dorthin. Die Übertragung der Bedeutung zur inneren Quelle blieb Aufgabe der Kapselung.

Das ICMP-Zitat endete an der inneren Grenze

Nach RFC 792 enthielt ein ICMP-Fehler den auslösenden IP-Header und mindestens 64 Bit anschließender Daten. Bei RFC 1241 füllten genau die acht Oktette des Encapsulation-Protocol-Headers diesen Raum. Vom Clear Datagram blieb im Zitat kein Byte.

Der Kapseler erkannte äußeres Ziel und Flow ID, aber nicht den inneren IP-Absender oder die TCP-Ports dieses Pakets. Mehrere Clear Headers konnten demselben Flow zugeordnet sein. Die ID ließ sich daher nicht exakt zum Original zurückrechnen. Die Meldung belegte einen äußeren Zustand, nicht eindeutig die innere Kommunikation.

Ein unbekannter Flow konnte dem vorherigen Kapseler und der Tabellenverwaltung gemeldet werden. Andere ICMP-Meldungen konnten entlang des Flow zurücklaufen; jeder Knoten übersetzte die ID für seinen Vorgänger. Fehlende innere Bytes entstanden dabei nicht neu. Scheiterte das Senden einer Fehlermeldung, wurde keine weitere erzeugt.

Der vorgeschlagene Kompromiss verschob die Benachrichtigung auf das nächste Paket. Ein ICMP markierte den Flow; beim nächsten passenden Clear Datagram erzeugte der Kapseler eine neue Meldung an dessen Quelle. Diese Meldung beschrieb gelernten Pfadzustand, war aber keine Eins-zu-eins-Quittung des früheren Fehlers. Der Text hielt das nur für bestimmte Meldungsarten wahrscheinlich für sicher.

Spätere RFCs behandelten dieselbe Grenze mit mehr Zustand

Spätere Dokumente belegen nicht die Verbreitung von RFC 1241. RFC 1853 stellt jedoch eine dokumentierte Verbindung her: Es unterschied einfaches IP-in-IP ohne speziellen Zwischenheader vom Protokoll 98 des RFC 1241 und nannte dessen Aufbau und Teile des Textes als Quelle.

RFC 2003 wiederholte, dass acht zitierte Oktette den inneren IP-Header nicht erfassen. Es verlangte Soft State für Tunnel-MTU, TTL und Erreichbarkeit. Damit konnte ein Kapseler spätere Pakete besser beurteilen, aber nicht jeden äußeren Fehler rückwirkend einem inneren Paket eindeutig zuweisen.

RFC 4459 bezeichnete Größenfragen in Netztunneln später als häufig und nicht trivial. Äußere Fragmentierung, Signalisierung kleinerer MTU, reservierte Größenreserve oder innere Fragmentierung verteilen Aufwand und Beweislast jeweils anders.

RFC 1241 belegt Format, lokale ID-Bedeutung, Rückübersetzung und den Verlust des Inneren im üblichen ICMP-Zitat. Es belegt keine konkrete Implementierung, Zustellung oder gleichwertige Benachrichtigung. Dafür wären Eingangsmitschnitt, Tabellenversion, äußerer Header, Entkapselungsbeobachtung und die tatsächlichen ICMP-Bytes gemeinsam nötig. „Transparent“ ist keine Abkürzung für fehlende Beweise.

Quellen