IETF Page 1 April 30, 1993 FTP Operation Over Big Address Internet Draft FTP Operation Over Big Address Records (FOOBAR) David M. Piscitello Bellcore dave@sabre.bellcore.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the Internet Draft abstract listing contained in the IETF Shadow Directories (cd internet-drafts) to learn the current status of this or any other Internet Draft. Introduction This Internet-Draft specifies a method for assigning long addresses in the HOST-PORT specification for the data port to be used in establishing a data connection for File Transfer Protocol, FTP (RFC959, 1985). This is a general solution, applicable for all "next generation" IP alternatives, and can also be extended to allow FTP operation over transport interfaces other than TCP. Abstract This paper describes a convention for specifying longer addresses in the PORT command. Acknowledgments Many thanks to all the folks in the IETF who casually mentioned how to do this, but who left it to me to write the internet draft. Special thanks to Rich Colella and Brian Carpenter who had the time and decency to comment on the initial draft:-) IETF Page 2 Internet Draft FOOBAR April 30, 1993 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 argument is the concatenation of a 32-bit internet and a 16-bit TCP . This address information is broken into 8-bit fields and the value of each field is transmitted as a decimal number (in character string 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, a new command, LPORT, is recommended. The LPORT command syntax is: LPORT The argument is the concatenation of the following fields; + an 8-bit argument (al) + an 8-bit argument (hal) + a of (h1, h2, ...) + an 8-bit (pal) + a of (p1, p2, ...) The argument takes the value of the protocol number of the "next generation" IP address (see Assigned Numbers, RFCxxxx, 1993), or generally speaking, a network layer protocol. 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). The fields are separated by commas. A LPORT command is thus of the general form LPORT al,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). IETF Page 3 April 30, 1993 FTP Operation Over Big Address Internet Draft [Note: Brian Carpenter of Cern has observed that this representation is counter-intuitive for cases where the natural representation of part of an OSI network service access point address is binary coded decimal (BCD); for example, those with E.164 International numbers for ISDN included. Readers are encouraged to post comments if this is inappropriate.] 2. Rationale An explicit address family argument 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. 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. 3. Conclusions The mechanism defined here is simple, extensible, and meets both IPNG and possibly multi-protocol internet needs. 4. References RFC959 Postel, J., and Reynolds, J., "File Transfer Protocol" October 1985. RFC1340 Reynolds, J., and Postel, J., "Assigned Numbers", July 1992 (probably does not include recently assigned IPv7 numbers). RFC1123 Braden, R.,ed. "Requirements for Internet hosts - application and support", 1989 October. IETF Page 4 Internet Draft FOOBAR April 30, 1993 5. Author Information David M. Piscitello Bell Communications Research NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 dave@mail.bellcore.com