Résumé
- La spécification RFC 793 réservait six bits de l’en-tête TCP et imposait leur émission à zéro.
- La RFC 3168 a attribué deux de ces positions à ECE et CWR pour la notification explicite de congestion.
- La RFC 9293 conserve quatre bits réservés : les bits non implémentés doivent être émis à zéro et ignorés à la réception.
Un espace vide encadré par des règles
La RFC 793 de 1981 plaçait un champ réservé de six bits juste après le champ Data Offset, qui indique où commence la charge utile. Ces bits étaient destinés à un usage futur et devaient être transmis à zéro. Ils ne formaient donc ni une option cachée ni un mécanisme permettant de prolonger l’en-tête.
Cette discipline donnait à tous les segments la même disposition de base. Un émetteur ne pouvait pas inventer une signification locale, tandis qu’un récepteur disposait d’un format stable. La réservation constituait un budget d’extension visible, mais encore inerte.
Deux positions deviennent ECE et CWR
La RFC 3168, publiée en 2001, a affecté le bit 9 à ECE et le bit 8 à CWR. Les quatre autres positions sont restées réservées. Cette évolution n’a donc pas déplacé la limite de l’en-tête TCP de base.
Le mécanisme relie plusieurs acteurs. Un routeur peut marquer un paquet IP avec le codepoint Congestion Experienced au lieu de dépendre uniquement de la perte. Le récepteur signale cette indication à l’émetteur en activant ECE dans un accusé de réception. L’émetteur réagit alors au signal de congestion et active CWR après avoir réduit sa fenêtre de congestion.
La négociation est essentielle : la RFC 3168 prévoit l’établissement de la capacité ECN pendant la connexion TCP. La simple présence d’une position de bit ne suffit donc pas à créer une fonctionnalité partagée.
La règle actuelle protège les deux directions
La RFC 9293 décrit désormais un champ réservé de quatre bits. Pour une fonction future qu’il ne comprend pas, un émetteur doit mettre le bit correspondant à zéro et un récepteur doit l’ignorer. La première règle empêche les signaux accidentels ou privés ; la seconde évite qu’un hôte ancien rejette automatiquement un segment pour cette seule raison.
Le registre IANA des indicateurs TCP encadre l’attribution. Il répertorie CWR et ECE avec les six indicateurs historiques et maintient les offsets 4 à 7 pour un usage futur. Une position réservée n’est donc pas abandonnée à l’interprétation locale : son sens dépend d’une spécification publique et d’une attribution gérée.
Ce que cette histoire ne démontre pas
La réservation n’est pas la preuve que les concepteurs de 1981 avaient prévu ECN. Elle montre plus sobrement que des positions ont été conservées pour un futur usage de contrôle, puis que deux d’entre elles ont été employées par une norme ultérieure.
Elle ne garantit pas non plus le déploiement. Les implémentations peuvent tarder, les équipements intermédiaires peuvent faire d’autres hypothèses et une nouvelle fonction peut exiger négociation, changements d’état et observations opérationnelles. Les RFC citées ne quantifient pas ces difficultés.
Sources
- RFC 793, « Transmission Control Protocol » (septembre 1981)
sources/rfc793.txt - RFC 3168, « The Addition of Explicit Congestion Notification (ECN) to IP » (septembre 2001)
sources/rfc3168.txt - RFC 9293, « Transmission Control Protocol (TCP) » (août 2022)
sources/rfc9293.txt
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
