Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc1545.txt.pdf Дата изменения: Wed Mar 27 23:12:37 2002 Дата индексирования: Tue Oct 2 18:40:00 2012 Кодировка:

Network Working Group Request for Comments: 1545 Category: Experimental

D. Piscitello Bellcore November 1993

FTP Operation Over Big Address Records (FOOBAR) Status of this Memo This memo defines an community. This memo kind. Discussion and Distribution of this Abstract This paper describes a convention for specifying longer addresses in the PORT command. Introduction This RFC specifies a method HOST-PORT specification for a data connection for File This is a general solution, alternatives, and can also transport interfaces other Acknowledgments Many thanks to all the folks in the IETF who casually to do this, but who left it to me to write this RFC. to Rich Colella, Bob Ullmann, Shawn Ostermann, Steve Carpenter who had the time and decency to comment on draft. :-) 1. Background The PORT command of File Transfer Protocol allows users to specify an address other than the default data port for the transport connection over which data are transferred. The PORT command syntax is: PORT The information is is transmitted argument is and a 16-bit broken into as a decimal the concatenation of TCP . 8-bit fields and the number (in character a 32-bit internet This address value of each field string mentioned how Special thanks Lunt, and Brian the initial for assigning long addresses in the the data port to be used in establishing Transfer Protocol, FTP (STD 9, RFC 959). applicable for all "next generation" IP be extended to allow FTP operation over than TCP. Experimental Protocol for the Internet does not specify an Internet standard of any suggestions for improvement are requested. memo is unlimited.

Piscitello

[Page 1]


RFC 1545

FTP Over Big Address

November 1993

representation). The fields are separated by commas. A port command is thus of the general form "PORT h1,h2,h3,h4,p1,p2", where h1 is the high order 8 bits of the internet host address. To accommodate larger network addresses anticipated for all IP "next generation" alternatives, new commands and reply codes are needed for FTP. This memo addresses these needs. 2. The LPRT Command The LPRT command allows users to specify a "long" address for the transport connection over which data are transferred. The LPRT command syntax is: LPRT The argument is the concatenation of the following fields; o o o o o an 8-bit argument (af) an 8-bit argument (hal) a of (h1, h2, ...) an 8-bit (pal) a of (p1, p2, ...)

The argument takes the value of the version number of IP (see Assigned Numbers, STD 2, RFC 1340), or generally speaking, an Internet layer protocol. Relevant assigned IPng version numbers are: Decimal -----0 1-3 4 5 6 7 8 9 10-14 15 Keyword ------reserved unassigned Internet Protocol (IP) ST Datagram Mode SIP TP/IX PIP TUBA unassigned reserved

Piscitello

[Page 2]


RFC 1545

FTP Over Big Address

November 1993

The value of each field is broken into 8-bit fields and the value of each field is transmitted as an unsigned decimal number (in character string representation, note that negative numbers are explicitly not permitted). The fields are separated by commas. A LPRT command is thus of the general form LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2... where h1 is the high order 8 bits of the internet host address, and p1 is the high order 8 bits of the port number (transport address). 3. The LPSV Command The L(ONG) PASSIVE command requests the server-DTP to listen on a data port other than its default data port and to wait for a connection rather than initiate one upon receipt of a transfer command. The response to this command includes the address family, host address length indicator, host address, port address length, and port address this server is listening on. The reply code and text for entering the passive mode using a long address is 228 (Interpretation according to FTP is: positive completion reply 2yz, connections x2z, passive mode entered using long address xy8). The suggested textual message to accompany this reply code is: 228 Entering Long Passive Mode (af,hal,h1,h2,h3,h4...,pal,p1,p2...) 4. Permanent Negative Completion Reply Codes The negative completion reply codes that are associated with syntax errors in the PORT and PASV commands are appropriate for the LPRT and LPSV commands (500, 501). An additional negative completion reply code is needed to distinguish the case where a host supports the LPRT or LPSV command, but does not support the address family specified. Of the FTP function groupings currently defined for reply codes (syntax, information, connections, authentication and accounting, and file system), "connections" seems the most logical choice; thus, an additional negative command completion reply code, 521 is added, with the following suggested textual message: 521 Supported address families are (af1, af2, ..., afn) Where (af1, af2, ..., afn) are the values of the version numbers of the "next generation" or other protocol families supported. IP address noted earlier.

Piscitello

[Page 3]


RFC 1545

FTP Over Big Address

November 1993

5.

Rationale An explicit address family argument in the LPRT command and LPSV reply allows the Internet community to experiment with a variety of "next generation IP" alternatives within a common FTP implementation framework. (It also allows the use of a different address family on the command and data connections.) An explicit length indicator for the host address is necessary because some of the IPNG alternatives make use of variable length addresses. An explicit host address is necessary because FTP says it's necessary. The decision to provide a length indicator for the port number is not as obvious, and certainly goes beyond the necessary condition of having to support TCP port numbers. Currently, at least one IPng alternative (TP/IX) supports longer port addresses. And given the increasingly "multi-protocol" nature of the Internet, it seems reasonable that someone, somewhere, might wish to operate FTP operate over Appletalk, IPX, and OSI networks as well as TCP/IP networks. (In theory, FTP should operate over *any* transport protocol that offers the same service as TCP.) Since some of these transport protocols may offer transport selectors or port numbers that exceed 16 bits, a length indicator may be desirable. If FTP must indeed be changed to accommodate larger network addresses, it may be prudent to determine at this time whether the same flexibility is useful or necessary with respect to transport addresses.

6.

Conclusions The mechanism defined here is simple, extensible, and meets both IPNG and possibly multi-protocol internet needs.

7.

References STD 9, RFC 959 Postel, J., and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute, October 1985.

STD 2, RFC 1340 Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. (Does not include recently assigned IPv7 numbers). STD 3, RFC 1123 Braden, R., Editor, "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, October 1989.

Piscitello

[Page 4]


RFC 1545

FTP Over Big Address

November 1993

8.

Security Considerations Security issues are not discussed in this memo.

9.

Author's Address David M. Piscitello Bell Communications Research NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 EMail: dave@mail.bellcore.com

Piscitello

[Page 5]