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

Versions: (draft-liu-ftp64-extension) 00 01 02

FTPEXT2                                                           D. Liu
Internet-Draft                                              China Mobile
Intended status: BCP                               Iljitsch van. Beijnum
Expires: July 11, 2012                                   IMDEA Networks
                                                                  Z. Cao
                                                            China Mobile
                                                        January  11, 2012


               FTP consideration for IPv4/IPv6 transition
                      draft-ietf-ftpext2-ftp64-02

Abstract

   The File transfer protocol(FTP) has a long histroy,, but still being
   widely used.  The first concept of FTP was described RFC 114, and
   then was specified in RFC 354.  FTP can work in IPv4 environment and
   then was extended to IPv6.  RFC 2428 defines IPv6 extensions of FTP.
   In the IPv6-IPv4 translation scenario, considerations should be
   applied to FTP client, server and translation box to ensure FTP
   protocol work properly.  This document discusses the details for FTP
   to work in IPv4-IPv6 transitiion scenario.  This document gives
   recommendation regarding how IPv6 FTP client should behave in 6to4
   scenario.

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 April 26, 2012.

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



Liu, et al.              Expires April 26, 2012                 [Page 1]

Internet-Draft    FTP consider for IPv4/IPv6 transition     October 2011


   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.  Conventions used in this document . . . . . . . . . . . . . . . 4
   3.  Client considerations . . . . . . . . . . . . . . . . . . . . . 4
   4.  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  . . . . . . . . . . . . . . . . . . . . . . . . 6


























Liu, et al.              Expires April 26, 2012                 [Page 2]

Internet-Draft    FTP consider for IPv4/IPv6 transition     October 2011


1.  Introduction

   Figure 1 illustrated the IPv6-IPv4 translation FTP scenario.

            +----------------------------------------------- -----+
            |                                                     |
            |                                                     |
            | +----------------+                 +--------------+ |
            | | IPv6 Network   |                 | IPv4 Network | |
            | | +-----------+  |  +-----------+  | +----------+ | |
            | | |IPv6       |--|--|Translation|--|-|IPv4      | | |
            | | |FTP Client |  |  |    Box    |  | |FTP Server| | |
            | | +-----------+  |  +-----------+  | +----------+ | |
            | |                |                 |              | |
            | +----------------+                 +--------------+ |
            |                                                     |
            |                                                     |
            +------------------------------------------------ ----+
                  Figure 1 IPv6-IPv4 translation FTP scenario.

                                 Figure 1

   The IPv6 FTP client situated in an IPv6 network and tries to
   communicate with an IPv4 server that situated in an IPv4 network
   through a translation box in the middle.

   It should be noted that in some scenario, the FTP client that running
   on the IPv6 host maybe legacy IPv4 FTP client.  Here "legacy IPv4 FTP
   client" refers to the FTP client software that only support IPv4.In
   this case, the communication will not succeed by only introducing
   translation box in the network.  That case is out the scope of this
   document.

   FTP has two operation modes: passive mode and active mode.  In
   passive mode, the server provides port used for the client to connect
   to.  In active mode, the server connects back to the client, using
   the IP address and port number which provide by the client.

   RFC 2428 specifies IPv6 extension of FTP.  Two new commands, EPRT/
   EPSV are specified.  The EPRT command is an extension of PORT, it
   could provide IPv6 address and port number to the server.  The EPSV
   command is an extension of PASV, when client sends this command, the
   server should responses its port number used for the client to
   connect.

   Many serves do not support EPSV command today, but most of them could
   support PASV mode.  This document provides guidelines and extensions
   for implementing IPv6 FTP client to avoid the problems when an IPv6



Liu, et al.              Expires April 26, 2012                 [Page 3]

Internet-Draft    FTP consider for IPv4/IPv6 transition     October 2011


   FTP client communicating with an IPv4 server through a 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 RFC 2119 [RFC2119].

   ALG: Application layer gateway


3.   Client considerations

   According to RFC 2428, the IPv6 client SHOULD support EPSV and EPRT
   command.  From the backward compatibility's perspective, this
   document suggests that the IPv6 FTP client SHOULD support both EPSV
   and PASV.  The reason is that during the early stage of IPv6
   transition, many FTP servers will be located in the IPv4 Internet
   which may not support EPSV command.  This requirement implies that
   the IPv6 FTP client supports both IPv4 and IPv6 protocol version.
   This requirement is reasonable since backward compatibility to IPv4
   is one of the basic requirements for any IPv6 applications especially
   in 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
   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 and port,
   then the FTP serve will continually to send TCP SYN to the victim
   host to try to establish data connection.  This kind of attack is
   recognized as FTP reflects attack. 2.  Passive mode of FTP may
   benefit when traverse firewalls or NAT. using passive mode also
   eliminate FTP ALG in the middle box.

   From the above analysis, it is suggested that FTP client SHOULD use
   passive mode instead of active mode whenever it is possible.  For
   IPv6 FTP client, according to RFC 2428, it should use EPSV command.

   In IPv4-IPv6 transition scenario, an IPv6 client may try to
   communicate with an IPv4 server.  In this case, the IPv4 server may
   not support EPSV command and the EPSV command may fail.  This
   document suggests that the IPv6 FTP client SHOULD retry with PASV
   command when EPSV command fails.  The IPv4 FTP server will respond to



Liu, et al.              Expires April 26, 2012                 [Page 4]

Internet-Draft    FTP consider for IPv4/IPv6 transition     October 2011


   PASV command with a message that contains an IPv4 address and port
   number of the FTP server that used for the client to connect to.  The
   client MUST ignores the IPv4 address provided in the response; it
   should use the control connection's IP address to connect to the
   server to establish the data connection.  The approach that simply
   ignoring PASV respond message's IP address and use control channel's
   IP address could not only simply the FTP client software's
   implementation but also can avoid the problems caused by using the
   IPv4 address that included in the response message.  For example, if
   the FTP client has a private IPv4 connection and a public IPv6
   connection, if it tries to use the IPv4 connection to establish data
   connection with the server, it will never succeed.  Another example
   is: in an IPv4 world if for example a PASV reply contains network
   address prefix, e.g. 192.168.0.0/16, which can happen if using
   encrypted communications and going though NAT and the server hasn't
   configured the "external" facing IP (And since the session is
   encrypted, NAT can't see the address to change it).  The client
   should identify this (and similar) wrong IPs and reuse the control
   connection's IP.


4.  Server considerations

   This document does not enforce any requirement for FTP server since
   this document considers the IPv6 FTP client communicating with IPv4
   FTP server scenario.  The IPv4 FTP server maybe just an ordinary IPv4
   FTP server.


5.  FTP ALG considerations

   This document argues that since FTP is a protocol that could avoid
   ALG by slightly adjusting the operation of the IPv6 FTP client it is
   not recommended the translation box to implement FTP ALG.

   Adjusting the operation of IPv6 client is feasible because IPv6 is
   not widely deployed and there are not much IPv6 FTP client deployed
   right now.  It is a good chance to give this guideline 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 April 26, 2012                 [Page 5]

Internet-Draft    FTP consider for IPv4/IPv6 transition     October 2011


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

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


6.  Security Considerations

   FTP security is discussed in RFC 2577 [RFC 2577].  The recommendation
   that is defined in this document will not impact FTP security.


7.  IANA Considerations

   None


8.  Acknowledgments

   The authors want to thanks the following people for their useful
   suggestions: Robert Oslin,Anthony Bryan,John C Klensin,Mykyta
   Yevstifeyev.


9.  References

9.1.  Normative References

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

9.2.  Informative References

   [FTP Security Considerations]
              M. Allman, "FTP Security Considerations", 1999,
              <http://tools.ietf.org/html/rfc2577>.

   [I-D.draft-ietf-behave-ftp64-11]
              I. van Beijnum, "An FTP ALG for IPv6-to-IPv4 translation",
              2011,
              <http://tools.ietf.org/html/draft-ietf-behave-ftp64-11>.








Liu, et al.              Expires April 26, 2012                 [Page 6]

Internet-Draft    FTP consider for IPv4/IPv6 transition     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


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

   Email: caozhen@chinamobile.com
























Liu, et al.              Expires April 26, 2012                 [Page 7]


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