Résumé

  • Data Offset fixe la limite physique de l’en-tête; EOL arrête la liste logique plus tôt si nécessaire.
  • NOP occupe un octet pour faciliter une disposition, mais les récepteurs doivent accepter les options non alignées.

Deux limites, deux fonctions

Un récepteur parcourt les options octet par octet. Il peut rencontrer NOP, puis une option dotée d’un champ de longueur, puis EOL. La longueur permet de franchir une option inconnue; EOL indique que les options significatives sont terminées. Les octets restants jusqu’à la limite annoncée par Data Offset sont du remplissage nul, pas des données applicatives.

La grammaire décrite par RFC 793 en 1981 distingue donc les options d’un seul octet des options comportant un type, une longueur et des données. EOL est le type 0 et NOP le type 1. Toute autre option, y compris une extension future, doit avoir une longueur. Cette règle permet de continuer après une option non reconnue, sous réserve d’une longueur légale.

Alignement sans obligation

NOP peut placer l’option suivante sur une limite de mot choisie par l’émetteur. RFC 793 exigeait déjà que le récepteur accepte une option commençant sur n’importe quel octet; RFC 9293 conserve explicitement cette obligation. NOP n’est donc ni un séparateur obligatoire ni une preuve de gain de performance.

EOL ne raccourcit pas l’en-tête et ne lance pas la charge utile. Il termine l’interprétation logique; Data Offset reste l’autorité physique. Lorsqu’EOL apparaît avant cette limite, le reste doit être rempli de zéros.

Une continuité de conception

RFC 9293 conserve la structure de RFC 793 : longueur pour les options ordinaires, tolérance aux options inconnues, EOL pour une fin anticipée et NOP pour une disposition facultative. Les longueurs nulles ou incohérentes doivent être traitées comme illégales; la robustesse dépend de la progression sûre du parseur.

Sources