Subject: Re: [BEHAVE] Feedback requested:FTP ALG for IPv6-to-IPv4 translation

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 27 Apr 2009 15:06:21 +0200

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