Re: [BEHAVE] A New Draft on FTP64

[liu dapeng <[e-mail]>]

2009/8/27, Dan Wing <[e-mail]>:
>
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of liu dapeng
>> Sent: Wednesday, August 26, 2009 12:03 PM
>> To: Iljitsch van Beijnum
>> Cc: [e-mail]
>> Subject: Re: [BEHAVE] A New Draft on FTP64
>>
>> 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.
>
> That algorithm will cause a timeout -- not an error -- with some FTP
> servers.  For example, ftp.dell.com responds positively to EPSV but
> does not actually allow connecting to the port indicated on the FTP
> control channel.  Other sites, such as ftp.microsoft.com, work just
> fine with EPSV.
>
> Would it be better to just try PASV first (and for the data channel,
> the FTP client should use the IP address of the control channel,
> ignoring what is in the PASV response) and if *that* fails it means
> the FTP server is really listening on IPv6 and refuses to use PASV
> and wants EPSV, so you only use EPSV after PASV returns an error?

my question is: the server is in an IPv4 network, if the PASV fails,
why does it expect EPSV command?

> -d
>
>
>> 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.
>> >
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>
>