[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

FTPEXT2                                                           D. Liu
Internet-Draft                                              China Mobile
Intended status: Best Current Practice                 Iljitsch. Beijnum
Expires: January 16, 2014                                 IMDEA Networks
                                                               Hui. Deng
                                                                  Z. Cao
                                                            China Mobile
                                                           July 15, 2013


Recommendations for FTP Clients and Servers in the IPv6/IPv4 Transition
                                Scenario
                       draft-liu-ftpext2-ftp64-00

Abstract

   The File transfer protocol, which was originally defined in RFC 114
   and published in 1971, well before TCP and IP were created.  However,
   it is still in wide use.  Many FTP servers implement RFC 959, which
   requires IPv4.  RFC 2428 defines extensions that allow FTP to work
   over IPv6 by introducing the EPRT and EPSV commands.  When IPv6 FTP
   clients attempt to communicate with IPv4 FTP servers through an
   IPv6-IPv4 translator, only certain combinations of FTP client and
   server behavior lead to successful file transfers.  This document
   proposes the best current practice for IPv6 FTP client
   implementations in the IPv6-IPv4 translation scenario, allowing file
   transfers to succeed without the presence of an ALG (Application
   Layer Gateway).

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 16, 2014.

Copyright Notice




Liu, et al.             Expires January 16, 2014                [Page 1]


Internet-Draft     Recommendation for IPv6 FTP client          July 2013


   Copyright (c) 2013 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
   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.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  IPv6 FTP Client Considerations  . . . . . . . . . . . . . . .   3
   4.  FTP Server considerations . . . . . . . . . . . . . . . . . .   5
   5.  FTP ALG considerations  . . . . . . . . . . . . . . . . . . .   5
     5.1.  FTP ALG limitations . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Figure 1 illustrates FTP [RFC0959] in the IPv6-IPv4 translation
   scenario.

         +------------------------------------------------------+
         |                                                      |
         |                                                      |
         | +----------------+                  +--------------+ |
         | | IPv6 Network   |                  | IPv4 Network | |
         | | +-----------+  |  +------------+  | +----------+ | |
         | | |IPv6       |--|--| IPv6-IPv4  |--|-|IPv4      | | |
         | | |FTP Client |  |  | Translator |  | |FTP Server| | |
         | | +-----------+  |  +------------+  | +----------+ | |
         | |                |                  |              | |
         | +----------------+                  +--------------+ |
         |                                                      |
         |                                                      |
         +------------------------------------------------------+



Liu, et al.             Expires January 16, 2014                [Page 2]


Internet-Draft     Recommendation for IPv6 FTP client          July 2013


               Figure 1. IPv6-IPv4 translation the FTP scenario.

                                 Figure 1

   The IPv6 FTP client is situated in an IPv6 network and communicates
   with an IPv4 server that is situated in an IPv4 network through a
   translation box in the middle.  Here "IPv6 FTP client" means an FTP
   client that supports IPv6, i.e., it implements [RFC2428].  "IPv4
   server" means an FTP server with only IPv4 connectivity, which may or
   may not support the RFC2428 extensions.

   The situation where a legacy IPv4 FTP client that does not support
   the RFC2428 extensions runs on the IPv6 host is out of scope.

   FTP has two operation modes: passive mode and active mode.  In
   passive mode, the server listens on a TCP port, which the client
   connects to.  In active mode, the server connects back to the client,
   using the IP address and port number provided by the client.

   RFC2428 specifies extensions to the FTP protocol which let it work
   over IPv6, and make it easier for FTP to work through firewalls and
   NATs.  Two new commands are specified: EPRT and EPSV.  The EPRT
   command is an extension of the existing PORT command.  It provides
   and IP address (IPv4 or IPv6) and a port number to the server to
   connect to.  The EPSV command is a simplified version of the PASV
   command.  Unlike with PASV, with EPSV the server does not respond
   with an IP address for the client to connect to.  Instead, the server
   only specifies a port number.  The IP address the client should
   connect to is the same IP address that the client is already
   connected to for the control channel TCP session.

   Many servers do not support EPSV command today, or send a valid
   response, but the subsequent data channel connection fails to
   establish.  However, most of these servers support PASV mode.  This
   document provides recommendations for IPv6 FTP clients that allow
   them to successfully communicate with an IPv4 server through a
   stateless [RFC6145] or stateful [RFC6146] IPv6-IPv4 translation box.

2.  Conventions used in this document

   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.  IPv6 FTP Client Considerations

   According to [RFC2428], the IPv6 client SHOULD support EPSV and EPRT
   commands.  This document recommends that the IPv6 FTP client SHOULD



Liu, et al.             Expires January 16, 2014                [Page 3]


Internet-Draft     Recommendation for IPv6 FTP client          July 2013


   support both EPSV and PASV command.  The reason is that during the
   early stage of IPv6 transition, many FTP servers will be still
   located in the IPv4 Internet and not support the EPSV command.  This
   requirement implies that the IPv6 FTP client SHOULD support both IPv4
   and IPv6.  This requirement is reasonable since backward
   compatibility to IPv4 is one of the basic requirements for any IPv6
   applications especially during the early stage of IPv6 transition.

   Most of today's dedicated IPv4 FTP client software uses passive mode
   as the default mode.  According to RFC 2428, for IPv6 FTP client,
   EPSV command MUST be used when the control and data connection is
   established between the same two machines.  The reasons that both
   IPv4 and IPv6 FTP client prefer passive mode includes:

   1.  Active mode of FTP may introduce security issues.  For example,
       the attacker may use PORT/EPRT command to specify a victim host's
       IP address and port, and then the FTP serve will send TCP SYN to
       the victim host to attempt to establish data connection.  This
       kind of attack is recognized as FTP reflects attack.
   2.  Using passive mode of FTP can traverse firewalls and NATs more
       easily because passive mode does not require the middle box to
       implement an FTP ALG (Application Layer Gateway).

   Considering the above, it is recommended that the IPv6 FTP client
   SHOULD use passive mode instead of active mode whenever it is
   possible.

   In IPv6/IPv4 translation scenario, an IPv6 FTP client which is
   located in the IPv6 network may need to communicate with an IPv4
   server which is located in the IPv4 network.  In this case, the IPv4
   server may not support EPSV command and if the IPv6 FTP client uses
   the EPSV command, the command may not be recognized so no file
   transfer can be established.

   This document recommends that the IPv6 FTP client SHOULD retry with
   PASV command when EPSV command fails with a 50x response from the
   server, the server sends a 229 response but the data connection
   cannot be established, or the control channel TCP session is lost
   between the 229 response and any other messages sent over the control
   channel by the server.

   After the client issues a PASV command, the IPv4 FTP server will
   respond with a 227 message that contains an IPv4 address and port
   number of the FTP server for the client to connect to.  The IPv6 FTP
   client MUST ignore the IPv4 address provided in the response;
   instead, it MUST use the remote IP address used for the control
   channel to establish the data connection.




Liu, et al.             Expires January 16, 2014                [Page 4]


Internet-Draft     Recommendation for IPv6 FTP client          July 2013


   Many IPv4 FTP clients already ignore the IP address in the 227
   response because this way, the data connection will still be
   established if the server includes its [RFC1918] address in the 227
   response.  Also, if a dual stack host connects over IPv6 for the
   control channel and then over IPv4 for the data channel, the server
   may reject the data channel connection because it comes from an
   unexpected address.

   Another important benefit of this approach is that the translation
   box will not need to implement FTP ALG [RFC6384].

4.  FTP Server considerations

   Clients conforming to the recommendations listed above will be able
   to transfer files to/from all FTP servers.  However, FTP servers are
   encouraged to support the EPSV command if this can be done
   successfully.  If the server cannot successfully use the EPSV
   command, for instance, because the server is located behind an
   application aware firewall that only allows incoming data connections
   after observing 227 responses in the FTP control channel, then
   servers SHOULD return a 502 response when the client sends the EPSV
   command.

   Implementers of FTP server software SHOULD include a setting that
   allows the EPSV command to return a 502 response.

5.  FTP ALG considerations

   This document recommends that the translation box does not need to
   implement FTP ALG [RFC6384] in the IPv6/IPv4 translation scenario.
   Instead, it is recommended that the IPv6 FTP client implementation
   should comply with this document to avoid the necessity of
   implementation FTP ALG in the IPv6/IPv4 translation box.

   Adjusting the behaviour of IPv6 clients is feasible because IPv6 is
   not widely deployed and there are not much IPv6 FTP client been
   deployed currently.  It is a good chance to publish this
   recommendation before the widely deployment of IPv6 and IPv6 FTP
   client.

5.1.  FTP ALG limitations

   Implementing FTP ALG in the translation box may have some
   limitations, such as:

   1) FTP ALG may case to increase the complexity of translation box,
   since FTP ALG needs to understand FTP protocol and translate the
   application layer payload and update the header of FTP control



Liu, et al.             Expires January 16, 2014                [Page 5]


Internet-Draft     Recommendation for IPv6 FTP client          July 2013


   packets.  ALG could also cause impair the translation box's
   performance.

   2) From the evolution perspective, if the network continues to
   provide support of FTP ALG indefinitely, the ALG function of the
   translation box will become more and more complex.

6.  Security Considerations

   FTP security is discussed in [RFC2577].  The extension that is
   defined in this document will not impact the FTP security.

7.  IANA Considerations

   No IANA action is required.

8.  Acknowledgments

   The authors want to thanks the following people for their useful
   suggestions: Robert Oslin, Anthony Bryan.

9.  References

9.1.  Normative References

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

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

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

9.2.  Informative References

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

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

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






Liu, et al.             Expires January 16, 2014                [Page 6]


Internet-Draft     Recommendation for IPv6 FTP client          July 2013


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

   [RFC6384]  van Beijnum, I., "An FTP Application Layer Gateway (ALG)
              for IPv6-to-IPv4 Translation", RFC 6384, October 2011.

Authors' Addresses

   Dapeng Liu
   China Mobile
   Unit2, 28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: liudapeng@chinamobile.com


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

   Email: iljitsch@muada.com


   Hui Deng
   China Mobile
   Unit2, 28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: denghui@chinamobile.com


   Zhen Cao
   China Mobile
   Unit2, 28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: caozhen@chinamobile.com








Liu, et al.             Expires January 16, 2014                [Page 7]


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