[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
Behavior Engineering for Hindrance                          Dapeng Liu
                                                              Zhen Cao
Internet Draft                                            China Mobile
Intended status: Standards Track                         August 27, 2009
Expires: February 2010



                 IPv6 IPv4 translation FTP considerations
                       draft-liu-behave-ftp64-03.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 February 27, 2010               [Page 1]


Internet-Draft  IPv6 IPv4 translation FTP considerations August 2009


Abstract

   The File transfer protocol, which is defined by the RFC 959, is
   widely used. RFC 2428 define 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. There already have some work to address this
   problem, such as "draft-van-beijnum-behave-ftp64-05" etc, but this
   document provides a different approach.

Table of Contents


   1. Introduction................................................3
   2. Conventions used in this document............................4
   3. Client considerations........................................4
   4. Server considerations........................................4
   5. ALG considerations..........................................4
   6. Existing solutions and comparison............................5
   7. Security Considerations......................................6
   8. IANA Considerations.........................................6
   9. Acknowledgments.............................................6
   10. References.................................................6
      10.1. Normative References...................................6
      10.2. Informative References.................................7
   Author's Addresses.............................................7




















Dapeng Liu            Expires February 27, 2010               [Page 2]


Internet-Draft  IPv6 IPv4 translation FTP considerations August 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.

   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 connect 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, but most of them could
   support PASV mode (draft-van-beijnum-behave-ftp64-05). This document
   provides guidelines for client and server to avoid the problems that
   IPv6 FTP client communication with an IPv4 server through a
   translation box.







Dapeng Liu            Expires February 27, 2010               [Page 3]


Internet-Draft  IPv6 IPv4 translation FTP considerations August 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

   It is required that all IPv6 FTP clients MUST support both EPSV and
   PASV command.

   When the client tries to connect to a server using IPv6 connection,
   it should use EPSV command first. If the server response that it does
   not support this command or encounters an error, it MUST retry with
   PASV command. The server will respond to PASV command with an message
   that contains an IPv4 address and port number 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.

   This approach 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 success.

4. Server considerations

   All FTP servers MUST support EPSV and PASV command. All FTP severs
   MUST could respond with error message to EPSV command if it does not
   support it. The FTP sever MUST allow the client to retry with PASV
   command when it fails with EPSV command. Also, the server must allow
   the client to use the control connection's IP address to establish
   data connection when it retries with PASV command.

5. FTP ALG considerations

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.


Dapeng Liu            Expires February 27, 2010               [Page 4]


Internet-Draft  IPv6 IPv4 translation FTP considerations August 2009


   2) For most of current Network Processor based translation box, ALG
      processing may cause its performance decreased significantly. The
      reason is that FTP ALG processing can not take the advantage of
      Network Processor, which is designed and optimized for processing
      regular packets (such as header translation).

   3) From the evolution perspective, if the network continues to
      provide support of FTP ALG all the time, the users will have no
      motivation to upgrade their FTP client software. If things evolve
      toward this direction, the ALG function of the translation box
      will become more and more complex. In reality, upgrading FTP
      client software is a more easy way to solve the ALG issue
      compared with requiring that all the translation box to implement
      FTP ALG.

5.2. Solution to avoid FTP ALG

   This document suggests that the translation box which situated
   between the IPv6 network and IPv4 network should not implement FTP
   ALG. It is depend on the client and server that comply with this
   specification to avoid the FTP ALG issue.

   The reason that this document does not encourage translation box to
   implement FTP ALG is that since the FTP ALG problem can be totally
   avoid by defining the behavior of the client and server, it is not
   necessary to implement it at all. This approach can reduce the
   translation box's complexity. Also, the FTP client and server's
   communication without ALG will significantly improve its performance.

   For the legacy IPv6 FTP client, this document suggests that the
   legacy client should behave like RFC1579 recommendation which is that
   "vendors convert their FTP clients programs to use PASV instead of
   PORT". For IPv6 FTP client, this recommendation should be "the users
   or vendors should convert their FTP clients programs to use EPSV
   instead of EPRT". This can be done by configuration and do not
   require upgrading of the client software for most of current IPv6 FTP
   client. This solution may require that the FTP server should support
   EPSV command.

6. Existing solutions and comparison

   [I-D.draft-van-beijnum-behave-ftp64-05] provides a solution that
   addresses same problem as this document, the major differences
   between the two approaches are:

   1. ALG considerations of the translation box



Dapeng Liu            Expires February 27, 2010               [Page 5]


Internet-Draft  IPv6 IPv4 translation FTP considerations August 2009


   [I-D.draft-van-beijnum-behave-ftp64-05] does not speak out in favor
   or against the deployment of an FTP application layer gateway.
   However, this document specifies that the translation box should not
   implement FTP ALG.

   The main concern of not recommending ALG is that FTP ALG could
   dramatically decrease the performance of the translation box due to
   the stateful application layer processing. ALG could be avoided by
   the FTP client and server's implantation that complies with this
   document. The argument here is that it is much easier for the
   client/server software to upgrade than implementation of ALG in the
   translation box. Eliminating the ALG function in the translation box
   will simply the protocol operation and avoid unexpected errors.

   2. Behavior of FTP client when retrying with PASV command

   [I-D.draft-van-beijnum-behave-ftp64-05] recommends that the client
   should use the IPv4 address in the PASV response message if it has
   IPv4 connectivity and use the control connection's IP address if it
   does not have IPv4 connectivity. However, this document specifies
   that the client should use the control channel's IP address without
   determination whether it has IPv4 connectivity or not. This will
   simplify the client software, besides, if the client has IPv4
   connectivity, the control channel will use its IPv4 address instead
   of using its IPv6 address to connect to the IPv4 server.  This
   approach can avoid the problems that maybe caused by using the
   client's IPv4 connection as described in section 3.

7. Security Considerations

   TBD

8. IANA Considerations

   None

9. Acknowledgments

   TBD

10. References

10.1. Normative References

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



Dapeng Liu            Expires February 27, 2010               [Page 6]


Internet-Draft  IPv6 IPv4 translation FTP considerations August 2009


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

10.2. Informative References

   [1]  I.van Beijnum,"IPv6-to-IPv4 translation FTP considerations",
         July 13, 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 February 27, 2010               [Page 7]