Re: [BEHAVE] A New Draft on FTP64

[liu dapeng <[e-mail]>]

2009/8/25, Iljitsch van Beijnum <[e-mail]>:
> On 24 aug 2009, at 19:40, liu dapeng wrote:
>
>> We upgrade the ftp64 draft, add some text considering the legacy FTP
>> implementation and other clarification as well. Any comments are
>> welcomed.
>
> Can you please send the new text to the list?

we upgrade setion 3 and 5, bellow is the text.

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.


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.


> A client that implements the client requirements and client
> recommendations listed in draft-van-beijnum-behave-ftp64-05 will be
> able to successfully interoperate with any server that implements EPSV
> or PASV through a stateful or stateless translator.

The solution in draft-van-beijnum-behave-ftp64-05 suggests that
"However, the server will respond to the PASV command with an IPv4
address that the client must use to connect to for the data
connection.  If the client has IPv4 reachability, it SHOULD set up a
data connection towards the IPv4 address." this may can not work in
some cases, as   draft-liu-behave-ftp64-02 mentioned:'" 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."


Since updating an
> FTP client is about the easiest possible upgrade that we could
> possibly require (an FTP client doesn't need special privileges and
> can run as a java applet in a browser) this provides a workable
> solution for most users.

aggree, this is what draft-liu-behave-ftp64-02 suggested.

> However, there is additional benefit in making FTP through a
> translator work for users with existing implementations, which can be
> accomplished by either server upgrades or an ALG.

Do not you think that server upgrading may be more reasonable from the
evolution perspective? if the network contitue to provide ALG all the
time, the server will never has motivation to upgrade, this will cause
the ALGs in the translation box become more and more complex, since
the translator will try to maintain ALGs for all the legacy
implementations; and the legacy implementation never think about
upgrading because they never aware the needs to upgrade. this approach
may be convenient for a little part of the users but is harmful for
the evolution of the network.

> Since at least one vendor has expressed interest in implementing such
> an ALG, having standard ALG functionality is better than undefined ALG
> functionality and we have the text now anyway, in my opinion it
> doesn't make sense to remove the ALG text, although I'm willing to
> make it (even) more clear that such an ALG is optional.

In my personal opioion, If the we do not recommend to implement FTP
ALG, maybe we should not include any text to describe how to implement
it for not misleading the reader. but maybe the text of ALG could be
adjusted as an appendix, then there will be no contradiction.
>