Subject: [BEHAVE] FTP64 ALG: how to proceed?

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 3 May 2009 16:26:47 +0200

Hi,

I got some feedback from Barry Leiba and John Klensin about the FTP  
ALG for IPv6-to-IPv4 translation. The comments don't really address  
what's in the draft, but rather the idea of having an FTP ALG in the  
first place. They really don't like it. John feels it's a better idea  
to update clients and servers rather than put ALGs in the middle. I'm  
afraid they, and perhaps others, will speak up during IETF last call.  
The fact that the behave charter says to stay away from ALGs probably  
won't help at that point.

Apart from that, there's the question of how much complexity for the  
sake of completeness we want to have in an FTP ALG.

Basically, we have four options at this point:

1. Take this feeback to heart and forego the ALG. This means that the  
only thing that will work is EPSV mode, which a large majority of  
clients use and about half of the servers.

2. Do a very minimalist/simple ALG. This would be translating all EPSV  
to PASV, which is compatible with (almost?) all servers and most  
clients. (See [1].)

3. Do a more complete ALG that handles EPSV and "normal" EPRT use, and  
let other EPRT use through transparently. This should work with pretty  
much all clients.

4. Try to be as complete as possible and cover all exceptional cases  
that can be covered. This is what http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-02 
  tries to do.

 From the feedback I've gotten, I think 4 is the wrong way to go  
because it makes the ALG relatively complex and because clients trying  
to do more complex stuff (set up control channels to two servers and  
instruct one to send and the other to receive so the data flows  
between the two servers) could fail because of the ALG double guessing  
what they're trying to do.

If anyone has any opinions, please let me know.

Iljitsch

[1] there is a possible corner case of servers that instruct the  
client to connect to a different address for the data than for the  
control channel. I think this is extremely rare because it requires  
the server to have multiple addresses and the server software to know  
about this and handle it properly. Also, EPSV doesn't support this so  
a server implementing EPSV would have to have different behaviors for  
EPSV and PASV without any obvious benefit for the different PASV  
behavior.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 3 May 2009 10:43:34 -0400

> If anyone has any opinions, please let me know.

To me, the whole point of this effort is to do _something_ for users
to kludge up usable communications between v4 and c6 networks, and
_not_ to make the networks really interoperate.  If I have the right
idea about that, then it seems like the answer we can quite plausibly
give to people for whom FTP doesn't work is, "You need to use
[client|server] $FOO instead."  I know that won't be popular with
everyone.  I don't think we can reasonably expect to solve all the
problems, and I don't think we should try.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 3 May 2009 16:48:27 +0200

> problems, and I don't think we should try.

So you're in favor of option 1, no ALG?

I'm with you with regard to the client part, but if you need to  
download a driver from ftp.lexmark.com or some such, I don't think the  
advice to upgrade the FTP server is going to be very helpful...

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 3 May 2009 11:41:21 -0400

> So you're in favor of option 1, no ALG?

Yes.

> I'm with you with regard to the client part, but if you need to download 
> a driver from ftp.lexmark.com or some such, I don't think the advice to 
> upgrade the FTP server is going to be very helpful...

To me, that's an opportunity to allow market forces to work: as soon
as I can't get my driver, I contact their support people.  Support costs
money.  Quickly, the cost of that will add up & supporting v6-only
users will become important, at which point I'd rather them think, "We
need to deploy on v6," than, "We need to add some more kludges."

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 3 May 2009 09:09:17 -0700

> > So you're in favor of option 1, no ALG?

So am I. As Iljitsch mentioned, most FTP clients support the EPSV mode already. They have to, because they are bound to encounter networks with no FTP ALG. The same pressure will force servers to upgrade.

Less ALG is generally a good thing, which is a reason for not publishing another ALG spec.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 3 May 2009 18:19:10 +0200

> So am I. As Iljitsch mentioned, most FTP clients support the EPSV  
> mode already. They have to, because they are bound to encounter  
> networks with no FTP ALG. The same pressure will force servers to  
> upgrade.

Well, let me point out that even in the Windows 7 beta the command  
line FTP client doesn't support EPSV. It will do PORT (IPv4) or EPRT  
(IPv6). These can't work through neither NAT nor NAT64 nor SIIT  
without an ALG.

However, it is of course not that hard to find an FTP client for  
Windows that will do EPSV. (And ftp.microsoft.com supports EPSV over  
IPv4.)

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 3 May 2009 12:16:37 -0600

I rather see us do things along the lines of EPSV to fix FTP instead  
of putting an ALG in the NAT.

Cullen <as individual contributor>

On May 3, 2009, at 8:26 AM, Iljitsch van Beijnum wrote:

> first place. They really don't like it. John feels it's a better  
> idea to update clients and servers rather than put ALGs in the  
> middle. I'm afraid they, and perhaps others, will speak up during  
> IETF last call. The fact that the behave charter says to stay away  
> from ALGs probably won't help at that point.
>
> 1. Take this feeback to heart and forego the ALG. This means that  
> the only thing that will work is EPSV mode, which a large majority  
> of clients use and about half of the servers.
>
> 2. Do a very minimalist/simple ALG. This would be translating all  
> EPSV to PASV, which is compatible with (almost?) all servers and  
> most clients. (See [1].)
>
> 3. Do a more complete ALG that handles EPSV and "normal" EPRT use,  
> and let other EPRT use through transparently. This should work with  
> pretty much all clients.
>
> because it makes the ALG relatively complex and because clients  
> trying to do more complex stuff (set up control channels to two  
> servers and instruct one to send and the other to receive so the  
> data flows between the two servers) could fail because of the ALG  
> double guessing what they're trying to do.
>
> the server to have multiple addresses and the server software to  
> know about this and handle it properly. Also, EPSV doesn't support  
> this so a server implementing EPSV would have to have different  
> behaviors for EPSV and PASV without any obvious benefit for the  
> different PASV behavior.
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 03 May 2009 20:31:16 +0200

Hi,

If i recall correctly, the comments expressed during the last meeting 
was that an FTP ALG was needed.

I think we have reached a good tradeoff basically defining the FTP ALG 
in a separate RFC than the basic NAT spec.
This allows to be compliant with the NAT spec wihtou having to implement 
any ALG, but also allows vendors that will implement an FTP ALG to 
obtain guidance.

So, i would suggest to have the FTP ALG be defined but in a separated 
document.

Regards, marcelo

Iljitsch van Beijnum escribió:
> that can be covered. This is what 
> http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-02 tries to do.
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 3 May 2009 21:45:00 +0200

> of putting an ALG in the NAT.

Would an informational document that explains the following be  
reasonable?

1. That server operators should support EPSV over IPv4
2. That clients should use EPSV rather than EPRT
3. What an FTP ALG should do in the case !(1 && 2)

This would give implementers who feel they need to offer an FTP ALG  
(which I'm sure will be most of them) guidance without explicitly  
endorsing ALGs and may get (some) client/server vendors and operators  
to upgrade.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 3 May 2009 19:08:33 -0600

I'm a little confused on how a v6 client, going though a nat64, to a  
v4 server that supports ESPV, is going to work. I was under the  
impression that it did not work and we needed to add a XSPV comment  
(Extra Extended Passive Mode)

On May 3, 2009, at 1:45 PM, Iljitsch van Beijnum wrote:

>> I rather see us do things along the lines of EPSV to fix FTP  
>> instead of putting an ALG in the NAT.
>
> endorsing ALGs and may get (some) client/server vendors and  
> operators to upgrade.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 4 May 2009 09:00:13 +0200

> (Extra Extended Passive Mode)

Unfortunately I don't have access to a NAT64 (I guess I could try with  
TRT if I really want) but here's a tcpdump of doing this over v4.

EPSV command on control channel:

08:52:20.597609 IP 192.168.2.4.57044 > 192.87.102.42.ftp: P 35:41(6)  
ack 732 win 65535 <nop,nop,timestamp 795345964 1628501846>
	0x0000:  4510 003a 3e72 4000 4006 130e c0a8 0204  E..:>r@.@.......
	0x0010:  c057 662a ded4 0015 7797 130e cee0 f60d  .Wf*....w.......
	0x0020:  8018 ffff 2d57 0000 0101 080a 2f68 042c  ....-W....../h.,
	0x0030:  6110 f756 4550 5356 0d0a                 a..VEPSV..

Server gives us port 63483, note that there is no address mentioned:

08:52:20.796189 IP 192.87.102.42.ftp > 192.168.2.4.57044: P  
732:780(48) ack 41 win 46 <nop,nop,timestamp 1628516058 795345964>
	0x0000:  4500 0064 1910 4000 2d06 4b56 c057 662a  E..d..@.-.KV.Wf*
	0x0010:  c0a8 0204 0015 ded4 cee0 f60d 7797 1314  ............w...
	0x0020:  8018 002e 7cca 0000 0101 080a 6111 2eda  ....|.......a...
	0x0030:  2f68 042c 3232 3920 456e 7465 7269 6e67  /h.,229.Entering
	0x0040:  2045 7874 656e 6465 6420 5061 7373 6976  .Extended.Passiv
	0x0050:  6520 4d6f 6465 2028 7c7c 7c36 3334 3833  e.Mode.(|||63483
	0x0060:  7c29 0d0a                                |)..
08:52:20.796267 IP 192.168.2.4.57044 > 192.87.102.42.ftp: . ack 780  
win 65535 <nop,nop,timestamp 795345965 1628516058>
	0x0000:  4510 0034 957d 4000 4006 bc08 c0a8 0204  E..4.}@.@.......
	0x0010:  c057 662a ded4 0015 7797 1314 cee0 f63d  .Wf*....w......=
	0x0020:  8010 ffff 9b5a 0000 0101 080a 2f68 042d  .....Z....../h.-
	0x0030:  6111 2eda                                a...

Client opens a new session towards port 63483 on the server:

08:52:20.796621 IP 192.168.2.4.57045 > 192.87.102.42.63483: S  
973991351:973991351(0) win 65535 <mss 1460,nop,wscale  
2,nop,nop,timestamp 795345965 0,sackOK,eol>
	0x0000:  4500 0040 b87e 4000 4006 990b c0a8 0204  E..@.~@.@.......
	0x0010:  c057 662a ded5 f7fb 3a0d edb7 0000 0000  .Wf*....:.......
	0x0020:  b002 ffff 1ba6 0000 0204 05b4 0103 0302  ................
	0x0030:  0101 080a 2f68 042d 0000 0000 0402 0000  ..../h.-........
08:52:21.221670 IP 192.87.102.42.63483 > 192.168.2.4.57045: S  
3496582725:3496582725(0) ack 973991352 win 5792 <mss  
1460,sackOK,timestamp 1628516273 795345965,nop,wscale 7>
	0x0000:  4500 003c 0000 4000 2d06 648e c057 662a  E..<..@.-.d..Wf*
	0x0010:  c0a8 0204 f7fb ded5 d069 9e45 3a0d edb8  .........i.E:...
	0x0020:  a012 16a0 1683 0000 0204 05b4 0402 080a  ................
	0x0030:  6111 2fb1 2f68 042d 0103 0307            a././h.-....
08:52:21.221749 IP 192.168.2.4.57045 > 192.87.102.42.63483: . ack 1  
win 65535 <nop,nop,timestamp 795345970 1628516273>
	0x0000:  4500 0034 8e0d 4000 4006 c388 c0a8 0204  E..4..@.@.......
	0x0010:  c057 662a ded5 f7fb 3a0d edb8 d069 9e46  .Wf*....:....i.F
	0x0020:  8010 ffff 5bea 0000 0101 080a 2f68 0432  ....[......./h.2
	0x0030:  6111 2fb1                                a./.

LIST command on the control channel:

08:52:21.221842 IP 192.168.2.4.57044 > 192.87.102.42.ftp: P 41:47(6)  
ack 780 win 65535 <nop,nop,timestamp 795345970 1628516058>
	0x0000:  4510 003a bb64 4000 4006 961b c0a8 0204  E..:.d@.@.......
	0x0010:  c057 662a ded4 0015 7797 1314 cee0 f63d  .Wf*....w......=
	0x0020:  8018 ffff ee9f 0000 0101 080a 2f68 0432  ............/h.2
	0x0030:  6111 2eda 4c49 5354 0d0a                 a...LIST..

ACK on the control channel:

08:52:21.351310 IP 192.87.102.42.ftp > 192.168.2.4.57044: P  
780:819(39) ack 47 win 46 <nop,nop,timestamp 1628516616 795345970>
	0x0000:  4500 005b 1911 4000 2d06 4b5e c057 662a  E..[..@.-.K^.Wf*
	0x0010:  c0a8 0204 0015 ded4 cee0 f63d 7797 131a  ...........=w...
	0x0020:  8018 002e 83a6 0000 0101 080a 6111 3108  ............a.1.
	0x0030:  2f68 0432 3135 3020 4865 7265 2063 6f6d  /h.2150.Here.com
	0x0040:  6573 2074 6865 2064 6972 6563 746f 7279  es.the.directory
	0x0050:  206c 6973 7469 6e67 2e0d 0a              .listing...
08:52:21.351386 IP 192.168.2.4.57044 > 192.87.102.42.ftp: . ack 819  
win 65535 <nop,nop,timestamp 795345971 1628516616>
	0x0000:  4510 0034 0139 4000 4006 504d c0a8 0204  E..4.9@.@.PM....
	0x0010:  c057 662a ded4 0015 7797 131a cee0 f664  .Wf*....w......d
	0x0020:  8010 ffff 98f9 0000 0101 080a 2f68 0433  ............/h.3
	0x0030:  6111 3108                                a.1.

Server sends data on the port 63483 session:

08:52:21.352057 IP 192.87.102.42.63483 > 192.168.2.4.57045: P  
1:383(382) ack 1 win 46 <nop,nop,timestamp 1628516617 795345970>
	0x0000:  4500 01b2 af41 4000 2d06 b3d6 c057 662a  E....A@.-....Wf*
	0x0010:  c0a8 0204 f7fb ded5 d069 9e46 3a0d edb8  .........i.F:...
	0x0020:  8018 002e d646 0000 0101 080a 6111 3109  .....F......a.1.
	0x0030:  2f68 0432 6c72 7778 7277 7872 7778 2020  /h.2lrwxrwxrwx..
	0x0040:  2020 3120 3020 2020 2020 2020 2035 3039  ..1.0........509
	0x0050:  2020 2020 2020 2020 2020 2020 2031 204e  .............1.N
	0x0060:  6f76 2030 3820 2032 3030 3720 6674 7020  ov.08..2007.ftp.
	0x0070:  2d3e 202e 0d0a 6c72 7778 7277 7872 7778  ->....lrwxrwxrwx
	0x0080:  2020 2020 3120 3020 2020 2020 2020 2030  ....1.0........0
	0x0090:  2020 2020 2020 2020 2020 2020 2020 2033  ...............3
	0x00a0:  204f 6374 2031 3220 2032 3030 3720 6d69  .Oct.12..2007.mi
	0x00b0:  7272 6f72 202d 3e20 7075 620d 0a6c 7277  rror.->.pub..lrw
	0x00c0:  7872 7778 7277 7820 2020 2031 2030 2020  xrwxrwx....1.0..

[...]

08:52:21.352842 IP 192.168.2.4.57045 > 192.87.102.42.63483: F 1:1(0)  
ack 384 win 65535 <nop,nop,timestamp 795345971 1628516617>
	0x0000:  4508 0034 c545 4000 4006 8c48 c0a8 0204  E..4.E@.@..H....
	0x0010:  c057 662a ded5 f7fb 3a0d edb8 d069 9fc5  .Wf*....:....i..
	0x0020:  8011 ffff 5911 0000 0101 080a 2f68 0433  ....Y......./h.3
	0x0030:  6111 3109                                a.1.

On the control channel, the server says it's done with sending

08:52:21.406775 IP 192.87.102.42.ftp > 192.168.2.4.57044: P  
819:843(24) ack 47 win 46 <nop,nop,timestamp 1628516667 795345970>
	0x0000:  4500 004c 1912 4000 2d06 4b6c c057 662a  E..L..@.-.Kl.Wf*
	0x0010:  c0a8 0204 0015 ded4 cee0 f664 7797 131a  ...........dw...
	0x0020:  8018 002e d2ff 0000 0101 080a 6111 313b  ............a.1;
	0x0030:  2f68 0432 3232 3620 4469 7265 6374 6f72  /h.2226.Director
	0x0040:  7920 7365 6e64 204f 4b2e 0d0a            y.send.OK...

As you can see, nothing here that wouldn't work through an IPv6->IPv4  
translator.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 4 May 2009 10:16:12 +0300

Cullen,

> (Extra Extended Passive Mode)

No. Tomorrow's NAT64 is no different than today's NAT44 with respect to EPSV. 
EPSV only conveys the server-side port number in the control channel. I expect 
that NAT64 will not change server-side port numbers, but rather IP addresses 
and client-side port numbers.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 4 May 2009 07:08:22 -0600

Thanks - I went and reread 2428 - I was confused and thought it only  
applied to v6 clients. I see what you mean.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 May 2009 13:27:58 -0400

> 3. What an FTP ALG should do in the case !(1 && 2)

I'm not opposed to that, FWIW.  I think there's a difference between
saying, "Here's how to do _x_," and, "We don't think you should _x_,
but if you're going to anyway please do it like this."  Indeed, the
failure to do the latter is how we got so many bad NATs in the first
place.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 4 May 2009 10:41:53 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Sunday, May 03, 2009 6:09 PM
> To: Iljitsch van Beijnum
> Cc: Behave WG
> Subject: Re: [BEHAVE] FTP64 ALG: how to proceed?
> 
> 
> v4 server that supports ESPV, is going to work.

In response to the EPSV command the IPv4 FTP server only returns
a port number.  From RFC2428:

   The first two fields contained in the parenthesis MUST be blank.  The
   third field MUST be the string representation of the TCP port number
   on which the server is listening for a data connection.  The network
   protocol used by the data connection will be the same network
   protocol used by the control connection.  In addition, the network
   address used to establish the data connection will be the same
   network address used for the control connection.  An example response
   string follows:

        Entering Extended Passive Mode (|||6446|)

so the IPv6-capable FTP client should be fine with receiving that -- it 
will connect to the same (synthetic) IPv6 address as the control channel
which is listening on the indicated TCP port.

-d

> I was under the

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 May 2009 15:56:16 -0700

> first place. They really don't like it. John feels it's a 
> better idea to update clients and servers rather than put ALGs 
> in the middle. 

Without an FTP-ALG the IPv6 FTP client would need to support IPv4's PASV and
would also need to know the IPv6 prefix of its IPv6 translator
(draft-wing-behave-learn-prefix).  There have been objections raised to doing
that in the past, specifically that it puts too much IPv6/IPv4 interworking
knowledge into the application:

   http://www.ietf.org/mail-archive/web/behave/current/msg04129.html

   "...
    I think the draft-jennings-behave-nat6 approach has the negative
    characteristic of importing NAT-related issues into IPv6-related
    code, and that is something we want to avoid if we can."

Perhaps the winds have changed.   I would certainly like to hear from everyone
on this issue, as we are getting close to submitting an updated charter and
updated milestones.

Based on my tests about 34% of FTP sites do not support EPSV.  When lucky, the
lack of support causes an immediate 5xx response on the control channel.  When
unlucky, the lack of support causes a long delay and eventual failure to
establish the data channel.  My test used a list of anonymous FTP sites from
2003.  From that list, I successfully did PASV directory listings with 2491
FTP servers.  Of those, 1626 (65%) correctly handled EPSV; 865 (34%) did not
support EPSV.  My Perl code (which is not very good) and test results are at
ftp://ftpeng.cisco.com/dwing/ftp-epsv.

> I'm afraid they, and perhaps others, will speak 
> up during IETF last call.  
> The fact that the behave charter says to stay away from ALGs 
> probably won't help at that point.

The charter does have an escape clause,

  "ALGs may be considered only for the most crucial of legacy applications."

FTP certainly qualifies as a legacy application.  It's a subjective decision
if 28% of FTP sites are 'crucial', and subjective if requiring IPv6 FTP
applications to support PASV and to learn the prefix of their IPv6 translator
is better than an ALG.

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 May 2009 01:44:58 +0200

> knowledge into the application:

Right. So let's cheat. We already have a session towards the server,  
what if we simply assume that the address in the PASV response can be  
reached through the address we're using for the data channel?

If we get to assume that the v4 address is always in the bottom 32  
bits we can even accommodate the corner case where the control channel  
goes to one address and the data connection to another by plugging the  
32 bits from the PASV response into the lower 32 bits and copying the  
upper 96 bits from the control channel destination.

> When
> establish the data channel.

Can you test again with the following:

EPSV
try to set up data channel
   if not successful within 5 seconds, time out and:
     send ABOR
     retry with PASV

If that works, we have a procedure for clients to work with all FTP  
servers out there without requiring an ALG. (Did you check if any  
servers allowed you to log in but didn't handle PASV successfully?)

In that case the question is: what's more reasonable, requiring  
everyone who wants to use FTP through a NAT64 or SIIT(bis) to upgrade  
their client software, or having an ALG. Note that a quick "java ftp  
client" search returns a good number of results. People could run such  
a client from their browser.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 May 2009 16:48:08 -0700

> [mailto:[email-masked]] On Behalf Of Christian Huitema
> Sent: Sunday, May 03, 2009 9:09 AM
> To: Andrew Sullivan; [email-masked]
> So am I. As Iljitsch mentioned, most FTP clients support the 
> EPSV mode already.

Hopefully those clients send just plain "EPSV" and not "EPSV 2".  I checked
Firefox 3.5b4 (source is easy to get) and it does send plain "EPSV".

-d

> They have to, because they are bound to 
> encounter networks with no FTP ALG. The same pressure will 
> force servers to upgrade.
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 May 2009 18:02:45 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Wednesday, May 06, 2009 4:45 PM
> To: Dan Wing
> Cc: 'Behave WG'
> > Without an FTP-ALG the IPv6 FTP client would need to 
> support IPv4's  
> > PASV and
> > (draft-wing-behave-learn-prefix).  There have been 
> objections raised  
> > to doing
> If that works,

It works some places and not others.  For example I did the following with the
FTP server
at ftp.dell.com:

  230 Anonymous user logged in.
  EPSV
  229 Entering Extended Passive Mode (|||2067|)
  LIST

I waited a few seconds, then continued:

  ABOR
  225 ABOR command successful.

That 225 came back immediately.  

  PASV
  425 Can't open data connection.
  PASV

It then disconnected the control channel.

With other FTP servers, the response to ABOR didn't come back immediately.
For example, with both ftp.nlm.nih.gov and ftp.rsa.com (two sites which give
timeouts with EPSV, probably due to incorrectly configured firewalls):

  230 Anonymous access granted, restrictions apply.
  EPSV
  229 Entering Extended Passive Mode (|||15296|)
  LIST
  ABOR

The ABOR command did not receive a response after one minute.

> we have a procedure for clients to work with all FTP  

Yes.  Of the list of about 5000 anonymous FTP sites in 2003, 107 of them
accepted anonymous logins but didn't give a directory listing using PASV.  You
can get a list of those by downloading
ftp://ftpeng.cisco.com/dwing/ftp-epsv/ftp-site-list.log and then doing:

  grep "PASV: " ftp-site-list.log | grep -v "PASV: Ok"

Output is below.

-d

> client" search returns a good number of results. People could 
> run such a client from their browser.

-----

alge.anart.no             PASV: Timeout EPSV: 000    01:53
cs.isa.ac.ru              PASV: Timeout EPSV: 000    02:23
ftp.academ.com            PASV: Timeout EPSV: 000    01:51
ftp.antivir.ru            PASV: Timeout EPSV: 000    01:54
ftp.arcetri.astro.it      PASV: Timeout EPSV: 000    01:53
ftp.batol.net             PASV: Timeout EPSV: 000    01:53
ftp.battlefront.com       PASV: Timeout EPSV: 550 Permission denied.   00:02
ftp.bbbs.net              PASV: Timeout EPSV: 450 Not connected.   00:23
ftp.bcs.zp.ua             PASV: Timeout EPSV: 000    02:02
ftp.blizzard.com          PASV: Timeout EPSV: 425 Can't open data connection.
00:25
ftp.buguruslan.ru         PASV: Timeout EPSV: 425 Can't open data connection.
00:29
ftp.cert.fr               PASV: 500 'PASV': command not understood. EPSV: 500
'E
PSV': command not understood.   00:03
ftp.chd.lv                PASV: Timeout EPSV: 425 Can't open data connection.
00:23
ftp.ci.tuwien.ac.at       PASV: Timeout EPSV: 000    02:04
ftp.combatmission.com     PASV: Timeout EPSV: 550 Permission denied.   00:02
ftp.cps.unizar.es         PASV: Timeout EPSV: 000    01:53
ftp.crashrecovery.org     PASV: Timeout EPSV: 000    02:23
ftp.cs.ualberta.ca        PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:01
ftp.cs.umn.edu            PASV: Timeout EPSV: 000    01:58
ftp.cyberglobe.net        PASV: Timeout EPSV: 000    01:34
ftp.dfn.de                PASV: Timeout EPSV: 000    01:54
ftp.dialognauka.ru        PASV: Timeout EPSV: 000    01:53
ftp.dials.ru              PASV: Timeout EPSV: 000    01:56
ftp.digimark.net          PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:02
ftp.dreams.org            PASV: Timeout EPSV: 000    03:07
ftp.dsi.unimi.it          PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:02
ftp.elliottician.com      PASV: Timeout EPSV: 550 Permission denied.   00:22
ftp.emba.uvm.edu          PASV: Timeout EPSV: 000    01:53
ftp.freestone.net         PASV: Timeout EPSV: 000    02:03
ftp.freiburg.linux.de     PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:02
ftp.fuller.net            PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:02
ftp.gdmag.com             PASV: 553 Permission denied. EPSV: 502 Unimplemented
c
ommand.   00:03
ftp.geo.vu.nl             PASV: Timeout EPSV: 000    02:08
ftp.ghost.dn.ua           PASV: Timeout EPSV: 000    02:03
ftp.greyhelm.com          PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:01
ftp.habber.net            PASV: 500 Unknown command EPSV: 500 Unknown command
00:01
ftp.highcriteria.com      PASV: Timeout EPSV: 425 Can't open data connection.
00:22
ftp.iile.ru               PASV: Timeout EPSV: 000    02:06
ftp.interklasa.pl         PASV: Timeout EPSV: 000    01:55
ftp.irfu.se               PASV: 425 Can't open passive connection: Permission
de
nied. EPSV: 500 'EPSV': command not understood.   00:03
ftp.jclark.com            PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:01
ftp.kompas.kolomna.ru     PASV: Timeout EPSV: 425 Can't open data connection.
00:24
ftp.ks.ru                 PASV: Timeout EPSV: 000    02:04
ftp.lith.com              PASV: Timeout EPSV: 425 Can't open data connection.
00:22
ftp.livinglogic.de        PASV: Timeout EPSV: 000    01:53
ftp.llnl.gov              PASV: 550 Permission denied. EPSV: 550 Permission
deni
ed.   00:00
ftp.loc.gov               PASV: Timeout EPSV: 000    01:51
ftp.lustre.org            PASV: Timeout EPSV: 000    01:53
ftp.markv.com             PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:01
ftp.me.ru                 PASV: 451 Too many passive-mode users. EPSV: 500
'EPSV
': command not understood   00:14
ftp.mebius.net            PASV: Timeout EPSV: 000    02:15
ftp.mincom.com            PASV: 550 Directory listing disabled. EPSV: 550
Direct
ory listing disabled.   00:03
ftp.mns.ru                PASV: Timeout EPSV: 000    02:04
ftp.mplik.ru              PASV: Timeout EPSV: 000    01:55
ftp.mpovti.ru             PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:02
ftp.mtn.org               PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:01
ftp.nccom.com             PASV: Timeout EPSV: 000    01:51
ftp.ncd.com               PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:07
ftp.ndlug.nd.edu          PASV: 000  EPSV: 599 Connection closed   00:02
ftp.nek.ru                PASV: Timeout EPSV: 425 Can't open data connection.
00:24
ftp.netwizards.net        PASV: 550 : No such file or directory EPSV: Timeout
00:10
ftp.newyorker.de          PASV: Timeout EPSV: 000    02:04
ftp.njcc.com              PASV: Timeout EPSV: 000    02:03
ftp.nndev.org             PASV: Timeout EPSV: 000    01:53
ftp.north.ad.jp           PASV: Timeout EPSV: 000    01:54
ftp.pflug.homeip.net      PASV: Timeout EPSV: 421 Idle Timeout (60 seconds):
clo
sing control connection.   01:13
ftp.phred.org             PASV: Timeout EPSV: 000    01:52
ftp.pitow.wroc.pl         PASV: 000  EPSV: 000    02:24
ftp.planet.com.tw         PASV: Timeout EPSV: 550 Permission denied.   00:23
ftp.qnet.fi               PASV: Timeout EPSV: 425 Can't open data connection.
00:24
ftp.rain.fr               PASV: Timeout EPSV: 000    01:56
ftp.rcom.ru               PASV: Timeout EPSV: 000    01:53
ftp.rcom.spb.su           PASV: Timeout EPSV: 000    01:53
ftp.rtr.com               PASV: Timeout EPSV: 000    01:52
ftp.rtsnet.ru             PASV: 451 Too many passive-mode users. EPSV: 500
'EPSV
': command not understood   00:13
ftp.science.tver.ru       PASV: 000  EPSV: 000    00:04
ftp.sofit.ru              PASV: Timeout EPSV: 425 Can't open data connection.
00:25
ftp.softcatala.org        PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:01
ftp.struscia.zuse.it      PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:03
ftp.sztaki.hu             PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:02
ftp.tba.org.tohoku.ac.jp  PASV: Timeout EPSV: 000    02:04
ftp.tc.cornell.edu        PASV: Timeout EPSV: 425 Can't open data connection.
00:22
ftp.telecharger.com       PASV: 550 Permission denied. EPSV: 550 Permission
deni
ed.   00:03
ftp.telstra.net           PASV: Timeout EPSV: 000    01:54
ftp.the.net               PASV: 000  EPSV: 000    03:51
ftp.uct.ac.za             PASV: Timeout EPSV: 150 About to send file list.
00:
25
ftp.ukr.net               PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:02
ftp.upmost.com.tw         PASV: 000  EPSV: 000    03:02
ftp.usyd.edu.au           PASV: Timeout EPSV: 000    01:53
ftp.utexas.edu            PASV: Timeout EPSV: 000    03:14
ftp.vak.ru                PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:03
ftp.videotest.ru          PASV: Timeout EPSV: 000    02:03
ftp.viewml.com            PASV: 000  EPSV: 000    00:14
ftp.vix.com               PASV: Timeout EPSV: 000    01:51
ftp.wcat.com              PASV: Timeout EPSV: 000    01:53
ftp.welmers.net           PASV: Timeout EPSV: 000    01:34
ftp.xatech.com            PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:01
ftp.xemacs.org            PASV: Timeout EPSV: 000    01:53
ftp.ysn.ru                PASV: Timeout EPSV: 000    01:55
ftp.zetnet.co.uk          PASV: 550 : No such file or directory EPSV: Timeout
00:03
jueves.cps.unizar.es      PASV: Timeout EPSV: 000    01:52
mmfd.nsu.ru               PASV: Timeout EPSV: 425 Can't open data connection.
00:23
moonhe.jinr.ru            PASV: Timeout EPSV: 000    02:04
moulon.inra.fr            PASV: Timeout EPSV: 425 Failed to establish
connection
.   01:02
net.tamu.edu              PASV: Timeout EPSV: 000    01:52
ts.kuban.ru               PASV: Timeout EPSV: 425 Failed to establish
connection
.   00:56
wall.etl.go.jp            PASV: Timeout EPSV: 150 Opening ASCII mode data
connec
tion for LIST (111 bytes).   00:05

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 May 2009 12:31:28 +0200

Ok, before we delve into the details, my conclusion after all this  
experimentation is that the wide variation in FTP behavior, some of it  
legitimate but problematic in the case of NATs/firewalls/NAT64s/SIITs,  
some of it just plain broken. I think we can do a reasonable job of  
smoothing over all of this with an ALG. On the other hand, we could  
update RFC 2428, or even RFC 959, in order to provide guidance to  
implementers to update their implementations to work better in today's  
and tomorrow's internet.

Obviously the former makes sense if we consider FTP a legacy  
application that isn't going to be maintained in most cases, while the  
latter is more appropriate if we deem FTP to be a protocol that we  
want to stick around in the future.

Dan: can we have some discussion about this in the upcoming remote  
interim meeting?

I guess we need to ask the apps people for their input.

>  225 ABOR command successful.

Hm, it probably makes more sense to establish the data connection  
first and only then issue commands like LIST. Not sure if it would  

> It then disconnected the control channel.

Great. So this doesn't solve the issue.

However, if we accept client changes then we can of course just let  
the client reconnect and then use PASV rather than EPSV.

> With other FTP servers, the response to ABOR didn't come back  

I believe they try to first shut down the data connection in an  
orderly fashion.

>> (Did you check if any

> accepted anonymous logins but didn't give a directory listing using  
> PASV.

Ugh. The numbers:

Filtering out anything that has "Can't " except "Can't open" leaves  
2598 entries

EPSV + PASV:       1626, 62.6%
No EPSV, but PASV:  972, 37.4%
No EPSV, no PASV:   107,  4.1%

I guess losing compatibility with 4.1% broken servers isn't the end of  
the world, especially as none of them jump out as high profile  
destinations.

Just for fun, here's what an IPv6 server says when you try to do PASV:

ftp> quote PASV
---> PASV
227 Entering Passive Mode (0,0,0,0,237,30)
ftp> quote LIST
---> LIST
150 Here comes the directory listing.
226 Directory send OK.

Another one:

ftp> quote PASV
227 Entering Passive Mode (9,237,25).
ftp> quote LIST
150 Opening ASCII mode data connection for file list
226 Transfer complete.

With the above two, I could simply connect to their IPv6 address on  
the indicated port and then get the directory listing. However, in  
this case that didn't work:

ftp> quote PASV
---> PASV
227 Entering Passive Mode (,238,133).

(The servers were ftp.nluug.nl, ftp.ripe.net and ftp.apnic.net.)

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 May 2009 14:00:54 -0700

> Sent: Thursday, May 07, 2009 3:31 AM
> To: Dan Wing
> Cc: 'Behave WG'
> experimentation is that the wide variation in FTP behavior, 
> some of it legitimate but problematic in the case of 
> NATs/firewalls/NAT64s/SIITs,  
> implementers to update their implementations to work better 
> in today's and tomorrow's internet.
>
> application that isn't going to be maintained in most cases, 
> while the latter is more appropriate if we deem FTP to be a 
> protocol that we want to stick around in the future.
>

Yes, we will put FTP on the agenda - but towards the end.

-d

> > Yes.  Of the list of about 5000 anonymous FTP sites in 
> 2003, 107 of  
> > them

---

From: Philip Matthews <[email-masked]>
Date: Wed, 20 May 2009 08:47:13 -0400

Chiming in late here ...

My quick thoughts on this subject are that what is important is what  
the major browsers do when given a link of the form:
    ftp://....
If someone who doesn't know much about computers clicks on such a  
link, we would like it to work.
Do these browsers do "EPSV" or "PASV" or what?

The people who explicitly run FTP are somewhat computer-literate, and  
will more able to find work-arounds if things fail.

- Philip

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 20 May 2009 16:07:44 +0300

> Do these browsers do "EPSV" or "PASV" or what?

In the envisioned scenario, the FTP client is running on an IPv6 (only) host. 
Using EPSV is hence the *only* valid thing to do. Needless to say, there are 
FTP client implementations that do not support IPv6. From my memories, some 
send malformatted PASV requests and some simply fail to establish the control 
channel in the first place.

But of course, if you deploy an IPv6-only network, you assume that your 
customers are IPv6-capable. In fact, it is not unlikely that a network where 
you can afford such control will have an HTTP proxy handling outgoing FTP 
connections (and the issue is moot).

Anyway, while we cannot assume that an IPv4 FTP server supports EPSV, we can 
assume that an IPv6 FTP client does.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 20 May 2009 15:07:58 +0200

> Do these browsers do "EPSV" or "PASV" or what?

I tried Safari beta 4 and Firefox 3 on my Mac and both did PASV for v4  
and EPSV for v6.

However, I don't think the browser case is the most relevant one. Yes,  
it's important, but basically this is just doing with FTP what can  
also happen over HTTP. An important use case of FTP is uploading  
files, which browsers can't do with FTP AFAIK.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 May 2009 16:49:30 -0700

> Using EPSV is hence the *only* valid thing to do.

It could use PASV.  If EPSV fails, and the FTP client knows the 
IPv6 prefix of its 6/4 translator, the FTP client can send PASV,
parse the response, and open an IPv6 socket that will be 
translated.  For whatever it's worth, I mentioned this in
draft-wing-behave-learn-prefix-02:

   So far, the authors have identified the following
   applications which can benefit knowing the IPv6 prefix of the host's
   IPv6/IPv4 translator:
   ...
   o  In the absence of an FTP ALG in the IPv6/IPv4 translator, IPv6 FTP
      clients that conect to an IPv4 FTP server which does not support
      EPSV [RFC2428].

> Needless to say, there are FTP client implementations that 
> do not support IPv6. From my memories, some 
> send malformatted PASV requests and some simply fail to 
> establish the control channel in the first place.

Yep.  But those don't work with FTP clients behind IPv4 NATs, 
so they really aren't terribly interesting.  I mean, we 
shouldn't try to make them work with FTP clients that emit
EPSV.

> But of course, if you deploy an IPv6-only network, you assume 
> that your customers are IPv6-capable. In fact, it is not unlikely 
> that a network where you can afford such control will have 
> an HTTP proxy handling outgoing FTP connections (and the issue 
> is moot).

Many IPv6-only networks are expected to be quite large: 
wireless networks (which will include tethered PCs which 
might run FTP clients), and there is already a large IPv6-
only network deployed in China (CERNET2) with thousands 
of clients.  This would make such a proxy very busy.
And as you know, it is awkward to reconfigure applications
(such as an FTP client or HTTP client) to use 
different application-level proxies when connecting/disconnecting
with different networks (e.g., ftp-proxy.comcast.net,
proxy.att.net, ftp-proxy-sj.cisco.com, ftp-proxy.starbucks.com).

> Anyway, while we cannot assume that an IPv4 FTP server 
> supports EPSV, we can assume that an IPv6 FTP client 
> does.

Agreed.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 May 2009 16:49:32 -0700

> Sent: Wednesday, May 20, 2009 6:08 AM
> To: Philip Matthews
> Cc: Behave WG; Dan Wing
> I tried Safari beta 4 and Firefox 3 on my Mac and both did 
> PASV for v4 and EPSV for v6.
> 
> However, I don't think the browser case is the most relevant 
> one. Yes, it's important, but basically this is just doing with 
> FTP what can also happen over HTTP.

Downloading from anonymous FTP is the most common use of FTP,
and we certainly need that to work.

And although we can argue that "content providers should just
make their content available on HTTP", that is not likely to
work.  With that logic, content providers would also make
their content available on IPv6 -- but that has not yet 
happened.  

We have a chicken-and-egg problem:  there is still FTP content
that needs to be accessible.  The FTP64 ALG, like all of
the translation being done in BEHAVE, is the 'incubator', so
to speak.

> An important use case of FTP is uploading  

I found this cute little Firefox add-on today,
http://fireftp.mozdev.org/

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 21 May 2009 11:55:56 +0200

> translated.

In the ftp64 -03 draft there is an even simpler solution: clients are  
advised to simply connect to the same address that is the destination  
of the control channel connection, and ignore the address provided in  
the server's response to the PASV command.

(You wouldn't happen to have correlated the PASV response address with  
the control channel address in your big FTP server test, would you?)

> Yep.  But those don't work with FTP clients behind IPv4 NATs,

???

If you have an FTP client that uses the old socket API it can't talk  
over IPv6. So that case is out.

If you have an FTP client that manages to connect over IPv6 but isn't  
aware of EPSV and EPRT, it would issue a PASV command. The client  
issuing the command wouldn't be a problem, because there are no  
arguments or other IP version specific issues with the _command_.

Only when the server responds there will be trouble. I tried this with  
a few IPv6 FTP servers which respond in various ways that don't allow  
for setting up the data connection successfully.

However, if the server is behind a NAT64 then the server will simply  
respond with its IPv4 address, which the client will then parse  
without issue. But then the client needs to connect to an IPv4  
destination which of course doesn't work in this case.

With IPv4 on both sides and a NAT44 in the middle there are no issues,  
the client simply connects to the server-supplied IPv4 address. Only  
with PORT the NAT has to cooperate and allow for the data connection  
to be set up from the server to the client.

> proxy.att.net, ftp-proxy-sj.cisco.com, ftp-proxy.starbucks.com).

There is automatic proxy discovery/configuration and large scale  
proxies have been known to work. If the proxy is only used for FTP I  
don't think this is an issue, as only a small fraction of the  
internet's traffic is FTP.

Note that Apache can be an FTP proxy:

http://httpd.apache.org/docs/2.2/mod/mod_proxy_ftp.html

However, it only supports downloads, not uploads, which brings us to:

> and we certainly need that to work.

Right, it's important, but it's also easy, you can do this with the  
Apache proxy if all else fails.

> the translation being done in BEHAVE, is the 'incubator', so

Not sure what you mean here...

> http://fireftp.mozdev.org/

Right. There's also a bunch of Java FTP clients that you can run from  
your browser.

But my point is that we need to look beyond the browser, because the  
browser in and of itself won't do uploads, and FTP support without  
uploads doesn't make sense.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 May 2009 09:22:55 -0700

> the control channel address in your big FTP server test, would you?)

In my tests?  No, I didn't check.  Should be easy, though -- I
will test that next week.

> > Yep.  But those don't work with FTP clients behind IPv4 NATs,

What I mean is that an IPv4 FTP client that can't parse the PASV
response, or an IPv4 FTP server that sends an un-parsable PASV
response, is not going to work with most modern clients 
(Firefox, IE, etc.) because they default to using PASV because
the client is, more often than not, behind a NAT (coffee shop,
in-home 802.11 NAT box, etc.).

> over IPv6. So that case is out.

That could occur in an IPv4 network to IPv6 network scenario. 
I agree that, for FTP, we might not want to address place a high 
priority on that in the working group.  But it could be made to 
work.

> to be set up from the server to the client.

Yes, "active FTP".

> proxies have been known to work.

This gets into the realm of requiring host changes, though.  And
there are only defacto standards around this area.

I have a proxy.pac file in my Firefox configuration (to tunnel 
traffic over ssh), but this gets fragile.  It doesn't work well
with wget, curl, HTTP clients built into anything shy of a full-
blown, full-featured web browser (IE, Firefox, Safari, Opera),
such as you might find in an IP phone, 

> If the proxy is only used for FTP I  

That the lack of functioning EPSV support in existing IPv4 FTP 
servers is part of the IPv6 transition problem.  BEHAVE's job
is to help with the transition.  So I was just saying we need
to keep pounding on FTP so it'll work as reliably as today's
IPv4 FTP.

> Right. There's also a bunch of Java FTP clients that you can 
> run from your browser.
> 

Ok.

-d

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 22 May 2009 09:55:30 +0300

On Thursday 21 May 2009 02:49:30 ext Dan Wing wrote:
> > In the envisioned scenario, the FTP client is running on an
> > IPv6 (only) host. Using EPSV is hence the *only* valid thing to do.
>

Yes and no. An hypothetical future FTP client that would be aware of network 
protocol translation could certainly do what you are suggesting. *But* I 
reckon the motivation for the FTP64 ALG is backward compatibility with 
existing FTP clients. I'm fairly confident none of those support say, prefix 
learning.

> For whatever it's worth, I mentioned this in

Hmm. So I guess the FTP ALG should just let PASV requests unmodified through, 
so that a prefix-aware FTP client will work regardless of the presence of an 
FTP ALG.

> shouldn't try to make them work with FTP clients that emit

I don't understand what you mean. FTP clients do not interoperate with -other- 
FTP clients in my understanding of FTP.

FTP clients that support PASV but don't support IPv6 definitely *do* work 
through IPv4 NATs. And they will break if you convert the IPv4 NATs into NAT64 
boxes (unless you do double 4-6-4 translation).

> of clients.  This would make such a proxy very busy.

Ok. But still, you're going to have to assume that your customers are IPv6 
capable anyway. And *today* that's not a feasible assumption. In other words, 
there is no foolproof way to make existing FTP clients "just work" on the IPv6 
side of a NAT64 translator.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 22 May 2009 09:30:35 +0200

On 22 mei 2009, at 8:55, Rémi Denis-Courmont wrote:

> An hypothetical future FTP client that would be aware of network

Please read the -03 draft.

In there, it says that IPv6 FTP clients should try PASV if EPSV is  
unsuccessful, but NOT bother with prefixes or anything, and simply  
assume that the address returned by the server in the PASV response is  
the same as the address for the server that the client is connected to  
through the control channel.

So except in the (presumably) very unusual case where the server has  
multiple addresses and returns a different address in the PASV  
response than the control channel address, all of this can work with  
client changes only.

(The draft also requires servers to only use the same address in PASV.  
So if servers are also upgraded it will certainly work.)

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 May 2009 08:48:06 -0700

> From: Rémi Denis-Courmont [mailto:[email-masked]] 
> Sent: Thursday, May 21, 2009 11:56 PM
> To: ext Dan Wing
> Cc: [email-masked]; 'ext Philip Matthews'; 'Iljitsch van Beijnum'
> existing FTP clients.

Yep.

> I'm fairly confident none of those support say, prefix 
> learning.

Agreed.  I was examining how an IPv6 FTP client might operate
across a translator without an FTP ALG in the translator.  I
think Iljitsch's idea of just ignoring the IPv4 address in the
PASV response has a lot of merit and is better than my idea of
prefix learning -- I will test Iljitsch's idea next week.

> so that a prefix-aware FTP client will work regardless of the 
> presence of an FTP ALG.

I agree.  The FTP64 ALG has no incentive to manipulate PASV 
from an IPv6 client.

> boxes (unless you do double 4-6-4 translation).

I didn't understand what you meant by IPv6 FTP clients that send 'malformatted
PASV requests', because PASV doesn't work with IPv6 FTP clients.  I don't have
a point I was trying to make, I was just trying to understand your statement
about mal-formed PASV.

> side of a NAT64 translator.

There is no foolproof way for any NAT or 6/4 translation stuff --
this is all a matter of degrees.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 May 2009 17:21:30 -0700

> From: Dan Wing [mailto:[email-masked]] 
> Sent: Thursday, May 21, 2009 9:23 AM
> To: 'Iljitsch van Beijnum'
> Cc: '"'Rémi Denis-Courmont'"'; [email-masked]'; 'ext Philip 
> Matthews'
> Subject: RE: [BEHAVE] FTP64 ALG: how to proceed?
> 

I just finished testing about 2400 FTP servers and all of them
did what you expected -- namely, the IPv4 address from the PASV
command is the same IPv4 address as the FTP control channel.

My very simple-minded script is at
ftp://ftpeng.cisco.com/dwing/ftp-epsv/ftp-pasv.pl
should anyone want to run their own tests.

The list of FTP servers are the ones reported as "PASV: Ok"
in ftp://ftpeng.cisco.com/dwing/ftp-epsv/ftp-site-list.log

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 29 May 2009 09:45:47 +0200

On 29 mei 2009, at 2:21, Dan Wing wrote:

>>> (You wouldn't happen to have correlated the PASV response
>>> address with the control channel address in your big FTP server  
>>> test, would you?)

> did what you expected -- namely, the IPv4 address from the PASV

Excellent.

Unless I missed something, it seems nobody is unhappy about what's in  
the draft now. So what I want to do is see if I can present it to the  
apps people in Stockholm and see if they will sign off on it, so to  
speak.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 29 May 2009 08:31:44 -0700

> apps people in Stockholm and see if they will sign off on it, so to  

That is a reasonable plan.  

-d