[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-van-beijnum-behave-ftp64) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 6384

Behavior Engineering for Hindrance                        I. van Beijnum
Avoidance                                       Institute IMDEA Networks
Internet-Draft                                             June 30, 2011
Intended status: Standards Track
Expires: January 1, 2012

                An FTP ALG for IPv6-to-IPv4 translation


   The File Transfer Protocol (FTP) has a very long history, and despite
   the fact that today other options exist to perform file transfers,
   FTP is still in common use.  As such, it is important that in the
   situation where some client computers only have IPv6 connectivity
   while many servers are still IPv4-only and IPv6-to-IPv4 translators
   are used to bridge that gap, FTP is made to work through these
   translators to the best possible extent.

   FTP has an active and a passive mode, both as original commands that
   are IPv4-specific, and as extended, IP version agnostic commands.
   The only FTP mode that works without changes through an IPv6-to-IPv4
   translator is extended passive.  However, many existing FTP servers
   do not support this mode, and some clients do not ask for it.  This
   document specifies a middlebox that may solve this mismatch.

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 January 1, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

van Beijnum              Expires January 1, 2012                [Page 1]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  ALG overview . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Control channel translation  . . . . . . . . . . . . . . . . .  6
     5.1.  Language negotiation . . . . . . . . . . . . . . . . . . .  7
   6.  EPSV to PASV translation . . . . . . . . . . . . . . . . . . .  8
   7.  EPRT to PORT translation . . . . . . . . . . . . . . . . . . .  9
     7.1.  Stateless EPRT translation . . . . . . . . . . . . . . . . 10
     7.2.  Stateful EPRT translation  . . . . . . . . . . . . . . . . 10
   8.  Default port 20 translation  . . . . . . . . . . . . . . . . . 11
   9.  Both PORT and PASV . . . . . . . . . . . . . . . . . . . . . . 11
   10. Default behavior . . . . . . . . . . . . . . . . . . . . . . . 12
   11. The ALGS command . . . . . . . . . . . . . . . . . . . . . . . 12
   12. Timeouts and translating to NOOP . . . . . . . . . . . . . . . 14
   13. IANA considerations  . . . . . . . . . . . . . . . . . . . . . 14
   14. Security considerations  . . . . . . . . . . . . . . . . . . . 15
   15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
   16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     17.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16

van Beijnum              Expires January 1, 2012                [Page 2]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

1.  Introduction

   [RFC0959] specifies two modes of operation for FTP: active mode, in
   which the server connects back to the client and passive mode, where
   the server opens a port for the client to connect to.  Without
   additional measures, active mode with a client-supplied port does not
   work through NATs or firewalls.  With active mode, the PORT command
   has an IPv4 address as its argument, and in passive mode, the server
   responds to the PASV command with an IPv4 address.  This makes both
   the passive and active modes as originally specified in [RFC0959]
   incompatible with IPv6.  These issues were solved in [RFC2428], which
   introduces the EPSV (extended passive) command, where the server only
   responds with a port number, and the EPRT (extended port) command,
   which allows the client to supply either an IPv4 or an IPv6 address
   (and a port) to the server.

   A survey done in April of 2009 of 25 randomly picked and/or well-
   known FTP sites reachable over IPv4 showed that only 12 of them
   supported EPSV over IPv4.  Additionally, only 2 of those 12 indicated
   that they supported EPSV in response to the FEAT command introduced
   in [RFC2389] that asks the server to list its supported features.
   One supported EPSV but not FEAT.  In 5 cases, issuing the EPSV
   command to the server led to a significant delay, in 3 cases followed
   by a control channel reset.  Due to lack of additional information,
   it is impossible to determine conclusively why certain FTP servers
   reset the control channel connection some time after issueing an EPSV
   command.  However, a reasonable explanation would be that these FTP
   servers are located behind application-aware firewalls which monitor
   the control channel session and only allow the creation of data
   channel sessions to the ports listed in the responses to PASV (and
   Maybe PORT) commands.  As the response to an EPSV command is
   different (a 229 code rather than a 227 code), a firewall that is
   unaware of the EPSV command would block the subsequent data channel
   setup attempt.  When after some time no data channel connection has
   been established, the FTP server may decide to terminate the control
   channel session in an attempt to leave this ambiguous state.

   All 25 tested servers were able to successfully complete a transfer
   in traditional PASV passive mode as required by [RFC1123].  More
   testing showed that the use of an address family argument with the
   EPSV command is widely mis- or unimplemented in servers.  The
   additional tests with more servers showed that approximately 65% of
   FTP servers support EPSV successfully and around 96% support PASV
   successfully.  Clients were not extensively tested, but previous
   experience from the author suggests that most clients support PASV,
   with the notable exception of the command line client included with
   Windows, which only supports active mode.  This FTP client uses the
   original PORT command when running over IPv4 and EPRT when running

van Beijnum              Expires January 1, 2012                [Page 3]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

   over IPv6.

   Although these issues can and should be addressed by modifying
   clients and servers to support EPSV successfully, such modifications
   may not appear widely in a timely fashion.  Also, network operators
   who may want to deploy IPv6-to-IPv4 translation generally don't have
   control over client or server implementations.  As such, this
   document standardizes an FTP Application Layer Gateway (ALG) that
   will allow unmodified IPv6 FTP clients to interact with unmodified
   IPv4 FTP servers successfully when using FTP for simple file
   transfers between a single client and a single server.

   Clients that want to engage in more complex behavior, such as server-
   to-server transfers, may make an FTP application layer gateway (ALG)
   go into transparent mode by issuing the ALGS command as explained in
   Section 5.

   The recommendations and specifications in this document apply to all
   forms of IPv6-to-IPv4 translation, including stateless translation
   such as [RFC6145] as well as stateful translation such as [RFC6146].

   This documentation does not deal with the LPRT and LPSV commands
   specified in [RFC1639] as these commands do not appear to be in
   significant use.

2.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  Terminology

   Within the context of this document, the words "client" and "server"
   refer to FTP client and server implementations, respectively.  An FTP
   server is understood to be an implementation of the FTP protocol
   running on a server system with a stable address, waiting for clients
   to connect and issue commands that eventually start data transfers.
   Clients interact with servers using the FTP protocol, and store
   (upload) files to, and retrieve (download) files from one or more
   servers.  This either happens interactively under control of a user,
   or is done as an unattended background process.  Most operating
   systems provide a web browser that implements a basic FTP client, as
   well as a command line client.  Third-party FTP clients are also
   widely available.

van Beijnum              Expires January 1, 2012                [Page 4]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

   Other terminology is derived from the documents listed in the
   references section.  Note that this document cannot be fully
   understood on its own; it depends on background and terminology
   outlined in the references.

4.  ALG overview

   The most robust way to solve an IP version mismatch between FTP
   clients and FTP servers would be by changing clients and servers
   rather than using an IPv6-to-IPv4 translator for the data channel and
   using an application layer gateway on the control channel.  As such,
   it is recommended to update FTP clients and servers as required for
   IPv6-to-IPv4 translation support where possible, to allow proper
   operation of the FTP protocol without the need for ALGs.

   On the other hand, network operators or even network administrators
   within an organization often have little influence over the FTP
   client and server implementations used over the network.  For those
   operators and administrators, deploying an ALG may be the only way to
   provide a satisfactory customer experience.  So, even though not the
   preferred solution, this document standardizes the functionality of
   such an ALG in order to promote consistent behavior between ALGs in
   an effort to minimize their harmful effects.

   Operators and administrators are encouraged to only deploy an FTP ALG
   for IPv6-to-IPv4 translation when the FTP ALG is clearly needed.  In
   the presence of the ALG, EPSV commands that could be handled directly
   by conforming servers are translated into PASV commands, introducing
   additional complexity and reducing robustness.  As such a "set and
   forget" policy on ALGs is not recommended.

   Note that the translation of EPSV through all translators and EPRT
   through a stateless translator is relatively simple but supporting
   translation of EPRT through a stateful translator is relatively
   difficult, because in the latter case a translation mapping must be
   set up for each data transfer using parameters that must be learned
   from the client/server interaction over the control channel.  This
   needs to happen before the EPRT command can be translated into a PORT
   command and passed on to the server.  As such, an ALG used with a
   stateful translator MUST support EPSV translation and MAY support
   EPRT translation.  However, an ALG used with a stateless translator
   MUST support EPSV translation and SHOULD also support EPRT

   The ALG functionality is described as a function separate from the
   IPv6-to-IPv4 translation function.  However, in the case of EPRT
   translation, the ALG and translator functions need to be tightly

van Beijnum              Expires January 1, 2012                [Page 5]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

   coupled, so if EPRT translation is supported, it is assumed that the
   ALG and IPv6-to-IPv4 translation functions are integrated within a
   single device.

5.  Control channel translation

   The IPv6-to-IPv4 FTP ALG intercepts all TCP sessions towards port 21
   for IPv6 destination addresses that map to IPv4 destinations
   reachable through an IPv6-to-IPv4 translator.  The FTP ALG implements
   the Telnet protocol ([RFC0854]) used for control channel interactions
   to the degree necessary to interpret commands and responses and re-
   issue those commands and responses, modifying them as outlined below.
   Telnet option negotiation attempts by either the client or the
   server, except for those allowed by [RFC1123], MUST be refused by the
   FTP ALG without relaying those attempts.  For the purpose of Telnet
   option negotiation, an FTP ALG MUST follow the behavior of an FTP
   server as specified in [RFC1123] section  This avoids the
   situation where the client and the server negotiate Telnet options
   that are unimplemented by the FTP ALG.

   There are two ways to implement the control channel ALG:

   1.  The ALG terminates the IPv6 TCP session, sets up a new IPv4 TCP
       session towards the IPv4 FTP server, and relays commands and
       responses back and forth between the two sessions.

   2.  Packets that are part of the control channel are translated

   As they ultimately provide the same result, either implementation
   strategy, or any other that is functionally equivalent, can be used.

   In the second case, an implementation MUST have the ability to track
   and update TCP sequence numbers when translating packets as well as
   the ability to break up packets into smaller packets after
   translation, as the control channel translation could modify the
   length of the payload portion of the packets in question.  Also, FTP
   commands/responses or Telnet negotiations could straddle packet
   boundaries, so in order to be able to perform the ALG function, it
   can prove necessary to reconstitute Telnet negotiations and FTP
   commands and responses from multiple packets.

   Some FTP clients use the TCP urgent data feature when interrupting
   transfers.  An ALG MUST either maintain the semantics of the urgent
   pointer when translating control channel interactions, even when
   crossing packet boundaries, or clear the URG bit in the TCP header.

van Beijnum              Expires January 1, 2012                [Page 6]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

   If the client issues the AUTH command, then the client is attempting
   to negotiate [RFC2228] security mechanisms which are likely to be
   incompatible with the FTP ALG function.  For instance, if the client
   attempts to negotiate TLS protection of the control channel
   ([RFC4217], an ALG can do one of three things:

   1.  Transparently copy data transmitted over the control channel back
       and forth, so the TLS session works as expected but the client
       commands and server responses are now hidden from the ALG.

   2.  Block the negotiation of additional security, which will likely
       make the client and/or the server break off the session, or if
       not, perform actions in the clear that were supposed to be

   3.  Negotiate with both the client and the server so two separate
       protected sessions are set up and the ALG is still able to modify
       client commands and server responses.  Again, clients and servers
       are likely to reject the session because this will be percieved
       as a man-in-the-middle attack.

   An ALG MUST adopt the first option, and allow a client and a server
   to negotiate security mechanisms.  To ensure consistent behavior, as
   soon as the initial AUTH command is issued by the client, an ALG MUST
   stop translating commands and responses, and start transparently
   copying back and forth TCP data sent by the client and the server.

   It is possible that commands or responses that were sent through the
   ALG before the AUTH command was issued were changed in length so TCP
   sequence numbers in packets entering the ALG and packets exiting the
   ALG no longer match.  In transparent mode, the ALG MUST continue to
   adjust sequence numbers if it was doing so before entering
   transparent mode as the result of the AUTH command.  The ALGS command
   (Section 11) can also be used to disable the ALG functionality, but
   the control channel MUST then still be monitored for subsequent ALGS
   commands that re-enable the ALG functionality.

5.1.  Language negotiation

   [RFC2640] specifies the ability for clients and servers to negotiate
   the language used between the two of them in the descriptive text
   that accompanies server response codes.  Ideally, IPv6-to-IPv4 FTP
   ALGs would support this feature, so that if a non-default language is
   negotiated by a client and a server, the ALG also transmits its text
   messages for translated responses in the negotiated language.
   However, even if the ALG supports negotiation of the feature, there
   is no way to make sure that the ALG has text strings for all possible
   languages.  So the situation where the client and server try to

van Beijnum              Expires January 1, 2012                [Page 7]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

   negotiate a language that the ALG doesn't support can't be avoided.
   The proper behavior for an FTP ALG in this situation may be addressed
   in a future specification, as the same issue is present in IPv4-to-
   IPv4 FTP ALGs.  For the time being, ALG implementations MAY employ
   one of the following strategies regarding LANG negotiation:

   1.  Monitor LANG negotiation, and send text in the negotiated
       language if text in that language is available.  If not, text is
       sent in the default language.

   2.  Not monitor LANG negotiation.  Text is sent in the default

   3.  Block LANG negotiation by translating the LANG command to a NOOP
       command, and translating the resulting 200 response into a 502
       response, which is appropriate for unsupported commands.  Text is
       sent in the default language.

   In the first two cases, if a language is negotiated, text transmitted
   by the client or the server MUST be assumed to be encoded in UTF-8
   rather than be limited to 7-bit ASCII.  An ALG that implements the
   first or second option MUST translate and/or forward commands and
   responses containing UTF-8 encoded text when those occur.  The ALG
   itself MUST NOT generate characters outside the 7-bit ASCII range
   unless it implements the first option and a language was negotiated.

   Note that section 3.1 of [RFC2640] specifies new handling for spaces
   and the CR character in path names.  ALGs that don't block LANG
   negotiation SHOULD comply with the specified rules for path handling.
   Implementers should especially note that the NUL (%x00) character is
   used as an escape whenever a CR character occurs in a pathname.

   In the sections that follow, a number of well-known response numbers
   are shown, along with the descriptive text that is associated with
   that response number.  However, this text is not part of the
   specification of the response.  As such, implementations MAY use the
   response text shown or they MAY show a different response text for a
   given response number.  Requirements language only applies to the
   response number.

6.  EPSV to PASV translation

   Although many IPv4 FTP servers support the EPSV command, some servers
   react adversely to this command (see Section 1 for examples), and
   there is no reliable way to detect in advance that this will happen.
   As such, an FTP ALG SHOULD translate all occurrences of the EPSV
   command issued by the client to the PASV command, and reformat a 227

van Beijnum              Expires January 1, 2012                [Page 8]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

   response as a corresponding 229 response.  However, an ALG MAY forego
   EPSV to PASV translation if it has positive knowledge, either through
   administrative configuration or learned dynamically, that EPSV will
   be successful without translation to PASV.

   For instance, if the client issues EPSV (or EPSV 2 to indicate IPv6
   as the network protocol), this is translated to the PASV command.  If
   the server with address then responds with:

      227 Entering Passive Mode (192,0,2,31,237,19)

   The FTP ALG reformats this as:

      229 Entering Extended Passive Mode (|||60691|)

   The ALG SHOULD ignore the IPv4 address in the server's 227 response.
   This is the behavior that is exhibited by most clients and is needed
   to work with servers that include [RFC1918] addresses in their 227
   responses.  However, if the 227 response contains an IPv4 address
   that does not match the destination of the control channel, the FTP
   ALG MAY send a 425 response to the client instead of the 229
   response, e.g.:

      425 Can't open data connection

   It is important that the response is in the 4xx range to indicate a
   temporary condition.

   If the client issues an EPSV command with a numeric argument other
   than 2, the ALG MUST NOT pass the command on to the server, but
   rather respond with a 522 error, e.g.:

      522 Network protocol not supported

   If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command
   to the server, but respond with a 504 error, e.g.:

      504 Command not implemented for that parameter

   This avoids the situation where an FTP server reacts adversely to
   receiving a PASV command after the client used the EPSV ALL command
   to indicate that it will only use EPSV during this session.

7.  EPRT to PORT translation

   Should the IPv6 client issue an EPRT command, the FTP ALG MAY
   translate this EPRT command to a PORT command.  The translation is

van Beijnum              Expires January 1, 2012                [Page 9]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

   different depending on whether the translator is a stateless one-to-
   one translator or a stateful one-to-many translator.

7.1.  Stateless EPRT translation

   If the address specified in the EPRT command is the IPv6 address used
   by the client for the control channel session, then the FTP ALG
   reformats the EPRT command into a PORT command with the IPv4 address
   that maps to the client's IPv6 address.  The port number MUST be
   preserved for compatibility with stateless translators.  For
   instance, if the client with IPv6 address 2001:db8:2::31 issues the
   following EPRT command:

      EPRT |2|2001:db8:2::31|5282|

   Assuming the IPv4 address that goes with 2001:db8:2::31 is, the FTP ALG reformats this as:

      PORT 192,0,2,31,20,162

   If the address specified in the EPRT command is an IPv4 address or an
   IPv6 address that is not the IPv6 address used by the client for the
   control session, the ALG SHOULD NOT attempt any translation, but pass
   along the command unchanged.

7.2.  Stateful EPRT translation

   If the address in the EPRT command is the IPv6 address used by the
   client for the control channel, the stateful translator selects an
   unused port number in combination with the IPv4 address used for the
   control channel towards the FTP server, and sets up a mapping from
   that transport address to the one specified by the client in the EPRT
   command.  The PORT command with the IPv4 address and port used on the
   IPv4 side of the mapping is only issued towards the server once the
   mapping is created.  Initially, the mapping is such that either any
   transport address or the FTP server's IPv4 address with any port
   number is accepted as a source, but once the three-way handshake is
   complete, the mapping SHOULD be narrowed to only match the negotiated
   TCP session.

   If the address specified in the EPRT command is an IPv4 address or an
   IPv6 address that is not the IPv6 address used by the client for the
   control session, the ALG SHOULD NOT attempt any translation, but pass
   along the command unchanged.

   If the client with IPv6 address 2001:db8:2::31 issues the EPRT

van Beijnum              Expires January 1, 2012               [Page 10]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

      EPRT |2|2001:db8:2::31|5282|

   And the stateful translator uses the address on its IPv4
   interface, a mapping with destination address and
   destination port 60192 towards 2001:db8:2::31 port 5282 may be
   created, after which the FTP ALG reformats the EPRT command as:

      PORT 192,0,2,31,235,32

8.  Default port 20 translation

   If the client does not issue an EPSV/PASV or EPRT/PORT command prior
   to initiating a file transfer, it is invoking the default active FTP
   behavior where the server sets up a TCP session towards the client.
   In this situation, the source port number is the default FTP data
   port (port 20) and the destination port is the port the client uses
   as the source port for the control channel session.

   In the case of a stateless translator, this does not pose any
   problems.  In the case of a stateful translator, the translator MAY
   accept incoming connection requests from the server on the IPv4 side
   if the transport addresses match that of an existing FTP control
   channel session, with the exception that the control channel session
   uses port 21 and the new session port 20.  In this case, a mapping is
   set up towards the same transport address on the IPv6 side that is
   used for the matching FTP control channel session.

   An ALG/translator MAY monitor the progress of FTP control channels
   and only attempt to perform a mapping when an FTP client has started
   a file transfer without issuing the EPSV, PASV, EPRT or PORT

9.  Both PORT and PASV

   [RFC0959] allows a client to issue both PORT and PASV to use non-
   default ports on both sides of the connection.  However, this is
   incompatible with the notion that with PASV, the data connection is
   made from the client to the server, while PORT reaffirms the default
   behavior where the server connects to the client.  As such, the
   behavior of an ALG is undefined when a client issues both PASV and
   PORT.  Implementations SHOULD NOT try to detect the situation where
   both PASV and PORT commands are issued prior to a command that
   initiates a transfer, but rather, translate commands as they occur.
   So if a client issues PASV, PASV is then translated to EPSV.  If
   after that, before any transfers have occurred, the client issues
   PORT and the ALG supports PORT translation for this session, the ALG

van Beijnum              Expires January 1, 2012               [Page 11]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

   translates PORT to EPRT.

10.  Default behavior

   Whenever the client issues a command which the ALG is not set up to
   translate, either because the command is not specified in this
   document, the command is not part of any FTP specification, the ALG
   functionality is disabled administratively for the command in
   question, or translation does not apply for any other reason, the
   command MUST be passed on to the server without modification, and the
   server response MUST be passed on to the client without modification.
   For example, if the client issues the PASV command, this command is
   passed on to the server transparently, and the server's response to
   the client.

11.  The ALGS command

   ALGs MUST support the new ALGS (ALG status) command that allows
   clients to query and set the ALG's status.  FTP servers (as opposed
   to ALGs) MUST NOT perform any actions upon receiving the ALGS
   command.  FTP servers MUST still send a response, however.  If FTP
   servers recognize the ALGS command, the best course of action would
   be to return a 202 response:

      202 Command not implemented, superfluous at this site

   However, there is no reason for FTP servers to specifically recognize
   this command; returning any 50x response that is normally returned
   when commands are not recognized is appropriate.

   A client can use the ALGS command to request the ALG's status and to
   enable and disable EPSV to PASV translation and, if implemented, EPRT
   to PORT translation.  There are three possible arguments to the ALGS

                   The ALG is requested to return the EPSV and EPRT
                   translation status.

                   The ALG is requested to enable translation.

                   The ALG is requested to disable translation.

   The ALG MUST enable or disable EPSV to PASV translation as requested.

van Beijnum              Expires January 1, 2012               [Page 12]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

   If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD enable
   it and ALGS DISABLE64 MUST disable it along with enabling or
   disabling EPSV to PASV translation, respectively.  If EPRT to PORT
   translation is not supported, ALGS ENABLE64 only enables EPSV to PASV
   translation.  After an ALGS command with any of the three supported
   arguments, the ALG MUST return a 216 response indicating the type of
   translation that will be performed.

   216 NONE
                   Neither EPSV nor EPRT translation is performed.

   216 EPSV
                   EPSV is translated to PASV, no EPRT translation is

   216 EPRT
                   EPRT is translated to PORT, no EPSV translation is

                   EPSV is translated to PASV, EPRT is translated to

   The translation type MAY be followed by a space and additional
   descriptive text until end-of-line.  If the ALG is unable to set the
   requested translation mode, for instance, because of lack of certain
   resources, this is not considered an error condition.  In those
   cases, the ALG responds with a 216 response followed by the keyword
   that indicates the current translation status of the ALG.

   If there is no argument to the ALGS command, or the argument is not
   one of STATUS64, ENABLE64 or DISABLE64 (or an argument specified by a
   supported newer document), a 504 or 502 error SHOULD be returned.

   The Augmented Backus-Naur Form (ABNF) notation (see [RFC5234]) of the
   ALGS command and its response are as follows:

   algs-command      = "ALGS" SP algs-token CRLF
   algs-token        = "STATUS64" / "ENABLE64" / "DISABLE64"

   algs-response     = (ok-response / error-response) CRLF
   ok-response       = "216" SP response-token [ freetext ]
   response-token    = "NONE" / "EPSV" / "EPRT" / "EPSVEPRT"
   error-response    = not-implemented / invalid-parameter
   not-implemented   = "502" [ freetext ]
   invalid-parameter = "504" [ freetext ]
   freetext          = (SP *VCHAR)

van Beijnum              Expires January 1, 2012               [Page 13]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

12.  Timeouts and translating to NOOP

   Wherever possible, control channels SHOULD NOT time out while there
   is an active data channel.  A timeout of at least 30 seconds is
   RECOMMENDED for data channel mappings created by the FTP ALG that are
   waiting for initial packets.

   Whenever a command from the client is not propagated to the server,
   the FTP ALG instead issues a NOOP command in order to keep the
   keepalive state between the client and the server synchronized.  The
   response to the NOOP command MUST NOT be relayed back to the client.
   An implementation MAY wait for the server to return the 200 response
   to the NOOP command and translate that 200 response into the response
   the ALG is required to return to the client.  This way, the ALG never
   has to create new packets to send to the client, but it can limit
   itself to modifying packets transmitted by the server.  If the server
   responds with something other than 200 to the NOOP command, the ALG
   SHOULD tear down the control channel session and log an error.

13.  IANA considerations

   IANA is requested to add to the FTP Commands and Extensions registry
   the following entry:

   Command Name

   FEAT Code

                              FTP64 ALG status

   Command Type

   Conformance Requirements

                              RFC TBD Section 11

   [TO BE REMOVED: This registration should take place at the following
   location: http://www.iana.org/assignments/ftp-commands-extensions/

van Beijnum              Expires January 1, 2012               [Page 14]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

14.  Security considerations

   In the majority of cases, FTP is used without further security
   mechanisms.  This allows an attacker with passive interception
   capabilities to obtain the login credentials, and an attacker that
   can modify packets to change the data transferred.  However, FTP can
   be used with TLS in order to solve these issues.  IPv6-to-IPv4
   translation and the FTP ALG do not impact the security issues in the
   former case nor the use of TLS in the latter case.  However, if FTP
   is used with TLS as per [RFC4217], or another authentication
   mechanism that the ALG is aware of, the ALG function is not performed
   so only passive transfers from a server that implements EPSV or a
   client that supports PASV will succeed.

   For general FTP security considerations, see [RFC2577].

15.  Contributors

   Dan Wing, Kentaro Ebisawa, Remi Denis-Courmont, Mayuresh Bakshi,
   Sarat Kamisetty, Reinaldo Penno, Alun Jones, Dave Thaler, Mohammed
   Boucadair, Mikael Abrahamsson, Dapeng Liu, Michael Liu, Andrew
   Sullivan, Anthony Bryan, Ed Jankiewicz Pekka Savola, Fernando Gont,
   Rockson Li and Donald Eastlake contributed ideas and comments.  Dan
   Wing ran experiments with a large number of FTP servers that were
   very illuminating; many of the choices underlying this document are
   based on his results.

16.  Acknowledgements

   Iljitsch van Beijnum is partly funded by Trilogy, a research project
   supported by the European Commission under its Seventh Framework

17.  References

17.1.  Normative References

   [RFC0854]  Postel, J. and J. Reynolds, "Telnet Protocol
              Specification", STD 8, RFC 854, May 1983.

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
              STD 9, RFC 959, October 1985.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

van Beijnum              Expires January 1, 2012               [Page 15]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2228]  Horowitz, M., "FTP Security Extensions", RFC 2228,
              October 1997.

   [RFC2428]  Allman, M., Ostermann, S., and C. Metz, "FTP Extensions
              for IPv6 and NATs", RFC 2428, September 1998.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

17.2.  Informative References

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

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2389]  Hethmon, P. and R. Elz, "Feature negotiation mechanism for
              the File Transfer Protocol", RFC 2389, August 1998.

   [RFC2577]  Allman, M. and S. Ostermann, "FTP Security
              Considerations", RFC 2577, May 1999.

   [RFC2640]  Curtin, B., "Internationalization of the File Transfer
              Protocol", RFC 2640, July 1999.

   [RFC4217]  Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
              October 2005.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

van Beijnum              Expires January 1, 2012               [Page 16]

Internet-Draft              IPv6-to-IPv4 FTP                   June 2011

Author's Address

   Iljitsch van Beijnum
   Institute IMDEA Networks
   Avda. del Mar Mediterraneo, 22
   Leganes, Madrid  28918

   Email: iljitsch@muada.com

van Beijnum              Expires January 1, 2012               [Page 17]

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