Résumé

  • Dans RFC 768, un résultat calculé égal à zéro devient tout-un; un champ tout-zéro signifie qu’aucun calcul n’a eu lieu.
  • Les erreurs non détectées ont révélé le coût collectif d’un raccourci local, puis IPv6 a supprimé la somme de contrôle de son propre en-tête.
  • L’exception de tunnel exige des ports choisis, l’accord des deux extrémités et des protections compensatoires observables.

Le champ pouvait refuser de témoigner

La somme UDP couvre les données et l’en-tête, mais aussi un pseudo-en-tête IP: adresses source et destination, numéro de protocole et longueur. RFC 768 lui donnait ainsi un rôle contre la corruption et la remise au mauvais destinataire.

L’arithmétique en complément à un peut produire zéro. Ce résultat valide est envoyé sous la forme tout-un. Le champ tout-zéro porte un autre message: l’émetteur n’a généré aucune somme. Ce n’est pas une réussite; c’est l’absence de verdict.

Une économie privée créa un angle mort commun

RFC 1122 autorisa encore une application à contrôler le calcul, tout en imposant son activation par défaut. Le texte rapporte de nombreux cas d’erreurs non détectées après que des applications de réseau local eurent désactivé la fonction pour gagner en efficacité.

Le gain appartenait à l’émetteur. La perte d’information touchait le récepteur et tous les opérateurs du chemin. La capacité technique d’omettre une preuve ne constituait donc pas l’autorité de décider pour des tiers inconnus.

IPv6 rétablit un verdict commun minimal

IPv4 vérifiait au moins son propre en-tête. IPv6 supprima cette somme de couche réseau. RFC 2460 rendit alors la somme UDP obligatoire et exigea le rejet des datagrammes nuls. Le pseudo-en-tête transport protégeait désormais une partie du contexte d’adressage qui n’était plus vérifiée dessous.

RFC 8200 conserve la règle: calcul à l’émission, FFFF si le résultat vaut zéro, rejet et journalisation recommandée à la réception d’un champ nul. Cette protection statistique n’authentifie personne. Elle empêche seulement la disparition unilatérale d’un minimum de preuve de livraison.

UDP-Lite nomma ce qui restait exposé

Certaines applications multimédias préfèrent un contenu partiellement altéré à une perte totale. RFC 3828 créa UDP-Lite: l’application peut limiter la couverture, mais le pseudo-en-tête et l’en-tête UDP-Lite restent toujours protégés. La somme transmise ne peut jamais être tout-zéro.

Le risque devient explicite. Le récepteur consent à la couverture partielle et fixe son minimum. La flexibilité ne repose plus sur l’effacement silencieux de tout contrôle.

L’exception de tunnel désigna ses responsables

Un point terminal de tunnel à haut débit peut transporter des paquets internes déjà protégés sans pouvoir relire chaque octet. RFC 6935 autorisa donc, dans des conditions contraintes, une somme UDP nulle sur IPv6. RFC 6936 en fixa les obligations.

Le mode reste désactivé par défaut. Les ports d’émission et de réception sont explicitement choisis; un port acceptant zéro doit aussi accepter les sommes calculées. Le protocole protège ses informations de contrôle et son état, traite fragmentation et erreurs de destination, vérifie les chemins susceptibles de contenir des intermédiaires intolérants et se défend contre injection et surcharge.

L’autorisation appartient ainsi à un tunnel identifié, administré par des extrémités capables de surveiller et de revenir au comportement normal. Elle ne voyage pas avec n’importe quel émetteur sur l’Internet public.

Sources et limites

La chronologie repose sur RFC 768, RFC 1122, RFC 2460, RFC 3828, RFC 6935, RFC 6936, RFC 8085 et RFC 8200. Ces textes prouvent des règles et des risques documentés, non un comportement uniforme ni un taux mondial d’erreurs. Une somme de contrôle n’est pas une authentification cryptographique.