One document matched: draft-ietf-behave-ftp64-08.xml
<?xml version="1.0" ?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc854 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0854.xml">
<!ENTITY rfc959 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0959.xml">
<!ENTITY rfc1123 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1123.xml">
<!ENTITY rfc1918 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY rfc2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2389 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2389.xml">
<!ENTITY rfc2228 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2228.xml">
<!ENTITY rfc2428 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2428.xml">
<!ENTITY rfc2577 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2577.xml">
<!ENTITY rfc2640 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2640.xml">
<!ENTITY rfc2765 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2765.xml">
<!ENTITY rfc4217 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4217.xml">
<!ENTITY rfc5234 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY I-D.ietf-behave-v6v4-xlate-stateful PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-v6v4-xlate-stateful">
<!ENTITY I-D.ietf-behave-v6v4-xlate PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-behave-v6v4-xlate-05.xml">
]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc subcompact="no" ?>
<rfc ipr="trust200902" docName="draft-ietf-behave-ftp64-08" category="std">
<front>
<title abbrev="IPv6-to-IPv4 FTP">An FTP ALG for IPv6-to-IPv4 translation</title>
<author initials="I" surname="van Beijnum" fullname="Iljitsch van Beijnum">
<organization>IMDEA Networks</organization>
<address>
<postal>
<street>Avda. del Mar Mediterraneo, 22</street>
<city>Leganes</city>
<region>Madrid</region>
<code>28918</code>
<country>Spain</country>
</postal>
<email>iljitsch@muada.com</email>
</address>
</author>
<date day='29' month='March' year='2011'></date>
<area>Transport</area>
<workgroup>Behavior Engineering for Hindrance Avoidance</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>FTP</keyword>
<keyword>SIIT</keyword>
<keyword>NAT64</keyword>
<abstract>
<t>
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.
</t>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
<xref target="RFC0959" /> specifies two modes of operation for FTP: active mode, in which the server connects back to the client and passive mode, where the server opens a port for the client to connect to. Without additional measures, active mode with a client-supplied port does not work through NATs or firewalls. With active mode, the PORT command has an IPv4 address as its argument, and in passive mode, the server responds to the PASV command with an IPv4 address. This makes both the passive and active modes as originally specified in <xref target="RFC0959" /> incompatible with IPv6. These issues were solved in <xref target="RFC2428" />, which introduces the EPSV (extended passive) command, where the server only responds with a port number, and the EPRT (extended port) command, which allows the client to supply either an IPv4 or an IPv6 address (and a port) to the server.
</t>
<t>
A survey done in April of 2009 of 25 randomly picked and/or well-known FTP sites reachable over IPv4 showed that only 12 of them supported EPSV over IPv4. Additionally, only 2 of those 12 indicated that they supported EPSV in response to the FEAT command introduced in <xref target="RFC2389" /> that asks the server to list its supported features. One supported EPSV but not FEAT. In 5 cases, issuing the EPSV command to the server led to a significant delay, in 3 cases followed by a control channel reset. All 25 servers were able to successfully complete a transfer in traditional PASV passive mode as required by <xref target="RFC1123"></xref>. More testing showed that the use of an address family argument with the EPSV command is widely mis- or unimplemented in servers. The additional tests with more servers showed that approximately 65% of FTP servers support EPSV successfully and around 96% support PASV successfully. Clients were not extensively tested, but previous experience from the author suggests that most clients support PASV, with the notable exception of the command line client included with Windows, which only supports active mode. This FTP client uses the original PORT command when running over IPv4 and EPRT when running over IPv6.
</t>
<t>
Although these issues can and should be addressed by modifying
clients and servers to support EPSV successfully (see <xref target="I-D.liu-ftp64-extension" />), such modifications may not appear widely in a
timely fashion. Also, network operators who may want to deploy IPv6-to-IPv4 translation
generally don't have control over client or server implementations. As such, this document
standardizes an FTP Application Layer Gateway (ALG) that will allow unmodified IPv6 FTP clients
to interact with unmodified IPv4 FTP servers successfully when using FTP for simple
file transfers between a single client and a single server.
</t>
<t>
Clients that want to engage in more complex behavior, such as server-to-server transfers, may make an FTP application layer gateway (ALG) go into transparent mode by issuing AUTH or ALGS commands as explained in <xref target="controlchanneltranslation" />.
</t>
<t>
The recommendations and specifications in this document apply to all forms of IPv6-to-IPv4 translation, including stateless translation such as <xref target="RFC2765" /> or <xref target="I-D.ietf-behave-v6v4-xlate" /> as well as stateful translation such as <xref target="I-D.ietf-behave-v6v4-xlate-stateful" />.
</t>
</section>
<section title="Notational Conventions">
<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"></xref>.</t>
</section>
<section title="Terminology">
<t>
Within the context of this document, the words "client" and "server" refer to FTP client and server implementations, respectively. An FTP server is understood to be an implementation of the FTP protocol running on a server system with a stable address, waiting for clients to connect and issue commands that eventually start data transfers. Clients interact with servers using the FTP protocol, and store (upload) files to, and retrieve (download) files from one or more servers. This either happens interactively under control of a user, or is done as an unattended background process. Most operating systems provide a web browser that implements a basic FTP client, as well as a command line client. Third-party FTP clients are also widely available.
</t>
<t>
Other terminology is derived from the documents listed in the references section. Note that this document cannot be fully understood on its own; it depends on background and terminology outlined in the references.
</t>
</section>
<section title="ALG overview">
<t>
The most robust way to solve an IP version mismatch between FTP clients and FTP servers would be by changing clients and servers rather than using an IPv6-to-IPv4 translator for the data channel and using an application layer gateway on the control channel.
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.
</t>
<t>
On the other hand, network operators or even network administrators within an organization often have little influence over the FTP client and server implementations used over the network. For those operators and administrators, deploying an ALG may be the only way to provide a satisfactory customer experience. So, even though not the preferred solution, this document standardizes the functionality of such an ALG in order to promote consistent behavior between ALGs in an effort to minimize their harmful effects.
</t>
<t>
Operators and administrators are encouraged to only deploy an FTP ALG for IPv6-to-IPv4 translation when the FTP ALG is clearly needed. In the presence of the ALG, EPSV commands that could be handled directly by conforming servers are translated into PASV commands, introducing additional complexity and reducing robustness. As such a "set and forget" policy on ALGs is not recommended.
</t>
<t>
Note that the translation of EPSV through all translators and EPRT through a stateless translator is relatively simple but supporting translation of EPRT through a stateful translator is relatively difficult, because in the latter case a translation mapping must be set up for each data transfer using parameters that must be learned from the client/server interaction over the control channel. This needs to happen before the EPRT command can be translated into a PORT command and passed on to the server. 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.
</t>
<t>
The ALG functionality is described as a function separate from the IPv6-to-IPv4 translation function. However, in the case of EPRT translation, the ALG and translator functions need to be tightly coupled, so if EPRT translation is supported, it is assumed that the ALG and IPv6-to-IPv4 translation functions are integrated within a single device.
</t>
</section>
<section anchor="controlchanneltranslation" title="Control channel translation">
<t>
The IPv6-to-IPv4 FTP ALG intercepts all TCP sessions towards port 21 for IPv6 destination addresses that map to IPv4 destinations reachable through an IPv6-to-IPv4 translator. The FTP ALG implements the Telnet protocol (<xref target="RFC0854"></xref>) used for control channel interactions to the degree necessary to interpret commands and responses and re-issue those commands and responses, modifying them as outlined below. Telnet option negotiation attempts by either the client or the server, except for those allowed by <xref target="RFC1123"></xref>, MUST be rejected by the FTP ALG without relaying those attempts. This avoids the situation where the client and the server negotiate Telnet options that are unimplemented by the FTP ALG.
</t>
<t>
There are two ways to implement the control channel ALG:
</t>
<list style="numbers">
<t>
The ALG terminates the IPv6 TCP session, sets up a new IPv4 TCP session towards the IPv4 FTP server, and relays commands and responses back and forth between the two sessions.
</t>
<t>
Packets that are part of the control channel are translated individually.
</t>
</list>
<t>
As they ultimately provide the same result, either implementation strategy, or any other that is functionally equivalent, can be used.
</t>
<t>
In the second case, an implementation MUST have the ability to track and update TCP sequence numbers when translating packets as well as the ability to break up packets into smaller packets after translation, as the control channel translation could modify the length of the payload portion of the packets in question. Also, FTP commands/responses or Telnet negotiations could straddle packet boundaries, so in order to be able to perform the ALG function, it can prove necessary to reconstitute Telnet negotiations and FTP commands and responses from multiple packets.
</t>
<t>
If the client issues the AUTH command, then the client is attempting to negotiate <xref target="RFC2228" /> security mechanisms which are likely to be incompatible with the FTP ALG function. In this situation, the FTP ALG MUST switch to transparently forwarding all data on the control channel in both directions until the end of the control channel session. This requirement applies regardless of the response from the server. In other words, it is the fact that the client attempts the AUTH negotiation that requires the ALG to become transparent, whether or not the attempt is successful. The transparency requirement applies to the commands and responses flowing between the client and the server. It is possible that commands or responses that were sent through the ALG before the AUTH command was issued were changed in length so TCP sequence numbers in packets entering the ALG and packets exiting the ALG no longer match. In transparent mode, the ALG MUST continue to adjust sequence numbers if it was doing so before entering transparent mode as the result of the AUTH command. The ALGS command (<xref target="algs" />) can also be used to disable the ALG functionality, but the control channel MUST then still be monitored for subsequent ALGS commands that re-enable the ALG functionality.
</t>
<t>
There have been FTP ALGs for the purpose of making active FTP work through IPv4 NATs for a long time. Another type of ALG would be one that imposes restrictions required by security policies. Multiple ALGs of different types can be implemented as a single entity. If such a multi-purpose ALG forbids the use of the AUTH command for policy reasons, the side effect of making the ALG stop performing the translations described here, as well as other possible interventions related to IPv6-to-IPv4 translation, MUST be retained even if the ALG responds to the AUTH command with an error and does not propagate the command to the server. This way, any time a client issues the AUTH command, it knows that an ALG will be in transparent mode afterwards. Implementers are further advised that unlike hosts behind an IPv4 NAT, IPv6 hosts using an IPv6-to-IPv4 translator will normally have the ability to execute FTP over IPv6 without interference from the IPv6-to-IPv4 translator or the ALG, so an IPv6-to-IPv4 translation FTP ALG is not the best place to implement security policies.
</t>
<section anchor="lang" title="Language negotiation">
<t>
<xref target="RFC2640" /> specifies the ability for clients and servers to negotiate the language used between the two of them in the descriptive text that accompanies server response codes. Ideally, IPv6-to-IPv4 FTP ALGs would support this feature, so that if a non-default language is negotiated by a client and a server, the ALG also transmits its text messages for translated responses in the negotiated language. However, even if the ALG supports negotiation of the feature, there is no way to make sure that the ALG has text strings for all possible languages. So the situation where the client and server try to negotiate a language that the ALG doesn't support can't be avoided. The proper behavior for an FTP ALG in this situation may be addressed in a future specification, as the same issue is present in IPv4-to-IPv4 FTP ALGs.
For the time being, ALG implementations may employ one of the following strategies regarding LANG negotiation:
</t>
<list style="numbers">
<t>
Monitor LANG negotiation, and send text in the negotiated language if text in that language is available. If not, text is sent in the default language.
</t>
<t>
Not monitor LANG negotiation. Text is sent in the default language.
</t>
<t>
Block LANG negotiation by translating the LANG command to a NOOP command, and translating the resulting 200 response into a response appropriate for unsupported commands, such as 500. Text is sent in the default language.
</t>
</list>
<t>
In the first two cases, if a language is negotiated, text transmitted by the client or the server MUST be assumed to be encoded in UTF-8 rather than be limited to 7-bit ASCII. An ALG that implements the first or second option MUST translate and/or forward commands and responses containing UTF-8 encoded text when those occur. The ALG itself MUST NOT generate characters outside the 7-bit ASCII range unless it implements the first option and a language was negotiated.
</t>
<t>
Note that <xref target="RFC2640" /> section 3.1 specifies new handling for spaces and the CR character in path names. ALGs that don't block LANG negotiation SHOULD comply with the specified rules for path handling. Implementers should especially note that the NUL (%x00) character is used as an escape whenever a CR character occurs in a pathname.
</t>
</section>
<t>
In the sections that follow, a number of well-known response numbers are shown, along with the descriptive text that is associated with that response number. However, this text is not part of the specification of the response. As such, implementations MAY use the response text shown or they MAY show a different response text for a given response number. Requirements language only applies to the response number.
</t>
</section>
<section anchor="epsv2pasv" title="EPSV to PASV translation">
<t>
Although many IPv4 FTP servers support the EPSV command, some servers react adversely to this command (see <xref target="intro" /> for examples), and there is no reliable way to detect in advance that this will happen. As such, an FTP ALG SHOULD translate all occurrences of the EPSV command issued by the client to the PASV command, and reformat a 227 response as a corresponding 229 response. However, an ALG MAY forego EPSV to PASV translation if it has positive knowledge, either through administrative configuration or learned dynamically, that EPSV will be successful without translation to PASV.
</t>
<t>
For instance, if the client issues EPSV (or EPSV 2 to indicate IPv6 as the network protocol), this is translated to the PASV command. If the server with address 192.0.2.31 then responds with:
</t>
<list style="empty">
<t>
227 Entering Passive Mode (192,0,2,31,237,19)
</t>
</list>
<t>
The FTP ALG reformats this as:
</t>
<list style="empty">
<t>
229 Entering Extended Passive Mode (|||60691|)
</t>
</list>
<t>
The ALG SHOULD ignore the IPv4 address in the server's 227 response. This is the behavior that is exhibited by most clients and is needed to work with servers that include <xref target="RFC1918" /> addresses in their 227 responses. However, if the 227 response contains an IPv4 address that does not match the destination of the control channel, the FTP ALG MAY send a 425 response to the client instead of the 229 response, e.g.:
</t>
<list style="empty">
<t>
425 Can't open data connection
</t>
</list>
<t>
It is important that the response is in the 4xx range to indicate a temporary condition.
</t>
<t>
If the client issues an EPSV command with a numeric argument other than 2, the ALG MUST NOT pass the command on to the server, but rather respond with a 522 error, e.g.:
</t>
<list style="empty">
<t>
522 Network protocol not supported
</t>
</list>
<t>
If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command to the server, but respond with a 504 error, e.g.:
</t>
<list style="empty">
<t>
504 Command not implemented for that parameter
</t>
</list>
<t>
This avoids the situation where an FTP server reacts adversely to receiving a PASV command after the client used the EPSV ALL command to indicate that it will only use EPSV during this session.
</t>
</section>
<section title="EPRT to PORT translation">
<t>
Should the IPv6 client issue an EPRT command, the FTP ALG MAY translate this EPRT command to a PORT command. The translation is different depending on whether the translator is a stateless one-to-one translator or a stateful one-to-many translator.
</t>
<section title="Stateless EPRT translation">
<t>
If the address specified in the EPRT command is the IPv6 address used by the client for the control channel session, then the FTP ALG reformats the EPRT command into a PORT command with the IPv4 address that maps to the client's IPv6 address. The port number MUST be preserved for compatibility with stateless translators. For instance, if the client with IPv6 address 2001:db8:2::31 issues the following EPRT command:
</t>
<list style="empty">
<t>
EPRT |2|2001:db8:2::31|5282|
</t>
</list>
<t>
Assuming the IPv4 address that goes with 2001:db8:2::31 is 192.0.2.31, the FTP ALG reformats this as:
</t>
<list style="empty">
<t>
PORT 192,0,2,31,20,162
</t>
</list>
<t>
If the address specified in the EPRT command is an IPv4 address or an IPv6 address that is not the IPv6 address used by the client for the control session, the ALG SHOULD NOT attempt any translation, but pass along the command unchanged.
</t>
</section>
<section title="Stateful EPRT translation">
<t>
If the address in the EPRT command is the IPv6 address used by the client for the control channel, the stateful translator selects an unused port number in combination with the IPv4 address used for the control channel towards the FTP server, and sets up a mapping from that transport address to the one specified by the client in the EPRT command. The PORT command with the IPv4 address and port used on the IPv4 side of the mapping is only issued towards the server once the mapping is created. Initially, the mapping is such that either any transport address or the FTP server's IPv4 address with any port number is accepted as a source, but once the three-way handshake is complete, the mapping SHOULD be narrowed to only match the negotiated TCP session.
</t>
<t>
If the address specified in the EPRT command is an IPv4 address or an IPv6 address that is not the IPv6 address used by the client for the control session, the ALG SHOULD NOT attempt any translation, but pass along the command unchanged.
</t>
<t>
If the client with IPv6 address 2001:db8:2::31 issues the EPRT command:
</t>
<list style="empty">
<t>
EPRT |2|2001:db8:2::31|5282|
</t>
</list>
<t>
And the stateful translator uses the address 192.0.2.31 on its IPv4 interface, a mapping with destination address 192.0.2.31 and destination port 60192 towards 2001:db8:2::31 port 5282 may be created, after which the FTP ALG reformats the EPRT command as:
</t>
<list style="empty">
<t>
PORT 192,0,2,31,235,32
</t>
</list>
</section>
</section>
<section title="Default port 20 translation">
<t>
If the client does not issue an EPSV/PASV or EPRT/PORT command prior to initiating a file transfer, it is invoking the default active FTP behavior where the server sets up a TCP session towards the client. In this situation, the source port number is the default FTP data port (port 20) and the destination port is the port the client uses as the source port for the control channel session.
</t>
<t>
In the case of a stateless translator, this does not pose any problems. In the case of a stateful translator, the translator MAY accept incoming connection requests from the server on the IPv4 side if the transport addresses match that of an existing FTP control channel session, with the exception that the control channel session uses port 21 and the new session port 20. In this case, a mapping is set up towards the same transport address on the IPv6 side that is used for the matching FTP control channel session.
</t>
<t>
An ALG/translator MAY monitor the progress of FTP control channels and only attempt to perform a mapping when an FTP client has started a file transfer without issuing the EPSV, PASV, EPRT or PORT commands.
</t>
</section>
<section title="Both PORT and PASV">
<t>
<xref target="RFC0959" /> allows a client to issue both PORT and PASV to use non-default ports on both sides of the connection. However, this is incompatible with the notion that with PASV, the data connection is made from the client to the server, while PORT reaffirms the default behavior where the server connects to the client. As such, the behavior of an ALG is undefined when a client issues both PASV and PORT. 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.
</t>
</section>
<section title="Default behavior">
<t>
Whenever the client issues a command which the ALG is not set up to translate, either because the command is not specified in this document, the command is not part of any FTP specification, the ALG functionality is disabled administratively for the command in question, or translation does not apply for any other reason, the command MUST be passed on to the server without modification, and the server response MUST be passed on to the client without modification. For example, if the client issues the PASV command, this command is passed on to the server transparently, and the server's response to the client.
</t>
</section>
<section anchor="algs" title="The ALGS command">
<t>
ALGs MUST support the new ALGS (ALG status) command that allows
clients to query and set the ALG's status. FTP servers (as opposed
to ALGs) MUST NOT perform any actions upon receiving the ALGS
command. FTP servers MUST still send a response, however.
If FTP servers recognize the ALGS command, the best course
of action would be to return a 202 response:
</t>
<list style="empty">
<t>
202 Command not implemented, superfluous at this site
</t>
</list>
<t>
However, there is no reason for FTP servers to specifically recognize
this command; returning any 50x response that is normally returned when
commands are not recognized is appropriate.
</t>
<t>
A client can use the ALGS command to
request the ALG's status and to enable and disable EPSV to PASV and,
if implemented, EPRT to PORT translation. There are three possible
arguments to the ALGS command:
</t>
<list style="hanging" hangIndent="16">
<t hangText="ALGS STATUS64"><vspace />The ALG is requested to return the EPSV and EPRT translation status.</t>
<t hangText="ALGS ENABLE64"><vspace />The ALG is requested to enable translation.</t>
<t hangText="ALGS DISABLE64"><vspace />The ALG is requested to disable translation.</t>
</list>
<t>
The ALG MUST enable or disable EPSV to PASV translation as requested.
If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD enable
it and ALGS DISABLE64 SHOULD disable it along with enabling or
disabling EPSV to PASV translation, respectively. If EPRT to PORT
translation is not supported, ALGS ENABLE64 only enables EPSV to PASV
translation. After an ALGS command with any of the three supported
arguments, the ALG MUST return a 216 response indicating the type of
translation that will be performed.
</t>
<list style="hanging" hangIndent="16">
<t hangText="216 NONE"><vspace />Neither EPSV nor EPRT translation is performed.</t>
<t hangText="216 EPSV"><vspace />EPSV is translated to PASV, no EPRT translation is performed.</t>
<t hangText="216 EPRT"><vspace />EPRT is translated to PORT, no EPSV translation is performed.</t>
<t hangText="216 EPSVEPRT"><vspace />EPSV is translated to PASV, EPRT is translated to PORT.</t>
</list>
<t>
The translation type MAY be followed by a space and additional descriptive text until end-of-line.
If the ALG is unable to set the requested translation mode, for
instance, because of lack of certain resources, this is not
considered an error condition. In those
cases, the ALG responds with a 216 response followed by the keyword
that indicates the current translation status of the ALG.
</t>
<t>
If there is no argument to the ALGS command, or the argument is not one of STATUS64, ENABLE64 or DISABLE64 (or an argument specified by a supported newer document), a 504 or 502 error SHOULD be returned.
</t>
<t>
The Augmented Backus-Naur Form (ABNF) notation (see <xref target="RFC5234"/>)
of the ALGS command and its response are as follows:
</t>
<figure><artwork type="abnf">
algs-command = "ALGS" SP algs-token CRLF
algs-token = "STATUS64" / "ENABLE64" / "DISABLE64"
algs-response = (ok-response / error-response) CRLF
ok-response = "216" SP response-token [ freetext ]
response-token = "NONE" / "EPSV" / "EPRT" / "EPSVEPRT"
error-response = not-implemented / invalid-parameter
not-implemented = "502" [ freetext ]
invalid-parameter = "504" [ freetext ]
freetext = (SP *VCHAR)
</artwork></figure>
</section>
<section title="Timeouts and translating to NOOP">
<t>
Wherever possible, control channels SHOULD NOT time out while there is an active data channel. A timeout of at least 30 seconds is RECOMMENDED for data channel mappings created by the FTP ALG that are waiting for initial packets.
</t>
<t>
Whenever a command from the client is not propagated to the server, the FTP ALG instead issues a NOOP command in order to keep the keepalive state between the client and the server synchronized. The response to the NOOP command MUST NOT be relayed back to the client. An implementation MAY wait for the server to return the 200 response to the NOOP command and translate that 200 response into the response the ALG is required to return to the client. This way, the ALG never has to create new packets to send to the client, but it can limit itself to modifying packets transmitted by the server.
If the server responds with something other than 200 to the NOOP command, the ALG SHOULD tear down the control channel session and log an error.
</t>
</section>
<section title="IANA considerations">
<t>
IANA is requested to add to the FTP Commands and Extensions registry the following entry:
</t>
<list style="hanging" hangIndent="27">
<t hangText="Command Name"><vspace />ALGS</t>
<t hangText="FEAT Code"><vspace />-N/A-</t>
<t hangText="Description"><vspace />FTP64 ALG status</t>
<t hangText="Command Type"><vspace />-N/A-</t>
<t hangText="Conformance Requirements"><vspace />o</t>
<t hangText="Reference"><vspace />RFC TBD <xref target="algs" /></t>
</list>
<t>
[TO BE REMOVED: This registration should take place at the following location:
http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xhtml]
</t>
</section>
<section title="Security considerations">
<t>
In the majority of cases, FTP is used without further security mechanisms. This allows an attacker with passive interception capabilities to obtain the login credentials, and an attacker that can modify packets to change the data transferred. However, FTP can be used with TLS in order to solve these issues. IPv6-to-IPv4 translation and the FTP ALG do not impact the security issues in the former case nor the use of TLS in the latter case. However, if FTP is used with TLS as per <xref target="RFC4217" />, or another authentication mechanism that the ALG is aware of, the ALG function is not performed so only passive transfers from a server that implements EPSV or a client that supports PASV will succeed.
</t>
<t>
For general FTP security considerations, see <xref target="RFC2577" />.
</t>
</section>
<section title="Contributors">
<t>
Dan Wing, Kentaro Ebisawa, Remi Denis-Courmont,
Mayuresh Bakshi, Sarat Kamisetty, Reinaldo Penno, Alun Jones, Dave Thaler,
Mohammed Boucadair, Mikael Abrahamsson, Dapeng Liu, Michael Liu, Andrew Sullivan, Anthony Bryan and Ed Jankiewicz
contributed ideas and comments.
Dan Wing ran experiments with a large number of FTP servers that were very
illuminating; many of the choices underlying this document are based on
his results.
</t>
</section>
<section title="Acknowledgements">
<t>
Iljitsch van Beijnum is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc854;
&rfc959;
&rfc1123;
&rfc2119;
&rfc2228;
&rfc2428;
&rfc5234;
</references>
<references title="Informative References">
&rfc1918;
&rfc2389;
&rfc2577;
&rfc2640;
&rfc2765;
&rfc4217;
&I-D.ietf-behave-v6v4-xlate-stateful;
&I-D.ietf-behave-v6v4-xlate;
<reference anchor='I-D.liu-ftp64-extension'>
<front>
<title>FTP extension for IPv4/IPv6 transition</title>
<author initials='D' surname='Liu' fullname='Dapeng Liu'>
<organization />
</author>
<author initials='I' surname='Beijnum' fullname='Iljitsch van Beijnum'>
<organization />
</author>
<author initials='Z' surname='Cao' fullname='Zhen Cao'>
<organization />
</author>
<date month='October' day='17' year='2010' />
<abstract><t>The File transfer protocol, which is defined by the RFC 959, has a long history, but still being widely used. The original version of FTP specification defines IPv4 version of FTP. RFC 2428 defines IPv6 extensions of FTP, introducingEPRT and EPSV command. In the IPv6- IPv4 translation scenario, considerations should be applied to FTP client, server and translation box to ensure FTP protocol work properly. This document discusses the details for FTP to work in IPv4-IPv6 transitiion scenario. This document proposes to update IPv6 FTP client's specification to make it easier to work in 6to4 scenario.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-liu-ftp64-extension-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-liu-ftp64-extension-00.txt' />
</reference>
<reference anchor='Bernstein' target='http://cr.yp.to/ftp/security.html'>
<front>
<title>PASV security and PORT security</title>
<author initials="D. J." surname="Bernstein" fullname="D. J. Bernstein"/>
<date year='2000'/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:42:23 |