Résumé

  • Dans l’octet de type d’une option IPv4, le bit Copy indique si l’option reste seulement dans le fragment d’offset nul ou doit être reproduite dans tous les fragments.
  • Fragmenter oblige à dériver les en-têtes, pas à les cloner : la liste d’options, l’IHL, la longueur totale, l’offset, MF et la somme de contrôle peuvent légitimement différer.
  • Une option copiée n’est ni authentifiée ni figée. Des fragments suivant des routes différentes peuvent faire évoluer ses champs, tandis que le premier fragment conserve l’autorité sur l’ensemble non copié.

Une seule enveloppe, trois héritages

La fragmentation IPv4 est souvent racontée comme une opération sur la charge utile. Une unité de transmission maximale plus petite apparaît, le paquet est découpé, puis la destination recolle les morceaux. Ce résumé omet le travail le plus révélateur : le module qui coupe doit décider ce que chaque nouvel en-tête a le droit et le devoir d’emporter.

RFC 791 décompose le type d’option en un bit Copy, deux bits Class et cinq bits Number. Une valeur Copy de zéro signifie que l’option est copiée seulement dans le premier fragment. Une valeur de un signifie qu’elle est copiée dans tous les fragments. « Premier » ne désigne pas celui qui gagne la course jusqu’au récepteur, mais celui qui contient les données à l’offset zéro.

Loose Source and Record Route porte le type 131, donc le bit supérieur vaut un. Record Route porte le type 7, donc ce bit vaut zéro. Dans l’exemple d’ouverture, les fragments ultérieurs doivent encore connaître l’instruction de routage qui accompagne le type 131 ; ils n’ont pas à dupliquer l’historique ordinaire de type 7. Ils peuvent donc présenter un IHL plus court que le fragment zéro tout en appartenant au même datagramme.

L’identité de réassemblage n’exigeait pas l’identité des en-têtes. C’est précisément parce que chaque fragment devient un objet routable séparément que sa dérivation devait être sémantique.

La règle précédait déjà la spécification de 1981

RFC 760, publié en janvier 1980, distinguait déjà les options à copier dans chaque fragment de celles qui ne resteraient que dans le premier. Sa procédure de fragmentation demandait une copie sélective de l’en-tête Internet lors de la création du fragment suivant.

RFC 791 transforma cette distinction en règle directement lisible dans le type. Le fragmenteur n’avait pas besoin de demander à une autorité extérieure si une option méritait d’être conservée. Il pouvait appliquer localement un bit défini dans la grammaire commune.

Cette économie de règle ne rendait pas l’opération grossière. Le premier fragment partait de l’en-tête original ; les suivants recevaient un en-tête sélectionné. Retirer les options non copiées changeait l’Internet Header Length. La quantité de données modifiait Total Length. La position dans le datagramme fixait Fragment Offset. L’existence d’une suite déterminait More Fragments. Toute modification de l’en-tête imposait une nouvelle Header Checksum.

Trois sommes de contrôle correctes ne prouvent donc pas que les trois en-têtes ont la bonne sémantique. Une option Copy 1 peut avoir disparu malgré une somme valide. Une option Copy 0 peut avoir été reproduite par erreur, là encore sous une somme parfaitement valide. La somme contrôle la cohérence locale des octets ; elle ne remplace pas la règle de filiation.

Le bit ne classait pas les options par importance

Un vocabulaire malheureux ferait de un le signe d’une option « importante » et de zéro celui d’un accessoire. La table ne dit rien de tel. Strict Source and Record Route, type 137, et Stream Identifier, type 136, ont Copy 1. Timestamp, type 68, et Record Route, type 7, ont Copy 0. L’ancienne Basic Security Option, type 130, avait aussi Copy 1, sans que ce bit lui fournisse le moindre chiffrement.

Copy 0 signifie seulement que la sémantique de l’option n’exige pas une copie dans chaque objet dérivé. L’option reste dans le fragment zéro, où se trouve la sélection complète de l’en-tête original. Copy 1 signifie que le fragment indépendant doit recevoir l’option. Il ne promet ni priorité, ni fiabilité, ni livraison, ni traitement réussi.

Le registre IANA des paramètres IPv4 expose encore les colonnes Copy, Class, Number, Value, Name et Reference. Il permet d’établir l’attribution documentaire d’un type. Il ne mesure pas son usage actuel, ne certifie pas une implémentation et ne prouve pas qu’un routeur a appliqué l’option.

Entre l’enregistrement d’un numéro et l’observation d’un effet, plusieurs marches restent à gravir : émission réelle, acceptation, traitement intermédiaire, arrivée, réassemblage. Aucune ne découle automatiquement de la précédente.

Copier n’interdisait pas aux chemins de diverger

L’expression « copiée dans tous les fragments » suggère facilement que les mêmes octets doivent arriver partout. RFC 815 montre pourquoi cette conclusion est trop forte. Des fragments d’un même datagramme peuvent suivre des chemins différents. Une option de source-and-record-route dupliquée au moment de la coupure peut être mise à jour par des routeurs différents.

À l’arrivée, les versions enregistrées ne racontent donc pas nécessairement la même route. Le bit Copy a transmis la capacité et la responsabilité de traiter l’option ; il n’a pas gelé les champs que la sémantique autorisait ensuite à évoluer.

Pour le réassemblage décrit, RFC 815 retient la route de retour enregistrée dans le premier fragment et ignore les variantes des autres. Ce choix n’est ni une fusion ni un vote. La spécification désigne une provenance d’autorité : le fragment d’offset nul.

Un outil qui déduplique immédiatement ces options peut supprimer la preuve de chemins divergents. Un autre qui déclare toute divergence hostile confond une mutation permise avec une falsification. Il faut conserver les fragments reçus, leur ordre, leur offset et la version finalement retenue.

Le premier fragment pouvait arriver le dernier

RFC 815 formule une difficulté très concrète : tant que le fragment zéro n’est pas arrivé, le récepteur peut ignorer la taille finale de l’en-tête. Un fragment non nul a le droit d’omettre les options Copy 0 et d’afficher un IHL plus petit.

Le premier fragment au sens du protocole peut donc être le dernier au sens de l’horloge. Si une sonde transforme « première observation » en « en-tête complet », elle donne une autorité définitive à un état que la spécification décrit comme partiel.

RFC 6274 réutilise cette frontière pour certaines vérifications de sécurité. Contrôler qu’un paquet réassemblé peut réellement contenir l’en-tête de transport annoncé exige l’IHL du premier fragment. S’il manque encore, une implémentation peut effectuer une vérification préliminaire, puis doit réappliquer le test complet lorsque l’offset zéro arrive.

Ce modèle sépare calcul provisoire et verdict irréversible. Il autorise le système à continuer sans prétendre que l’incertitude a disparu. Une file d’attente de réassemblage n’est pas seulement un tampon d’octets ; elle conserve aussi une question encore ouverte sur la forme de l’en-tête original.

L’alignement empêchait une suppression aveugle

End of Option List et No Operation rappellent que la zone d’options est une grammaire, pas un sac d’octets indépendants. Ils terminent ou alignent la liste. Lorsqu’un fragmenteur retire une option non copiée, il peut devoir reconstruire la fin et le remplissage afin que le nouvel en-tête reste aligné sur 32 bits.

Une mise en œuvre correcte doit donc lire les types et longueurs, éviter de couper une option multioctet, refermer la liste, recalculer l’IHL et la somme de contrôle. Le seul fait de reconnaître le bit supérieur ne suffit pas si le parseur détruit les frontières auxquelles ce bit s’applique.

La leçon vaut aussi pour une option inconnue. Ne pas en comprendre la politique détaillée ne confère pas le droit de la supprimer partout ou de la reproduire arbitrairement. La structure commune fournit au moins les moyens de parcourir, préserver ou refuser de manière déterministe.

Un socle minimal peut être strict. Il est minimal parce qu’il ne décide que ce qui doit être commun, non parce qu’il tolère des transformations impossibles à vérifier.

La fragilité ultérieure n’annulait pas le mécanisme

RFC 8900 reformule la règle : toutes les options IPv4 figurent dans le premier fragment, et seules celles dont le bit Copy vaut un figurent dans les fragments suivants. Le document analyse aussi la fragilité pratique de la fragmentation face aux pertes, aux middleboxes, aux filtres qui ne voient pas l’en-tête de transport et aux ressources de réassemblage.

Il ne s’agit pas d’un recensement prouvant que toute fragmentation échoue. Les mécanismes de panne et leur fréquence sont deux types de preuve différents. Une recommandation de réduire l’exposition à la fragmentation n’autorise pas à réécrire l’histoire comme si les règles de copie n’avaient jamais eu d’effet.

IPv6 adopta plus tard un autre partage. RFC 8200 réserve la fragmentation à la source et sépare les en-têtes nécessaires à chaque fragment de ceux portés avec la première partie fragmentable. Cette comparaison éclaire le déplacement de la frontière, mais l’article reste consacré au problème IPv4 : comment un hôte ou un routeur autorisé à fragmenter pouvait transmettre juste assez de sémantique à chaque dérivé.

Celui qui coupe n’obtient pas la propriété du sens

Dans IPv4, le fragmenteur peut être la source ou un routeur intermédiaire, selon la taille, le chemin et notamment le bit Don’t Fragment. L’image du routeur à l’ouverture n’est donc pas une règle universelle.

Quelle que soit l’entité, son mandat reste étroit. Elle divise les données, maintient les champs de réassemblage, choisit les options selon Copy, ferme le nouvel en-tête et recalcule ce qui doit l’être. Elle ne peut pas redéfinir le contenu de Record Route, transformer Copy 0 en jugement d’inutilité ou promettre qu’une option Copy 1 sera exécutée en aval.

Cette distribution de l’autorité est ce qui permet aux implémentations indépendantes de coopérer. La règle commune protège les invariants nécessaires à l’acheminement et au réassemblage. Les décisions qui n’ont pas besoin d’être communes restent là où leur contexte existe.

Une enquête doit accepter les différences légitimes

Une chaîne de preuve utile associe adresse source, destination, protocole, Identification, Fragment Offset, MF, IHL, types d’option, valeurs Copy et ordre d’arrivée. Elle cherche des violations précises : option Copy 0 dans un fragment non nul, disparition d’une option Copy 1, longueur incohérente, option tronquée, alignement invalide ou verdict préliminaire jamais rejoué.

L’absence du fragment zéro doit rester une absence. Elle ne prouve pas que le datagramme original ne portait aucune option non copiée. De même, une option copiée différente n’est pas automatiquement malveillante si son propre format autorise l’écriture en chemin.

La meilleure observation ne force pas les fragments à raconter une histoire uniforme. Elle conserve assez de provenance pour distinguer une divergence permise, une perte, une réécriture et une contradiction.

Sources et limite de preuve

Cette analyse s’appuie sur RFC 760, RFC 791, RFC 815, RFC 1122, RFC 1812, RFC 6274, RFC 8900, RFC 8200 et le registre IANA. Ces sources établissent les règles et des conséquences opérationnelles bornées ; elles ne démontrent ni la prévalence actuelle, ni la conformité d’un produit, ni la fréquence d’une attaque, ni le sort de tous les fragments réels.