Résumé

  • Le type 136 associait un type, une longueur fixe de 4 et un Stream ID SATNET de 16 bits, copié dans tous les fragments.
  • Les normes ont d’abord imposé l’inaction et le transit inchangé, avant que la dépréciation formelle puis le filtrage n’achèvent son retrait.

Un pont réduit à une étiquette

Dans RFC 791, le mécanisme tient en quatre octets : type 136, longueur 4, puis deux octets d’identifiant. Il devait faire traverser à un Stream ID SATNET des réseaux dépourvus de la notion de flux. Son bit de copie était actif : chaque fragment héritait de la valeur, qui ne pouvait apparaître qu’une fois par datagramme.

Cette économie rendait possible le transport sans compréhension intermédiaire. Mais elle révélait aussi la dépendance totale envers SATNET. Le champ ne définissait ni attribution, ni négociation, ni validation, ni usage Internet autonome. Quand le concept d’origine a cessé d’être utile, les quatre octets n’avaient aucun sens nouveau à produire.

RFC 1122 qualifiait déjà l’option d’obsolète : un hôte ne devait pas l’émettre et devait l’ignorer silencieusement à la réception. RFC 1812 appliquait la même discipline aux routeurs. Ils ne devaient pas la créer ; reçue localement, elle était ignorée ; dans un paquet transféré, elle restait inchangée.

Ignorer sans supprimer ménageait une transition sûre. L’ancien champ ne pilotait plus aucun comportement, mais sa simple présence ne cassait pas encore le transfert. La compatibilité était devenue inertie.

RFC 6814 a formellement déprécié Stream ID en 2012. RFC 7126 n’y trouvait plus d’usage courant, aucun risque de sécurité spécifique connu, ni impact opérationnel ni coût d’interopérabilité en cas de blocage ; il recommandait donc de rejeter les paquets qui le contenaient.

Sources