Zusammenfassung

  • RFC 5320 macht äußere IPv4-Fragmentierung zum Eingang einer Regelschleife: Der Ausgang berichtet, der Eingang prüft das SEAL_ID-Fenster und ändert S_MSS für die nächste Segmentgeneration.
  • Ein belastbarer Beleg trennt Sondenabsicht, 32- oder 16-Bit-Identität, Beobachtung, Anpassung, IPv4- und SEAL-Reassembly, Übergabe nach oben sowie den Experimental-Status.

Der Regler lernte von einer Beschädigung

Ein Tunnel überspannt eine virtuelle Topologie, während die physischen Links unterschiedliche MTUs haben können. SEAL sendet die äußere IPv4-Hülle gewöhnlich mit DF=0. Ein Router darf sie fragmentieren, der Ausgang kann das Ereignis melden, und der Eingang verkleinert spätere Segmente.

Damit wird ein Störfall zur Messprobe. Seine Aussage bleibt dennoch eng: Ein Paket traf irgendwo auf eine kleinere Grenze. Das Fragment nennt nicht den Link, fixiert keine dauerhafte Pfad-MTU, bestätigt keine übrigen Teile und beobachtet keine Anwendung.

„Bericht angenommen“ darf deshalb nicht als „Pfad validiert“ erscheinen. Der erste Satz kann eine Anpassung autorisieren. Der zweite benötigt mehrere unabhängige Ereignisse.

Ein NAT verkürzt den Identitätsvertrag

Im Normalbetrieb besteht SEAL_ID aus 32 Bits. Die oberen 16 stehen in der ID Extension des SEAL-Headers, die unteren in der äußeren IPv4 Identification. Der Eingang beginnt pro Ausgang zufällig und zählt modulo 2^32 weiter.

Ein IPv4-NAT kann die äußere Hälfte umschreiben. Im NAT-Modus bleibt daher nur die 16-Bit-Erweiterung als verfolgte Identität; sie zählt modulo 2^16, während die äußere Identification zufällig gesetzt wird.

Wer nach der Übersetzung beide Felder wieder verbindet, erzeugt eine Identität, die kein Endpunkt gepflegt hat. Auch eine korrekte Übereinstimmung beweist nur den Bezug zu jüngstem Zustand, nicht Inhalt, Lieferung oder kryptografische Pfadauthentisierung.

S_MRU und S_MSS tragen verschiedene Pflichten

S_MRU, zunächst höchstens 2 KB, begrenzt die verlangte Wiederzusammensetzung am Ausgang. S_MSS begrenzt das einzelne Segment und wird aus der unteren IPv4-MTU, den Headerkosten und einer Schranke um S_MRU/8 bestimmt.

Beides als „Tunnel-MTU“ zu speichern, löscht die Zuständigkeit. Das eine beschreibt Rekonstruktionsfähigkeit, das andere Sendekörnung. Eine Verringerung von S_MSS ändert nicht automatisch die sichtbare innere MTU. Ein zu großes, nicht fragmentierbares inneres Paket kann weiter verworfen und mit PTB beantwortet werden.

Der Beleg hält Interface-MTU, Overheads, S_MRU, Wert und Generation von S_MSS, innere Länge, Fragmentierbarkeit und Auslöser getrennt fest.

Drei Schnitte brauchen drei Namen

SEAL kann ein Mittelschichtpaket in höchstens acht überlappungsfreie Segmente schneiden. Nichtletzte Segmente sind gleich groß, das letzte nicht größer; More Segments und eine Drei-Bit-Nummer beschreiben die Reihe. Der Ausgang stellt das Paket vor der Übergabe wieder her.

Das ist weder innere IPv4-Fragmentierung noch äußere Fragmentierung durch einen Pfadrouter. Die drei Vorgänge besitzen andere Erzeuger, Kennungen, Reassembly-Punkte und Korrekturen. Ein einzelner Zähler fragments erklärt keine Entscheidung.

Äußeres IPv4-Reassembly kann gelingen und SEAL-Reassembly scheitern. Danach kann die obere Schicht noch ablehnen. Ein Erfolg darf die nächste Stufe nicht automatisch ausfüllen.

R und A stellen unterschiedliche Fragen

R=1 im Segment null bittet um Bericht bei äußerer Fragmentierung. A=1 verlangt eine Bestätigung. Eine explizite Sonde kann Daten tragen oder ein NULL-Paket mit No Next Header sein; ihre SEAL_ID liegt im Fenster offener Sendungen.

Sind R und A gesetzt und Fragmentierung tritt ein, sendet der Ausgang eine Fragmentation-Needed-Nachricht, nicht zwei unabhängige Bestätigungen. Die ursprüngliche Absicht muss im Datensatz bleiben.

Auch Schweigen ist mehrdeutig. Der Ausgang kann Berichte ohne Bestätigungsanforderung begrenzen; Sonde oder Antwort können verloren gehen; oder es gab keine Fragmentierung. Abwesenheit entscheidet nicht zwischen diesen Ursachen.

Ein kurzes erstes Fragment ist nicht die MTU

Rohes ICMP bleibt ein weicher Hinweis: Es kann gefälscht sein und zu wenig zitieren. Ein gekapselter Bericht im aktuellen Fenster ist besser zugeordnet, zeigt aber noch nicht zwingend die MTU des Engpasses.

Bei Runt Fragmentation erzeugt ein Router ein ungewöhnlich kurzes erstes Stück. RFC 5320 verlangt deshalb eine iterative Suche: verkleinern, unter der neuen Generation senden, erneut beobachten. Ein Einzelwert erhält keine dauerhafte Autorität.

Nur der erste anwendbare Bericht soll S_MSS in einer Generation verändern. Weitere Berichte des alten Zustands sind keine neuen Befehle. Die nächste Entscheidung wartet auf Verkehr unter dem neuen Wert.

Korrelation ist keine Authentisierung

Nonce, Kennung und aktuelles Fenster begrenzen die Annahme kontextloser Meldungen. Doch ohne IPsec kann der SEAL-Header offenliegen, und Layer-2-Integrität schützt nur einen lokalen Abschnitt. Daraus entsteht keine Ende-zu-Ende-Pfadbescheinigung.

Die präzise Anzeige lautet „Feedback einer noch aktiven Sendung zugeordnet“, ergänzt um NAT-Modus, Epoche, Fenster, Generation und Sondentyp. „Pfad authentisiert“ würde zeitliche Zuordnung in eine Sicherheitsgarantie verwandeln.

Reassembly darf trotz gültigem Bericht aufgeben

Der Ausgang verwaltet Wasserstände, Lücken, Duplikate, Reihenfolge und Speicherdruck. Nach 15 Sekunden läuft die Wartezeit ab. Eine unvollständige Menge darf verworfen werden, obwohl zuvor gültiges Feedback zurückging.

Darum sind Kapsel empfangen, äußeres IPv4 zusammengesetzt, SEAL rekonstruiert, nach oben übergeben und Ergebnis beobachtet getrennte Felder. Erfolg der Anpassung ist kein Anwendungserfolg.

Experimental ist eine institutionelle Grenze

RFC 5320 erschien im Februar 2010 als Experimental Independent Submission. Der IESG-Hinweis sagt, dass es nicht den normalen IETF-Konsensprozess durchlief. SEAL_PROTO, SEAL_PORT und SEAL_OPTION sind experimentell und dürfen nicht in ausgelieferten Produkten oder gewöhnlichen Deployments verwendet werden.

Spätere RFCs zu Identification, Fragmentierung und MTU-Ermittlung liefern Kontext, machen SEAL aber nicht rückwirkend zum Standard. Eine RFC-Nummer identifiziert ein Dokument; sie erteilt keine Produktionsfreigabe.

Der minimale Entscheidungsbeleg

Zu speichern sind Zeit, Eingang, Ausgang, 32/16-Bit-Modus, Zustandsepoche, SEAL_ID, R, A, NULL oder Daten, Sendegröße, aktives Fenster, S_MRU, Wert und Generation von S_MSS, beobachtetes Fragment, Berichtsweg, erlaubte Änderung sowie die getrennten Ergebnisse beider Reassemblies und der oberen Übergabe.

Anpassung beseitigt die Symptome, von denen sie gelernt hat. Ohne Beleg bleibt der Parameter, während seine Begründung verschwindet. Ein Signal ist nur dann dauerhaft nützlich, wenn es keine erfundene Gewissheit tragen muss.

Quellen