Subject: [BEHAVE] A New Draft on FTP64

From: liu dapeng <[email-masked]>
Date: Thu, 20 Aug 2009 21:59:27 +0800

Hello everyone:

We have posted a draft about FTP64 issue
(http://tools.ietf.org/html/draft-liu-behave-ftp64-00). We know that
there is another solution proposed
(http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-05), but we
have a different view and approache regarding to this problem, the
main differences are:

1. Our viewpoint regarding to FTP64 is that since the ALG problem
could be totally avoided by carefully defining the behavior of the FTP
client and server, translation box need not to implement FTP ALG.

2.We propose that the client just uses the control channel’s IP
address when it retries with PASV command. This approach not only
simplifies the client's implementation, but also avoids some problems
caused by using the IPv4 connectivity of the client.

Any comments are welcome.

BR,
Dapeng Liu

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Aug 2009 17:15:57 +0200

> client and server, translation box need not to implement FTP ALG.

Ok, you don't want to run an FTP64 ALG. However, what if other people  
do want to run an FTP64 ALG? In that case, it's useful to have a  
specification about how such an ALG should behave, so that  
interoperability problems can be avoided.

So I would like to know from you:

- do you want the ALG specification to be removed from the FTP64  
document?

And from others:

- do you foresee yourself implementing and/or running an FTP64 ALG?

If the answer to both questions is "yes" then we have a hard decision  
to make...

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 20 Aug 2009 14:48:18 -0400

> - do you foresee yourself implementing and/or running an FTP64 ALG?

Certainly. ALGs (not only FTP64) are alive and well in the 64 world.

But in this area there will always be a separation between what gets
standardized (or not) and deployed.

Standardization of ALGs has always been a tricky problem - just like NATs.
The difference is that people finally got around to admit the NATs exist,
will be around for a while and producing very good documents on them. ALGs
on the other hand are still pretty much unspecified but have existed as long
as NATs have.

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Jacni Qin <[email-masked]>
Date: Tue, 25 Aug 2009 00:12:04 +0800

hi Dapeng,

i read the draft, in section6,

   2. Behavior of FTP client when retrying with PASV command

   [I-D.draft-van-beijnum-behave-ftp64-05
<http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-05>]
recommends that the client
   should use the IPv4 address in the PASV response message if it has
   IPv4 connectivity and use the control connection's IP address if it
   does not have IPv4 connectivity. However, this document specifies
   that the client should use the control channel's IP address without
   determination whether it has IPv4 connectivity or not. This will
   simplify the client software, besides, if the client has IPv4
   connectivity, the control channel will use its IPv4 address instead
   of using its IPv6 address to connect to the IPv4 server.

reusing the control connection's (or channel, maybe we can unify the words)
IP address ? as i understand.
if so, it makes the clients neat, or is there other matter of concern i
missed?

Jacni

---

From: liu dapeng <[email-masked]>
Date: Tue, 25 Aug 2009 01:33:36 +0800

> if so, it makes the clients neat, or is there other matter of concern i

It can also avoid the potential problems caused by using the client's
IPv4 connection. For example, if the client has a private IPv4
connection and a public IPv6 connection. If the client tries to use
its IPv4 connection to establish data connection to the server, it
will never success.

---

From: liu dapeng <[email-masked]>
Date: Tue, 25 Aug 2009 01:40:11 +0800

Hello everyone:

We upgrade the ftp64 draft, add some text considering the legacy FTP
implementation and other clarification as well. Any comments are
welcomed.

BR,
Dapeng Liu
----------------------------------------------------------------------------------------------------------------------
From: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
Subject: I-D Action:draft-liu-behave-ftp64-01.txt
X-RSN: 1/0/935/26127/29474
X-HREF: http://www.ietf.org/ibin/c5i?mid=6&rid=49&k1=935&k2=29474

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : IPv6 IPv4 translation FTP considerations
Author(s) : D. Liu, Z. Cao
Filename : draft-liu-behave-ftp64-01.txt
Pages : 7
Date : 2009-08-24

The File transfer protocol, which is defined by the RFC 959, is
widely used. RFC 2428 define IPv6 extensions of FTP, introducing EPRT
and EPSV command.

In the IPv6-IPv4 translation scenario, considerations should be
applied to FTP client, server and translation box to ensure FTP
protocol work properly. There already have some work to address this
problem, such as "draft-van-beijnum-behave-ftp64-05" etc, but this
document provides a different approach.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-liu-behave-ftp64-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

*****
Click below to download the attachment(s) in this message:
Attachment: draft_liu_behave_ftp64_01.txt (1K)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Aug 2009 22:13:52 +0200

> implementation and other clarification as well. Any comments are

Can you please send the new text to the list?

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

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.

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.

---

From: liu dapeng <[email-masked]>
Date: Thu, 27 Aug 2009 03:02:31 +0800

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

> 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
> can run as a java applet in a browser) this provides a workable

aggree, this is what draft-liu-behave-ftp64-02 suggested.

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

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Aug 2009 22:57:37 +0200

> evolution perspective?

No. Many clients use EPSV today, and a good number of servers don't  
work with those clients. Apparently the people that run these servers  
don't care.

> if the network contitue to provide ALG all the
> time, the server will never has motivation to upgrade,

I'm afraid the opposite will happen, and people will stay away from  
NAT64 because "it doesn't work". Waiting for IPv4 users to update  
their stuff isn't the best strategy.

> adjusted as an appendix, then there will be no contradiction.

Does anyone else favor putting the ALG description in an appendix?

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 26 Aug 2009 17:25:54 -0400

What is the purpose of this document? Is it to make current FTP6 clients
work with current FTP4 servers? Or is it to give guidance to future FTP6 and
FTP4 implementations?

The problem at hand as I understand it is to make current clients and
servers (that already work through FTP NAT44) to work through FTP NAT64
without change.  If that is the case then ALG part is crucial.

If the purpose is to guide future implementations although it has merit it
does not help the problem at hand.

If this turns out into one of those dogmatic discussions that NAT and ALGs
are evil and the IETF does not provide a document specifying how FTP64 ALG
should work, people are going to develop without guidance (once more).

Hopefully we can reach some consensus on the purpose and scope of the
document.

Thanks,

Reinaldo

---

From: Dave Thaler <[email-masked]>
Date: Wed, 26 Aug 2009 21:54:30 +0000

> Does anyone else favor putting the ALG description in an appendix?

My personal opinion is that I think the FTP64 document should remain
structured essentially as it is now.

-Dave

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 26 Aug 2009 18:11:52 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of liu dapeng
> Sent: Wednesday, August 26, 2009 12:03 PM
> To: Iljitsch van Beijnum
> Cc: [email-masked]
> Subject: Re: [BEHAVE] A New Draft on FTP64
> 

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?

-d

> The server will respond to PASV command with 
> an message
> >

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 26 Aug 2009 18:22:24 -0700

> What is the purpose of this document? Is it to make current 
> FTP6 clients work with current FTP4 servers? Or is it to give 
> guidance to future FTP6 and FTP4 implementations?

There are two FTP64-related documents.  I'm not sure which one you
are referring to when you say 'this document':

* draft-van-beijnum-behave-ftp64-05.txt

  This document describes how existing IPv6 FTP clients and existing 
  IPv4 FTP servers function, and explains how an FTP ALG is useful if 
  a NAT64 operator wants those existing FTP clients and FTP servers to
  work through a 6/4 translator.

  This document was accepted in Stockholm as a WG document.  I am very 
  close to sending a request to the mailing list to adopt it as a WG 
  document, but I am waiting for our new charter (and the FTP-related 
  milestone in it) to be accepted by IESG.

* draft-liu-behave-ftp64-01.txt describes how IPv6 FTP clients can
  be changed to function across a NAT64, so that the NAT64 doesn't
  need to have an FTP ALG.  

  This document is probably most appropriate in the applications area
  as it describes a change in how the FTP applications are supposed to
  work when operating across a translator.

-d

> servers (that already work through FTP NAT44) to work through 
> FTP NAT64 without change.  If that is the case then ALG part 
> is crucial.
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 26 Aug 2009 18:31:20 -0700

> structured essentially as it is now.

Agreed, as my personal opinion.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 27 Aug 2009 01:42:02 -0400

Hello,

I'm taking about draft-van-beijnum-behave-ftp64-05.txt

Thanks,

Reinaldo

---

From: Hui Deng <[email-masked]>
Date: Thu, 27 Aug 2009 20:26:22 +0800

If there is not client changing, I agree,
it seem it has changed, then how could it remain strcutured essentially here?

Thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 27 Aug 2009 20:28:34 +0800

then, I would like to ask the chairs, if there are some proposals
could enhance FTP6
and make FTP64 more efficiently, how could we process this work, since
FTP64 is right here.

thanks

-Hui

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Aug 2009 08:40:58 -0700

> From: Hui Deng [mailto:[email-masked]] 
> Sent: Thursday, August 27, 2009 5:29 AM
> To: Dan Wing
> Cc: Dave Thaler; Iljitsch van Beijnum; [email-masked]

If there are changes to draft-van-beijnum-behave-ftp64 that you'd like to see,
please continue to send them to the list.  Dave and I only expressed our
personal opinion on the placement of the ALG text in the document; if there is
widespread support for putting the text into an appendix, we will support
that.

Suggested changes to FTP clients and FTP servers should be done in the IETF's
applications area, because dictating/changing application behavior is outside
of BEHAVE's scope.  I know the applications area does not currently have an
FTP-specific working group, but they do have an area-wide mailing list
([email-masked]) and area meetings (an I-D that I co-authored was
presented at the Applications area meeting in Stockholm).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Aug 2009 09:05:45 -0700

> From: Reinaldo Penno [mailto:[email-masked]] 
> Sent: Wednesday, August 26, 2009 10:42 PM
> To: Dan Wing; Iljitsch van Beijnum; liu dapeng
> Cc: [email-masked]

That document explains how current IPv6 FTP clients work
in conjunction with current IPv4 FTP servers, and where
there is breakage; it does not expect IPv4 FTP servers 
will change (which is BEHAVE's same expectation for IPv4
HTTP servers, for that matter).

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Aug 2009 18:18:39 +0200

> HTTP servers, for that matter).

That's not completely accurate. The document does make modifications  
to RFCs 959 and 2428, imposing new requirements on both clients and  
servers. This is in line with the feedback I got from the applications  
people.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Aug 2009 09:29:54 -0700

> servers. This is in line with the feedback I got from the 
> applications people.

My interpretation of draft-van-beijnum-behave-ftp64-05 requirements
boil down to 'support EPSV as specified in RFC2428', and the only
additional thing you're requiring is that the IP address of the
data channel is the same as the IP address as the control channel;
but my testing showed that every FTP server I tested on the Internet
already met that additional requirement.  Are the FEAT requirements
new, too?  (afterall, I don't think previous FTP specifications
required FEAT to agree with the actual features of the FTP server;
rather, it's just assumed an FTP server would do that because
it is reasonable).  That is, excepting perhaps FEAT, requirements are 
not 'new', and nearly any deployed IPv4 FTP server or deployed IPv6
FTP client would already meet them.  If you feel one wouldn't, 
please say so (as I know you will!).

My interpretation of draft-liu-behave-ftp64-03 is that it
suggests more substantial changes to requirements, to the point
that existing deployed IPv6 FTP clients and existing, deployed 
IPv4 FTP servers are unlikely to comply with draft-liu-behave-ftp64-03.

-d

---

From: liu dapeng <[email-masked]>
Date: Fri, 28 Aug 2009 01:02:42 +0800

> and wants EPSV, so you only use EPSV after PASV returns an error?

maybe this is better, and for the legacy server, this approach can also work.
In essence,for the client, this approach use PASV but treat it as as
EPSV (ignoring the IP address of the response message)

---

From: liu dapeng <[email-masked]>
Date: Fri, 28 Aug 2009 01:11:54 +0800

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

---

From: liu dapeng <[email-masked]>
Date: Fri, 28 Aug 2009 01:24:56 +0800

> HTTP servers, for that matter).

it seems in section 3 "server requirements", there will be some
requirement for the server?  also it seems to specify  some
requirement for the client in section 4.

---

From: liu dapeng <[email-masked]>
Date: Fri, 28 Aug 2009 01:42:03 +0800

> data channel is the same as the IP address as the control channel;

it seems in draft-van-beijnum-behave-ftp64-05, it 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. "

draft-liu-behave-ftp64-03 points out this approach may cause some
issues, and suggests that just simply use control channel's IP
address.

> already met that additional requirement.

the serve may allow the client to establish data connection using the
control channel's IP address, but how about the client that has to
ignore the PASV respond message's IP address and simply using the
control channel's IP address? does the client already support this or
it will require the client to upgrade?

 Are the FEAT requirements
> suggests more substantial changes to requirements,

Actually, draft-liu-behave-ftp64-03 does not have more requriment for
the client and server, expect that it suggests to simply use the
control channel's IP address when it retry with PASV command.

Besides, draft-liu-behave-ftp64-03 gives the clear opinion that it
suggests that if the client and server comply with this document then
it will not need FTP ALG in NAT64.

to the point

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Aug 2009 19:42:35 +0200

> and wants EPSV, so you only use EPSV after PASV returns an error?

I can't definitively say that won't work, but the responses IPv6 FTP  
servers send after a PASV command make me not want to go down this  
path. We know that with EPSV 65% of the v4 servers and 100% of the v6  
servers work, which I wouldn't want to risk breaking.

If you want I'll send some examples tomorrow, currently my IPv6 tunnel  
is having a bad hair day or some such...

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Aug 2009 19:49:38 +0200

On 27 aug 2009, at 18:29, Dan Wing wrote:

> That is, excepting perhaps FEAT, requirements are

The feat stuff is new, most servers don't do it as specified in the  
draft now. Also the ability to turn off EPSV and EPSV itself as a  
requirement are new.

On the client side, the requirement to support EPSV shouldn't be a big  
deal, I doubt any other IPv6-capable clients than the windows command  
line one don't support this. The PASV stuff is not a requirement.

> IPv4 FTP servers are unlikely to comply with draft-liu-behave- 

It goes a step or two further, yes, but down a road already taken by  
draft-van-beijnum-behave-ftp64-05.

We currently have one or more people feeling that an ALG is required  
and one or more people that feel it's a bad idea. The draft allows for  
both, and also mandates a way for users to make the ALG go into  
transparent mode, so I'm thinking we're ready to declare victory...?

(I'll address the smaller issues in the next version.)

---

From: liu dapeng <[email-masked]>
Date: Fri, 28 Aug 2009 02:07:16 +0800

> transparent mode, so I'm thinking we're ready to declare victory...?

my question is: should we simply put the different opinions (maybe
opposite) together to make a specification or should we investigate
the problems more deeply and try to make a specification that could
best solve the problem?

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Aug 2009 11:10:12 -0700

> From: liu dapeng [mailto:[email-masked]] 
> Sent: Thursday, August 27, 2009 10:12 AM
> To: Dan Wing
> Cc: [email-masked]; Iljitsch van Beijnum

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

> >> > recommendations listed in 
> draft-van-beijnum-behave-ftp64-05 will be
> this will cause

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Aug 2009 20:10:59 +0200

> the problems more deeply and try to make a specification that could

The problem is that there is no objective "best". For some people the  
extra state required by an ALG would be expensive but changing the  
clients wouldn't be, for others an ALG is no problem but they have  
little control over the clients so they can't change them or this  
involves expensive support calls.

---

From: liu dapeng <[email-masked]>
Date: Fri, 28 Aug 2009 02:12:36 +0800

> is having a bad hair day or some such...

yes, it maybe better if you send some examples or explain this in
detail. thanks.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Aug 2009 20:13:04 +0200

On 27 aug 2009, at 20:10, Dan Wing wrote:

Not going to repeat all of that...

The proof of the pudding is in the eating. If EPSV works, it works. If  
it doesn't, do PASV. The only downside is that it can take a while to  
not work, but for FTP that shouldn't be fatal.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Aug 2009 11:18:28 -0700

> Sent: Thursday, August 27, 2009 10:42 AM
> To: Dan Wing
> Cc: Iljitsch van Beijnum; Reinaldo Penno; [email-masked]

Yes, that is one place where the drafts differ.  Hopefully we can
reach consensus on what the FTP client should best do.

> it will require the client to upgrade?

I have no way to test all the FTP clients on the Internet.  I can,
however, test all the FTP servers that are publicly accessible and
have run tests against over 2000 of them.  See 
ftp://ftp-eng.cisco.com/dwing/ftp-epsv

> it will not need FTP ALG in NAT64.

Here is where we stand:

The IETF will have no success in modifying the behavior of IPv4 FTP servers on
the Internet, in the timeframe necessary for deployment of NAT64 devices
(~2011-2012).

There is a chance we could have success in modifying behavior of IPv6 FTP
clients that are behind NAT64 translators.

We are certainly able to influence how FTP ALGs, built into NAT64 translators,
should function in the event one of today's IPv6 FTP clients is trying to
communicate with one of today's IPv4 FTP servers through a NAT64.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Aug 2009 11:19:07 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Thursday, August 27, 2009 10:43 AM
> To: Dan Wing
> Cc: 'liu dapeng'; [email-masked]

Ok.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Aug 2009 11:21:19 -0700

> Sent: Thursday, August 27, 2009 10:50 AM
> To: Dan Wing
> Cc: 'Reinaldo Penno'; 'liu dapeng'; [email-masked]
> draft now.

Do FTP clients rely on FEAT?  Does it benefit the clients (or servers)
to use FEAT?  Should the clients rely on FEAT working and rely on it
accurately describing the supported commands (versus just trying to
use a command and getting a 2xx or 5xx response)?

> Also the ability to turn off EPSV and EPSV itself as a  
> requirement are new.
> 

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Aug 2009 11:24:55 -0700

> Sent: Thursday, August 27, 2009 11:11 AM
> To: liu dapeng
> Cc: Dan Wing; Reinaldo Penno; [email-masked]
> >> and one or more people that feel it's a bad idea. The 
> draft allows  
> >> for

A should discussion in the draft could clarify that.  It would explain
how someone installing a NAT64 should decide to enable/disable the
FTP ALG, based on their knowledge of the IPv6 FTP clients behind 
their NAT64.

-d

---

From: liu dapeng <[email-masked]>
Date: Fri, 28 Aug 2009 02:29:41 +0800

> involves expensive support calls.

the point is: maybe we should all have to aggree that ALG is bad,
especially for translation box, so should not we try to find some
solutions to avoid it if it is possible(or give some clear guidelines
to avoid it if it possiable) ?
mybe that is the best we can do.

it is quite late here, I will continue to discuss tomorrow, thanks for
the discussion.