Résumé

  • Dans un jumbogramme IPv6, la valeur nulle du champ Payload Length renvoie à une option Jumbo Payload placée dans l’en-tête de proche en proche qui suit immédiatement.
  • L’option indique sur 32 bits une charge strictement supérieure à 65 535 octets ; le zéro isolé ne démontre ni l’absence de données ni la conformité du paquet.
  • Une construction conforme ne garantit pas qu’un tunnel, un équipement intermédiaire ou le chemin de retour saura la transporter et en rendre compte.

Un renvoi, pas une mesure

Le champ Payload Length de l’en-tête IPv6 de base ne dispose que de 16 bits. En temps normal, il mesure tout ce qui suit les 40 octets de cet en-tête, extensions comprises. Pour dépasser 65 535 octets, la RFC 2675 n’agrandit pas l’en-tête commun à tous les paquets. Elle réserve la valeur zéro et confie la mesure à une option exceptionnelle.

Ce mécanisme ne fonctionne que comme un couple. Si le champ vaut zéro, si Next Header annonce un en-tête Hop-by-Hop Options et si des octets existent après l’en-tête de base, le destinataire doit examiner cet en-tête. L’option Jumbo Payload y fournit une valeur non signée de 32 bits. Elle comprend les extensions et les données de couche supérieure, mais pas les 40 octets de l’en-tête IPv6, et elle doit être supérieure à 65 535.

Une fiche d’incident qui ne conserve que « Payload Length = 0 » archive donc une instruction sans son résultat. Il faut encore connaître la chaîne des en-têtes, la présence de l’option, sa position et sa valeur, ainsi que la longueur effectivement capturée. Dans une capture tronquée, l’absence des octets attendus décrit parfois la limite de l’outil, non celle du paquet sur le réseau.

Les contradictions que la norme refuse

La RFC 2675 énumère quatre incohérences décisives. Un zéro suivi d’un en-tête de proche en proche dépourvu d’option Jumbo est erroné. Une option Jumbo accompagnée d’une longueur de base non nulle l’est aussi. Une valeur Jumbo inférieure à 65 536 n’a pas sa place dans ce format. Enfin, l’option Jumbo et l’en-tête Fragment ne doivent jamais cohabiter.

Ces cas montrent que la preuve est structurée : ni le zéro ni la grande valeur ne se suffisent. Leur accord et le contexte de la chaîne d’en-têtes font foi. Les réponses ICMPv6 Parameter Problem prévues pointent vers l’élément contradictoire. Selon la RFC 4443, le Type 4 Code 0 signale un champ d’en-tête fautif et le paquet est abandonné, sous réserve des règles qui gouvernent l’émission de la réponse.

Il serait pourtant imprudent de transformer l’absence d’ICMPv6 en acquittement implicite. Un filtrage, une limitation de débit, une route asymétrique ou l’absence de chemin retour peuvent faire disparaître le message. L’erreur observée est une preuve positive ; le silence, lui, laisse plusieurs scénarios ouverts.

Le zéro d’UDP n’est pas le même zéro

Dans un datagramme UDP transporté par un jumbogramme, le champ UDP Length peut lui aussi valoir zéro si la longueur réelle dépasse 65 535. Le destinataire déduit alors cette longueur de la valeur Jumbo, après retrait des éventuels en-têtes d’extension placés avant UDP. La somme de contrôle utilise la longueur réelle ainsi obtenue, jamais zéro.

Les deux sentinelles sont coordonnées, mais relèvent de règles distinctes. La première se lit dans IPv6 et renvoie vers l’option ; la seconde se lit dans UDP et modifie le calcul de la longueur UDP. Déduire l’une de l’autre sans inspecter le paquet crée une preuve imaginaire. TCP n’a pas de champ équivalent de longueur de paquet ; pour les jumbogrammes, une MSS de 65 535 est traitée comme sans limite propre et la taille utile dépend surtout de la découverte du MTU du chemin.

La conformité ne réserve pas de capacité

L’usage n’a de sens que sur un lien dont le MTU dépasse 65 575 octets, soit l’en-tête IPv6 de 40 octets ajouté à une charge au-delà de 65 535. Les nœuds qui ne sont reliés à aucun réseau de cette capacité ne sont pas tenus d’implémenter les jumbogrammes. La RFC 8201 rappelle en outre que le Path MTU est le plus petit MTU rencontré ; un paquet trop grand peut être rejeté et susciter un message Packet Too Big.

On peut donc établir qu’un paquet est bien formé sans prouver qu’il a atteint sa destination. L’émetteur, le destinataire et leur premier lien peuvent être compatibles, tandis qu’un tunnel ou un boîtier intermédiaire ne l’est pas. À l’inverse, la RFC 9288 souligne qu’écarter tout paquet uniquement parce qu’il contient l’option Jumbo revient à rejeter des jumbogrammes valides.

Une analyse solide sépare trois questions : que déclare le paquet, sa syntaxe est-elle cohérente, et que s’est-il passé sur le chemin ? Les champs répondent à la première, un parseur complet à la deuxième, et seules des observations de bout en bout répondent à la troisième. Bob Hinden est ici un repère d’attribution parmi les coauteurs de la RFC 2675 et de la spécification IPv6 ; le texte ne lui attribue ni invention solitaire ni contrôle du déploiement.

Sources