An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
RFC 6384

Received changes through RFC Editor sync (changed abstract to 'The File Transfer Protocol (FTP) 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, in situations where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent.

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 do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. [STANDARDS-TRACK]')

[Ballot comment]
#1)  It's probably worth expanding ALG in the title.  It's not expanded in the abstract and as a security guy I  thought you were going to be talking about an Algorithm ;)

#2) Section 4 includes:

  As such,
  it is recommended to update FTP clients and servers as required for
  IPv6-to-IPv4 translation support where possible, to allow proper
  operation of the FTP protocol without the need for ALGs.

r/recommended/RECOMMENDED?

#3) Section 5: missing right parenthesis: ([RFC4217]

#4) I think you need a normative reference for UTF-8.

IANA understands that, upon approval of this document, there is a single
IANA Action which must be completed.

In the FTP Commands and Extensions registry located at:

http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xml

a single, new registration will be made as follows:

cmd: ALGS
FEAT code: -N/A-
Description: FTP64 ALG status
Type: -N/A-
conf: o
reference: [ RFC-to-be ]

IANA understands that this is the only action required upon approval of
this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <behave@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-behave-ftp64-10.txt> (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard


The IESG has received a request from the Behavior Engineering for
Hindrance Avoidance WG (behave) to consider the following document:
- 'An FTP ALG for IPv6-to-IPv4 translation'
  <draft-ietf-behave-ftp64-10.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The File Transfer Protocol (FTP) 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 only have IPv6 connectivity
  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
  do not support this mode, and some clients do not ask for it.  This
  document specifies a middlebox that may solve this mismatch.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1322/

IPR has been disclosed and announced to the mailing list,
https://datatracker.ietf.org/ipr/search/?option=document_search&document_sea
rch=draft-ietf-behave-ftp64
and there has been no subsequent WG discussion about this IPR disclosure.

AD Review:

1) should security considerations discuss trust between client-alg and alg-server? I assume TLS cannot be used end-to-end for FTP, but must be hop-to-hop client-to-alg, and alg-to-server. Assuming different credentials apply, the secuirty association must be established between the client and the alg, not client-server, and the security association  must be established between the alg and server, not client-server. I would also assume that how this is accomplished depends on whether active or passive mode is being used to establish connections.
The text as written might already already say that only passive mode is used in the presence of tLS protection, but I'm not sure that is what the text says.

2) section 4 "As such, an ALG used with a stateful translator MUST support EPSV and MAY support EPRT. However, an ALG used with a stateless translator SHOULD also support EPRT. " Is there a requirement regarding stateless and EPSV?

3) in section 9, "Implementations SHOULD NOT try to detect the situation where both PASV and PORT commands are issued prior to a command that initiates a transfer, but rather, apply the same translation they would have if there had not been a PASV command prior to a PORT command or a PORT command prior to a PASV command. " I find this a bit ambiguous. Is it expected that the translation they would have done be based on having received only the second command (as if the first had not been received), or based on not having received either?

4) should the NOOP in section 12 be reflected in the ABNF algs-command ?

5) draft-liu-ftp64-extensions should be updated to draft-ietf-ftpext2-ftp64 during subsequent processing.

6) The normative reference to ftpext2 work could cause this document to be held up in processing. is there a way to eliminate this reference? Can an implementation "support EPSV successfully" without this ftpext2 extension? The text isn't clear that "successfully" means requiring support for an IPv4-IPv6 translation environment; that is only implied by the choice of reference [2428] vs [ftpext2].

  (1.a)  Who is the Document Shepherd for this document?

draft-ietf-behave-ftp64-07
Dan Wing, dwing@cisco.com

          Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Yes.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

This document has received significant review from BEHAVE. 


  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

It was reviewed by people attending the FTPEXT2 BoF.


  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.

No concerns.

          Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

IPR has been disclosed and announced to the mailing list,
https://datatracker.ietf.org/ipr/search/?option=document_search&document_sea
rch=draft-ietf-behave-ftp64
and there has been no discussion about this IPR declaration.


  (1.e)  How solid is the WG consensus behind this document?

Solid.


          Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The WG has a good understanding of, and agreement with, this document.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No such threats or appeals.


  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)

Yes.

          Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews? 

The document adds new FTP commands, which extends
http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensi
ons.xhtml
and the document contains an IANA Considerations section adequate for
doing that.

          If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Intended Status:  Standards Track


  (1.h)  Has the document split its references into normative and
          informative?

Yes.

          Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

All normative references are to standards-track RFCs.


  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?

Yes.

          If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?

Yes.

          Are the IANA registries clearly identified?

Yes.

          If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?

The document does not create a new IANA registry.

          Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Yes, the ABNF passes the validator at
http://www.apps.ietf.org/content/chris-newmans-abnf-validator


  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.


This document describes middlebox behavior to reduce the problem of
IPv6 FTP clients connecting to IPv4 FTP servers on the Internet.



          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

Yes, controversy around the requirements that could be made of already-
deployed FTP clients and FTP servers.  This text has been removed and
will appear in a separate document.


          Document Quality
            Are there existing implementations of the protocol?

None have been announced.


            Have a
            significant number of vendors indicated their plan to
            implement the specification?

Yes, several vendors are actively implementing the specification.


            Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?

They are listed in the document's contributors section.


            If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

No such reviews were necessary.


          Personnel
            Who is the Document Shepherd for this document?

Dan Wing, dwing@cisco.com

            Who is the
            Responsible Area Director?

David Harrington, ietfdbh@comcast.net


            If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are <TO BE ADDED BY THE AD>.'


The document doesn't require IANA experts.



  The Document Shepherd MUST send the Document Shepherd Write-Up to the
  Responsible Area Director and iesg-secretary@ietf.org together with
  the request to publish the document.  The Document Shepherd SHOULD
  also send the entire Document Shepherd Write-Up to the working group
  mailing list.  If the Document Shepherd feels that information which
  may prove to be sensitive, may lead to possible appeals, or is
  personal needs to be written up, it SHOULD be sent in direct email to
  the Responsible Area Director, because the Document Shepherd Write-Up
  is published openly in the ID Tracker.  Question (1.f) of the
  Write-Up covers any material of this nature and specifies this more
  confidential handling.