Zusammenfassung

  • Spätere IPv4-Fragmente können einen Reassembly-Kontext eröffnen, Daten belegen und sogar das Ende des Datagramms erkennen lassen, ohne dass der Anfang vorliegt.
  • Beim Timeout muss der Host den unvollständigen Zustand verwerfen. ICMP Time Exceeded Code 1 ist nach RFC 1122 nur dann verpflichtend, wenn Fragment null empfangen wurde.
  • Die gespeicherte erste Header-Kopie verbindet lokales Scheitern mit einem zitierfähigen Fehlerbericht. Ohne sie bleibt die Freigabe von Speicher notwendig, die Fernmeldung aber nicht.

Lücken sind leichter zu speichern als eine Erklärung

RFC 815 formulierte Reassembly als Verwaltung fehlender Bereiche. Eine Liste beschreibt die holes. Ein eintreffendes Fragment verkürzt einen Eintrag, teilt ihn oder lässt ihn verschwinden. Ist die Liste leer, ist das Datagramm vollständig.

Die Darstellung ist sparsam und verträgt beliebige Reihenfolge. Sie muss nicht wissen, welches Fragment zeitlich zuerst kam. Doch der ursprüngliche IP-Header folgt einer anderen Regel. Einige IPv4-Optionen werden in alle Fragmente kopiert, andere bleiben im ersten. Solange das Fragment mit Offset null fehlt, kann der Empfänger die endgültige Header-Form nicht sicher kennen.

Das ist kein bloßes Layoutproblem. Der Header wird später zum Material einer Fehlermeldung. Ein Algorithmus, der nur das erfolgreiche Ende betrachtet, kann die Lücken perfekt verwalten und dennoch den Beleg verlieren, den der Fehlerpfad braucht.

Jeder Offset konnte Speicher beanspruchen

RFC 791 ordnet Fragmente anhand von Quelle, Ziel, Protokoll und Identification einem Buffer zu. Der Offset bestimmt die Datenposition. Offset null kennzeichnet den Anfang; MF null kennzeichnet das Ende. Beide Kennzeichen müssen nicht im selben Paket und nicht in Ankunftsreihenfolge erscheinen.

Das Beispiel reserviert Ressourcen, sobald ein passender Buffer fehlt. Daten werden an ihre Position kopiert. Der letzte Teil bestimmt die Gesamtlänge. Nur bei FO = 0 wird der Header in den eigenen Header-Buffer gelegt. Erst bekannte Länge plus lückenlose Blöcke ab null ergeben ein Datagramm.

Damit kann ein Kontext umfangreich und zugleich aussagelos sein. Mehrere Fragmente belegen echte Bytes; das letzte definiert die rechte Grenze; links bleibt der entscheidende Anfang offen. Der Empfänger hat einen Zustand, nicht das ursprüngliche Objekt.

Der erste Timer vermischte Weg und Zeit

RFC 791 empfahl zunächst 15 Sekunden als Untergrenze. Der Timer wurde auf den größeren Wert aus aktuellem Stand und verbleibendem TTL eines eintreffenden Fragments gesetzt. Die Spezifikation verband Datenrate, Timer und notwendige Buffer-Kapazität ausdrücklich.

TTL war jedoch keine verlässliche Sekundenmessung. Router reduzierten es mindestens um eins pro Verarbeitung, auch wenn keine Sekunde verging. Der Restwert spiegelte damit Hop-Anzahl und Zeit nicht sauber. Eine lokale Speicherentscheidung wurde von einem Feld beeinflusst, dessen operative Bedeutung auf dem Weg eine andere geworden war.

RFC 1122 empfahl daher einen festen Reassembly-Timeout von 60 bis 120 Sekunden. Zu kurz gefährdet verspätete legitime Fragmente; zu lang bindet Speicher und verlängert den Zeitraum, in dem Identification-Werte nicht mit älteren Generationen kollidieren dürfen. Die Spanne ist historische Vorgabe, kein gemessener heutiger Standardwert.

Der zusätzliche Satz für den Fehlerfall

RFC 1122 empfahl den Clark-Algorithmus und setzte dann eine Grenze zu RFC 815: Der erste Fragment-Header muss für eine mögliche ICMP Time Exceeded Reassembly Timeout message gespeichert werden.

Dieser Satz macht den Lebenszyklus vollständig. Der Header wird nicht erst benötigt, wenn alle Daten da sind. Er ist auch aufzubewahren, wenn die übrigen Daten möglicherweise niemals erscheinen. State hat zwei Ausgänge: Lieferung oder erklärtes Scheitern. Für beide ist der Anfang relevant.

Die Norm verlangt beim Ablauf, das teilweise zusammengesetzte Datagramm zu verwerfen. Wenn Fragment null empfangen wurde, muss außerdem ICMP Time Exceeded an die Quelle gesendet werden. Cleanup und Report haben damit verschiedene Voraussetzungen.

Code 1 zitiert den Anfang

RFC 792 definiert Type 11 Code 1 und sein Format. Der Fehler enthält den ursprünglichen IP-Header und die ersten 64 Datenbits. Unter den damaligen Protokollannahmen sollte die Quelle damit den betroffenen Prozess finden können.

Auch ein späteres Fragment hat einen IP-Header und eine Quelladresse. Der Empfänger kann es sonst nicht zuordnen. Die Einschränkung bedeutet nicht, dass es namenlos wäre. Sie bedeutet, dass sein Nutzlastbeginn nicht der versprochene Beginn des ursprünglichen Datagramms ist.

RFC 792 beschränkt ICMP errors auf Fehler bei Fragment null und erlaubt, bei dessen Fehlen ganz auf Time Exceeded zu verzichten. Eine erreichbare Rückadresse genügt nicht für eine wahrheitsgemäße Zitation. Der Fehlerpfad darf fehlenden Kontext nicht durch beliebige spätere Bytes ersetzen.

Ein Router ist nur für eigene Datagramme Host

RFC 1812 zieht die Rollenlinie. Reassembliert ein Router ein an ihn selbst gerichtetes Paket, handelt er als Host und folgt den Host-Anforderungen. Transitverkehr macht nicht jeden Router zum Reassembly-Besitzer.

Die Router-Anforderungen verbieten zudem ICMP errors als Reaktion auf ein nicht erstes Fragment; diese Einschränkung hat Vorrang. Für Diagnose zählt daher, welches Ziel den Kontext hielt, nicht welches Gerät irgendein Teilstück sah.

Speicherzeit ist auch Identitätszeit

RFC 6864 verbindet Reassembly-Timeout und maximale Datagramm-Lebensdauer mit der notwendigen Eindeutigkeitsperiode des 16-Bit-Identification-Feldes. Solange alte Teile plausibel sind, kann dieselbe Kombination von Quelle, Ziel, Protokoll und ID Generationen vermischen.

Ein längerer Timeout hält daher nicht nur Daten, sondern eine frühere Identitätsbehauptung offen. Diese Beobachtung ergänzt den Ressourcenpreis, ohne die eigene Geschichte des Identification-Feldes zu wiederholen.

Der fehlende Report ist kein fehlender Fehler

Ein beobachteter Code 1 beweist eng begrenzt: Ein Ziel hielt unvollständige Fragmente bis zum Ablauf, besaß Fragment null, erzeugte einen Bericht, und dieser erreichte den Beobachtungspunkt. Er beweist nicht, welches Fragment wo verloren ging.

Ohne Code 1 bleiben mehrere Ursachen: Fragment null fehlte, ICMP wurde lokal begrenzt, gefiltert oder auf dem Rückweg verloren, oder Implementierung und Messpunkt verhielten sich anders. Wer nur Reports zählt, bevorzugt statistisch die Fehler, deren Anfang erhalten blieb.

Drei Aufzeichnungen, die nicht dasselbe beweisen

Ein belastbarer Ablauf enthält mindestens drei voneinander getrennte records. Der Empfangsrecord sagt, welche Offsets eintrafen. Der Reassembly-Record sagt, welche holes bestanden, wie lange der Kontext lebte und warum er endete. Der ICMP-Record sagt, ob der Kontext eine Meldung erlaubte, ob sie erzeugt und ob sie gesendet wurde. Erst danach kann eine Quelle ihren eigenen Empfangsrecord hinzufügen.

Diese Aufteilung verhindert einen verbreiteten Kurzschluss. Ein gesendeter Code 1 ist nicht identisch mit einem empfangenen Code 1. Ein lokaler Timeout ist nicht identisch mit einem sendefähigen Timeout. Und eine Menge später Fragmente ist nicht identisch mit einem fast vollständigen Datagramm: Fehlt der Anfang, fehlt zugleich der Teil, auf den der externe Bericht angewiesen ist.

Auch der Endfragment-Status muss getrennt bleiben. MF null kann die beabsichtigte Gesamtlänge offenlegen, aber keine Aussage darüber liefern, ob die fehlenden Bereiche jemals gesendet wurden, unterwegs verloren gingen oder am Ziel verworfen wurden. Der Reassembler beobachtet nur seinen eigenen Ausschnitt der Kette.

Das verhindert ebenfalls eine unzulässige MTU-Diagnose. Code 1 kann auf fragmentierte Übertragung hinweisen, doch die geschlossene RFC-Evidenz sagt nicht, dass ein bestimmter MTU-Wert, Tunnel oder Filter die Ursache war. Ohne Sendepaket, Pfadänderung und Fragmentkarte bleibt die Ursache offen.

Die feinere Buchhaltung ist kein Ruf nach unbegrenztem Logging. Sie definiert, welche wenigen Tatsachen getrennt erhalten werden müssen, damit spätere Verdichtung nicht aus vier unterschiedlichen Ausgängen eine scheinbar eindeutige Zahl macht.

Eine Timer-Änderung verändert die beobachtete Population

Wird länger gewartet, können einige zuvor abgelaufene legitime Datagramme noch vollständig werden. Sie verschwinden aus der Fehlerpopulation. Andere unvollständige Kontexte bleiben lediglich länger bestehen. Weniger Code 1 kann deshalb gleichzeitig mit höherem Memory-Peak auftreten.

Ein kürzerer Timer gibt Ressourcen früher frei, erhöht aber die Zahl der durch Delay verlorenen Sets. War Fragment null vorhanden, wächst eventuell auch die Menge der ICMP-fähigen Abläufe. Die Quellseite kann eine lokale Policy-Änderung dann fälschlich als neuen Path-Fehler interpretieren.

Vergleichbar bleiben nur getrennte Nenner: angelegte Kontexte, Sets mit Fragment null, Sets mit Endfragment, completions, expiries und vorzeitige evictions. Das Verhältnis Code 1 received / fragments sent vermischt alle Stufen und ist für eine Kausalbehauptung zu grob.

Auch die Zeitachse braucht zwei Perspektiven. Der Reassembler misst das Alter seines lokalen context. Der Sender misst Abstand zwischen Übertragung und beobachteter Antwort. Queueing und Rückweg liegen dazwischen. Die Werte dürfen korreliert, aber nicht als identische Uhr behandelt werden.

Die RFC-Empfehlung erklärt, welche Abwägung ein Host treffen soll. Sie nimmt dem Betreiber die Prüfung nicht ab. Eine Änderung braucht erwarteten Nutzen, Grenzwerte für Schaden und einen getesteten Rollback, bevor sie zur dauerhaften Policy wird.

Dabei sollte auch der Beobachtungszeitraum länger als der getestete Timeout sein. Sonst wird ein noch wartender Kontext als verschwunden gezählt und die Messung bevorzugt kurze Abläufe. Vergleichsfenster müssen denselben Traffic-Typ, dieselben Datagrammgrößen und bekannte Tunneländerungen berücksichtigen. Erst dann lässt sich sagen, ob die Policy Speicher zurückgewonnen oder lediglich Fehler zeitlich verschoben hat.

Quellen und Evidenzgrenzen

Die Quellen belegen Regeln, Algorithmen und dokumentierte Abwägungen. Sie messen keine aktuellen Defaults, Fragmentraten, ICMP-Zustellung, Filterung oder Produktkonformität.