Behavior Engineering for Hindrance                        I. van Beijnum
Avoidance                                                 IMDEA Networks
Internet-Draft                                             April 6, 2009
Expires: October 8, 2009

                FTP Application Layer Gateway for NAT64

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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-

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on October 8, 2009.

Copyright Notice

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


   The only FTP mode that works without changes through an IPv6-to-IPv4
   translator is extended passive, introduced in 1998.  However, many
   existing FTP servers don't support this mode, making it impossible to

van Beijnum              Expires October 8, 2009                [Page 1]

Internet-Draft                    ftp64                       April 2009

   support the File Transfer Protocol through an IPv6-to-IPv4 translator
   without an Application Layer Gateway.  This document describes the
   behavior of such an ALG.

1.  Introduction

   [RFC0959] specifies two modes of operation for FTP: active mode, in
   which the server connects back to the client on port 20 or a client-
   provided port number, and active mode, where the server opens a port
   for the client to connect to.  Without additional action, active mode
   doesn't work through NATs or firewalls.  And in both cases, an IPv4
   address is specified, making both modes incompatible with IPv6.
   These issues were solved in [RFC2428], which specifies the EPSV
   (extended passive) mode that only specifies a port number and the
   EPRT (extended port) command which allows the client to supply an
   IPv6 address to the server.

   A survey 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 ([RFC2389]), while one supported EPSV
   but not FEAT.  In 5 cases, issuing the EPSV command to the server led
   to a signficant delay, in 3 cases followed by a control channel
   reset.  It appears that in these cases, the server did support EPSV
   but a middlebox didn't.  All 25 servers were able to successfully
   complete a transfer in PASV mode as required by [RFC1123].

   Based on the survey, an FTP ALG should be considered a necessary part
   of any NAT64 deployment.  Since all servers in the survey supported
   PASV passive mode, NAT64 implementers SHOULD implement EPSV to PASV
   translation.  NAT64 implementers MAY also implement EPRT to PORT
   translation.  However, as many hosts reside behind firewalls, often
   unbeknownst to the FTP clients running on those hosts, active FTP is
   relatively likely to fail with or without translation.

2.  Notational Conventions

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

3.  Control channel translation

   The NAT64 FTP ALG intercepts all sessions towards IPv4 destinations
   port 21.  The FTP ALG implements the Telnet protocol ([RFC0854]) used

van Beijnum              Expires October 8, 2009                [Page 2]

Internet-Draft                    ftp64                       April 2009

   for control channel interactions to the degree necessary to interpret
   commands and responses and re-issue those commands and responses,
   optionally modifying them.  Option negotiation attempts by the client
   except for those allowed by [RFC1123] SHOULD be rejected by the FTP
   ALG without relaying those attempts to the server.  This avoids the
   situation where the client and the server negotiate options unknown
   to the FTP ALG.

   If the client issues the AUTH command and the server responds with
   code 234 or 334, the client and server are negotiating [RFC2228]
   security mechanisms which are likely to be incompatible with the FTP
   ALG function.  In this situation, the FTP ALG MUST switch to
   transparently fowarding all data on the control channel in both
   directions until the end of the control channel session.

4.  EPSV to PASV translation

   Although many IPv4 FTP servers support the EPSV command, some servers
   react adversely to this command, and there is no reliable way to
   detect in advance that this will happen.  As such, a NAT64 FTP ALG
   SHOULD translate all occurrences of the EPSV command issued by the
   the client to the PASV command, and reformat a 227 response as a
   corresponding 229 response.

   For instance, if the client issues EPSV, this is translated to the
   PASV command.  If the server with address then reponds

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

   The FTP ALG reformats this as:

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

   If the server's 227 response contains an IPv4 address that doesn't
   match the destination of the control channel, the FTP ALG SHOULD
   reply with:

   425 Can't open data connection.

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

5.  EPRT to PORT translation

   Should the IPv6 client issue an EPRT command, the FTP ALG MAY

van Beijnum              Expires October 8, 2009                [Page 3]

Internet-Draft                    ftp64                       April 2009

   translate this EPRT command to a PORT command.  In that case, there
   are three possibilities: the address specified in the EPRT command is
   the client's IPv6 address, it's another IPv6 address or it's an IPv4
   address.  If it's an IPv6 address within the range that the
   translator is prepared to serve, even if it's not the client's
   address, the NAT64 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 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 is
   narrowed to only match the negotiated TCP session.

   If the address in the EPRT command is an IPv6 address that the NAT64
   is not prepared to translate for, the EPRT command is passed along to
   the server unmodified.  If the address in the EPRT command is an IPv4
   address, the FTP ALG reformats the EPRT command to the equivalent
   PORT command without changing the transport address.  In these cases,
   the NAT64 doesn't create a mapping.  This behavior retains
   compatibility with the server-to-server transfer option in FTP.

   Note that there is the corner case where the client doesn't specify
   either EPSV or EPRT because it wants to use active FTP on the default
   port.  This case isn't handled and will result in failure.

6.  Timeouts

   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 mappings created by the FTP ALG that are waiting for
   initial packets.

7.  IANA considerations


8.  Security considerations

   In the majority of cases, FTP is used without further security
   mechanisms.  This allows a passive attacker 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.  NAT64 translation and the FTP ALG don't impact

van Beijnum              Expires October 8, 2009                [Page 4]

Internet-Draft                    ftp64                       April 2009

   the security issues in the former case nor the use of TLS in the
   latter case.

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

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

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

              Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
              Address and Protocol Translation from IPv6 Clients to IPv4
              Servers", draft-bagnulo-behave-nat64-03 (work in
              progress), March 2009.

Appendix A.  Document and discussion information

   The latest version of this document will always be available at  Please direct questions and comments
   to the BEHAVE mailinglists or directly to the author.

Appendix B.  Acknowledgement

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

van Beijnum              Expires October 8, 2009                [Page 5]

Internet-Draft                    ftp64                       April 2009

Author's Address

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


van Beijnum              Expires October 8, 2009                [Page 6]