Internet DRAFT - draft-dd-pret
draft-dd-pret
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
