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

Versions: 00 01 02 03 04 05

Internet Engineering Task Force                              Mark Allman
INTERNET DRAFT                                           Shawn Ostermann
File: draft-allman-ftp-variable-04.txt                   Ohio University
                                                          March 26, 1997
                                             Expires: September 26, 1997

           FTP Extensions for Variable Protocol Specification

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

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


    The specification for the File Transfer Protocol assumes that the
    underlying network protocols use a 32-bit network address and a
    16-bit transport address (specifically IP version 4 and TCP).  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 a
    variety of network and transport protocols.

1.  Introduction

    The File Transfer Protocol [PR85] only provides the ability to open
    data connections on networks using the TCP/IP protocol suite
    [Com95].  FTP assumes network addresses will be 32 bits in length
    and the transport address (TCP port number) will be 16 bits long.

    Changes to FTP to support different network and transport protocols
    will be needed as new protocols are deployed (most notably, IPv6
    [DH96]).  RFC 1639 [Pis94] specifies extensions to FTP to enable its
    use over various network protocols.  While RFC 1639 allows for
    variable length transport addresses, it provides no mechanism to
    choose which transport protocol will be used.  The transport
    protocol is assumed to be based on the network protocol chosen.

    This document provides a specification which makes no assumptions

Expires: September 26, 1997                                     [Page 1]

draft-allman-ftp-variable-04.txt                          March 26, 1997

    regarding the underlying network and transport protocols.  In
    addition, protocol specification and encoding have been changed to a
    more human-readable format.  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 and transport protocols as well as the network and transport
    addresses.  The format of EPRT is:

        EPRT <net-prot>|<trans-prot>|<net-addr>|<trans-addr>

    The <net-prot> and <trans-prot> arguments MUST be upper-case strings
    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]

        Transport Protocols:

            Keyword         Protocol
            -------         --------
            TCP             Transmission Control Protocol [Pos81b]
            RDP             Reliable Data Protocol [PH90]

    Keywords for other protocols will be specified as needed.

    The <net-addr> and <trans-addr> are protocol specific string
    representations of the respective addresses.  For each of the
    following keywords, addresses MUST be in the following format:

        Keyword     Address Format      Example
        -------     --------------      -------
        IP4         dotted decimal
        IP6         IPv6 string         1080::8:800:200C:417A
                    defined in [HD96]
        TCP         string              6446
                    of decimal port
        RDP         string              3684
                    of decimal port

Expires: September 26, 1997                                     [Page 2]

draft-allman-ftp-variable-04.txt                          March 26, 1997

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

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

    The following are sample EPRT commands:

        EPRT IP4|TCP||6275

        EPRT |RDP||5282

    The first command specifies that the server should use IPv4/TCP to
    open a data connection to the host "" on port 6275.  The
    second command specifies that the server should use the network
    protocol and network address used by the control connection to open
    an RDP 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 codes 500 and 501
    [PR85] are sufficient to handle most errors (e.g., syntax errors)
    involving the EPRT command.  However, two additional error codes are
    needed.  The response code 522 indicates that the server does not
    support the requested network protocol.  Likewise, the response code
    523 indicates that the server does not support the requested
    transport protocol.  The interpretation of these error codes is:

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

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

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

    In this document, any text enclosed within "<>" is informational
    text which 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

        (IP6) Supported network protocols

        (IP4,IP6) Supported network protocols

    Similarly, if the transport protocol is not supported, the format of

Expires: September 26, 1997                                     [Page 3]

draft-allman-ftp-variable-04.txt                          March 26, 1997

    the response string MUST be:

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

    where the protocols are identified by the keywords listed above for
    the EPRT command.

    In the case when both the network and transport protocols specified
    in the EPRT command are unsupported, the error reported MUST be 522
    (unsupported network protocol).

3.  The EPSV Command

    The EPSV command requests that a server listen on a data port and
    wait for a connection.  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:

        (<net-prot>|<trans-prot>|<net-addr>|<trans-addr>) \
            <text indicating server is entering extended passive mode>

    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.  An example response string follows:

        (IP4|TCP||6446) Entering Extended Passive Mode

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

4.  Security Issues

    These FTP extensions increase the scope of the FTP "bounce attack"
    by making it possible for connections to be made using a transport
    protocol other than TCP.  A companion Internet Draft [AO96] is a
    more general discussion of FTP security issues and techniques to
    reduce these security problems.

5.  Conclusions

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

Expires: September 26, 1997                                     [Page 4]

draft-allman-ftp-variable-04.txt                          March 26, 1997


    [AO96] Mark Allman and Shawn Ostermann.  Security Issues of Interest
        to FTP Server Implementers (Internet Draft, in preparation).

    [Com95] Douglas E. Comer.  Internetworking with TCP/IP, Volume 1,
        Principles, Protocols, and Architecture.  Prentice Hall, 3rd
        edition, 1995.

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

    [PH90] C. Partridge and R. Hinden.  Version 2 of the Reliable Data
        Protocol (RDP), April 1990.  RFC 1151.

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

Author's Addresses:

    Mark Allman and Shawn Ostermann
    School of Electrical Engineering and Computer Science
    Ohio University
    416 Morton Hall
    Athens, OH  45701

Expires: September 26, 1997                                     [Page 5]

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