Subject: [BEHAVE] matching FTP control&data IPv4 addresses

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 May 2010 14:12:03 -0700

Section 4.2 of draft-ietf-behave-ftp64-03 discusses the issue where the IPv4
address of the data connection differs from the control connection:

  "For instance, if the client issues EPSV (or EPSV 2 to indicate IPv6
   as the network protocol), this is translated to the PASV command.  If
   the server with address 192.0.2.31 then responds with:

      227 Entering Passive Mode (192,0,2,31,237,19)

   The FTP ALG reformats this as:

      229 Entering Extended Passive Mode (|||60691|)

   The ALG SHOULD ignore the IPv4 address in the server's 227 response.
   This is the behavior that is exhibited by most clients and is needed
   to work with servers that include [RFC1918] addresses in their 227
   responses.  However, if the 227 response contains an IPv4 address
   that does not match the destination of the control channel, the FTP
   ALG MAY send the following response to the client instead of the 229
   response:

      425 Can't open data connection."

This done because the syntax of the EPSV command prevents the IPv4 data
connection's IP address from being communicated back to the IPv6 FTP client.
That is all understood and goodness.

However, we could make that scenario work.

To do so, the FTP64 ALG would have to be running on a stateful NAT64 (not a
stateless NAT64), and would have to map the IPv6 data connection to the IPv4
data connection indicated by PASV.  This seems it might be useful to discussed
in the I-D.  I think we don't want to require it of implementations because it
occurs infrequently.

Thoughts if we should add some text discussing it?  Or just leave as-is?

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 May 2010 23:32:00 +0200

> Thoughts if we should add some text discussing it?  Or just leave as-is?

I believe the only example we have of FTP servers that list an IPv4 address in the 227 response that isn't the destination of the control channel session is the case of FTP servers behind NAT, where actually trusting the address in the 227 response leads to failure...

We could point all of this out explicitly, though.

Iljitsch

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 May 2010 14:55:03 -0700

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Wednesday, May 19, 2010 2:32 PM
> To: Dan Wing
> Cc: IETF BEHAVE WG
> Subject: Re: [BEHAVE] matching FTP control&data IPv4 addresses
> 
> I believe the only example we have of FTP servers that list 
> an IPv4 address in the 227 response that isn't the 
> destination of the control channel session is the case of FTP 
> servers behind NAT, where actually trusting the address in 
> the 227 response leads to failure...

So you're saying v4 data connections would fail.

> We could point all of this out explicitly, though.

Yes, seems worth a sentence pointing out that the v4 data
connection would likely fail, so no need to attempt to make
the v6 data connection work.

-d