[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 rfc2428                                              
FTPEXT Working Group                                         Mark Allman
Internet Draft                              NASA Lewis/Sterling Software
Expires: July 14, 1998                                   Shawn Ostermann
                                                         Ohio University
                                                        January 14, 1998


                        FTP Extensions for IPv6
                <draft-ietf-ftpext-ftp-over-ipv6-00.txt>


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 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.''

    To learn the current status of any Internet-Draft, please check the
    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
    ftp.isi.edu (US West Coast).

    Distribution of this document is unlimited.  Please send comments
    to the FTP Extension working group (FTPEXT-WG) of the Internet
    Engineering Task Force (IETF) at <ftp-wg@hethmon.com>.
    Subscription address is <ftp-wg-request@hethmon.com>.
    Discussions of the group are archived at
    <URL:http://w3.hethmon.com/ftpext/>.

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 open
    data connections on networks using the IPv4 protocol [Pos81a].  FTP
    assumes network addresses will be 32 bits in length.  However, with

Allman and Ostermann                                            [Page 1]


INTERNET-DRAFT         FTP Extensions for IPv6          January 14, 1998

    the deployment of version 6 of the Internet Protocol [DH96] this
    will no longer be the case.  RFC 1639 [Pis94] specifies extensions
    to FTP to enable its use over various network protocols.  However,
    the mechanism can fail in a multiple 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.

    This document provides a specification which makes no assumptions
    regarding the underlying network protocol.  In this specification,
    the FTP commands PORT and PASV are replaced with EPRT and EPSV,
    respectively.

2.  The EPRT Command

    The EPRT command allows for the specification of an extended address
    for the data connection.  The extended address consists 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.
    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 upper-case string indicating the
    protocol to be used (and, implicitly, the address length).  This
    specification defines keywords for the following network protocols:

        Keyword     Protocol
        -------     --------
        IP4         Internet Protocol, Version 4 [Pos81a]
        IP6         Internet Protocol, Version 6 [DH96]

    It is expected that keywords for additional network protocols will
    be specified as needed in later documents.

    The <net-addr> is a protocol specific string representation of the
    network address.  For each of the following keywords, addresses MUST
    be in the following format:

        Keyword     Address Format      Example
        -------     --------------      -------
        IP4         dotted decimal      132.235.1.2
        IP6         IPv6 string         1080::8:800:200C:417A
                    representations
                    defined in [HD96]

    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.

Allman and Ostermann                                            [Page 2]


INTERNET-DRAFT         FTP Extensions for IPv6          January 14, 1998


    The <net-prt> and <net-addr> fields are optional.  If left blank,
    their default values are as follows:

        Field           Default Value If Omitted
        -----           ------------------------
        <net-prt>       Network protocol of the control connection
        <net-addr>      Network address of the control connection

    The following are sample EPRT commands:

        EPRT |IP4|132.235.1.2|6275|

        EPRT |||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 network
    protocol and network address used by the control connection 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 codes 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)

    In this document, any text enclosed within "<>" is informational
    text that can be written in any language.  In the above case, the
    text SHOULD indicate that the network protocol in the EPRT command
    is not supported by the server.  Two example response strings
    follow:

        Supported network protocols (IP6)

        Supported network protocols (IP4,IP6)

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

Allman and Ostermann                                            [Page 3]


INTERNET-DRAFT         FTP Extensions for IPv6          January 14, 1998

    argument.  The response to this command includes all
    information needed to setup a connection using the EPRT command.
    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><net-prt><d><net-addr><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.  As with the EPRT command, the first two fields in
    the EPSV response are optional.  Similar to the EPRT commands, when
    left blank these fields default to the values used for the control
    connection.  An example response string follows:

        Entering Extended Passive Mode (|IP4|132.235.1.2|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.  However, since
    it is possible for the server to return an unsupported protocol in
    the EPSV response, the client needs to be able to request a specific
    protocol.  If the server returns a protocol that the client does not
    support, the client will not be able to open a data connection to
    the server.  In this situation, the client MUST issue an ABOR
    (abort) command to allow the server to close down the listening
    connection.  The client can then send an EPSV command requesting the
    use of a specific network protocol, as follows:

        EPSV <net-prt>

    If the requested protocol is supported by the server, it SHOULD use
    the protocol.  If not, the server MUST return the 522 error messages
    as outlined in section 2.

    The client may issue either form of the EPSV command at any time.
    In other words, the version without arguments need not be issued
    before the version with arguments.

4.  IPv6 Transition Issues

    To aid in transition from IPv4 to IPv6 it is RECOMMENDED that the
    network address be omitted from the EPRT command and the EPSV
    response whenever possible.  This will allow the end hosts to
    utilize standard IPv6 mechanisms to communicate (such as network

Allman and Ostermann                                            [Page 4]


INTERNET-DRAFT         FTP Extensions for IPv6          January 14, 1998

    address translators), rather than forcing FTP to negotiate the
    network protocol.

5.  Security Issues

    The above changes to FTP do not introduce new FTP security problems.
    A companion Internet Draft [AO96] is a more general discussion of
    FTP security issues and techniques to reduce these security
    problems.

6.  Conclusions

    The extensions specified in this paper will enable FTP to operate
    over a variety of network protocols.

References

    [AO97] Mark Allman and Shawn Ostermann.  FTP Security
        Considerations, January 1998.  I-D
        draft-ietf-ftpext-sec-consider-00.txt (work in progress).

    [Bra97] Scott Bradner.  Key words for use in RFCs to Indicate
        Requirement Levels, March 1997.  RFC 2119.

    [DH96] S. Deering and R. Hinden.  Internet Protocol, Version 6
        (IPv6) Specification, January 1996.  RFC 1883.

    [HD96] R. Hinden and S. Deering.  IP Version 6 Addressing
        Architecture, January 1996.  RFC 1884.

    [Pis94] D. Piscitello.  FTP Operation Over Big Address Records
        (FOOBAR), June 1994.  RFC 1639.

    [Pos81a] J. Postel.  Internet Protocol, September 1981.  RFC 791.

    [Pos81b] J. Postel.  Transmission Control Protocol, September 1981.
        RFC 793.

    [PR85] J. Postel and J. Reynolds.  File Transfer Protocol (FTP),
        October 1985.  RFC 959.















Allman and Ostermann                                            [Page 5]


INTERNET-DRAFT         FTP Extensions for IPv6          January 14, 1998

Author's Addresses:

    Mark Allman
    NASA Lewis Research Center/Sterling Software
    21000 Brookpark Rd.  MS 54-2
    Cleveland, OH  44135
    mallman@lerc.nasa.gov
    http://gigahertz.lerc.nasa.gov/~mallman/

    Shawn Ostermann
    School of Electrical Engineering and Computer Science
    Ohio University
    416 Morton Hall
    Athens, OH  45701
    ostermann@cs.ohiou.edu








































Allman and Ostermann                                            [Page 6]