Résumé

  • RFC 818 attribua le port 107 à un service optionnel de Telnet utilisateur : l'application jointe pouvait ouvrir une seconde session Telnet au lieu de livrer l'appelant à un exécutif général.
  • Chez BBN, un Telnet serveur entrant alimentait, par un pseudo-terminal, un Telnet utilisateur sortant. L'écran semblait continu, mais l'ensemble gardait deux connexions TCP, deux négociations et plusieurs décisions locales.
  • Le test confirmait le fonctionnement de cette chaîne au moment observé. Le numéro enregistrait un rendez-vous ; il n'authentifiait pas l'opérateur et n'autorisait pas à lui seul la destination suivante.

Un service général supposait une machine générale

Le Telnet classique organisait l'accès autour du port 23. Le programme utilisateur ouvrait la connexion ; le serveur distant l'acceptait et plaçait normalement l'appelant devant l'exécutif de la machine. Le choix du programme venait après : l'EXEC de TOPS-20 ou un shell Unix servait de carrefour local.

Cette convention n'était pourtant pas l'essence du protocole. RFC 764, en 1980, définissait un moyen bidirectionnel de relier des terminaux et des processus. Le Network Virtual Terminal fournissait la représentation minimale commune. Des options permettaient d'aller plus loin si les deux extrémités y consentaient ; un refus ramenait à l'état NVT que toutes devaient comprendre.

Même les mots « utilisateur » et « serveur » n'étaient pas des titres permanents. Le premier désignait généralement la machine portant le terminal physique. Dans un échange entre terminaux ou processus, il pouvait simplement désigner l'initiateur. Une même machine pouvait donc changer de rôle d'une connexion à l'autre.

Le port 23 liait cependant Telnet à une attente concrète : derrière la porte se trouverait un hôte de service et son interpréteur général. Un petit équipement réseau n'avait aucune raison de simuler cette architecture.

Exposer le programme qui savait appeler

RFC 818, daté de novembre 1982, partit précisément du petit hôte. Sa fonctionnalité pouvait être limitée ; il pouvait ne posséder aucun exécutif. Dans ce cas, un port bien connu pour une application déterminée avait plus de sens qu'un faux accès général.

L'application retenue fut le Telnet utilisateur. Un hôte qui choisissait de fournir ce service acceptait une connexion au port 107. La connexion entrante parlait toujours Telnet, mais elle donnait accès au composant local dont le métier était d'initier une connexion vers un autre hôte.

Le paradoxe disparaît dès que l'on dessine les processus. Un écouteur répond à l'appel extérieur. Derrière lui, le programme utilisateur conserve sa fonction sortante. Le port rend la composition trouvable ; il ne transforme pas tous ses éléments en une seule extrémité.

Cette économie correspond à une spécification initiale mince. Il fallait partager un numéro, un transport et la grammaire Telnet. Il n'était pas nécessaire de normaliser l'organisation intérieure de chaque petit équipement, ni d'obliger ceux qui n'en avaient pas besoin à publier le même service.

BBN relia des composants déjà en marche

Le cas décrit n'était pas une simple proposition. Le terminal concentrator TC68K de BBN reposait sur un Motorola MC68000. Une connexion réseau desservait seize connexions de terminaux RS-232 et un minuteur programmable. Le Micro-Operating System faisait fonctionner IP, ICMP, TCP et Telnet.

Deux applications existaient déjà. Le User TC-Telnet permettait à un terminal local de joindre un hôte par le réseau. Un Server Telnet offrait une façade réseau à des équipements qui ignoraient le réseau : imprimantes, traceurs et ordinateurs sans pile propre.

Les TC68K étaient répartis entre plusieurs bâtiments. Pour tester une unité éloignée, BBN mit un Telnet utilisateur dos à dos avec un Telnet serveur. L'opérateur ouvrait une session vers le concentrateur distant et apparaissait au programme utilisateur comme un terminal branché localement. Il pouvait ensuite employer les fonctions normales du TC-Telnet et consulter ses statistiques.

Le seul logiciel supplémentaire que le mémo juge nécessaire était un pilote de pseudo-téléscripteur, ou PTY. Pour l'application, ce dispositif ressemblait à un terminal. En réalité, il transportait un flux de caractères entre deux processus.

La solution était modeste parce que le code existant imposait la forme utile. BBN n'ajouta pas une autorité de gestion au protocole partagé. Il ajouta une interface locale suffisamment semblable à un terminal pour que deux applications éprouvées puissent coopérer.

Le pseudo-terminal n'abolissait pas les frontières

L'opérateur voyait un seul dialogue. L'équipement exécutait au moins quatre étapes : son Telnet utilisateur local ouvrait une première connexion ; le Telnet serveur du TC68K la terminait ; le PTY transmettait le flux au Telnet utilisateur de ce TC68K ; celui-ci ouvrait une seconde connexion vers la cible.

Les deux connexions TCP n'étaient pas fusionnées. Chacune avait ses séquences, sa fermeture, ses erreurs et sa négociation Telnet. Un octet reçu par la première n'était pas encore une action accomplie par l'application finale. Une option acceptée sur un côté ne devenait pas automatiquement un accord de l'autre côté.

RFC 818 ne spécifie ni traduction universelle des options, ni association de sécurité de bout en bout, ni règle complète de propagation des pannes. Le mot « dos à dos » décrit une composition locale, pas un tunnel qui rendrait les intermédiaires inexistants.

RFC 854, en 1983, conserva la symétrie de Telnet et en indiqua la limite : c'était un principe de fonctionnement, non une loi absolue. Le NVT existait conceptuellement aux deux extrémités, tandis que les responsabilités pouvaient différer. Le TC68K était serveur dans la relation entrante et utilisateur dans la relation sortante parce que ces adjectifs appartenaient à deux relations distinctes.

Que signifiait « le chemin fonctionne » ?

RFC 818 explique que la construction vérifiait le chemin réseau entre deux TC68K et donnait accès aux statistiques gardées par l'application utilisateur standard. Il faut préserver la valeur de cette preuve sans l'agrandir.

Une réussite montrait que l'appel atteignait le port, que le serveur traitait assez de Telnet, que le PTY transportait le flux, que le programme utilisateur créait la connexion testée et que la cible renvoyait les informations visibles. C'était plus riche qu'un simple signal de présence : plusieurs couches réelles avaient été exercées.

Mais l'essai ne garantissait pas toutes les routes, tous les moments, toutes les options ou toutes les applications. Il ne prouvait pas qu'une imprimante avait produit une page. Il ne révélait pas l'identité juridique de la personne devant le clavier. Il ne transformait pas la capacité de joindre un hôte en permission de joindre n'importe lequel.

Une console donne facilement une impression d'unité. L'exploitation sérieuse garde au contraire une chronologie pour chaque frontière : admission, création du PTY, sélection de la cible, résultat de la seconde connexion et preuve propre au service final.

La symétrie gardait un socle, pas une égalité fictive

En 1989, RFC 1123 présenta Telnet comme le protocole standard de connexion distante entre clavier/écran et interpréteur de commandes. Ses exigences continuaient pourtant de distinguer les programmes utilisateur et serveur. Tous devaient maintenir la négociation, refuser proprement ce qu'ils ne comprenaient pas et revenir au NVT minimal. Certaines fonctions de contrôle incombaient aux deux ; d'autres prenaient un sens propre au côté serveur ou utilisateur.

Ce modèle autorisait l'assemblage sans effacer la responsabilité. Le langage commun était symétrique. Les pouvoirs locaux ne l'étaient pas nécessairement. Une publication pouvait proposer une extension ou un service ; sa réalité dépendait encore de machines qui l'implémentaient et d'opérateurs qui l'activaient.

Le registre IANA des noms de service et numéros de port conserve aujourd'hui rtelnet au port 107, décrit comme Remote Telnet Service. Cette continuité documente un point de coordination. Elle ne mesure aucun déploiement actuel et ne garantit ni sécurité ni support. La ligne UDP du registre ne change pas non plus RFC 818 en protocole sans connexion : le texte exigeait Telnet sur une connexion.

Les équipements série révélèrent les décisions cachées

RFC 2217, expérimental en 1997, aborda plus tard un autre accès Telnet à un équipement série. Des serveurs d'accès donnaient accès à des modems, imprimantes, traceurs ou appareils de mesure. Le flux interactif ne suffisait plus.

Le débit, la taille des caractères, la parité, les bits d'arrêt, les signaux de modem et le contrôle de flux étaient des états du port local. RFC 2217 ajouta COM-PORT-OPTION et utilisa la négociation Telnet habituelle. Après accord, des commandes explicites demandaient un changement et des notifications rendaient l'état visible.

L'accusé le plus intéressant n'était pas celui de TCP. TCP confirmait la réception des octets. La réponse du serveur d'accès indiquait la valeur effectivement appliquée après traitement, éventuellement différente de la demande. Transport et exécution recevaient enfin deux preuves distinctes.

La fin de session devait elle aussi être explicite. Le serveur devait couper le service éloigné et remettre les paramètres série dans un état connu défini par l'administrateur. Sans ce nettoyage, une décision locale d'un client survivrait dans la réalité du client suivant.

RFC 2217 n'est pas présenté comme le successeur documenté de RFC 818. Il sert de comparaison : plus un pont de caractères commande du matériel, plus il faut nommer les décisions que l'apparente transparence cachait.

Le registre désignait la porte

L'histoire du port 107 n'accorde aucun pouvoir mystique aux numéros. IANA pouvait conserver un nom commun. L'opérateur choisissait d'écouter. Le serveur choisissait d'admettre. Le Telnet utilisateur choisissait — sous politique locale — quelle connexion initier. La cible décidait de l'action finale.

Enregistrement, déploiement, authentification, autorisation et accomplissement sont cinq verbes différents. Le TC68K fut utile parce que sa composition les rendait opérables avec peu de code. Il aurait été dangereux de les confondre sous le seul fait qu'une porte portait un numéro reconnu.