[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feedback requested:FTP ALG for IPv6-to-IPv4 translation

[CC to behave list, trim behave or v6ops as required]

On 27 apr 2009, at 13:31, Rémi Denis-Courmont wrote:
This does not say how "EPSV ALL" is translated... You cannot let EPSV ALL 
go through if you translate later EPSV requests, as it would break
EPSV-capable FTP IPv4 servers. As such, I guess the ALG should accept the 
request and not forward it to the FTP server.
Not sure if issuing EPSV ALL would actually cause trouble if then PASV is issued, but just to be on the safe side and to avoid servers (or middleboxes) reacting badly to EPSV in general it's probably best to filter these out. Need to think about EPSV <protocol>, too. 


|  If the server's 227 response contains an IPv4 address that doesn't
| match the destination of the control channel, the FTP ALG SHOULD send 
|  the following response to the client:



|  425 Can't open data connection.



How common is this case? Shouldn't the ALG succeed, as it can do IPv4
address translation anyway?
It should be rare, because in this case the server asks to connect to a different host (or different address on the same host) to get the data than the address we're talking to for the control channel.
The problem is that the 229 response doesn't allow for an address. It would be possible to put it in there anyway, but I have no idea what the result of that would be. Alternatively, it would be possible to create a mapping from pref64::10.0.0.1 port 1234 to 10.0.0.2 port 1234 as a way to solve this, but that's very ugly and this way EPSV translation can't happen on just the control channel anymore. 


One thing that would be good to know is whether ALL IPv6 FTP clients
do EPSV or if there are also ones that do EPRT or, worse, active FTP
without issuing EPRT.
Not that I know. However, as the author of one popular piece of software 
that does include FTP functionality, I would like to mention that some
users explicitly requested active mode be added.
Right. Active mode with EPRT would work if that part is also implemented as described in the draft (EPRT is MAY, EPSV is SHOULD), but: 


Their rationale was that
it's better/easier for their client-side firewall to allow inbound traffic 
from TCP port 20 (ftp-data)
If port 20 is assumed and no EPSV or EPRT is issued, then there is no obvious way to correlate the incoming session on the v4 side to the v6 host, especially if multiple clients are talking to the same server at the same time. I think this is too nasty to bother with.