Zusammenfassung

  • Das höchstwertige Bit eines IPv4-Optionstyps entschied, ob die Option nur in das erste Fragment oder in alle Fragmente kopiert wurde.
  • Fragmentierung erzeugte abgeleitete statt identische Header: Optionsmenge, IHL, Gesamtlänge, Offset, MF und Prüfsumme durften sich gezielt unterscheiden.
  • Copy 1 verteilte Verarbeitungskontext, garantierte aber weder Zustellung noch Authentizität oder unveränderte Bytes am Ziel. Für den vollständigen nicht kopierten Zustand blieb das Null-Offset-Fragment maßgeblich.

Gleichheit war nie die Bedingung für Zusammengehörigkeit

Bei einer groben Darstellung der Fragmentierung wird die Nutzlast zerteilt und jeder Teil mit demselben Header versehen. IPv4 verlangte etwas Anspruchsvolleres. Jedes Fragment musste selbst weiterleitbar sein, doch nicht jede Information des ursprünglichen Headers gehörte in jede abgeleitete Einheit.

RFC 791 teilt das Option-Type-Oktett in ein Copy-Bit, zwei Class-Bits und fünf Number-Bits. Copy null bedeutet: nur in das erste Fragment kopieren. Copy eins bedeutet: in alle Fragmente kopieren.

Das erste Fragment ist nicht das zuerst eingetroffene. Es ist das Fragment, dessen Fragment Offset null ist und das den Anfang der ursprünglichen Daten trägt. Dort bleibt der vollständige ursprüngliche Optionssatz. Nichtnull-Fragmente führen nur die Optionen weiter, deren Copy-Bit eins ist.

Loose Source and Record Route besitzt Typ 131 und damit Copy 1. Record Route besitzt Typ 7 und Copy 0. Enthält der Ursprung beide, darf das Null-Offset-Fragment einen längeren IHL als spätere Fragmente haben. Die abweichenden Header widersprechen nicht der gemeinsamen Reassembly-Identität. Sie belegen die vorgesehene Vererbung.

Die selektive Kopie war älter als RFC 791

RFC 760 beschrieb im Januar 1980 bereits Optionen, die in jedes Fragment kopiert werden sollten, und andere, die nur im ersten verblieben. Bei der Erzeugung des nächsten Fragments sollte der Internet Header selektiv kopiert werden.

RFC 791 band diese Entscheidung sichtbar in den Typ ein. Ein Fragmentierer musste keine zentrale Stelle befragen und keine lokale Wichtigkeitstabelle erfinden. Er konnte eine deterministische Regel aus dem gemeinsamen Format lesen.

Die Regel war klein, ihre Ausführung aber nicht trivial. Der erste Header beruhte auf dem Original. Für spätere Header wurden nicht kopierte Optionen entfernt. Dadurch änderte sich die Internet Header Length. Die jeweilige Nutzlast änderte Total Length. Die Position bestimmte Fragment Offset, die verbleibende Folge More Fragments. Jede Headeränderung verlangte eine neue Header Checksum.

Fragmentieren bedeutete also nicht nur Schneiden. Der ausführende Host oder Router musste eine nachvollziehbare Ableitung herstellen. Ein korrektes Prüfsummenfeld allein beweist diese Ableitung nicht: Auch ein Header, der fälschlich eine Copy-1-Option verloren hat, kann eine mathematisch passende Prüfsumme tragen.

Copy 1 war kein Gütesiegel

Strict Source and Record Route vom Typ 137 und Stream Identifier vom Typ 136 verwenden Copy 1. Timestamp vom Typ 68 und Record Route vom Typ 7 verwenden Copy 0. Die historische Basic Security Option vom Typ 130 hatte ebenfalls Copy 1. Daraus entsteht keine Rangliste von bedeutend bis entbehrlich.

Copy 0 bedeutet nur, dass die Semantik keine Wiederholung in jedem selbstständig weitergeleiteten Fragment verlangt. Die Option verschwindet nicht aus dem Originalzustand; sie bleibt beim Offset null. Copy 1 bedeutet, dass der Kontext mitgegeben wird. Es verspricht keine Priorität, Zuverlässigkeit, Verschlüsselung, Authentisierung oder erfolgreiche Verarbeitung.

Das IANA-Register für IPv4-Parameter führt Copy, Class, Number, Value, Name und Reference getrennt auf. Damit lässt sich eine Zuweisung und ihre Dokumentquelle belegen. Das Register misst weder heutigen Einsatz noch Produktunterstützung und bestätigt keine Wirkung auf einem bestimmten Pfad.

Zuweisung, Implementierung, Aussendung, Transitbehandlung, Ankunft und Reassembly sind verschiedene Beweisstufen. Eine amtliche Zeile schließt nur die erste.

Kopierte Optionen konnten unterwegs auseinanderlaufen

„In alle Fragmente kopiert“ klingt nach identischen Endzuständen. RFC 815 macht diese Annahme unhaltbar. Fragmente eines Datagramms können unterschiedliche Routen nehmen. Eine kopierte Source-and-Record-Route-Option kann auf jedem Weg von anderen Routern fortgeschrieben werden.

Am Ziel dürfen die aufgezeichneten Routen deshalb voneinander abweichen, obwohl alle Kopien beim Schnitt einen gemeinsamen Ursprung hatten. Copy 1 konserviert die Fähigkeit zur weiteren Verarbeitung, nicht jedes veränderliche Byte.

Für die beschriebene Reassembly verwendet RFC 815 die im ersten Fragment aufgezeichnete Rückroute und ignoriert andere Fassungen. Das ist keine Mehrheitsentscheidung und keine Verschmelzung. Die Spezifikation weist einer bestimmten Herkunft Autorität zu.

Wer solche Optionen beim Erfassen sofort dedupliziert, löscht möglicherweise den Nachweis verschiedener Pfade. Wer jede Differenz als Angriff meldet, ignoriert eine erlaubte Veränderung. Rohfragmente, Ankunftsfolge und ausgewählte Reassembly-Fassung müssen getrennt bleiben.

Der vollständige Header konnte später eintreffen

RFC 815 weist darauf hin, dass ein Empfänger die endgültige Headergröße womöglich erst kennt, wenn das erste Fragment eintrifft. Ein früher eingetroffenes Nichtnull-Fragment darf Copy-0-Optionen weglassen und deshalb einen kürzeren IHL besitzen.

Zeitliche Reihenfolge schafft keine semantische Autorität. Das erste beobachtete Fragment beschreibt sich selbst vollständig, das Ursprungsdatagramm aber nur teilweise. Ein System, das aus seinem IHL sofort die endgültige Headergröße ableitet, macht aus einer gültigen Teilansicht eine falsche Gesamtaussage.

RFC 6274 nutzt diese Grenze bei einer Sicherheitsprüfung. Ob das zusammengesetzte Paket genug Platz für den behaupteten Transportheader besitzt, hängt vom IHL des Null-Offset-Fragments ab. Fehlt es noch, ist nur eine vorläufige Prüfung möglich; nach seiner Ankunft muss die vollständige Bedingung erneut angewandt werden.

Vorläufigkeit ist kein Ausfall. Sie erhält eine Entscheidung revidierbar, bis die maßgebliche Evidenz vorhanden ist. Gefährlich wird eine Optimierung erst, wenn sie den vorläufigen Zustand aus Leistungsgründen endgültig macht.

Ende und Ausrichtung gehörten zur Grammatik

End of Option List und No Operation beenden oder richten den Optionsbereich aus. Werden nicht kopierte Optionen aus einem späteren Header entfernt, kann der Fragmentierer Abschluss und Padding neu setzen müssen, damit der Header weiterhin an einer 32-Bit-Grenze endet.

Ein Algorithmus darf deshalb nicht einfach einzelne Oktette mit oberstem Bit null löschen. Er muss Optionslängen und -grenzen verstehen, mehrbytige Optionen intakt lassen, das Ende wiederherstellen, IHL korrigieren und erst dann die Prüfsumme bilden.

Auch eine unbekannte Option besitzt syntaktische Grenzen. Eine Implementierung mag ihre vollständige Wirkung nicht kennen, erhält dadurch aber kein Recht, sie beliebig umzudeuten. Die gemeinsame Grammatik ermöglicht deterministisches Überspringen, Kopieren oder explizites Ablehnen.

Eine minimale Spezifikation ist nicht nachlässig. Sie beschränkt die gemeinsamen Entscheidungen, besteht aber auf prüfbaren Regeln für genau diese Entscheidungen.

Spätere Fragilität widerlegt die frühere Funktion nicht

RFC 8900 fasst zusammen, dass alle IPv4-Optionen im ersten Fragment erscheinen und nur Copy-1-Optionen in späteren Fragmenten. Das Dokument analysiert zugleich die Anfälligkeit der Fragmentierung gegenüber Verlust, Middleboxes, Filtern ohne Transportheader und knappen Reassembly-Ressourcen.

Diese Analyse beschreibt Ausfallmechanismen, keine universelle Ausfallquote. Sie belegt weder, dass jedes Fragment scheitert, noch dass alte Optionen heute häufig sind oder alle Geräte gleich reagieren. Architekturdiagnose und Einsatzmessung dürfen nicht vermischt werden.

RFC 8200 zeigt als Kontrast, wie IPv6 Fragmentierung auf die Quelle beschränkt und die pro Fragment notwendigen Header anders trennt. Das beleuchtet eine spätere Verschiebung der Grenze. Es macht den IPv4-Copy-Mechanismus nicht rückwirkend bedeutungslos; dieser musste auch mit Zwischenroutern als Fragmentierern umgehen.

Der Fragmentierer erhielt keine Deutungshoheit

Unter IPv4 kann die Quelle oder ein Router fragmentieren, abhängig von MTU, Pfad und Don’t Fragment. Der Router in der Eröffnung macht die fremde Transformation sichtbar, ist aber nicht der einzige Fall.

In beiden Fällen ist die Befugnis eng: Nutzlast teilen, Reassembly-Felder setzen, Optionen nach Copy auswählen, Abschluss und Prüfsumme erneuern. Sie umfasst nicht, Copy-0-Information für wertlos zu erklären, die Wahrheit einer Copy-1-Option zu bescheinigen oder ihre Zustellung zu garantieren.

Die gemeinsame Schicht definiert nur, was unabhängige Implementierungen für kompatible Ableitungen brauchen. Die Quelle wählt Optionen. Der Pfad verarbeitet, soweit die Option es vorsieht. Das Ziel rekonstruiert und folgt der festgelegten Provenienz.

Beweise müssen erlaubte Unterschiede erhalten

Eine brauchbare Untersuchung verknüpft Quelle, Ziel, Protokoll, Identification, Offset, MF, IHL, Optionstyp, Copy-Wert und Ankunftsfolge. Sie sucht präzise Verletzungen: Copy 0 in einem Nichtnull-Fragment, fehlendes Copy 1, abgeschnittene Optionen, falsche Ausrichtung oder eine nie wiederholte Vorprüfung.

Fehlt das Null-Offset-Fragment, bleibt der vollständige Optionssatz unbekannt. Daraus darf nicht gefolgert werden, dass das Original keine Record-Route- oder Timestamp-Option trug. Weichen veränderliche Kopien ab, muss zunächst geprüft werden, ob das Format diese Veränderung erlaubt.

Gute Evidenz erzwingt keine künstliche Gleichheit. Sie erhält die Ableitung so, dass ein späteres System die Regel erneut anwenden kann.

Quellen und Beweisgrenze

Grundlage sind RFC 760, RFC 791, RFC 815, RFC 1122, RFC 1812, RFC 6274, RFC 8900, RFC 8200 und das IANA-Register. Sie belegen Spezifikationen und begrenzte Betriebsfolgen, nicht heutige Verbreitung, Produktkonformität, Angriffshäufigkeit oder das Verhalten jedes realen Pfades.