<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
  <!ENTITY RFC0959 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0959.xml">
  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC2428 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2428.xml">
  <!ENTITY RFC6384 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6384.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-tsou-behave-ftp46-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
        or pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters -->

    <title abbrev="FTP46">An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Tina Tsou" initials="T." role="editor"
            surname="Tsou">
      <organization>Huawei Technologies (USA)</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <code>CA  95050</code>
          <country>USA</country>
        </postal>
        <phone>+1 408 330 4424</phone>
        <email>tina.tsou.zouting@huawei.com</email>
      </address>
    </author>

    <author initials="S." surname="Perreault" fullname="Simon Perreault">
      <organization>Viagenie</organization>
      <address>
        <postal>
          <street>246 Aberdeen</street>
          <city>Quebec</city>
          <region>QC</region>
          <code>G1R 2E1</code>
          <country>Canada</country>
        </postal>
        <phone>+1 418 656 9254</phone>
        <email>simon.perreault@viagenie.ca</email>
        <uri>http://viagenie.ca</uri>
      </address>
    </author>

    <author fullname="Jing Huang" initials="J." surname="Huang">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Huawei Area F, Bantian, Longgang District</street>
          <city>Shenzhen</city>
          <code>518129</code>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>James.huang@huawei.com</email>
      </address>
    </author>

    <date year="2013" />

    <!-- Meta-data Declarations -->

    <area>INT</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
     If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <abstract>
      <t>An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited to an 
      IPv6 client connecting to an IPv4 server. This memo supports the case of an 
      IPv4 client connecting to an IPv6 server.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Overview" title="Overview">
      <t>During the transition from IPv4 to IPv6, some operators need to deploy NAT in
      their network. Some subscribers have the need to run IPv4 based FTP servers at
      home, and some of the FTP <xref target="RFC0959"></xref> control messages carry 
      IP address and port number in the payload, which will cause a NAT traversal problem.
      </t>

      <t><xref target="RFC6384"></xref> defines FTP ALG for NAT64, but only for the
      case where the FTP client is on the inside of the NAT64. The case where an FTP
      server is on the inside of the NAT64 is not covered.</t>

      <t>When the FTP server is behind NAT, it can publish its service address via a HTTP redirect
      server and a DDNS system which needs to support both IP address and port rather than IP address 
      only, or other possible methods. The FTP server can listen on any possible ports, not just 
      port 21; FTP server can get it external IP address and port via some technology like UPnP, and then
      publish the acquired IP address and port as its URI, ftp://203.0.113.1:1200, port 1200 is 
      allocated by NAT.</t>

      <section title="Requirements Language"> <!-- req -->
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
      </section> <!-- req -->
    </section>

    <section title="Terminology">
      <t></t>
    </section>
    


    <section title="Scenarios">
      <t>There can be several scenarios if NAT is involved in the network.</t>
      <t>a) In this scenario, the FTP client is behind NAT, FTP ALG needs to handle
      the EPRT / PORT command in FTP active mode, translating the IP address and
      port. This scenario has been covered by <xref target="RFC6384"></xref>,
      but only for NAT64. This scenario for other kinds of NAT has not been
      covered.</t>
      <figure title="FTP Client Behind NAT"
              align="center">
        <artwork>
+--------+    +---------+    +-------+    +---------+    +--------+
|  FTP   |    |         |    |       |    |         |    |  FTP   |
| Client +----+  IPv6   +----+ NAT64 +----+  IPv4   +----+ Server +
|        |    | Network |    |       |    | Network |    |        |
|  IPv6  |    |         |    |       |    |         |    |  IPv4  |
+--------+    +---------+    +-------+    +---------+    +--------+
        </artwork>
      </figure>

      <t>b) If the FTP server is behind a NAT, FTP passive mode will be the only
      working mode, the EPSV / PASV command and the response will be processed by 
      FTP ALG. This memo covers this scenario.</t>
      <figure title="FTP Server Behind NAT"
              align="center">
        <artwork>
+--------+    +---------+    +-------+    +---------+    +--------+
|  FTP   |    |         |    |       |    |         |    |  FTP   |
| Server +----+  IPv6   +----+ NAT64 +----+  IPv4   +----+ Client +
|        |    | Network |    |       |    | Network |    |        |
|  IPv6  |    |         |    |       |    |         |    |  IPv4  |
+--------+    +---------+    +-------+    +---------+    +--------+
        </artwork>
      </figure>
    </section>

    <section title="PASV to EPSV">
      <t>If FTP client issues PASV command to FTP server, FTP ALG translates PASV command 
      into EPSV command <xref target="RFC2428"></xref>, setting the "net-prt" field to
      2 (IPv6). The response of EPSV command is translated into PASV response. FTP ALG 
      allocates an IPv4 address and port for the EPSV response message, and builds a NAT 
      mapping entry if the NAT is stateful. The source address of the EPSV response message 
      and the "tcp-port" in the payload are used for the NAT mapping. The allocated IPv4 
      address and port are put into the PASV response message.</t>

      <t>For instance, in the IPv4 side of NAT64, FTP server's address is 203.0.113.1. FTP 
      client issues a PASV command to FTP server, and it is translated into EPSV command
      by FTP AGL, as shown below:</t>
      <t>PASV command:</t>
      <t>PASV</t>
      <t>EPSV command:</t>
      <t>EPSV 2</t>
    
      <t>When FTP server returns a success response of EPSV containing tcp-port 3000, FTP AGL
      allocates an IPv4 address 203.0.113.1 and tcp-port 2000 corresponding to the tcp-port 
      3000 in the EPSV response message, and puts the allocated IP address and port into PASV 
      response message, as shown below:</t>
      <t>EPSV success response:</t>
      <t>229 Entering Passive Mode (|||3000|)</t>
      <t>PASV success response:</t>
      <t>227 Entering Passive Mode (203,0,113,1,7,208)</t>
    </section>

    <section title="EPSV (IPv4) to EPSV (IPv6)">
      <t>If FTP client issues EPSV command to FTP server, FTP ALG modifies the "net-prt", 
      change the value from 1 (IPv4) to 2 (IPv6). The response of IPv6 EPSV command is also 
      translated. FTP ALG allocates an IPv4 address and port for the EPSV response message. </t>

      <t><xref target="RFC2428"></xref> requires that "the network address used to establish 
      the data connection will be the same network address used for the control connection", 
      so NAT MUST to make sure that IPv4 address for control connection and IPv4 address for
      data connection for a FTP server must be the same, which means all the mappings for an
      IPv6 address MUST have the same external IPv4 address.</t>

      <t>For instance, in the IPv4 side of NAT64, FTP server's address is 203.0.113.1. The
      FTP client issues an IPv4 EPSV command to FTP server, and it is translated into IPv6 
      EPSV command by FTP AGL, as shown below:</t>
      <t>EPSV (IPv4) command:</t>
      <t>EPSV 1</t>
      <t>EPSV (IPv6) command:</t>
      <t>EPSV 2</t>
    
      <t>When FTP server returns a success response of EPSV containing port 3000, FTP AGL 
      will allocate an IPv4 address 203.0.113.1 and port 2000 corresponding to the port 3000 in 
      the EPSV response message, and put the allocated port into PASV response message, as 
      shown below:</t>
      <t>EPSV (IPv6) success response:</t>
      <t>229 Entering Passive Mode (|||3000|)</t>
      <t>EPSV (IPv4) success response:</t>
      <t>229 Entering Passive Mode (|||2000|)</t>
    </section>

    <section title="Command to disable FTP ALG">
        <t>Command ALGS defined in <xref target="RFC6384"></xref> is extended, three more possible
        arguments are added:</t>
        <t><list hangIndent="10" style="hanging">
            <t hangText="ALGS STATUS46">to return the EPSV and EPRT translation status.</t>
            <t hangText="ALGS ENABLE46">to enable translation.</t>   
            <t hangText="ALGS DISABLE46">to disable translation.</t>       
        </list></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>RFC6384's security considerations applies to this document.</t>
    </section>

    <section title="Acknowledgements">
      <t></t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->
  <back>
    <references title="Normative References">
      &RFC0959;
      &RFC2119;
      &RFC2428;
      &RFC6384;
    </references>
  </back>
</rfc>
