Internet-Draft Damin Daster Intended Status: Proposed Standard Expires: July 1, 2011 November 08, 2010 Distributed Transfer Support for FTP draft-dd-pret-00 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 http://datatracker.ietf.org/drafts/current/. 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. Abstract 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", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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 11.0.0.10, and two slaves have an IP 111.0.0.10 and 112.0.0.11, respectively. Master 11.0.0.10 has a list of files that are available, and what slaves each file is available on; Slave 111.0.0.10 has files rfc3659.txt Slave 112.0.0.11 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 111.0.0.10 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 data-connection. 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 resemble... 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 following... 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 damin@emuxperts.net