Zusammenfassung

  • RFC 2004 legt kein vollständiges zweites IPv4-Paket um das erste. Es verändert Protocol, Ziel und gegebenenfalls Quelle im vorhandenen Header und fügt nur die für den Rückbau nötigen acht oder zwölf Oktett ein.
  • Das S-Bit spart die ursprüngliche Quelladresse nur dann aus, wenn der Tunneleingang selbst bereits die Quelle des Datagramms ist. Diese Gleichheitsannahme ist eine Kodierungsregel, kein Identitätsnachweis.
  • Der Prüfsummenbereich des Minimal Forwarding Header endet an dessen Rand. Erfolgreiche Rekonstruktion belegt weder Tunnelberechtigung noch Pfadintegrität, ursprüngliche Urheberschaft oder Zustellung.

Die Reise benutzt denselben Header

RFC 2004 wollte den Mindestaufwand herkömmlicher IP-in-IP-Kapselung vermeiden. Statt mindestens zwanzig Oktett für einen vollständigen äußeren IPv4-Header hinzuzufügen, übernimmt der bestehende Header vorübergehend die Tunnelrolle. Sein Protocol-Feld wird auf 55 gesetzt, das Ziel auf den Tunnelausgang. Stammt das Datagramm nicht vom Tunneleingang selbst, wird auch die Quelle durch eine Adresse dieses Eingangs ersetzt. Total Length wächst, und die IPv4-Header-Prüfsumme wird neu berechnet.

Zwischen diesem veränderten Header und der unveränderten Nutzlast steht der Minimal Forwarding Header. Seine kurze Form umfasst acht Oktett, die lange zwölf. Gegenüber einem IPv4-Header ohne Optionen spart das zwölf beziehungsweise acht Oktett. Doch die Mechanismen sind nicht bloß unterschiedlich große Umschläge: Bei RFC 2003 bleibt der vollständige innere Header erhalten. RFC 2004 bewahrt nur ausgewählte Werte und eine Vorschrift zu ihrer späteren Einsetzung.

Vier optionale Oktett verkörpern eine Voraussetzung

Immer gespeichert werden das ursprüngliche Protocol und das ursprüngliche Ziel. Die ursprüngliche Quelle erscheint nur bei S=1. Das ist nötig, wenn der Tunneleingang die Quelladresse für den Tunnelweg überschrieben hat. Der Ausgang liest dann zwölf Oktett und setzt die gespeicherte Quelle wieder ein.

Bei S=0 fehlen diese vier Oktett. Der Standard erlaubt das, weil der Tunneleingang in diesem Fall die ursprüngliche Quelle ist und das sichtbare Quellfeld nicht geändert werden muss. Derselbe Wert soll also sowohl für den Tunnelweg als auch für das rekonstruierte Datagramm gelten.

Das ist eine überprüfbare Bedingung einer konformen Implementierung, aber kein kryptografischer Beleg. Das S-Bit sagt dem Parser, welche Länge und welche Rückbauregel gelten. Es bestätigt nicht, wer den Tunnel eingerichtet hat, ob die Adresse autorisiert war oder ob der Absender diese Identität führen durfte. Wer den Wert nicht speichert, verliert zugleich eine unabhängige Vergleichskopie.

Zwei Prüfsummen schützen zwei verschiedene Zustände

Der Minimal Forwarding Header besitzt eine eigene 16-Bit-Einerkomplement-Prüfsumme. In ihre Berechnung gehen nur seine acht oder zwölf Oktett ein, wobei das Prüfsummenfeld als null behandelt wird. Weder der veränderte IPv4-Header noch die Nutzlast sind Teil dieses Bereichs. Ein gültiges Ergebnis zeigt deshalb nur, dass gespeichertes Protocol, Steuerbits und gespeicherte Adressen innerhalb dieses kleinen Headers konsistent sind.

Der gerade tunnelnde IPv4-Header hat separat seine IPv4-Prüfsumme. Am Ausgang werden Protocol und Ziel, gegebenenfalls die Quelle, sowie Total Length erneut verändert; der Minimal Forwarding Header wird entfernt, und eine neue IPv4-Header-Prüfsumme entsteht. Keine dieser Prüfsummen ist eine Signatur. Keine deckt die Nutzlast Ende zu Ende ab oder genehmigt die Tunnelbeziehung.

Rückbau ist keine Zeitreise

Die Rekonstruktion liefert keinen bytegleichen Schnappschuss des Eingangs. Schon die frühere IPv4-Prüfsumme wurde nicht aufbewahrt. Vor allem aber bleibt die ursprüngliche TTL in demselben, nun umfunktionierten Header und wird bei normalem Weiterleiten auf jedem Tunnelhop herabgesetzt. Deshalb kann der Tunnel in traceroute sichtbar bleiben. Der Ausgang restauriert keine frühere TTL.

Das Ergebnis ist ein IPv4-Datagramm, das nach den gewöhnlichen Regeln weiterverarbeitet werden kann. Daraus folgen jedoch weder ein bestimmter physischer Weg noch die Zulässigkeit aller Zwischenhandlungen, die Echtheit der Quellidentität, die Annahme durch den nächsten Hop oder der Empfang durch eine Anwendung.

Fragmentierung markiert die Grenze der Kompression

Ein bereits fragmentiertes ursprüngliches Datagramm darf nicht minimal gekapselt werden. Im kleinen Forwarding Header gibt es keinen Platz, um dessen vorhandene Fragmentierungsangaben zu sichern. Das ist eine Eintrittsbedingung. Nach der Kapselung dürfen die normalen IPv4-Regeln für Optionen und Fragmentierung wieder gelten, sofern DF dies nicht verhindert; für MTU-Fragen bleibt RFC 1191 einschlägig.

Schleifenvermeidung, ICMP-Behandlung und Soft State übernimmt RFC 2004 nicht neu, sondern verweist auf RFC 2003. Auch die Sicherheitssektion ist bewusst knapp: Sicherheit wird nicht behandelt, die Überlegungen seien im Allgemeinen ähnlich. Ein Paket mit Protocol 55 und korrekten Prüfsummen trägt daher keine Sicherheitszusage, die das Dokument nie formuliert hat.

Als optionale Kapselung stand RFC 2004 neben RFC 2002 für Mobile IP. Ein registriertes Mobility Binding ist aber ein anderer Datensatz als ein beobachteter Tunnelheader. RFC Editor und IETF Datatracker belegen Dokumentstatus und Standardisierung, nicht einen konkreten Einsatz. Genau diese Trennung entspricht Lu Hengs Running-Code Primacy: Ein Standardtext ist Spezifikationsevidenz; betriebliche Wirklichkeit verlangt laufende Belege. Minimum Initial Specification und Reality Layers helfen, dieselbe Grenze zu lesen: Eine knappe gemeinsame Regel kann Rekonstruktion deterministisch machen, ohne den größeren Kontext zu beweisen.

Quellen