Résumé

  • IPv4 ne protégeait que son en-tête. Un routeur pouvait vérifier la version reçue, diminuer le TTL, modifier les champs permis, puis produire un nouveau checksum adapté à cet en-tête sans rien affirmer sur les données transportées.
  • TCP et UDP étendaient le calcul à leur en-tête, à leurs données et à un pseudo-en-tête composé de faits IP choisis. Cette liaison décelait certaines erreurs de livraison, mais n’authentifiait ni l’émetteur ni la légitimité du chemin.
  • L’arithmétique en complément à un possède deux zéros. La mise à jour de RFC 1141 pouvait produire 0xFFFF là où le recalcul complet donnait 0x0000; RFC 1624 a réparé ce bord. IPv6 a ensuite supprimé le checksum de l’en-tête de base tout en maintenant la responsabilité des couches supérieures.

Une preuve renouvelée à chaque routeur

Le TTL d’un datagramme IPv4 diminue au passage de chaque module. La fragmentation peut changer longueur, drapeaux et décalage. Certaines options autorisent encore d’autres mutations. L’en-tête qu’un routeur transmet n’est donc pas toujours celui qu’il a reçu.

RFC 791 place son checksum dans cette réalité. Tous les mots de seize bits de l’en-tête sont additionnés en complément à un, puis le complément de la somme est inscrit dans le champ, traité comme zéro pendant le calcul. La couverture s’arrête expressément à l’en-tête.

Le routeur vérifie l’état entrant, abandonne immédiatement un en-tête incohérent, effectue la mutation légitime et renouvelle la valeur. Le checksum n’est pas le sceau immuable de l’origine. Il atteste une cohérence locale pour une version donnée de l’en-tête entre deux points de traitement.

Le même texte refuse d’en faire davantage : IP ne fournit ici ni contrôle d’erreur des données, ni accusé de réception, ni retransmission. Une valeur correcte ne protège pas le contenu. Elle garde seulement les champs dont la couche Internet a besoin pour décider quoi faire.

Un paquet, plusieurs périmètres

IPv4, UDP et TCP partagent une famille arithmétique, pas une preuve unique. IPv4 somme son en-tête. RFC 768 fait porter UDP sur son en-tête, ses données et un pseudo-en-tête. RFC 793 couvre l’en-tête et le texte TCP, plus quatre-vingt-seize bits conceptuels.

Cette séparation évite qu’un TTL mutable oblige chaque routeur à recalculer le checksum de transport. Le routeur assume l’en-tête IPv4; les extrémités assument TCP ou UDP. Une trame peut encore porter un contrôle de liaison, valable seulement sur son adjacency.

Trois succès ne forment pas une certification générale. Le contrôle de liaison ignore la route entière. Le contrôle IPv4 ignore la charge utile. Le contrôle de transport ignore l’identité juridique, la politique de routage et l’intention d’un acteur.

Le pseudo-en-tête qui ne voyage pas

UDP ajoute conceptuellement les adresses source et destination, le numéro de protocole et la longueur UDP aux octets qu’il somme. TCP fait de même avec sa longueur. Ce pseudo-en-tête n’est pas envoyé comme structure autonome; le récepteur le reconstruit depuis les informations IP.

Les RFC disent qu’il protège contre les datagrammes ou segments mal acheminés. Des octets TCP intacts ne devraient pas être acceptés aussi facilement s’ils arrivent sous une autre destination ou un autre protocole que ceux dont dépendait l’émission.

Cette liaison reste non cryptographique. Qui fabrique ou modifie volontairement les champs couverts peut recalculer le résultat. Le pseudo-en-tête ne prouve pas le détenteur d’une adresse, l’exactitude d’un registre, la conformité d’une route ni l’absence d’interception.

Sa qualité tient à sa modestie : une couche emprunte les faits dont elle dépend sans acquérir l’autorité de gouverner la couche qui les fournit.

Deux zéros nécessaires à UDP

En complément à un, 0x0000 représente le zéro positif et 0xFFFF le zéro négatif. L’équivalence arithmétique ne suffit pas à les rendre synonymes sur le réseau.

RFC 768 demande de transmettre un résultat calculé égal à zéro sous la forme de tous les bits à un. Un champ UDP transmis avec tous les bits à zéro signifie au contraire que l’émetteur n’a produit aucun checksum. 0xFFFF peut donc être une vérification valide; 0x0000, dans le contrat UDP sur IPv4, peut signaler son omission.

Le protocole garde ainsi distincts « calcul effectué, résultat zéro » et « calcul absent ». Une implémentation qui fusionne les deux représentations parce que son langage les traite commodément détruit cette information.

RFC 8200 resserre la règle pour IPv6 : UDP doit par défaut calculer le checksum, convertir le résultat zéro en 0xFFFF, et le récepteur doit jeter un champ tout-zéro. Une exception limitée existe pour certains tunnels UDP soumis à des exigences particulières; elle ne rend pas le checksum généralement facultatif.

Une arithmétique ouverte aux machines différentes

RFC 1071 explique comment réduire le coût sans changer la réponse commune. Si la parité des octets est préservée, l’addition est commutative et associative : on peut fractionner les buffers, calculer des sommes partielles et les réunir. L’ordre des octets peut différer, des accumulateurs plus larges peuvent retarder le repli des retenues, et une machine peut dérouler ou paralléliser ses boucles. Un octet final isolé reçoit un zéro uniquement pour le calcul.

Le protocole ne normalise donc pas un programme. Il normalise les entrées et la représentation finale. Cette liberté locale reste subordonnée à l’égalité exacte du résultat; perdre la parité, la dernière donnée ou une retenue n’est pas une optimisation.

Le coût d’un changement pouvait rester petit

Après avoir décrémenté le TTL, un routeur connaît déjà le mot modifié. RFC 1141 montre comment retirer l’ancienne contribution et ajouter la nouvelle plutôt que parcourir tout l’en-tête. Dans le cas du TTL, une diminution d’une unité revient à ajouter 1 ou 256 au champ stocké selon la position de l’octet, avec l’addition en complément à un.

RFC 1624 cite aussi fragmentation et mise à jour d’une route source. L’objectif est juste : faire suivre le coût à l’ampleur de la mutation. Pourtant le seul critère de correction demeure l’identité avec un recalcul complet du nouvel en-tête.

La formule qui confondait la frontière du zéro

RFC 1624 révèle que la formule de RFC 1141 supposait une propriété distributive qui cesse de tenir lorsque le résultat vaut zéro. Son exemple remplace un mot 0x5555 par 0x3285, les autres octets totalisant 0xCD7A. Le recalcul complet produit 0x0000; la formule précédente produit 0xFFFF.

Dans un en-tête IPv4, ces écritures ne sont pas librement permutables. Il existe au moins un champ non nul. L’addition en complément à un de valeurs non nulles peut produire le zéro négatif mais pas le positif; après complément final, 0x0000 peut apparaître dans le champ, tandis que 0xFFFF ne peut être le résultat canonique.

La correction est HC' = ~(~HC + ~m + m'), toutes les additions gardant les règles du complément à un. Elle évite la transformation invalide et rejoint la référence complète.

Certains récepteurs masquaient l’écart. Ceux qui ajoutaient le champ reçu à la somme puis comparaient au zéro négatif, suivant RFC 1071, pouvaient accepter les deux formes dans l’exemple. D’autres recalculaient une valeur et la comparaient directement au champ. Des essais de produit ont exposé la condition; analyse et simulation ont validé la réparation.

La tolérance du consommateur n’autorise pas le producteur à émettre une représentation impossible. L’interopérabilité dépend du résultat canonique, pas d’une interprétation charitable en aval.

IPv6 a déplacé la charge

L’en-tête de base IPv6 de RFC 8200 ne contient aucun checksum Internet. Les contrôles TCP, UDP et ICMPv6 emploient toutefois un pseudo-en-tête IPv6 : adresses source et destination finale sur 128 bits, longueur supérieure et valeur Next Header.

Le texte explique notamment qu’ICMPv6 ajoute ces informations parce que les champs IPv6 dont il dépend ne sont plus protégés, contrairement à IPv4, par un checksum de couche Internet. La responsabilité n’a donc pas disparu; elle a été placée auprès des protocoles qui consomment les données.

IPv4 imposait à chaque routeur de vérifier puis renouveler un petit résultat, souvent à côté de contrôles de liaison et de transport. IPv6 a retiré ce travail répété de son en-tête fixe, conservé les calculs d’extrémité et fermé par défaut l’option UDP sans checksum.

Sources et incertitudes

RFC 768 porte UDP et les deux zéros; RFC 791, IPv4; RFC 793, TCP; RFC 1071, les propriétés d’implémentation; RFC 1141, la mise à jour; RFC 1624, son défaut et sa correction; RFC 8200, le déplacement IPv6.

Ces textes ne désignent pas un inventeur unique et ne décrivent ni tous les matériels actuels ni la fréquence de l’offload. Ils n’autorisent aucun taux numérique d’erreurs non détectées ici. Un succès n’exclut pas une modification volontaire suivie d’un recalcul; un échec n’identifie pas seul le dispositif ou la personne qui a changé les octets.

Ils établissent un fait plus étroit : définir les octets couverts, l’acteur qui renouvelle la valeur et la fin de sa portée a rendu de nombreuses incohérences détectables sans créer une autorité universelle.