4.5 En-tête de fragmentation (Fragment Header)

Le Fragment header est utilisé par une source IPv6 pour envoyer des paquets plus grands que le MTU du chemin vers leur destination. (Note : contrairement à IPv4, la fragmentation dans IPv6 est effectuée uniquement par les nœuds sources, et non par les routeurs sur le chemin de livraison du paquet — voir la section 5.) Le Fragment header est identifié par la valeur Next Header 44 dans l'en-tête précédent, et a le format suivant :

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

Next Header (en-tête suivant) — Sélecteur sur 8 bits. Identifie le type de l'en-tête initial de la Fragmentable Part (partie fragmentable) (définie ci-dessous) du paquet original. Utilise les mêmes valeurs que le champ Protocol d'IPv4 [RFC-1700 et seq.].

Reserved (réservé) — Champ réservé sur 8 bits. Initialisé à zéro à l'émission ; ignoré à la réception.

Fragment Offset (décalage de fragment) — Entier non signé sur 13 bits. Décalage, en unités de 8 octets, des données qui suivent cet en-tête, par rapport au début de la Fragmentable Part du paquet original.

Res (réservé) — Champ réservé sur 2 bits. Initialisé à zéro à l'émission ; ignoré à la réception.

M flag (indicateur M) — 1 = d'autres fragments suivent ; 0 = dernier fragment.

Identification — 32 bits. Voir la description ci-dessous.

Pour envoyer un paquet trop grand pour le MTU du chemin vers sa destination, le nœud source PEUT diviser le paquet en fragments et envoyer chaque fragment comme un paquet séparé, à réassembler au niveau du récepteur.

Pour chaque paquet à fragmenter, le nœud source génère une valeur Identification. Cette Identification DOIT être différente de celle de tout autre paquet fragmenté envoyé récemment* avec les mêmes adresses Source Address et Destination Address. Si un Routing header est présent, la Destination Address concernée est celle de la destination finale.

*« Récemment » signifie dans la durée de vie maximale possible du paquet, incluant le temps de transmission de la source à la destination et le temps passé à attendre le réassemblage avec d'autres fragments du même paquet. Cependant, il n'est pas exigé que le nœud source connaisse la durée de vie maximale du paquet. On suppose plutôt que cette exigence peut être satisfaite en maintenant la valeur Identification comme un simple compteur « wrap-around (à rebouclage) » sur 32 bits, incrémenté à chaque fois qu'un paquet doit être fragmenté. Le choix de maintenir un seul compteur pour le nœud ou plusieurs compteurs (par exemple, un par adresse source possible du nœud, ou un par combinaison active (adresse source, adresse destination)) est une décision d'implémentation.

Structure du paquet original

Le paquet initial, grand et non fragmenté, appelé « original packet (paquet original) », est considéré comme composé de deux parties, comme suit :

original packet:

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

La Unfragmentable Part (partie non fragmentable) est composée de l'en-tête IPv6 plus tout en-tête d'extension qui doit être traité par les nœuds en chemin vers la destination, c'est-à-dire tous les en-têtes jusqu'au Routing header inclus (s'il est présent), sinon le Hop-by-Hop Options header (s'il est présent), sinon aucun en-tête d'extension.

La Fragmentable Part (partie fragmentable) est composée du reste du paquet, c'est-à-dire tout en-tête d'extension qui ne doit être traité que par le nœud de destination finale, plus l'en-tête de couche supérieure et les données.

La Fragmentable Part du paquet original est divisée en fragments, chacun (sauf éventuellement le dernier fragment « le plus à droite ») d'une longueur multiple entière de 8 octets. Ces fragments sont transmis dans des « fragment packets (paquets de fragments) » séparés, comme suit :

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 |
+------------------+--------+----------+

Composition des paquets de fragments

Chaque paquet de fragment est composé de :

(1) La Unfragmentable Part du paquet original, avec le Payload Length de l'en-tête IPv6 original modifié pour contenir uniquement la longueur de ce paquet de fragment (sans compter la longueur de l'en-tête IPv6 lui-même), et le champ Next Header du dernier en-tête de la Unfragmentable Part modifié à 44.

(2) Un Fragment header contenant :

• La valeur Next Header identifiant le premier en-tête de la Fragmentable Part du paquet original.

• Un Fragment Offset contenant le décalage du fragment, en unités de 8 octets, par rapport au début de la Fragmentable Part du paquet original. Le Fragment Offset du premier fragment (« le plus à gauche ») est 0.

• Une valeur M flag de 0 si le fragment est le dernier (« le plus à droite »), sinon 1.

• La valeur Identification générée pour le paquet original.

(3) Le fragment lui-même.

La longueur des fragments DOIT être choisie de sorte que les paquets de fragments résultants s'adaptent au MTU du chemin vers la destination du paquet.

Processus de réassemblage

À la destination, les paquets de fragments sont réassemblés dans leur forme originale non fragmentée, comme suit :

reassembled original packet:

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

Les règles suivantes régissent le réassemblage :

Le paquet original est réassemblé uniquement à partir de paquets de fragments ayant les mêmes Source Address, Destination Address et Fragment Identification.

La Unfragmentable Part du paquet réassemblé est constituée de tous les en-têtes jusqu'au Fragment header du premier paquet de fragment (c'est-à-dire celui dont le Fragment Offset est zéro), avec les deux modifications suivantes :

• Le champ Next Header du dernier en-tête de la Unfragmentable Part est obtenu à partir du champ Next Header du Fragment header du premier fragment.

• Le Payload Length du paquet réassemblé est calculé à partir de la longueur de la Unfragmentable Part et de la longueur et du décalage du dernier fragment. Par exemple, la formule pour calculer le Payload Length du paquet original réassemblé est :

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

where
PL.orig  = Payload Length field of reassembled packet.
PL.first = Payload Length field of first fragment packet.
FL.first = length of fragment following Fragment header of
           first fragment packet.
FO.last  = Fragment Offset field of Fragment header of
           last fragment packet.
FL.last  = length of fragment following Fragment header of
           last fragment packet.

La Fragmentable Part du paquet réassemblé est construite à partir des fragments suivant les Fragment headers dans chaque paquet de fragment. La longueur de chaque fragment est calculée en soustrayant de la longueur Payload Length du paquet la longueur des en-têtes entre l'en-tête IPv6 et le fragment lui-même ; sa position relative dans la Fragmentable Part est calculée à partir de sa valeur Fragment Offset.

Le Fragment header n'est pas présent dans le paquet final réassemblé.

Conditions d'erreur

Les conditions d'erreur suivantes peuvent survenir lors du réassemblage de paquets fragmentés :

Erreur de délai d'attente : Si des fragments insuffisants pour compléter le réassemblage du paquet ne sont pas reçus dans les 60 secondes suivant la réception du premier fragment arrivé pour ce paquet, le réassemblage de ce paquet DOIT être abandonné et tous les fragments déjà reçus pour ce paquet DOIVENT être rejetés. Si le premier fragment (c'est-à-dire celui dont le Fragment Offset est zéro) a été reçu, un message ICMP Time Exceeded — Fragment Reassembly Time Exceeded DEVRAIT être envoyé à la source de ce fragment.

Erreur de longueur : Si la longueur d'un fragment (dérivée du champ Payload Length du paquet de fragment) n'est pas un multiple de 8 octets et que le M flag de ce fragment est 1, ce fragment DOIT être rejeté et un message ICMP Parameter Problem, Code 0, DEVRAIT être envoyé à la source du fragment, pointant vers le champ Payload Length du paquet de fragment.

Erreur de paquet trop grand : Si la longueur et le décalage d'un fragment sont tels que le Payload Length du paquet réassemblé à partir de ce fragment dépasserait 65 535 octets, ce fragment DOIT être rejeté et un message ICMP Parameter Problem, Code 0, DEVRAIT être envoyé à la source du fragment, pointant vers le champ Fragment Offset du paquet de fragment.

Conditions non erronées

Les situations suivantes ne sont pas attendues mais, si elles se produisent, ne sont pas considérées comme des erreurs :

Différences d'en-têtes : Le nombre et le contenu des en-têtes précédant le Fragment header dans différents fragments du même paquet original peuvent différer. Quels que soient les en-têtes présents avant le Fragment header dans chaque paquet de fragment, ils sont traités à l'arrivée du paquet avant que le fragment ne soit mis en file d'attente pour le réassemblage. Seuls les en-têtes du paquet de fragment dont le décalage est zéro sont conservés dans le paquet réassemblé.

Différences de Next Header : Les valeurs Next Header dans les Fragment headers de différents fragments du même paquet original peuvent différer. Seule la valeur du paquet de fragment dont le décalage est zéro est utilisée pour le réassemblage.