One document matched: draft-tsou-behave-ftp46-01.xml
<?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>
| PAFTECH AB 2003-2026 | 2026-04-24 04:09:16 |