Subject: [BEHAVE] New Version Notification for draft-ietf-behave-ftp64-01

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 May 2010 01:01:18 +0200

Here's an FTP64 update.

I incorporated pretty much all the comments. I made this standards track, with RFC 2119 language for the ALG stuff but only "recommendations" for the client and server behaviors. So I think it's compatible with the charter.

https://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/

Feedback would be appreciated.

Still to do: go over everything for language and to see if the abstract and the introduction are still in agreement with the rest of the text, and I need to do something about the example addresses.

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: 3 mei 2010 0:55:36 GMT+02:00
> To: [email-masked]
> Subject: New Version Notification for draft-ietf-behave-ftp64-01 
> 
> 
> A new version of I-D, draft-ietf-behave-ftp64-01.txt has been successfully submitted by Iljitsch van Beijnum and posted to the IETF repository.
> 
> Filename:	 draft-ietf-behave-ftp64
> Revision:	 01
> Title:		 IPv6-to-IPv4 translation FTP considerations
> Creation_date:	 2010-05-02
> WG ID:		 behave
> Number_of_pages: 15
> 
> Abstract:
> The File Transfer Protocol has a very long history, and despite the
> fact that today, other options exist to perform file transfers, FTP
> is still in common use.  As such, it is important that in the
> situation where some client computers are IPv6-only while many
> servers are still IPv4-only and IPv6-to-IPv4 translators are used to
> bridge that gap, FTP is made to work through these translators as
> best it can.
> 
> FTP has an active and a passive mode, both as original commands that
> are IPv4-specific, and as extended, IP version agnostic commands.
> The only FTP mode that works without changes through an IPv6-to-IPv4
> translator is extended passive.  However, many existing FTP servers
> don't support this mode, and some clients don't ask for it.  This
> document describes server, client and middlebox (if any) behavior
> that minimizes this problem.
> 
> 
> 
> The IETF Secretariat.
>