Re: [BEHAVE] A New Draft on FTP64

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: liu dapeng [mailto:[e-mail]] 
> Sent: Thursday, August 27, 2009 10:12 AM
> To: Dan Wing
> Cc: [e-mail]; Iljitsch van Beijnum
> Subject: Re: [BEHAVE] A New Draft on FTP64
> 
> 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?

I agree.  But the problem is that the IPv6 FTP client doesn't know if 
the AAAA response is 'real' or was synthesized, so the FTP client
doesn't know if the FTP server is listening on IPv4 (and thus PASV
should work) or listening on IPv6 (and thus EPSV should work).

-d



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