Subject: FTP behavior to avoid ALG in IPv4/IPv6 translation scenario

From: liu dapeng <[email-masked]>
Date: Wed, 16 Sep 2009 02:18:37 +0800

Hello everyone:

We write a draft about how FTP could avoid ALG problem in the
IPv4/IPv6 translation scenario, should we have to write an RFC 2428bis
to carry the work forward?

blow is the link of the draft for reference:
http://tools.ietf.org/html/draft-liu-behave-ftp64-03

(it was posted and discussed in Behave WG firstly, but we then realize
that maybe Application area is the right place to proceed the work)

BR,
Dapeng liu

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 15 Sep 2009 21:55:23 +0200

> that maybe Application area is the right place to proceed the work)

Some background from BEHAVE:

The only major point of contention between this draft and the FTP64  
draft that I presented in Stockholm (draft-van-beijnum-behave- 
ftp64-05) is that Liu's doesn't allow for an FTP ALG for IPv6-to-IPv4  
translation. There is text in mine that describes such an ALG, but  
doesn't mandate its implementation, in my draft. That draft was  
accepted as a BEHAVE wg item in Stockholm but the chairs haven't asked  
for this on the mailinglist yet.

The reason that I feel that the ALG text needs to be in there is that  
at least one vendor has said they will probably implement such an ALG,  
and removing text that would make such ALGs behave in a predictable  
way even though the text is now available seems unhelpful.

However, the last word hasn't been said on this issue, I welcome any  
opinions.

Iljitsch

---

From: "Al Costanzo" <[email-masked]>
Date: Wed, 16 Sep 2009 09:12:21 -0500

My two cents Iljitsch,

>From previous discussions with Jon Postel ("the" RFC editor) years ago when 
I was working on RFC1505. he discussed the fact that if a vendor is 
interested in something, it is the IETF role to write the documentation even 
if there is a standards track document that does the same thing using a 
different methodology.

I have never forgotten this and 1505 was introduced as an experimential RFC 
even though MIME had its foothold  as standards track documents at the time.

I state this because I personally feel that IMHO, it is better to state 
something then to leave it to vendor interpretation. Because of vendor 
interpretation we are still stuck to this date with the useless line: 
"MIME-Version: 1.0" in every email.

Lets try to not repeat from mistakes from the past, mandate: "FTP ALG for 
IPv6-to-IPv4" don't leave it to the decision of the vendor, the IETF always 
should provide guidance. and remember that if you decide to place a version 
number in the coversion don't force it to stay "1.0" because of something 
you forgot to state in the RFC.  Take this lesson from MIME's error.

Regards,

Al Costanzo
> translation

----- Original Message ----- 
From: "Iljitsch van Beijnum" <[email-masked]>
To: "liu dapeng" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 15, 2009 2:55 PM
Subject: Re: FTP behavior to avoid ALG in IPv4/IPv6 translation scenario

> The only major point of contention between this draft and the FTP64  draft 
> that I presented in Stockholm (draft-van-beijnum-behave- ftp64-05) is that 
> Liu's doesn't allow for an FTP ALG for IPv6-to-IPv4  translation. There is 
> text in mine that describes such an ALG, but  doesn't mandate its 
> implementation, in my draft. That draft was  accepted as a BEHAVE wg item 
> in Stockholm but the chairs haven't asked  for this on the mailinglist 
> yet.
>
> The reason that I feel that the ALG text needs to be in there is that  at 
> least one vendor has said they will probably implement such an ALG,  and 
> removing text that would make such ALGs behave in a predictable  way even 
> though the text is now available seems unhelpful.
>
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss