Résumé

  • L’option Alternate Checksum Request, Kind 14, ne constituait qu’une offre dans un SYN. Les deux SYN devaient porter exactement le même numéro d’algorithme ; absence, divergence ou ignorance d’un ancien hôte maintenaient le checksum standard pour toute la connexion.
  • SYN et RST demeuraient toujours sous la règle standard. Le résultat Fletcher de 32 bits exigeait en outre Kind 15 sur les segments concernés. La RFC 4614 a ensuite noté le manque d’intérêt, et la RFC 6247 a classé la RFC 1146 Historic et les deux options obsolete.

Un message ne peut pas certifier une règle inconnue

La base commune précédait l’expérience. La RFC 793 définit le checksum TCP comme le complément à un de la somme des mots de 16 bits couvrant en-tête, données et pseudo-en-tête. La RFC 9293 conserve l’obligation actuelle : l’émetteur doit produire cette valeur et le récepteur doit la contrôler.

Avant le premier SYN, les deux pairs n’ont partagé aucune décision sur un autre algorithme. Si la proposition était elle-même protégée par la nouveauté qu’elle décrit, le destinataire devrait lui faire confiance avant de savoir comment la lire.

La RFC 1146 place donc Alternate Checksum Request dans un SYN dont la somme reste standard. Le pair vérifie d’abord le contenant selon une règle acquise, puis examine la demande concernant les futurs segments ordinaires.

L’ancien algorithme ne subsiste pas par négligence. Il est le seul notaire disponible. La nouvelle règle ne peut recevoir une autorité limitée qu’après deux actes dont l’intégrité est établie dans la langue précédente.

L’offre, l’accord et l’usage avaient des preuves différentes

Kind 14 mesure trois octets. Le dernier porte l’identifiant : 0 pour le checksum TCP standard, 1 pour Fletcher 8 bits donnant 16 bits, 2 pour Fletcher 16 bits donnant 32 bits.

Une option visible dans un SYN prouve qu’un émetteur a proposé un nombre. Elle ne prouve pas que l’autre l’a compris, accepté ou même reçu.

L’accord n’existe que si le SYN du sens opposé contient également Kind 14 avec exactement le même nombre. Si une option manque ou si les valeurs diffèrent, la connexion entière utilise la méthode standard. Le texte ne prévoit ni liste de préférences, ni compromis entre 1 et 2.

L’usage exige encore une autre pièce. Les segments ordinaires qui suivent doivent présenter une somme compatible avec le choix. Pour le résultat de 32 bits, ils doivent en plus porter correctement la seconde partie. La chaîne de garde empêche un paquet isolé de raconter à lui seul l’histoire complète.

Ignorer une option ne signifiait pas l’accepter

La RFC 1122 exige qu’une option TCP inconnue, mais dotée d’une longueur permettant de la parcourir, soit ignorée sans erreur. Un stack ancien pouvait ainsi recevoir Kind 14 et poursuivre un handshake ordinaire.

Sa réponse ne contenait pas la même demande. Le nouvel hôte observait que la condition bilatérale n’était pas satisfaite et revenait au checksum standard pour toute la session.

Le silence du pair n’était jamais élevé au rang de consentement. Il formait au contraire un refus sûr : celui qui ne connaissait pas l’extension ne devait pas exécuter un comportement spécial pour la rejeter.

Cette règle évitait le demi-déploiement dangereux où chaque bout interprète autrement le même champ. Elle permettait aussi à une mise à niveau unilatérale de rester invisible, puisque la connexion réussissait tout de même.

Le second SYN conservait sa propre autorité

Le premier pair pouvait choisir son offre, pas la réponse. Le second SYN était un acte indépendant produit par celui qui devrait vérifier et émettre les segments sous la nouvelle règle.

Une configuration connue à l’avance ne remplaçait pas cet acte. Une connexion précédente ne créait pas de mandat durable. La connaissance des numéros de registre n’était pas une permission. Chaque session recommençait par deux messages contrôlables.

Cette symétrie évitait aussi de faire d’un serveur le simple objet d’une préférence cliente. Les deux directions du trafic changeaient de sémantique ; les deux propriétaires de cette interprétation devaient laisser une trace.

En cas de désaccord, le retour n’était pas négocié à son tour. La base standard constituait déjà le point commun. Son emploi sur toute la connexion supprimait la période où les deux calculs auraient pu coexister sans certitude.

Deux catégories de segments restaient hors délégation

Même après l’accord, SYN et RST utilisaient toujours le checksum standard. Le SYN arrive avant le résultat qu’il contribue à former.

Le RST peut venir d’un hôte qui ne possède aucun état de cette connexion. Lui demander l’algorithme négocié reviendrait à conditionner le rejet d’un état inconnu à la connaissance de cet état.

L’ancien calcul demeurait donc à l’entrée et à la sortie sans état. La délégation au nouvel algorithme ne couvrait que les segments ordinaires d’une connexion connue par les deux bouts.

Cette limite doit rester visible dans les outils. Un RST standard n’invalide pas nécessairement un accord. Un SYN standard ne prouve pas l’absence de Kind 14. La nature du segment fait partie de la preuve.

Trente-deux bits exigeaient une pièce supplémentaire

Le résultat de l’algorithme 1, long de 16 bits, tenait dans le champ existant. Celui de l’algorithme 2 comptait 32 bits. La RFC 1146 plaçait la partie A dans le champ normal et la partie B dans Alternate Checksum Data, Kind 15.

Kind 15 n’était pas une seconde négociation. C’était le coût récurrent du choix long dans les segments applicables : espace d’option, logique de parsing et dépendance à l’état du handshake.

Une Kind 15 de longueur incorrecte ou présente dans un contexte impropre devait entraîner le rejet du segment, l’envoi d’un RST et l’abandon de la connexion. Avant l’accord, ignorer une proposition inconnue favorisait la compatibilité. Après l’accord, ignorer une représentation de contrôle mal formée aurait détruit l’intégrité commune.

La différence de traitement marque la frontière de garde. La tolérance protège une base avant tout état partagé ; la rigueur protège l’interprétation après que les deux parties l’ont choisie.

Une compatibilité réussie pouvait masquer une adoption manquée

Mettre à niveau un seul endpoint ne cassait rien. Il proposait Kind 14, l’ancien pair l’ignorait, et la session standard aboutissait. L’expérience ne divisait pas immédiatement le réseau.

Mais le bénéfice exigeait deux implémentations, le même numéro et un chemin qui préserve les options. Sans mesure spécifique, l’utilisateur ne voyait qu’une connexion réussie, que l’alternative ait fonctionné ou non.

Le fallback supprimait le symptôme qui aurait rendu urgente la coordination du second déploiement. Le coût du code et des tests pouvait se répandre avant que l’effet ne se manifeste dans un nombre significatif de paires.

La sûreté du retour et la friction d’adoption provenaient de la même décision : refuser qu’un seul côté impose un nouveau sens. Il fallait donc mesurer séparément les offres, les correspondances et les usages.

La catégorie Experimental bornait la promesse

La RFC 1146 paraît en mars 1990 avec le statut Experimental et déconseille explicitement l’emploi dans les systèmes de production. Elle décrit une expérience interopérable, pas une migration obligatoire.

La RFC 1071 rassemble les propriétés et techniques d’implémentation de l’Internet checksum. Elle éclaire la base mathématique, mais ses exemples — dont certains portent des errata held — ne fournissent aucune mesure du déploiement d’Alternate Checksum.

En 2006, la RFC 4614 indique que la proposition n’a pas suscité d’intérêt. La formule n’établit ni l’absence de tout prototype ni l’échec mathématique de Fletcher. Elle documente la trajectoire d’attention.

En 2011, la RFC 6247 transfère la RFC 1146 vers Historic, constate l’absence de large déploiement et demande le marquage obsolete de Kind 14 et 15. Son développement précis sur les risques de spoofing concerne T/TCP ; il ne faut pas l’emprunter comme cause particulière de la retraite des checksums alternatifs.

Le dossier soutient une conclusion mesurée : l’expérience bilatérale n’a pas acquis l’intérêt et l’implantation nécessaires pour rester une voie actuelle. Le changement de statut ferme la promesse normative sans effacer les traces.

Le registre gardait le sens, non la fréquence

Le registre TCP Parameters de l’IANA conserve Kind 14 et 15, aujourd’hui marqués obsolete. Il conserve aussi les identifiants 0, 1, 2 et 3 dans la table Alternate Checksum Algorithms.

Cette persistance permet de décoder un ancien paquet et empêche une réattribution contradictoire. Elle prouve l’allocation, le sens historique et le statut présent de la ligne.

Elle ne mesure ni les implémentations actives, ni les négociations, ni les connexions qui auraient utilisé le mécanisme. Un registre est une autorité sémantique, pas un capteur de trafic. Obsolete n’efface pas les équipements anciens ; enregistré ne recommande pas une nouvelle émission.

Le lecteur doit ainsi maintenir quatre dossiers : offre dans un sens, accord des deux sens, usage dans les données et statut du code. Chacun possède sa source légitime.

La vieille langue préservait le droit de refuser

Le paradoxe initial devient alors une règle de gouvernance. Une modification partagée devait être demandée dans une forme déjà commune. Elle devait recevoir une réponse distincte. Elle devait rester limitée à ceux qui avaient répondu.

Le pair ancien pouvait refuser sans connaître le débat. Le pair sans état pouvait émettre un RST sans reconstruire le passé. Le registre pouvait ensuite conserver les numéros sans prétendre que le mécanisme vivait encore.

Seul l’ancien algorithme pouvait annoncer le nouveau parce que lui seul possédait, avant la négociation, une chaîne de vérification reconnue par les deux extrémités. Loin d’affaiblir l’expérience, cette dépendance rendait ses frontières vérifiables — et rendait aussi visible la coordination qu’une adoption réelle aurait exigée.

Sources