Fonctionnement de FTP sur des enregistrements de grosses adresses (FOOBAR)

Statut de ce mémoire

Le présent mémoire définit un protocole expérimental pour la communauté de l’Internet. Il ne spécifie aucune sorte de norme de l’Internet. On invite à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé

Cet article décrit une convention pour spécifier les familles d’adresses autres que la famille d’adresse Internet par défaut dans les commandes et réponses FTP.

Introduction

Dans le protocole de transfert de fichier [RFC0959], l’argument <accès-d'hôte> de la commande PORT spécifie l’accès de données à utiliser pour établir une connexion de données pour FTP [RFC0959]. Cet argument est aussi utilisé dans la réponse PASV pour demander au serveur-DTP d’écouter sur un accès de données autre que son accès de données par défaut. La présente RFC spécifie une méthode pour allouer des adresses autres que les adresses IPv4 de 32 bits aux accès de données grâce à la spécification d’une commande "long Port (LPRT)" et d’une réponse "Long Passive (LPSV)", dont chacune a comme argument un <accès-d'hôte-long>, qui permet des familles d’adresses supplémentaires, des adresses réseau de longueur variable et des numéros d’accès de longueur variable.

Ceci est une solution générale, applicable pour toutes les solutions de remplacement de "prochaine génération" IP, ainsi que pour d’autres protocoles réseau que IP. Cette révision étend aussi FTP pour permettre son fonctionnement sur des interfaces de transport autres que TCP.

Remerciements

Tous nos remerciements à toutes les personnes de l’IETF qui ont soigneusement mentionné comment faire, mais qui m’ont laissé la tâche de rédiger cette RFC. Des remerciements tout particuliers à Rich Colella, Bob Ullmann, Steve Lunt, Jay Israel, Jon Postel, Shawn Ostermann, et Tae Kyong Song, qui ont contribué à ce travail.

1. Fondements

La commande PORT du protocole de transfert de fichier permet aux utilisateurs de spécifier une adresse autre que l’accès de données par défaut pour la connexion de transport sur laquelle sont transférées les données. La syntaxe de la commande PORT est la suivante :

PORT <SP> <accès-d’hôte> <CRLF>

L’argument <accès-d’hôte> est l’enchaînement d’une <adresse-d’hôte> internet de 32 bits et d’une <adresse-d’accès> TCP de 16 bits. Ces informations d’adresse sont séparées en champs de 8 bits et la valeur de chaque champ est transmise comme un nombre décimal (en représentation de chaîne de caractères). Les champs sont séparés par des virgules. Une commande PORT est donc de la forme générale "PORT h1,h2,h3,h4,p1,p2", où h1 est les 8 bits de poids fort de l’adresse internet de l’hôte.

L’argument <accès-d’hôte> est aussi utilisé par la réponse PASV, et dans certaines réponses d’achèvement négatives.

Pour s’accommoder des plus grandes adresses réseau prévues pour toutes les solutions de remplacement de "prochaine génération" IP, et s’accommoder du fonctionnement de FTP sur des protocoles réseau et transport autres que IP, de nouveaux codes de commandes et de réponses sont nécessaires pour FTP.

2. Commande LPRT

La commande LPRT permet aux usagers de spécifier une adresse "longue" pour la connexion de transport sur laquelle les données sont transférées. La syntaxe de la commande LPRT est :

LPRT <SP> <accès-d’hôte-long> <CRLF>

L’argument <accès-d’hôte-long> est l’enchaînement des champs suivants ;

o un argument de 8 bits <famille-d’adresse> (af)

o un argument de 8 bits <longueur-d’adresse-d’hôte> (hal)

o une <adresse-d’hôte> de <longueur-d’adresse-d’hôte> (h1, h2, ...)

o une <longueur-d’adresse-d’accès> (pal)

o une <adresse-d’accès> de <longueur-d’adresse-d’accès> (p1, p2, ...)

Les valeurs initiales allouées à l’argument <famille-d’adresse> prennent la valeur du numéro de version de IP (voir la [RFC1340] (STD2) "Numéros alloués") ; les valeurs dans la gamme de 0-15 en décimal sont donc réservées pour IP et allouées par l’IANA. Les valeurs dans la gamme 16-255 sont disponibles pour que l’IANA les alloue à tous les autres protocoles de couche réseau sur lesquels FTP peut fonctionner.

Les numéros de <famille-d’adresse> alloués pertinents pour FOOBAR sont :

Décimal Mot-clé

0 réservé

1-3 non alloués

4 Protocole Internet (IP)

5 Mode datagramme ST

6 SIP

7 TP/IX

8 PIP

9 TUBA

10-14 non alloués

15 réservé

16 Novell IPX

La valeur de chaque champ est séparée en champs de 8 bits et la valeur de chaque champ est transmise comme un nombre décimal non signé (en représentation de chaîne de caractères ; noter que les nombres négatifs sont explicitement interdits). Les champs sont séparés par des virgules.

Une commande LPRT a donc la forme générale suivante :

LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2...

où h1 est les huit bits de poids fort de l’adresse internet de l’hôte, et p1 est les huit bits de poids fort du numéro d’accès (adresse de transport).

3. Commande LPSV

La commande L(ONG) PASSIVE demande au serveur-DTP d’écouter sur un accès de données autre que son accès de données par défaut et d’attendre une connexion plutôt que d’en initier une à réception d’une commande de transfert. La réponse à cette commande comporte la famille d’adresses, l’indicateur de longueur d’adresse d’hôte, l’adresse d’hôte, la longueur de l’adresse d’accès, et l’adresse d’accès du processus qui écoute chez le serveur. Le code de réponse et le texte pour entrer dans le mode passif en utilisant une adresse longue est 228 (l’interprétation selon FTP est : réponse d’achèvement positif : 2yz, connexions : x2z, entrée en mode passif en utilisant une adresse longue ; xy8).

Le message de texte suggéré pour accompagner ce code de réponse est :

228 Entrée en mode passif long (af, hal, h1, h2, h3,..., pal, p1, p2...)

4. Codes de réponse d’achèvement négatif permanent

Les codes de réponse d’achèvement négatif qui sont associés aux erreurs de syntaxe dans les commandes PORT et PASV sont appropriés pour les commandes LPRT et LPSV (500, 501). Un code de réponse d’achèvement négatif supplémentaire est nécessaire pour distinguer le cas où un hôte prend en charge la commande LPRT ou LPSV, mais ne prend pas en charge la famille d’adresses spécifiée.

Parmi les groupements de fonction de FTP qui sont définis pour les codes de réponse (syntaxe, information, connexions, authentification et comptabilité, et système de fichiers), "connexions" semble le choix le plus logique ; donc, un code de réponse d’achèvement négatif supplémentaire de 521 est ajouté, avec le message textuel suggéré suivant :

521 Les familles d’adresses prises en charge sont (af1, af2, ..., afn)

Où (af1, af2, ..., afn) sont les valeurs des numéros de version des familles de protocole de "prochaine génération" ou autres prises en charge. (Noter qu’il a été suggéré que les familles pourraient aussi être représentées par des chaînes ASCII.)

5. Motivations

Un argument explicite de famille d’adresses dans la commande LPRT et la réponse LPSV permet à la communauté de l’Internet d’expérimenter diverses solutions de remplacement pour les protocoles de "prochaine génération IP" et autres protocoles de couche réseau au sein d’un cadre commun de mises en œuvre de FTP. (Il permet aussi l’utilisation d’une famille d’adresses différente sur les convexions de commande et de données.) Un indicateur explicite de longueur pour l’adresse de l’hôte est nécessaire parce que certaines des solutions de remplacement de IPng font usage d’adresses de longueur variable. Une adresse d’hôte explicite est nécessaire parce que FTP dit que c’est nécessaire.

La décision de fournir in indicateur de longueur pour le numéro d’accès n’est pas si évidente, et va certainement au delà de la condition nécessaire d’avoir à prendre en charge des numéros d’accès TCP.

Actuellement, au moins une solution IPng (TP/IX) prend en charge de plus longues adresses d’accès. Étant donnée la nature de plus en plus "multi-protocoles" de l’Internet, il semble raisonnable que quelqu’un, quelque part, puisse souhaiter faire fonctionner FTP sur des réseaux Appletalk, IPX, et OSI aussi bien que sur des réseaux TCP/IP. (En théorie, FTP devrait fonctionner sur *tout* protocole de transport qui offre le même service que TCP.) Comme certains de ces protocoles de transport peuvent offrir des numéros de sélecteurs de transport ou d’accès qui excèdent 16 bits, un indicateur de longueur peut être souhaitable. Si FTP doit bien sûr être changé pour s’accommoder de plus grandes adresses réseau, il serait prudent de déterminer à ce moment là si la même souplesse est utile ou nécessaire par rapport aux adresses de transport.

6. Conclusions

Le mécanisme définit ici est simple, extensible, et satisfait aux besoins à la fois de IPNG et du multi-protocole Internet.

7. Références

[RFC0959] J. Postel et J. Reynolds, "Protocole de transfert de fichiers (FTP)", STD 9, octobre 1985. (MàJ par RFC7151)

[RFC1123] R. Braden, éditeur, "Exigences pour les hôtes Internet – Application et prise en charge", STD 3, octobre 1989.

[RFC1340] J. Reynolds et J. Postel, "Numéros alloués", STD 2, juillet 1992. (Rendue obsolète par la RFC 1700, elle-même Historique)

8. Considérations pour la sécurité

Les questions de sécurité ne sont pas discutées dans le présent mémoire.

9. Adresse de l’auteur

David M. Piscitello

Core Competence, Inc.

1620 Tuckerstown Road

Dresher, PA 19025

USA

mél : dave@corecom.com