GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6384

Internet Engineering Task Force (IETF) I. van Beijnum Request for Comments: 6384 Institute IMDEA Networks Category: Standards Track October 2011 ISSN: 2070-1721

An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation

Abstract

 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, in situations 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,
 it is important that 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 is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6384.

Copyright Notice

 Copyright (c) 2011 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

Van Beijnum Standards Track [Page 1] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

 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 . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  4
 3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
 4.  ALG Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
 5.  Control Channel Translation  . . . . . . . . . . . . . . . . .  5
   5.1.  Language Negotiation . . . . . . . . . . . . . . . . . . .  7
 6.  EPSV to PASV Translation . . . . . . . . . . . . . . . . . . .  8
 7.  EPRT to PORT Translation . . . . . . . . . . . . . . . . . . .  9
   7.1.  Stateless EPRT Translation . . . . . . . . . . . . . . . .  9
   7.2.  Stateful EPRT Translation  . . . . . . . . . . . . . . . . 10
 8.  Default Port 20 Translation  . . . . . . . . . . . . . . . . . 10
 9.  Both PORT and PASV . . . . . . . . . . . . . . . . . . . . . . 11
 10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 11
 11. The ALGS Command . . . . . . . . . . . . . . . . . . . . . . . 12
 12. Timeouts and Translating to NOOP . . . . . . . . . . . . . . . 13
 13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
 14. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   17.1. Normative References . . . . . . . . . . . . . . . . . . . 15
   17.2. Informative References . . . . . . . . . . . . . . . . . . 15

1. Introduction

 [RFC0959] specifies two modes of operation for FTP: active mode, in
 which the server connects back to the client, and passive mode, in
 which 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 with 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.

Van Beijnum Standards Track [Page 2] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

 A survey done in April 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 of these cases, a control
 channel reset followed the delay.  Due to lack of additional
 information, it is impossible to determine conclusively why certain
 FTP servers reset the control channel connection some time after
 issuing an EPSV command.  However, a reasonable explanation would be
 that these FTP servers are located behind application-aware firewalls
 that 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.  If no data channel connection has been established
 after some time, 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 misimplemented or unimplemented in servers.
 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 the author's
 previous experience 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 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 do not 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.

Van Beijnum Standards Track [Page 3] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

 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",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 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; they 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.
 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

Van Beijnum Standards Track [Page 4] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

 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
 translation.
 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
 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
 4.1.2.12.  This avoids the situation where the client and the server
 negotiate Telnet options that are unimplemented by the FTP ALG.

Van Beijnum Standards Track [Page 5] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

 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
     individually.
 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.
 If the client issues the AUTH command, then the client is attempting
 to negotiate [RFC2228] security mechanisms that are likely to be
 incompatible with the FTP ALG function.  For instance, if the client
 attempts to negotiate Transport Layer Security (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
     encrypted.
 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 perceived
     as a man-in-the-middle attack.

Van Beijnum Standards Track [Page 6] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

 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 TCP data sent by the server to the client and vice versa.
 The ALG SHOULD ignore the AUTH command and not go into transparent
 mode if the server response is in the 4xx or 5xx ranges.
 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.  Thus, the situation where the client and server try to
 negotiate a language not supported by the ALG is unavoidable.  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
     language.
 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.

Van Beijnum Standards Track [Page 7] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

 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
 [RFC3629] 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 carriage return (CR) character in pathnames.  ALGs that do
 not 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
 response as a corresponding 229 response.  However, an ALG MAY forego
 EPSV to PASV translation if it has positive knowledge, either gained
 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 192.0.2.31 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|)

Van Beijnum Standards Track [Page 8] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

 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, for example:
    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, for example:
    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, for example:
    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
 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|

Van Beijnum Standards Track [Page 9] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

 Assuming the IPv4 address that goes with 2001:db8:2::31 is
 192.0.2.31, 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
 command:
    EPRT |2|2001:db8:2::31|5282|
 And the stateful translator uses the address 192.0.2.31 on its IPv4
 interface, a mapping with destination address 192.0.2.31 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.

Van Beijnum Standards Track [Page 10] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

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

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, but before any transfers have occurred, the client issues
 PORT and the ALG supports PORT translation for this session, the ALG
 translates PORT to EPRT.

10. Default Behavior

 Whenever the client issues a command that the ALG is not set up to
 translate (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 is passed on to
 the client transparently.

Van Beijnum Standards Track [Page 11] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

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.  However, FTP servers MUST still send a response.  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
 command:
 ALGS STATUS64   The ALG is requested to return the EPSV and EPRT
                 translation status.
 ALGS ENABLE64   The ALG is requested to enable translation.
 ALGS DISABLE64  The ALG is requested to disable translation.
 The ALG MUST enable or disable EPSV to PASV translation as requested.
 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
                 performed.
 216 EPSVEPRT    EPSV is translated to PASV; EPRT is translated to
                 PORT.
 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

Van Beijnum Standards Track [Page 12] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

 resources, this is not considered an error condition.  In those
 cases, the ALG returns 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" / "EPSVEPRT"
 error-response    = not-implemented / invalid-parameter
 not-implemented   = "502" [ freetext ]
 invalid-parameter = "504" [ freetext ]
 freetext          = (SP *VCHAR)

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 a 200 response to the NOOP
 command, the ALG SHOULD tear down the control channel session and log
 an error.

Van Beijnum Standards Track [Page 13] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

13. IANA Considerations

 IANA has added the following entry to the "FTP Commands and
 Extensions" registry:
 Command Name               ALGS
 FEAT Code                  -N/A-
 Description                FTP64 ALG status
 Command Type               -N/A-
 Conformance Requirements   o
 Reference                  RFC 6384 Section 11

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's experiments with a large number of FTP servers were very
 illuminating; many of the choices underlying this document are based
 on his results.

Van Beijnum Standards Track [Page 14] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

16. Acknowledgements

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

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.
 [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.
 [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
            10646", STD 63, RFC 3629, November 2003.
 [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.

Van Beijnum Standards Track [Page 15] RFC 6384 An IPv6-to-IPv4 FTP ALG October 2011

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

Author's Address

 Iljitsch van Beijnum
 Institute IMDEA Networks
 Avda. del Mar Mediterraneo, 22
 Leganes, Madrid  28918
 Spain
 EMail: iljitsch@muada.com

Van Beijnum Standards Track [Page 16]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6384.txt · Last modified: 2011/10/06 00:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki