Résumé

  • Le RFC 894 affectait la valeur hexadécimale 0800 au type IPv4 et imposait de compléter par des zéros un champ de données Ethernet inférieur à 46 octets. Ces octets existaient sur le lien, sans appartenir au paquet IP ni à son champ Total Length.
  • Cette règle oblige à conserver deux mesures : la mémoire de réception doit accueillir la charge livrée par le lien, tandis que le parseur IP doit s’arrêter à Total Length. Le RFC 6274 a ensuite formalisé cette inclusion et le rejet du cas inverse, quand IP annonce plus d’octets que le lien n’en fournit.
  • Le bourrage n’était pas pour autant sans conséquence. CERT/CC a documenté des pilotes qui y recopiaient d’anciennes données de tampon et divulguaient ainsi de la mémoire. De même, les errata vérifiés du RFC 894 corrigent la lecture sans réécrire le témoignage original.

Un mot faux au milieu de deux bornes justes

Le premier paragraphe de format du RFC 894 est sans ambiguïté. Un datagramme IP est placé dans une trame Ethernet standard. Le champ Type porte 0800 en hexadécimal. Le champ de données commence par l’en-tête IP, suivi immédiatement des données IP.

Le paragraphe suivant fixe le minimum physique. Si ce champ ne compte pas 46 octets, l’émetteur ajoute des octets nuls. Le texte précise qu’ils ne font pas partie du paquet IP et qu’ils ne sont pas inclus dans Total Length.

Puis vient la faute : « minimum » 1 500, suivi de « maximum » 1 500. Lire le premier mot à la lettre détruirait la distinction que le document vient d’établir entre 46 et 1 500. Le problème n’est pas un débat tardif sur la technologie. C’est une contradiction interne dans le texte de 1984.

L’erratum 570, de type technique et vérifié, remplace « minimum » par « maximum ». L’erratum 5141, signalé plus tard et vérifié en 2024, enregistre la même correction. Aucun ne prétend qu’Ethernet aurait changé de taille à sa date de vérification.

La politique des errata du RFC Editor conserve volontairement la séparation. Un RFC publié ne change plus. Un erratum vérifié est considéré comme exact, mais n’est pas incorporé aux versions TXT, PDF ou XML. Pour citer correctement la borne, il faut donc garder le document qui contient l’erreur et le registre qui l’interprète.

Le premier mètre appartenait à IP

Trois ans auparavant, le RFC 791 avait défini Total Length comme la longueur du datagramme en octets, en-tête et données compris. IHL répond à une autre question : la longueur de l’en-tête en mots de 32 bits, donc l’endroit où commencent les données.

Ces champs permettent déjà de vérifier que l’en-tête tient dans le datagramme. Ethernet ajoute une enveloppe extérieure. Il peut imposer un minimum à cette enveloppe, mais il ne peut pas modifier rétrospectivement la valeur que l’expéditeur IP a placée dans Total Length.

Prenons un en-tête IPv4 minimal de vingt octets sans données. Ethernet doit présenter un champ de données de 46 octets. Les vingt-six octets restants n’ont pas été fournis par l’application et ne sont pas devenus un contenu IP. Le pilote les crée pour le lien, sous forme de zéros.

On obtient ainsi une inégalité parfaitement valide :

IHL × 4 <= Total Length <= longueur de la charge du lien

Le deuxième signe peut être strict. Ce n’est pas une anomalie à réparer en allongeant le datagramme ; c’est précisément la place du bourrage.

0800 donnait un langage, pas une taille

La confusion des mètres pouvait commencer deux octets plus tôt. Sur un câble partagé par Ethernet et IEEE 802.3, le même emplacement d’en-tête servait soit de longueur, soit de type.

Le RFC 1122 explique la règle de distinction : une valeur inférieure ou égale à 1 500 est une longueur 802.3 ; les EtherType valides sont supérieurs à 1 500. 0800 hexadécimal vaut 2 048 en décimal. Il sélectionne donc IPv4. Il ne décrit pas une trame de 2 048 octets.

Le choix du langage précède le calcul de l’objet. Après avoir reconnu IPv4, le récepteur consulte le champ Total Length de l’en-tête IP. Il ne remplace pas cette valeur par la fin du tampon Ethernet simplement parce que le tampon contient davantage d’octets.

Le RFC 1122 rendait le format du RFC 894 obligatoire en émission et en réception sur Ethernet 10 Mb/s. La réception de la forme du RFC 1042 était recommandée, son émission facultative. Une machine capable d’émettre les deux devait proposer un réglage et choisir le RFC 894 par défaut. Un câble commun n’abolissait donc pas la preuve de format.

Huit octets d’enveloppe ne devenaient pas huit octets d’IP

Le RFC 1042 transportait IP et ARP dans IEEE 802.2 LLC et SNAP. LLC et SNAP ajoutaient ensemble huit octets ; les seize derniers bits de SNAP portaient l’EtherType, 2 048 pour IP et 2 054 pour ARP.

Le document répétait la règle du bourrage nul hors de Total Length. Il mentionnait aussi un minimum de 28 octets pour un paquet IP dans ce contexte : vingt pour l’en-tête IP minimal, huit pour LLC et SNAP, sans compter l’en-tête MAC. Ce nombre ne remplace pas le minimum de 46 octets du champ de données Ethernet. Les périmètres comptés ne sont pas les mêmes.

Le RFC 1122 donnait ensuite un MTU de 1 500 pour Ethernet et de 1 492 pour 802.3. Les huit octets d’écart correspondaient à l’enveloppe LLC/SNAP. Ils réduisaient la place disponible dans le support ; ils ne changeaient ni la constitution de l’en-tête IP ni l’autorité de Total Length.

Le RFC 895, publié le même mois pour l’Ethernet expérimental à 3 Mb/s et adresses de huit bits, fournit un autre contrôle. Il utilisait une valeur de type différente et autorisait un datagramme de 1 536 octets. Pourtant, son bourrage restait lui aussi extérieur à IP. Les dimensions locales variaient ; la frontière du datagramme demeurait.

Un trailer déplaçait des en-têtes ; un pad ne déplaçait rien

Le RFC 893, également daté d’avril 1984, décrit une autre terminaison de trame. Le trailer encapsulation déplaçait des en-têtes variables derrière les données afin d’améliorer l’alignement mémoire chez certains récepteurs. Il fallait que les deux voisins comprennent cette représentation.

Le bourrage du RFC 894 est beaucoup plus simple. L’en-tête IP reste en tête et les données IP le suivent. Des zéros apparaissent après la fin déclarée seulement si le lien a besoin d’atteindre son minimum. Aucun en-tête n’est à reconstruire et aucune application ne reçoit de données supplémentaires.

Le voisinage matériel des octets ne leur donne donc pas une fonction commune. Un pad, un trailer, une option IP et le FCS appartiennent à quatre syntaxes différentes.

Le tampon extérieur et l’objet intérieur exigeaient deux décisions

Le RFC 6274 transforme cette histoire en règle de robustesse. Un module IP peut recevoir du lien plus d’octets que Total Length. Un bourrage légitime l’explique souvent ; une activité malveillante peut aussi l’expliquer.

Pour éviter un défaut de mémoire, le tampon doit être dimensionné selon la charge annoncée par le lien. Pour éviter un défaut de parsing, IP doit pourtant s’en tenir à Total Length. Réserver la place de l’enveloppe ne confère pas une signification IP à son suffixe.

Le cas inverse est invalide. Si le lien fournit moins d’octets que Total Length n’en revendique, le paquet doit être rejeté et l’événement enregistré. Il ne faut ni compléter avec le contenu adjacent de la mémoire ni laisser une couche supérieure lire un objet incomplet. IHL doit également tenir dans Total Length.

Une politique qui ne garde qu’une longueur échoue donc dans un sens ou dans l’autre. La longueur IP seule peut sous-dimensionner le stockage de la charge reçue. La longueur du lien seule peut faire avaler à IP des octets qui ne lui appartiennent pas.

Des octets sans sens IP pouvaient tout de même parler

En janvier 2003, la note CERT/CC VU#412115 a documenté des pilotes qui ne remplissaient pas les trames courtes avec des zéros. Ils réutilisaient d’anciennes données du tampon de trame. Selon l’implémentation, un observateur distant pouvait ainsi récolter des fragments de mémoire du noyau, de mémoire statique du pilote ou d’un tampon matériel.

Ces fragments n’étaient toujours pas un payload IP valide. Un parseur conforme s’arrêtait avant eux. Mais le voisin Ethernet les voyait. L’exclusion sémantique n’avait jamais été une garantie de confidentialité physique.

Le registre CERT ne permet pas d’accuser tous les pilotes. Ses déclarations fournisseurs distinguent systèmes touchés, non touchés et état inconnu. Il prouve un mécanisme réalisé, pas une fréquence universelle.

La responsabilité suit néanmoins la couche qui a ajouté les octets. Si un pilote choisit de ne pas effacer la zone, il ne peut pas invoquer Total Length pour dire que ce qu’il a émis n’existe pas.

Sources