4.5 Fragment-Header

Der Fragment Header wird von einer IPv6-Quelle verwendet, um Pakete zu senden, die größer als die Pfad-MTU zum Ziel sind. (Hinweis: Im Gegensatz zu IPv4 wird die Fragmentierung in IPv6 nur vom Quellknoten durchgeführt, nicht von Routern auf dem Übertragungsweg – siehe Abschnitt 5.) Der Fragment Header wird durch den Next Header-Wert 44 im vorherigen Header identifiziert und hat folgendes Format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Identification                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header (Nächster Header) – 8-Bit-Selektor. Identifiziert den Typ des ersten Headers des fragmentierbaren Teils (Fragmentable Part) des ursprünglichen Pakets (definiert unten). Verwendet dieselben Werte wie das Protocol-Feld in IPv4 [RFC-1700 et seq.].

Reserved (Reserviert) – 8-Bit-Reservierungsfeld. Beim Senden auf null initialisiert; beim Empfangen ignoriert.

Fragment Offset (Fragment-Offset) – 13-Bit-Ganzzahl ohne Vorzeichen. Der Offset der Daten, die diesem Header folgen, relativ zum Beginn des fragmentierbaren Teils des ursprünglichen Pakets, in 8-Oktett-Einheiten.

Res (Reserviert) – 2-Bit-Reservierungsfeld. Beim Senden auf null initialisiert; beim Empfangen ignoriert.

M-Flag (M-Markierung) – 1 = weitere Fragmente folgen; 0 = letztes Fragment.

Identification (Identifikation) – 32 Bit. Siehe Beschreibung unten.

Um ein Paket zu senden, das für die MTU des Pfades zu seinem Ziel zu groß ist, kann der Quellknoten das Paket in Fragmente aufteilen und jedes Fragment als separates Paket senden, das am Empfänger wieder zusammengesetzt wird.

Für jedes zu fragmentierende Paket erzeugt der Quellknoten einen Identification-Wert. Dieser Identification-Wert MUSS sich von dem jedes anderen kürzlich* gesendeten fragmentierten Pakets mit derselben Source Address und Destination Address unterscheiden. Wenn ein Routing Header vorhanden ist, ist die relevante Destination Address die Adresse des endgültigen Ziels.

*„Kürzlich" bedeutet innerhalb der maximalen möglichen Lebensdauer des Pakets, einschließlich der Übertragungszeit von der Quelle zum Ziel und der Zeit, die damit verbracht wird, auf die Wiederzusammensetzung mit anderen Fragmenten desselben Pakets zu warten. Es wird jedoch nicht verlangt, dass der Quellknoten die maximale Paketlebensdauer kennt. Stattdessen wird angenommen, dass die Anforderung erfüllt werden kann, indem der Identification-Wert als einfacher 32-Bit-„Wrap-around"-Zähler geführt wird, der jedes Mal inkrementiert wird, wenn ein Paket fragmentiert werden muss. Ob ein einzelner Zähler für den Knoten oder mehrere Zähler geführt werden (z. B. einer für jede mögliche Quelladresse des Knotens oder einer für jede aktive (Quelladresse, Zieladresse)-Kombination), ist eine Implementierungsentscheidung.

Struktur des ursprünglichen Pakets

Das ursprüngliche, große, unfragmentierte Paket wird als „original packet (ursprüngliches Paket)" bezeichnet und besteht aus zwei Teilen:

original packet:

+------------------+----------------------//-----------------------+
|  Unfragmentable  |                 Fragmentable                  |
|       Part       |                     Part                      |
+------------------+----------------------//-----------------------+

Der nicht fragmentierbare Teil (Unfragmentable Part) besteht aus dem IPv6-Header plus allen Erweiterungsheadern, die von Knoten auf dem Weg zum Ziel verarbeitet werden müssen, d. h. alle Header bis einschließlich des Routing Headers (falls vorhanden), andernfalls des Hop-by-Hop Options Headers (falls vorhanden), andernfalls keine Erweiterungsheader.

Der fragmentierbare Teil (Fragmentable Part) besteht aus dem Rest des Pakets, d. h. alle Erweiterungsheader, die nur vom endgültigen Zielknoten verarbeitet werden müssen, plus dem Header der oberen Schicht und den Daten.

Der fragmentierbare Teil des ursprünglichen Pakets wird in Fragmente aufgeteilt, von denen jedes (außer möglicherweise dem letzten „rechtesten" Fragment) eine Länge hat, die ein Vielfaches von 8 Oktetten ist. Diese Fragmente werden in separaten „Fragment-Paketen (fragment packets)" übertragen:

original packet:

+------------------+--------------+--------------+--//--+----------+
|  Unfragmentable  |    first     |    second    |      |   last   |
|       Part       |   fragment   |   fragment   | .... | fragment |
+------------------+--------------+--------------+--//--+----------+

fragment packets:

+------------------+--------+--------------+
|  Unfragmentable  |Fragment|    first     |
|       Part       | Header |   fragment   |
+------------------+--------+--------------+

+------------------+--------+--------------+
|  Unfragmentable  |Fragment|    second    |
|       Part       | Header |   fragment   |
+------------------+--------+--------------+
                      o
                      o
                      o
+------------------+--------+----------+
|  Unfragmentable  |Fragment|   last   |
|       Part       | Header | fragment |
+------------------+--------+----------+

Zusammensetzung der Fragment-Pakete

Jedes Fragment-Paket besteht aus:

(1) Dem nicht fragmentierbaren Teil des ursprünglichen Pakets, wobei das Payload Length-Feld des ursprünglichen IPv6-Headers so geändert wird, dass es nur die Länge dieses Fragment-Pakets enthält (ohne die Länge des IPv6-Headers selbst), und das Next Header-Feld des letzten Headers des nicht fragmentierbaren Teils auf 44 geändert wird.

(2) Einem Fragment Header, der enthält:

• Den Next Header-Wert, der den ersten Header des fragmentierbaren Teils des ursprünglichen Pakets identifiziert.
• Den Fragment Offset, der den Offset des Fragments relativ zum Beginn des fragmentierbaren Teils des ursprünglichen Pakets in 8-Oktett-Einheiten enthält. Der Fragment Offset des ersten „linkesten" Fragments ist 0.
• Den M-Flag-Wert 0, wenn das Fragment das letzte „rechteste" Fragment ist, andernfalls 1.
• Den für das ursprüngliche Paket erzeugten Identification-Wert.

(3) Dem Fragment selbst.

Die Länge der Fragmente MUSS so gewählt werden, dass die resultierenden Fragment-Pakete in die MTU des Pfades zum Ziel des Pakets passen.

Wiederzusammensetzungsprozess

Am Ziel werden die Fragment-Pakete in ihrer ursprünglichen, unfragmentierten Form wieder zusammengesetzt:

reassembled original packet:

+------------------+----------------------//------------------------+
|  Unfragmentable  |                 Fragmentable                   |
|       Part       |                     Part                       |
+------------------+----------------------//------------------------+

Die folgenden Regeln steuern die Wiederzusammensetzung:

Das ursprüngliche Paket wird nur aus Fragment-Paketen mit derselben Source Address, Destination Address und Fragment Identification wieder zusammengesetzt.

Der nicht fragmentierbare Teil des wieder zusammengesetzten Pakets besteht aus allen Headern bis (aber nicht einschließlich) des Fragment Headers des ersten Fragment-Pakets (d. h. des Pakets mit Fragment Offset null), mit zwei Änderungen:

• Das Next Header-Feld des letzten Headers des nicht fragmentierbaren Teils wird aus dem Next Header-Feld des Fragment Headers des ersten Fragments übernommen.
• Die Payload Length des wieder zusammengesetzten Pakets wird aus der Länge des nicht fragmentierbaren Teils sowie der Länge und dem Offset des letzten Fragments berechnet. Die Formel zur Berechnung der Payload Length des wieder zusammengesetzten ursprünglichen Pakets lautet:

PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last

wobei
PL.orig  = Payload Length-Feld des wieder zusammengesetzten Pakets.
PL.first = Payload Length-Feld des ersten Fragment-Pakets.
FL.first = Länge des Fragments nach dem Fragment Header des
           ersten Fragment-Pakets.
FO.last  = Fragment Offset-Feld des Fragment Headers des
           letzten Fragment-Pakets.
FL.last  = Länge des Fragments nach dem Fragment Header des
           letzten Fragment-Pakets.

Der fragmentierbare Teil des wieder zusammengesetzten Pakets wird aus den Fragmenten nach den Fragment Headern in jedem Fragment-Paket aufgebaut. Die Länge jedes Fragments wird berechnet, indem die Länge der Header zwischen dem IPv6-Header und dem Fragment selbst von der Payload Length des Pakets subtrahiert wird; seine relative Position im fragmentierbaren Teil wird aus seinem Fragment Offset-Wert berechnet.

Der Fragment Header ist im endgültigen, wieder zusammengesetzten Paket nicht vorhanden.

Fehlerbedingungen

Bei der Wiederzusammensetzung fragmentierter Pakete können folgende Fehlerbedingungen auftreten:

Zeitüberschreitungsfehler: Wenn innerhalb von 60 Sekunden nach dem Empfang des ersten eintreffenden Fragments eines Pakets nicht genügend Fragmente empfangen wurden, um die Wiederzusammensetzung des Pakets abzuschließen, MUSS die Wiederzusammensetzung dieses Pakets aufgegeben werden, und alle bereits empfangenen Fragmente dieses Pakets MÜSSEN verworfen werden. Wenn das erste Fragment (d. h. das Fragment mit Fragment Offset null) empfangen wurde, SOLLTE eine ICMP-Time-Exceeded-Nachricht (Fragment Reassembly Time Exceeded) an die Quelle dieses Fragments gesendet werden.

Längenfehler: Wenn die Länge eines Fragments (abgeleitet aus dem Payload Length-Feld des Fragment-Pakets) kein Vielfaches von 8 Oktetten ist und das M-Flag dieses Fragments 1 ist, MUSS dieses Fragment verworfen werden, und es SOLLTE eine ICMP-Parameter-Problem-Nachricht (Code 0) an die Quelle des Fragments gesendet werden, die auf das Payload Length-Feld des Fragment-Pakets zeigt.

Paket-zu-groß-Fehler: Wenn die Länge und der Offset eines Fragments dazu führen würden, dass die Payload Length des aus diesem Fragment wieder zusammengesetzten Pakets 65.535 Oktette überschreitet, MUSS dieses Fragment verworfen werden, und es SOLLTE eine ICMP-Parameter-Problem-Nachricht (Code 0) an die Quelle des Fragments gesendet werden, die auf das Fragment Offset-Feld des Fragment-Pakets zeigt.

Nicht-Fehlerbedingungen

Die folgenden Situationen werden voraussichtlich nicht auftreten, gelten aber, wenn sie auftreten, nicht als Fehler:

Header-Unterschiede: Die Anzahl und der Inhalt der Header vor dem Fragment Header können sich bei verschiedenen Fragmenten desselben ursprünglichen Pakets unterscheiden. Welche Header auch immer in jedem Fragment-Paket vor dem Fragment Header vorhanden sind, werden beim Eintreffen des Pakets verarbeitet, bevor das Fragment zur Wiederzusammensetzung in die Warteschlange gestellt wird. Nur die Header im Fragment-Paket mit Offset null werden im wieder zusammengesetzten Paket beibehalten.

Next-Header-Unterschiede: Die Next Header-Werte in den Fragment Headern verschiedener Fragmente desselben ursprünglichen Pakets können unterschiedlich sein. Nur der Wert aus dem Fragment-Paket mit Offset null wird für die Wiederzusammensetzung verwendet.