rfc2428.txt

这是 关于FTP最新版本的PROFTP的 源码

Network Working Group                                          M. Allman
Request for Comments: 2428                  NASA Lewis/Sterling Software
Category: Standards Track                                   S. Ostermann
                                                         Ohio University
                                                                 C. Metz
                                                           The Inner Net
                                                          September 1998


                    FTP Extensions for IPv6 and NATs

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   The specification for the File Transfer Protocol assumes that the
   underlying network protocol uses a 32-bit network address
   (specifically IP version 4).  With the deployment of version 6 of the
   Internet Protocol, network addresses will no longer be 32-bits.  This
   paper specifies extensions to FTP that will allow the protocol to
   work over IPv4 and IPv6.  In addition, the framework defined can
   support additional network protocols in the future.

1.  Introduction

   The keywords, such as MUST and SHOULD, found in this document are
   used as defined in RFC 2119 [Bra97].

   The File Transfer Protocol [PR85] only provides the ability to
   communicate information about IPv4 data connections.  FTP assumes
   network addresses will be 32 bits in length.  However, with the
   deployment of version 6 of the Internet Protocol [DH96] addresses
   will no longer be 32 bits long.  RFC 1639 [Pis94] specifies
   extensions to FTP to enable its use over various network protocols.
   Unfortunately, the mechanism can fail in a multi-protocol
   environment.  During the transition between IPv4 and IPv6, FTP needs
   the ability to negotiate the network protocol that will be used for
   data transfer.



Allman, et. al.             Standards Track                     [Page 1]

RFC 2428            FTP Extensions for IPv6 and NATs      September 1998


   This document provides a specification for a way that FTP can
   communicate data connection endpoint information for network
   protocols other than IPv4.  In this specification, the FTP commands
   PORT and PASV are replaced with EPRT and EPSV, respectively.  This
   document is organized as follows.  Section 2 outlines the EPRT
   command and Section 3 outlines the EPSV command.  Section 4 defines
   the utilization of these two new FTP commands.  Section 5 briefly
   presents security considerations.  Finally, Section 6 provides
   conclusions.

2.  The EPRT Command

   The EPRT command allows for the specification of an extended address
   for the data connection.  The extended address MUST consist of the
   network protocol as well as the network and transport addresses.  The
   format of EPRT is:

           EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>

   The EPRT command keyword MUST be followed by a single space (ASCII
   32).  Following the space, a delimiter character (<d>) MUST be
   specified.  The delimiter character MUST be one of the ASCII
   characters in range 33-126 inclusive.  The character "|" (ASCII 124)
   is recommended unless it coincides with a character needed to encode
   the network address.

   The <net-prt> argument MUST be an address family number defined by
   IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the
   writing of this document).  This number indicates the protocol to be
   used (and, implicitly, the address length).  This document will use
   two of address family numbers from [RP94] as examples, according to
   the following table:

        AF Number   Protocol
        ---------   --------
        1           Internet Protocol, Version 4 [Pos81a]
        2           Internet Protocol, Version 6 [DH96]

   The <net-addr> is a protocol specific string representation of the
   network address.  For the two address families specified above (AF
   Number 1 and 2), addresses MUST be in the following format:

        AF Number   Address Format      Example
        ---------   --------------      -------
        1           dotted decimal      132.235.1.2
        2           IPv6 string         1080::8:800:200C:417A
                    representations
                    defined in [HD96]



Allman, et. al.             Standards Track                     [Page 2]

RFC 2428            FTP Extensions for IPv6 and NATs      September 1998


   The <tcp-port> argument must be the string representation of the
   number of the TCP port on which the host is listening for the data
   connection.

   The following are sample EPRT commands:

        EPRT |1|132.235.1.2|6275|

        EPRT |2|1080::8:800:200C:417A|5282|

   The first command specifies that the server should use IPv4 to open a
   data connection to the host "132.235.1.2" on TCP port 6275.  The
   second command specifies that the server should use the IPv6 network
   protocol and the network address "1080::8:800:200C:417A" to open a
   TCP data connection on port 5282.

   Upon receipt of a valid EPRT command, the server MUST return a code
   of 200 (Command OK).  The standard negative error code 500 and 501
   [PR85] are sufficient to handle most errors (e.g., syntax errors)
   involving the EPRT command.  However, an additional error code is
   needed.  The response code 522 indicates that the server does not
   support the requested network protocol.  The interpretation of this
   new error code is:

        5yz Negative Completion
        x2z Connections
        xy2 Extended Port Failure - unknown network protocol

   The text portion of the response MUST indicate which network
   protocols the server does support.  If the network protocol is
   unsupported, the format of the response string MUST be:

        <text stating that the network protocol is unsupported> \
            (prot1,prot2,...,protn)

   Both the numeric code specified above and the protocol information
   between the characters '(' and ')' are intended for the software
   automata receiving the response; the textual message between the
   numeric code and the '(' is intended for the human user and can be
   any arbitrary text, but MUST NOT include the characters '(' and ')'.
   In the above case, the text SHOULD indicate that the network protocol
   in the EPRT command is not supported by the server.  The list of
   protocols inside the parenthesis MUST be a comma separated list of
   address family numbers.  Two example response strings follow:

        Network protocol not supported, use (1)

        Network protocol not supported, use (1,2)



Allman, et. al.             Standards Track                     [Page 3]

RFC 2428            FTP Extensions for IPv6 and NATs      September 1998


3.  The EPSV Command

   The EPSV command requests that a server listen on a data port and
   wait for a connection.  The EPSV command takes an optional argument.
   The response to this command includes only the TCP port number of the
   listening connection.  The format of the response, however, is
   similar to the argument of the EPRT command.  This allows the same
   parsing routines to be used for both commands.  In addition, the
   format leaves a place holder for the network protocol and/or network
   address, which may be needed in the EPSV response in the future.  The
   response code for entering passive mode using an extended address
   MUST be 229.  The interpretation of this code, according to [PR85]
   is:

        2yz Positive Completion
        x2z Connections
        xy9 Extended Passive Mode Entered

   The text returned in response to the EPSV command MUST be:

        <text indicating server is entering extended passive mode> \
            (<d><d><d><tcp-port><d>)

   The portion of the string enclosed in parentheses MUST be the exact
   string needed by the EPRT command to open the data connection, as
   specified above.

   The first two fields contained in the parenthesis MUST be blank.  The
   third field MUST be the string representation of the TCP port number
   on which the server is listening for a data connection.  The network
   protocol used by the data connection will be the same network
   protocol used by the control connection.  In addition, the network
   address used to establish the data connection will be the same
   network address used for the control connection.  An example response
   string follows:

        Entering Extended Passive Mode (|||6446|)

   The standard negative error codes 500 and 501 are sufficient to
   handle all errors involving the EPSV command (e.g., syntax errors).

   When the EPSV command is issued with no argument, the server will
   choose the network protocol for the data connection based on the
   protocol used for the control connection.  However, in the case of
   proxy FTP, this protocol might not be appropriate for communication
   between the two servers.  Therefore, the client needs to be able to
   request a specific protocol.  If the server returns a protocol that
   is not supported by the host that will be connecting to the port, the



Allman, et. al.             Standards Track                     [Page 4]

RFC 2428            FTP Extensions for IPv6 and NATs      September 1998