Subject: Re: [BEHAVE] A New Draft on FTP64

From: Sheng Jiang <[email-masked]>
Date: Fri, 21 Aug 2009 20:08:03 +0800

ALGs are always annoying, for sure. They are not generic among applications.
Each application may need its own ALG. How many ALGs may we have to run
beside NAT64. If applications or protocols are carefully designed and
implemented, our world would be much better; IPv6/IPv4 inter-communication
would be much easier. For my understanding, any ALGs, except for DNS ALG,
are not necessary.

draft-liu-behave-ftp64-00 is such effort to avoid ALG in network side.

Cheers,

Sheng

> On 8/20/09 8:15 AM, "Iljitsch van Beijnum" <iljitsch at muada.com> wrote:

>> On 20 aug 2009, at 15:59, liu dapeng wrote:
>> 
>> 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.
> 
> 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?

---

From: bo zhou <[email-masked]>
Date: Sun, 23 Aug 2009 23:27:15 +0800

Agreed with Sheng. If we can avoid FTP ALG in network side by carefully
defined the behaviours of client and server, why we should put ALG inside
the standardisation.
Furthermore, ALGs (not only FTP) cannot avoid during NAT64 deployment. like
Reinaldo mentioned, it is a tricky problem to standardise ALG even everybody
know it will exist as long as NAT64 exist.
Regards,
Bo Zhou

On Fri, Aug 21, 2009 at 8:08 PM, Sheng Jiang <[email-masked]> wrote:

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

-- 
Regards,

Bo Zhou
China Mobile

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 23 Aug 2009 09:28:03 -0700

bo zhou wrote:
> defined the behaviours of client and server, why we should
> put ALG inside the standardisation.

The historical problem being that ftp clients and servers have been
disinclined to change their behavior just because someone writes a draft
and passes it through the iesg and rfc editor, that's in part why we are
where we are today with ftp.

You can avoid alg by dropping the client/server combos you don't want to
support off the list, it doesn't make the problem go away but it does
remove it as an obstacle to this draft.

> Furthermore, ALGs (not only FTP) cannot avoid during NAT64 deployment.
> like Reinaldo mentioned, it is a tricky problem to standardise ALG even
> everybody know it will exist as long as NAT64 exist.
> Regards,
> Bo Zhou
> 
> On Fri, Aug 21, 2009 at 8:08 PM, Sheng Jiang <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > On 8/20/09 8:15 AM, "Iljitsch van Beijnum" <iljitsch at muada.com
>     <http://muada.com/>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: bo zhou <[email-masked]>
Date: Mon, 24 Aug 2009 12:26:15 +0800

Although FTP behaviours has been disinclined to change its behaviours based
by a draft you pointed out, it cannot predict the issue of ALG in 64
translation or others scenarios. If we can carefully modify the FTP client
and server behaviour to avoid ALG, why not? Especially, the draft is focus
on ftp64 scenario, so no excuse to leave the problem even we know we can
sort it out by some slight behaviour modification.

Regards,

Bo Zhou

-- 
Regards,

Bo Zhou
China Mobile

---

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

> where we are today with ftp.

yes, you said it, while if we have a chance to improve it now, why not? :-)

Jacni

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 24 Aug 2009 09:22:13 -0700

Jacni Qin wrote:
> 
> 
> On Mon, Aug 24, 2009 at 12:28 AM, Joel Jaeggli <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     bo zhou wrote:

You can write whatever you want, it won't change the deployed code.

---

From: Hui Deng <[email-masked]>
Date: Tue, 25 Aug 2009 22:21:55 +0800

> You can write whatever you want, it won't change the deployed code.
How many people really use FTP6 today?

-Hui

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 25 Aug 2009 11:03:32 -0700

> How many people really use FTP6 today?

How long has your host stack and many of the included applications
supported ipv6? 6 years? longer maybe?

What odds do you put on the windows xp command-line ftp client being
changed? and that change being propagated into systems everywhere.
That's only one example but it's an ubiquitous one.

The point is legacy applications don't change, if they did v4 to v6
migration would be a lot simpler in the first place.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Aug 2009 20:34:03 +0200

> That's only one example but it's an ubiquitous one.

But to what degree does that matter?

Browsers support FTP with EPSV and in most cases, it's possible to  
install more capable FTP client. FTP clients are high on those "so I  
switched to this new OS, what software do I install?" lists.

Also note that the ftp64 draft that was adopted as a wg draft in  
Stockholm requires clients to at least support PASV, or an ALG that  
goes beyond what is suggested for stateful translation, just  
supporting EPRT, like the Windows command line client does, doesn't  
cut it.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 25 Aug 2009 18:39:08 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Iljitsch van Beijnum
> Sent: Tuesday, August 25, 2009 11:34 AM
> To: Joel Jaeggli
> Cc: Behave WG
> Subject: Re: [BEHAVE] A New Draft on FTP64
>

That particular client doesn't work through IPv4 NATs either.  I think
the FTP64 ALG only needs to work for clients that work through IPv4 NATs,
but should not require any changes to clients that do.

-Dave

---

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

> That's only one example but it's an ubiquitous one.

command line users can use the EPSV command to change to pasive mode
if the server support this command. besides, most of ordinary users
may use GUI based ftp client programs which maybe easily to upgrade
(numberless softwares support online upgrading)

---

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

inline please

> supported ipv6? 6 years? longer maybe?
==> maybe longer than that, and who have ever used that?

> migration would be a lot simpler in the first place.
==> I change my laptop every two years, and guess most of people
around me do the smiliar thing.
we download everything each time during installing everything.
I updated my skype and MSN software perodically.  (Depends on how
often they update it)

thanks for the discussion

-Hui