Behavior Engineering for Hindrance                               D.Liu
                                                                 Z.Cao
Internet Draft                                            China Mobile
Intended status: Standards Track                        October 27, 2009
Expires: April 2010



                 IPv6 IPv4 translation FTP considerations
                       draft-liu-behave-ftp64-04.txt


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

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February, 2010.

   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 (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your
   rights and restrictions with respect to this document.








Dapeng Liu             Expires April 27, 2010                 [Page 1]


Internet-Draft  IPv6 IPv4 translation FTP considerations October 2009


Abstract

   The File transfer protocol, which is defined by the RFC 959, has a
   long history, but still widely used today. The original version of
   FTP specification defines IPv4 FTP which means it assumes the IP
   version is IPv4. RFC 2428 defines IPv6 extensions of FTP, introducing
   EPRT and EPSV command.

   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 gives guidelines for the FTP
   client, server and the translation box to ensue FTP working properly
   in the IPv4-IPv6 transition scenario.

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
      5.2. FTP ALG consideration...................................6
   6. Security Considerations......................................7
   7. IANA Considerations.........................................7
   8. Acknowledgments.............................................7
   9. References..................................................7
      9.1. Normative References....................................7
      9.2. Informative References..................................7
   Author's Addresses.............................................8

















Dapeng Liu             Expires April 27, 2010                 [Page 2]


Internet-Draft  IPv6 IPv4 translation FTP considerations October 2009


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.

   The IPv6 FTP client situated in an IPv6 network and tries to
   communicate with an IPv4 server that situated in an IPv4 network
   using 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. 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 issue 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 for client and
   server to avoid the problems when an IPv6 FTP client communicating
   with an IPv4 server through a translation box.



Dapeng Liu             Expires April 27, 2010                 [Page 3]


Internet-Draft  IPv6 IPv4 translation FTP considerations October 2009


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.

3. Client considerations

   According to RFC 2428, the IPv6 client SHOULD support EPSV and EPRT
   command. Furthermore, it specifies that when the control and data
   connections are being established between the same tow machines, the
   EPSV command MUST be used. 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.

   Normally, there are two kinds of FTP clients: the dedicated FTP
   client software and FTP client the embedded in other applications.
   For example, gftp is a kind of dedicated ftp client software that
   running on Linux. Conversely, IE also could be used as FTP client,
   but it belongs to FTP client embedded in other application.

   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.

   As an exception, IE uses active mode in default. But IE can be
   configured to use passive mode.

   From the above analysis, it is suggested that FTP client SHOULD use
   passive mode instead of active mode. For IPv6 FTP client, according
   to RFC 2428, it should use EPSV command. In the IPv4-IPv6 transition
   scenario, an IPv6 client may try to communicate with an IPv4 server.


Dapeng Liu             Expires April 27, 2010                 [Page 4]


Internet-Draft  IPv6 IPv4 translation FTP considerations October 2009


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

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
      packets. ALG could also cause the decline of the translation
      box's performance.




Dapeng Liu             Expires April 27, 2010                 [Page 5]


Internet-Draft  IPv6 IPv4 translation FTP considerations October 2009


   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.

5.2. FTP ALG consideration

   Although this document does not recommend implementing FTP ALG in the
   translation box but in some exceptional scenario the operator may
   want to deploy FTP ALG in their translation box for special purpose,
   this document also gives guidelines for FTP ALG implementation in t
   IPv6-IPv4 translation box.

   1. Passive mode

   In passive mode, the IPv6 FTP client may send EPSV which may not
   recognized by the IPv4 FTP server. The FTP ALG may translate EPSV to
   PASV and the corresponding response messages should also be
   translated.

   2. Active mode

   For active mode, the IPv6 FTP client may issue EPRT command which
   contains the client's IPv6 address and port number that used for the
   server to connect. The FTP ALG should translate EPRT command to PORT
   command. The FTP ALG should translate the client's IPv6 address to
   the corresponding IPv4 address. The IPv6-IPv4 mapping maybe created
   by the translation box during the initiating of FTP connection in
   statefull translation mode. In stateless translation mode, there is
   no need to create mapping dynamically. If the translation box using
   port multiplexing, the port number in the EPRT command should also be
   translated.

   3. Default connection port

   According to RFC 959 if no EPSV or EPRT command issued, the server
   may connects to the client's control connection's port use source
   port 20. The FTP ALG should intercept this TCP connection and
   translate the corresponding port number if translation box translates
   the IPv6-IPv4 port number.

   4. The control connection and data connection belongs to different
      machines

   The FTP protocol can support the scenario that the control connection
   and data connection belongs to different machines. The FTP ALG
   function of current version of this document does not address this
   scenario.


Dapeng Liu             Expires April 27, 2010                 [Page 6]


Internet-Draft  IPv6 IPv4 translation FTP considerations October 2009




6. Security Considerations

   TBD

7. IANA Considerations

   None

8. Acknowledgments

   TBD

9. References

9.1. Normative References

   [RFC959]  J. Postel,J.Reynolds, "File Transfer Protocol(FTP)",October
             1985

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

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

   [RFC1579] S.Bellovin, "Firewall-Friendly FTP", February 1994.

9.2. Informative References

   [1]  I.van Beijnum,"IPv6-to-IPv4 translation FTP considerations",
         July 13, 2009.















Dapeng Liu             Expires April 27, 2010                 [Page 7]


Internet-Draft  IPv6 IPv4 translation FTP considerations October 2009


Author's Addresses

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

   Phone: (8610)13911788933
   Email: liudapeng@chinamobile.com

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

   Phone: (8610)15120015799
   Email: caozhen@chinamobile.com































Dapeng Liu             Expires April 27, 2010                 [Page 8]