[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet-Draft                                             Damin Daster
Intended Status: Proposed Standard
Expires: July 1, 2011                                 November 08, 2010

Distributed Transfer Support for FTP

Status of This Memo
        This Internet-Draft is submitted in full conformance with the
         provisions of BCP 78 and BCP 79.

        Internet-Drafts are working documents of the Internet
         Engineering Task Force (IETF).  Note that other groups may
         also distribute working documents as Internet-Drafts.  The
         list of current Internet-Drafts is at

        Internet-Drafts are draft documents valid for a maximum of
         six months and may be updated, replaced, or obsoleted by
         other documents at any time. It is inappropriate to use
         Internet-Drafts as reference material or to cite them other
          than as "work in progress."

        This Internet-Draft will expire on March 31, 2011.

        This document specifies new File Transfer Protocol (FTP)
         commands to allow for a distributed FTP server to operate
         correctly. The purpose is to address an issue in the FTP
         Protocol which causes a truely distributed FTP server from
         being possible.

        Truely distributed meaning that data-connections do not need
         to be routed through the FTP server, itself, to be transferred
         to the client, and allowing data to be stored completely
         separately from the FTP Server.

Copyright Notice

        Copyright (c) 2010 IETF Trust and the persons identified as the
         document authors.  All rights reserved.

        This document is subject to BCP 78 and the IETF Trust's Legal
         Provisions Relating to IETF Documents
         (http://trustee.ietf.org/license-info) in effect on the date
         of publication of this document.  Please review these
         documents carefully, as they describe your rights and
         restrictions with respect to this document.  Code Components
         extracted from this document must include Simplified BSD
         License text as described in Section 4.e of the Trust Legal
         Provisions and are provided without warranty as described in
         the Simplified BSD License.

                                                               [Page 1]

Table of Contents
        1. Introduction
        2. Document Conventions
        3. Background Information
        4. PreTransfer (PRET)
                4.1. Syntax
                4.2. Error Reponses
                4.3. FEAT Response for PRET
                4.4. When PRET is sent
                4.5. Examples
        5. Impact on Other FTP Commands
        6. Security Considerations
        7. IANA Considerations

                                                               [Page 2]

1. Introduction
        This document updates the File Transfer Protocol (FTP). One new
         command is added: "PRET". When a server supports the PRET
         command, the behavior of the client is adjusted slightly when
         using certain standard FTP commands such as; PASV, PORT

        The purpose of this expansion to the FTP protocol is to allow
         for the correct operation of a Distributed FTP Server. It is
         designed to address an issue in the FTP protocol caused by
         initiating data-connections before the server knows what is
         going to be transferred through the connection.

2. Document Conventions
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
         "MAY", and "OPTIONAL" in this document are to be interpreted
         as described in RFC 2119.

        This document also uses notation defined in STD 9, RFC 959.
3. Background Information
        There is an issue in the FTP protocol which is caused by the
         fact that data-connections are initiated BEFORE the FTP server
         knows what will be transfered through it.

        Allow for this scenario;
                A master-server has IP, and two slaves have
                 an IP and, respectively.
                Master has a list of files that are
                 available, and what slaves each file is available on;
                        Slave has files rfc3659.txt
                        Slave has files rfc.pret.txt

                When an FTP client wants to receive rfc3659.txt it may
                 come to this situation;
                        C> PASV
                        S> 227 Entering Passive .. (11,0,0,10,100,101).
                        C> RETR rfc3659.txt
                        S> 550 Oops, rfc3659.txt is only at

        The problem ultimately comes down to not knowing what IP needs
         to be sent in response to a PASV command, or what server needs
         to open a connection in response to a PORT command.
        Unforunately, there is no way to know what IP to send without
         knowing what the client intends to do. That is what this
         document intends to correct.

                                                               [Page 3]

4. PreTransfer (PRET)
        The FTP command, PRE-TRANSFER (PRET), can be used by the client
         to indicate to the server what the client intends to do BEFORE
         it asks to initiate a connection.

        4.1. Syntax
                The syntax for the PRET command is:
                        pret = "PrEt" intent

                As with all FTP commands, the "PRET" command label is
                 interpreted in a case-insensitive manner.

                The "intent" is a FTP command that the client will
                 send at some point in the future. Intent may contain
                 whitespaces when the future command contains them.
                 This may be further defined as a FTP command which
                 will actually cause data-transfer through a

                The server-PI will respond to the PRET command with a
                 200 reply with no other important information. In the
                 case of an error, it will return an error.
                        pret-response = "200" informational-text

        4.2. Error Responses
                Where the command is correctly parsed, but the "intent"
                 is in some way, invalid, a 550 response will be sent.
                Further, if the "intent" is also valid, but is not
                 possible, a 550 response will be sent.

        4.3. FEAT Response for PRET
                When replying to the FEAT command, a server-FTP process
                 that supports the PRET command MUST include "PRET" in
                 it's response. This response SHOULD use "PRET" in
                 upper case only. That is the response SHOULD
                C> FEAT
                S> 211- [descriptive text]
                S>  ...
                S>  PRET
                S>  ...
                S> 211 END

                The ellipses indicate place holders where other
                 features may be listed, but are not required. The
                 one-space indention of the feature lines is mandatory.

                                                               [Page 4]

        4.4. When PRET is sent
                The purpose of PRET is to allow the FTP to have a
                 fore-knowledge of what the client intends to do, so
                 that it is allowed to act in a certain way when the
                 intention is fulfilled.

                This is most applicable to a Distributed FTP Server
                 where the data may be stored behind a completely
                 different IP Address from the FTP Server itself.

                The PRET command should be sent in preparation for...
                        Directoy Listing
                        File Data Transfer
                        Data-Connection Initialization

                When any of the above occurs, a PRET command SHOULD
                 be sent BEFORE a connection is made between the client
                 and the server. Typically this occurs when a valid
                 PASV or PORT command is sent.

        4.5. Examples
                In the case of a directory listing, we may do the
                        C> PRET LIST
                        S> 200 Ready to Proceed
                        C> PASV
                        S> 227 Entering Passive Mode (1,2,3,4,100,101).
                        C> LIST
                        S> 150 Opening Data Connection
                        ...List-Data Transfers...
                        S> 226 Transfer complete.

                In the case of a file retrieval...
                        C> PRET RETR rfc959.txt
                        S> 200 Ready to Proceed
                        C> PASV
                        S> 227 Entering Passive Mode (1,2,3,4,100,102).
                        C> RETR rfc959.txt
                        S> 150 Opening Data Connection
                        ...File-Data Transfers...
                        S> 226 Transfer complete.

                In the case of file storage...
                        C> PRET STOR pret.rfc.txt
                        S> 200 Ready to Proceed
                        C> PASV
                        S> 227 Entering Passive Mode (1,2,3,4,100,103).
                        C> RETR STOR pret.rfc.txt
                        S> 150 Opening Data Connection
                        ...File-Data Transfers...
                        S> 226 Transfer complete.

                PRET SHOULD also be used in an active FTP session. It
                 is used in the same way. PRET SHOULD also be used in
                 ALL scenarios where a data-connection is made between
                 the server and client.

                                                               [Page 5]

5. Impact on Other FTP Commands
        PRET MAY impact the response to commands that provoke a
         data-connection between the client and server. And
         possibly, the origin and/or destination of the
         connection itself.
        This situation only occurs when PRET is supported by the
         server, and when PRET is used by the client.

6. Security Considerations
        The proposed additions to the FTP protocol are not
         expected to have any security ramifications.
7. IANA Considerations
        No proposed changes affect IANA.

Authors' Addresses
        Damin Daster

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/