Résumé

  • Le bit de poids fort du type d’option IPv4 indique si l’option est copiée dans tous les fragments.
  • Zéro laisse l’option dans le premier fragment; un la fait accompagner tous les fragments, sans garantir qu’un équipement la traite ou l’accepte.

Un datagramme, des en-têtes différents

La fragmentation divise les données et crée plusieurs en-têtes IPv4. Ces en-têtes ne sont pas nécessairement identiques. RFC 791 prévoit que certaines options soient copiées, tandis que d’autres restent dans le premier fragment.

La règle est encodée dans chaque option. L’octet de type comprend un bit de copie, deux bits de classe et un numéro d’option sur cinq bits. Le bit vaut zéro si l’option ne doit pas être copiée lors de la fragmentation, et un si elle doit être copiée dans tous les fragments.

Ainsi, un fragment ultérieur peut ne pas contenir une option présente dans l’en-tête initial sans être malformé pour cette seule raison. Une option marquée pour la copie, en revanche, doit être reportée dans chaque en-tête produit par la fragmentation.

Propagation et classification sont distinctes

Les sept autres bits répondent à d’autres questions. La classe distingue historiquement les options de contrôle de celles liées au débogage et à la mesure; le numéro identifie la syntaxe de l’option. Aucun des deux ne décide de sa propagation.

RFC 791 marque les options de routage par la source et l’option Security comme copiées. Record Route et Timestamp ne le sont pas et restent dans le premier fragment. Le bit décrit une règle de propagation, pas l’importance, la sûreté ou le rang d’une option.

Les options non copiées peuvent rester dans le premier fragment parce qu’il contient le début des données originales. Les options copiées signalent au contraire que leur état doit accompagner les fragments séparés.

Chaque fragment possède son propre en-tête

Des ensembles d’options différents peuvent donner des longueurs d’en-tête différentes. Un fragment qui perd des options non copiées peut avoir un IHL plus court. Sa longueur totale couvre son propre en-tête et ses données, tandis que le checksum IPv4 ne couvre que l’en-tête de ce fragment ; aucune de ces valeurs ne peut simplement reprendre celle du datagramme initial.

Une règle conservée par l’histoire

RFC 7126, publié en 2014, reprend la même organisation du type: copie, classe et numéro. Il décrit aussi des équipements qui peuvent supprimer, ignorer ou traiter les paquets contenant des options IPv4.

La copie ne promet donc ni interprétation ni acceptation. Elle indique seulement ce que la fragmentation doit placer dans chaque en-tête avant les politiques locales de traitement et de filtrage.

Sources