Résumé

  • Le RFC 1545, expérimental en novembre 1993, proposait LPRT et LPSV pour porter une famille d’adresses, la longueur de l’adresse hôte et celle du port. PORT utilisait jusque-là six octets décimaux : quatre pour l’hôte, deux pour le port.
  • Le code de réponse 228 annonçait le mode passif à adresse longue ; 521 signalait qu’un serveur comprenait la nouvelle commande mais ne prenait pas en charge la famille demandée. Le RFC 1639 remplaça le premier texte en juin 1994 et étendit l’idée à d’autres familles de réseau et transports.

Un passeport à six cases

Le FTP ne se contente pas d’une seule conversation. Sur la connexion de contrôle, client et serveur échangent ordres et réponses. Une autre connexion transporte les données. Dans le RFC 959, la commande PORT indique l’adresse à utiliser pour cette seconde liaison. Son argument a la simplicité d’un formulaire bien rodé : quatre nombres décimaux pour l’adresse Internet de 32 bits, puis deux pour le port TCP de 16 bits, séparés par des virgules. Dans l’environnement IPv4 de cette époque, le formulaire remplissait son rôle.

Une convention aussi commode peut devenir une barrière au moment où le monde qu’elle suppose change. Au début des années 1990, plusieurs formes possibles de l’Internet suivant étaient discutées. Certaines envisageaient des adresses plus longues ou de longueur variable ; des transports pouvaient aussi utiliser des sélecteurs plus larges qu’un port TCP. Le problème apparaissait avant même le transfert du fichier. Il fallait dire au pair où ouvrir la connexion de données, et la phrase de commande imposait encore ses six petites cases.

David Piscitello publia en novembre 1993 le RFC 1545, texte expérimental intitulé FTP Operation Over Big Address Records. FOOBAR : le nom ressemble à une plaisanterie laissée dans la version finale par un ingénieur de bonne humeur. La solution, elle, était précise. LPRT commençait par un identifiant de famille d’adresses, suivi de la longueur de l’adresse hôte, de l’adresse, de la longueur du port et du port. Les valeurs passaient encore sous forme d’octets décimaux séparés par des virgules. Le changement crucial tenait aux compteurs : le correspondant connaissait la famille parlée et la taille des deux morceaux qui suivaient.

Le mode passif avait besoin de la même liberté. Avec LPSV, le serveur devait écouter sur un port de données et renvoyer une réponse 228 Entering Long Passive Mode contenant famille, longueurs et adresse. Faire grandir uniquement l’adresse fournie par le client aurait laissé la réponse du serveur prisonnière de l’ancien moule. FOOBAR ouvrait les deux côtés du dialogue. Cela comptait dans FTP, où la connexion de contrôle et celle des données jouent des rôles distincts.

Le texte ajoutait aussi 521. Un serveur pouvait reconnaître LPRT ou LPSV et pourtant ignorer la famille d’adresses demandée. Cette réponse lui permettait de l’indiquer et de lister les familles qu’il savait traiter. Les erreurs de syntaxe conservaient d’autres codes, 500 et 501. On distinguait ainsi une phrase mal formée d’une phrase comprise dont le vocabulaire réseau manquait au serveur. Le diagnostic devenait une information exploitable pour choisir une autre famille.

La liste de 1993 montre combien l’avenir restait ouvert : IP, ST Datagram Mode, SIP, TP/IX, PIP et TUBA figuraient parmi les valeurs évoquées. FOOBAR ménageait même un champ de longueur pour le port de transport. Ce supplément n’était pas gratuit : TP/IX envisageait des sélecteurs plus longs que les seize bits du TCP. Le mémo permettait en outre à la connexion de commande et à celle des données d’employer des familles différentes. Les applications auraient pu traverser une transition mêlant plusieurs réseaux, sans cérémonie unique où tout le monde basculerait à minuit.

Le premier texte fut rapidement repris. Le RFC 1639, paru en juin 1994, déclara le RFC 1545 obsolète et conserva le principe du grand enregistrement d’adresse. Il réserva les valeurs 0 à 15 aux numéros de version de la famille IP et ouvrit les valeurs 16 à 255 aux autres protocoles de couche réseau attribués par l’IANA. Novell IPX occupait la valeur 16. La révision parla également de transports autres que TCP. Le vieux formulaire FTP venait d’obtenir un guichet pour plusieurs langues réseau.

La difficulté historique se voit dans une ligne : PORT h1,h2,h3,h4,p1,p2. Une hypothèse sur l’adresse de la machine et le port de transport s’y cachait, à l’intérieur d’un protocole d’application utilisé pour déplacer des fichiers. Le futur d’Internet pouvait être discuté au niveau des routeurs ; il devait aussi passer ce contrôle d’identité au guichet FTP. FOOBAR prit le problème au sérieux, précisément parce que ses six cases semblaient si modestes.