Zusammenfassung

  • RFC 2003 setzt vor ein vollständiges IPv4-Datagramm einen neuen IPv4-Header: außen stehen Tunneleingang und -ausgang, innen die ursprünglichen Kommunikationspartner.
  • Ein weiterleitender Eingang vermindert die innere TTL vor der Kapselung; die äußere TTL gilt unabhängig davon für den Weg zum Ausgang.
  • DF, Tunnel-MTU, äußere Fragmentierung, Wiederzusammensetzung und ICMP-Übersetzung verteilen Pflichten, die sich aus Protokoll 4 allein nicht ablesen lassen.

Eine Fehlermeldung verrät ihren Adressaten

RFC 2003 beschreibt IP-in-IP ohne Austausch des ursprünglichen Pakets. Der Kapsler fügt einen IPv4-Header hinzu. Dessen Quelladresse gehört zum Eingang, die Zieladresse zum Entkapsler. Die inneren Adressen bleiben beim ursprünglichen Sender und Empfänger. Vor dem Ausgang wird nach außen geroutet, danach wieder nach innen.

Der Wert 4 im äußeren Protocol-Feld sagt nur, dass als Nächstes ein IPv4-Header folgt. RFC 1853 hebt den Verzicht auf einen besonderen Zwischenheader hervor. Diese klare Typangabe ist aber keine Authentifizierung, keine Zulassungsentscheidung und keine Empfangsbestätigung.

ICMP kann die Grenze nicht wortgleich überqueren

Ein äußeres Protocol Unreachable wird als Netz oder Host unerreichbar an den ursprünglichen Sender gemeldet, weil dieser Protokoll 4 nicht gesendet hat. Port Unreachable wird nicht weitergereicht: Im äußeren Header gibt es keinen Port. Datagram Too Big muss weitergegeben werden. Tunnel Time Exceeded erscheint als Host Unreachable. Parameter Problem ist nur dann zurechenbar, wenn der Zeiger ein aus dem inneren Paket kopiertes Feld trifft.

Die historische Zitierregel aus RFC 792 verlangte lediglich den fehlerhaften IP-Header und die ersten acht folgenden Oktette. Bei IP-in-IP reicht das womöglich nicht bis zum inneren Header. Der Eingang kann dann den Tunnelzustand aktualisieren, ohne das einzelne innere Datagramm zu kennen.

Mindestens MTU, Weglänge oder TTL und Erreichbarkeit des Ausgangs werden als weicher Zustand gehalten. Eine spätere Meldung kann auf diesem Modell beruhen und muss keinem inneren ICMP-Ereignis eins zu eins entsprechen. Das ist nützliche Betriebskenntnis, aber kein Paketbeleg.

DF entscheidet über den Ort der Arbeit

Ist Don't Fragment innen gesetzt, muss es außen gesetzt sein. Ist es innen frei, darf der Eingang außen dennoch DF wählen, um die Tunnel-MTU zu ermitteln. Die Vorgabe des ursprünglichen Senders bleibt geschützt, während der Tunnelbetreiber für seinen Abschnitt strenger sein kann.

RFC 1191 schreibt vor, dass ein Router bei einem zu großen DF-Paket Destination Unreachable, Code 4, samt Next-Hop-MTU zurückgibt. Im Tunnel geht die Nachricht an die äußere Quelle, also den Eingang. Gegenüber dem ursprünglichen Sender ist die nutzbare MTU um den hinzugefügten Header kleiner.

Hat der Sender Fragmentierung erlaubt und erst der Eingang außen DF gesetzt, kann es laut RFC 2003 nichts Sinnvolles geben, was der Eingang über genau diesen Fehlschlag nach innen meldet. Er kann während einer MTU-Suche eine Kopie behalten, nach der Antwort fragmentieren und erneut senden oder äußeres DF für bestimmte Daten vermeiden. Diese Entscheidung braucht eine eigene, versionierte Spur.

Wird außen fragmentiert, muss der Ausgang alle äußeren Fragmente zusammensetzen, bevor er den inneren Inhalt freilegt. Puffer und Zeitgeber enden dort. Wird ein geeignetes inneres Datagramm vorher fragmentiert, reist jedes innere Fragment in einem eigenen Umschlag; der endgültige Empfänger setzt innen zusammen. Ein bloßer Zähler „Fragmente“ verschweigt diese verschiedenen Schuldner.

Zwei TTL-Werte sind zwei Verantwortungen

Leitet der Eingang weiter, vermindert er die innere TTL vor der Kapselung. Bei null verwirft er das Paket und meldet normalerweise Time Exceeded; ein Datagramm mit TTL null darf nie gekapselt werden. Erzeugt der Eingang das Datagramm selbst, verbraucht die Kapselung allein keinen inneren Hop.

Die äußere TTL wird passend zum Ausgang gewählt. Entkapselung vermindert die innere TTL nicht, spätere normale Weiterleitung schon. Aus einer gesunden äußeren TTL lässt sich deshalb kein inneres Restbudget ableiten. Vor- und Nachwert innen, Start- und Beobachtungswert außen sowie die Weiterleitung hinter dem Ausgang gehören getrennt ins Protokoll.

Aktuelle Auslegung schließt spätere RFCs ein

Der Text von 1996 kopierte TOS nach außen. RFC 3168 präzisierte die ECN-Bits: Ein vollwertiger Tunnel bewahrt Stausignale über Eingang und Ausgang, ein eingeschränkter deaktiviert ECN außen. Eine äußere Congestion-Experienced-Markierung darf beim Öffnen nicht still verschwinden.

RFC 6864 änderte die Aussage zur äußeren IPv4 Identification. Eindeutigkeit hängt davon ab, ob Fragmentierung möglich oder vorhanden ist; das Feld ist keine allgemeine Seriennummer für atomare Pakete. Der IETF-Datatracker weist RFC 2003 als Proposed Standard mit beiden Aktualisierungen aus. Er bestätigt Dokumentstatus, nicht die Umsetzung eines beobachteten Systems.

Der Umschlag begrenzt die Aussage

RFC 2003 warnt, dass Kapselung ursprüngliche Adressen, Protokoll und Ports aus ihren üblichen Filterpositionen entfernt. Vertrauen in die äußere Quelle authentifiziert nicht die innere. Zulassung kann Prüfungen beider Schichten erfordern.

RFC 791 definiert die zugrunde liegenden IPv4-Felder; RFC 4459 zeigt, dass MTU und Fragmentierung in Tunneln dauerhaft schwierige Aufgaben blieben. Spezifikation belegt die Regel, Konfiguration die Absicht, Eingangsmitschnitt die Bindung der Header, Wiederzusammensetzung den rekonstruierten Umschlag, Ausgangsmitschnitt eine weitere Weiterleitung und eine Anwendungsantwort ein späteres Ergebnis.

Running-Code Primacy trennt Veröffentlichung von tatsächlichem Verhalten. Minimum Initial Specification lässt örtliche Entscheidungen offen, ohne den gemeinsamen Kern aufzugeben. Reality Layers hält Symbol, Absicht, Beobachtung und Wirkung auseinander. Protokoll 4 sagt, welchen Umschlag man öffnet. Für Zustellung braucht es korrelierte Belege danach.

Quellen