Résumé

  • Quand un routeur modifie un champ d'en-tête IP, il peut adapter la somme de contrôle en partant de l'ancienne valeur. Le RFC 1141 proposait un raccourci pour cette opération.
  • Le RFC 1624 a montré que ce raccourci pouvait produire 0xFFFF alors que le recalcul intégral produisait 0x0000. Une nouvelle équation préservait la bonne représentation du zéro.

Imaginez un comptable à qui l'on présente deux zéros. L'un est une feuille dont toutes les cases sont vides; sur l'autre, elles sont toutes noircies. Sur le papier, le solde semble identique. Dans un paquet, les bits se voient. Le calcul incrémental de la somme de contrôle Internet s'est heurté à cette différence après avoir paru commode pendant des années.

Le RFC 1071 de septembre 1988 expliquait comment additionner des mots de 16 bits en arithmétique à complément à un. Le champ de somme de contrôle recevait le complément du résultat. Pour vérifier un paquet, le destinataire pouvait additionner les mêmes mots avec ce champ et demander un résultat composé uniquement de bits à un. Le texte cherchait aussi à ménager les processeurs : addition parallèle, retenues différées, ordre des octets et calcul couplé à une copie mémoire. Quand un routeur décrémentait la durée de vie, ou TTL, pourquoi recalculer tout l'en-tête alors qu'un seul champ avait changé ?

Le RFC 1141, en janvier 1990, transforma cette intuition en formule directement appliquée à la valeur déjà stockée dans le champ de contrôle. Il indiquait notamment qu'une diminution du TTL pouvait se refléter en ajoutant 0x100 à cette valeur lorsque le TTL occupait l'octet de poids fort du mot concerné. Pour une opération répétée par les routeurs, le raccourci avait l'allure d'un travail économisé à chaque paquet.

Le piège ne se cachait pas dans une longue séquence de champs. L'arithmétique à complément à un dispose de deux représentations du zéro : 0x0000, le zéro positif, et 0xFFFF, le zéro négatif. Le RFC 1624 de mai 1994 observa que la simplification employée par le RFC 1141 supposait une propriété distributive qui cesse de tenir lorsque le résultat tombe sur cette frontière. La formule produisait alors le bon concept de zéro avec les mauvais bits.

L'exemple publié est assez précis pour tenir sur un bout de papier. Un champ de 16 bits de l'en-tête passe de 0x5555 à 0x3285; la somme des autres mots vaut 0xCD7A. L'ancienne somme de contrôle est 0xDD2F. Refaire tout le calcul donne 0x0000 pour le nouvel en-tête. Suivre le raccourci du RFC 1141 donne 0xFFFF. L'équation corrigée du RFC 1624, HC' = ~(~HC + ~m + m'), retrouve 0x0000. Pour cet en-tête IP contenant au moins un champ non nul, le recalcul intégral ne peut déposer 0xFFFF dans le champ de contrôle.

Reste la réaction du destinataire. Selon le RFC 1624, une machine qui vérifie la somme de l'en-tête entier, champ de contrôle compris, accepte les deux valeurs de l'exemple : le total vaut dans les deux cas tous les bits à un. Une machine qui recalcule le champ et compare sa valeur exacte avec celle du paquet peut rejeter la version 0xFFFF. La divergence devenait visible selon la méthode de vérification à l'autre bout. Une erreur de représentation au départ rencontrait une règle d'acceptation à l'arrivée.

Le RFC 1624 raconte aussi d'où vint le contre-exemple : des essais sur un produit appliquant l'algorithme du RFC 1141 révélèrent le cas défaillant. Une simulation valida ensuite la correction. Le texte ne livre ni nom de produit ni décompte de paquets touchés. Il fournit une chaîne de travail plus intéressante qu'une anecdote invérifiable : essai, valeurs reproductibles, équation corrigée, méthode recommandée. Une variante par soustraction avec emprunt permettait même de réduire le coût des instructions supplémentaires.

Le routeur devait ajuster sa somme de contrôle parce qu'il modifiait l'en-tête. La chasse aux économies de calcul était donc parfaitement raisonnable. Elle avait simplement croisé un zéro déguisé en son frère. En réseau, deux nombres égaux pour l'algèbre peuvent laisser des traces binaires que le voisin traite différemment.