Résumé

  • La RFC 791 destinait le champ Identification à l’association des fragments d’un même datagramme.
  • La RFC 6864 retire cette signification aux datagrammes atomiques et la conserve pour les datagrammes non atomiques, lorsque la fragmentation demeure possible ou a déjà eu lieu.

Deux datagrammes, un même identifiant

Deux datagrammes IPv4 ordinaires peuvent porter la même valeur Identification lorsque DF vaut 1, MF vaut 0 et que le décalage de fragment vaut zéro. Ils sont alors atomiques : aucune fragmentation ultérieure ni réassemblage ne peut les concerner. La répétition de l’ID ne prouve donc ni duplication, ni épuisement d’un compteur, ni violation d’une règle d’unicité.

La RFC 791 définissait l’Identification comme une valeur attribuée par l’émetteur pour aider à réunir les fragments. Avec les adresses source et destination, le protocole, le drapeau MF et le décalage, elle permettait de distinguer les morceaux de datagrammes encore en cours de réassemblage.

Mais un champ de 16 bits ne propose que 65 536 valeurs. Imposer une non-répétition à tous les datagrammes, pendant toute la durée de vie maximale, devient coûteux lorsque le débit augmente. Les datagrammes qui ne peuvent pas être fragmentés n’ajoutent pourtant aucun risque de confusion entre fragments.

La RFC 6864 sépare donc les deux états à partir de champs déjà présents. Un datagramme non atomique autorise la fragmentation ou en porte déjà la trace : DF vaut zéro, MF vaut un, ou le décalage est non nul. Son ID conserve alors sa fonction de réassemblage. Pour un datagramme atomique, la source peut choisir n’importe quelle valeur et les équipements doivent ignorer ce champ. Zéro n’est pas une valeur réservée.

Cette évolution n’abolit pas l’ID IPv4. Elle limite sa promesse au problème qu’il résout effectivement. Les outils qui veulent corréler ou dédupliquer des paquets doivent donc s’appuyer sur d’autres éléments ; un motif séquentiel peut révéler une implémentation, mais ne constitue pas une identité garantie.

Sources