Résumé

  • TPKT place devant un TPDU un en-tête de quatre octets : version, réserve et longueur totale. Le destinataire sait ainsi quelle portion du flot TCP forme l’objet suivant.
  • Cette convention rétablit une frontière de registre ; elle ne prouve ni identité, ni intégrité, ni autorisation, ni succès applicatif.

RFC 793 présente TCP comme un flot continu d’octets. Les segments visibles sur le réseau ne sont pas une ponctuation durable offerte au programme qui lit. C’est pourquoi une interface qui attend des objets discrets ne peut pas traiter un retour de read comme l’équivalent d’un message complet.

En 1987, RFC 1006 voulait offrir le service de transport ISO au-dessus de TCP/IP. Le problème précis n’était pas de refaire tout OSI : les TPDU sont des objets de protocole discrets, là où TCP n’expose aucune limite explicite. La solution fut TPKT, un paquet de longueur variable composé d’un en-tête constant et d’un TPDU.

L’en-tête contient une version sur huit bits, un octet réservé et une longueur sur seize bits. Pour la version 3 de RFC 1006, la version vaut toujours 3 ; la longueur couvre le paquet entier, en-tête compris, et va de 7 à 65 535 octets. Le lecteur accumule d’abord quatre octets, calcule la longueur déclarée, attend exactement le reste, puis remet le TPDU au traitement transport. Deux TPKT peuvent arriver ensemble ; un seul peut arriver en plusieurs lectures. La taille dessinée sur quatre octets dans la RFC n’impose pas un multiple de quatre : c’est la longueur déclarée qui tranche.

Le geste est petit mais discipliné. Il ne demande pas à TCP de préserver une intention qu’il ne promet pas. Il place au-dessus de TCP un contrat de cadrage que l’émetteur et le récepteur peuvent vérifier. Pour la discussion de classe 0, RFC 1006 assimile l’objet de service réseau pertinent au TPDU. Cela ne change pas le TPDU en preuve qu’un utilisateur est connu ou qu’une opération métier a abouti.

RFC 1006, STD 35, a remplacé RFC 983 et réservait le port TCP 102 aux hôtes qui implémentaient cette norme. Le port est un indice de convention, pas une attestation de propriétaire ou de service actif. Le but était de faire fonctionner les couches ISO supérieures sur un support TCP/IP sans leur imposer la connaissance du porteur inférieur. Ni le port ni l’en-tête ne recréent un réseau ISO sous TCP.

RFC 2126 a mis à jour ce texte en 1997. Il conserve la forme version/réservé/longueur de TPKT, raffine la classe 0 pour la base RFC 1006 et ajoute une classe 2 au-dessus de TCP. Sa limite de sécurité est nette : le protocole n’est ni plus ni moins sûr que TCP et ISO 8073. Un délimiteur aide un analyseur à savoir où s’arrêter ; il ne chiffre pas, n’authentifie pas et ne décide pas du sens d’une charge utile.

La bonne trace opérationnelle sépare donc connexion TCP, octets reçus, en-tête TPKT, longueur attendue, résultat du parseur TPDU et résultat applicatif. Les fusionner en une seule ligne « message accepté » détruit précisément les responsabilités que le mécanisme avait laissées distinctes.

Sources et limites

Ces RFC établissent la différence flot/objet, le format TPKT et sa mise à jour. Elles n’établissent pas une diffusion actuelle, une configuration d’hôte donnée, l’identité d’un pair ou l’aboutissement d’une action.