Internet Engineering Task Force (IETF)                    I. van Beijnum
Request for Comments: 6384                      Institute IMDEA Networks
Category: Standards Track                                   October 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF)                    I. van Beijnum
Request for Comments: 6384                      Institute IMDEA Networks
Category: Standards Track                                   October 2011
ISSN: 2070-1721

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




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.


Status of This Memo


This is an Internet Standards Track document.


This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2011 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(自本文件出版之日起生效。请审阅这些文件

carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  ALG Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Control Channel Translation  . . . . . . . . . . . . . . . . .  5
     5.1.  Language Negotiation . . . . . . . . . . . . . . . . . . .  7
   6.  EPSV to PASV Translation . . . . . . . . . . . . . . . . . . .  8
   7.  EPRT to PORT Translation . . . . . . . . . . . . . . . . . . .  9
     7.1.  Stateless EPRT Translation . . . . . . . . . . . . . . . .  9
     7.2.  Stateful EPRT Translation  . . . . . . . . . . . . . . . . 10
   8.  Default Port 20 Translation  . . . . . . . . . . . . . . . . . 10
   9.  Both PORT and PASV . . . . . . . . . . . . . . . . . . . . . . 11
   10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 11
   11. The ALGS Command . . . . . . . . . . . . . . . . . . . . . . . 12
   12. Timeouts and Translating to NOOP . . . . . . . . . . . . . . . 13
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
   16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     17.2. Informative References . . . . . . . . . . . . . . . . . . 15
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  ALG Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Control Channel Translation  . . . . . . . . . . . . . . . . .  5
     5.1.  Language Negotiation . . . . . . . . . . . . . . . . . . .  7
   6.  EPSV to PASV Translation . . . . . . . . . . . . . . . . . . .  8
   7.  EPRT to PORT Translation . . . . . . . . . . . . . . . . . . .  9
     7.1.  Stateless EPRT Translation . . . . . . . . . . . . . . . .  9
     7.2.  Stateful EPRT Translation  . . . . . . . . . . . . . . . . 10
   8.  Default Port 20 Translation  . . . . . . . . . . . . . . . . . 10
   9.  Both PORT and PASV . . . . . . . . . . . . . . . . . . . . . . 11
   10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 11
   11. The ALGS Command . . . . . . . . . . . . . . . . . . . . . . . 12
   12. Timeouts and Translating to NOOP . . . . . . . . . . . . . . . 13
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
   16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     17.2. Informative References . . . . . . . . . . . . . . . . . . 15
1. Introduction
1. 介绍
   [RFC0959] specifies two modes of operation for FTP: active mode, in
   which the server connects back to the client, and passive mode, in
   which 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 with 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
   [RFC0959], incompatible with IPv6.  These issues were solved in
   [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.
   [RFC0959] specifies two modes of operation for FTP: active mode, in
   which the server connects back to the client, and passive mode, in
   which 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 with 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
   [RFC0959], incompatible with IPv6.  These issues were solved in
   [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.

A survey done in April 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 [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 of these cases, a control channel reset followed the delay. Due to lack of additional information, it is impossible to determine conclusively why certain FTP servers reset the control channel connection some time after issuing an EPSV command. However, a reasonable explanation would be that these FTP servers are located behind application-aware firewalls that monitor the control channel session and only allow the creation of data channel sessions to the ports listed in the responses to PASV (and maybe PORT) commands. As the response to an EPSV command is different (a 229 code rather than a 227 code), a firewall that is unaware of the EPSV command would block the subsequent data channel setup attempt. If no data channel connection has been established after some time, the FTP server may decide to terminate the control channel session in an attempt to leave this ambiguous state.


All 25 tested servers were able to successfully complete a transfer in traditional PASV passive mode as required by [RFC1123]. More testing showed that the use of an address family argument with the EPSV command is widely misimplemented or unimplemented in servers. 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 the author's previous experience 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.


Although these issues can and should be addressed by modifying clients and servers to support EPSV successfully, such modifications may not appear widely in a timely fashion. Also, network operators who may want to deploy IPv6-to-IPv4 translation generally do not 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.

尽管这些问题可以而且应该通过修改客户端和服务器来解决,以成功支持EPSV,但此类修改可能不会及时广泛出现。此外,可能希望部署IPv6到IPv4转换的网络运营商通常无法控制客户端或服务器实现。因此,本文档对FTP应用层网关(ALG)进行了标准化,当使用FTP在单个客户端和单个服务器之间进行简单的文件传输时,该网关将允许未修改的IPv6 FTP客户端与未修改的IPv4 FTP服务器成功交互。

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 the ALGS command as explained in Section 5.


The recommendations and specifications in this document apply to all forms of IPv6-to-IPv4 translation, including stateless translation such as [RFC6145] as well as stateful translation such as [RFC6146].


This documentation does not deal with the LPRT and LPSV commands specified in [RFC1639] as these commands do not appear to be in significant use.


2. Notational Conventions
2. 符号约定

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 [RFC2119].


3. Terminology
3. 术语

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; they 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.


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.


4. ALG Overview
4. ALG概述

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.


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.


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.

当明确需要FTP ALG时,鼓励运营商和管理员仅为IPv6到IPv4的转换部署FTP ALG。在ALG存在的情况下,可由一致性服务器直接处理的EPSV命令被转换为PASV命令,从而增加了复杂性并降低了健壮性。因此,不建议对ALG执行“设置并忘记”策略。

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 translation and MAY support EPRT translation. However, an ALG used with a stateless translator MUST support EPSV translation and SHOULD also support EPRT translation.


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.


5. Control Channel Translation
5. 控制通道转换

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 ([RFC0854]), 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 [RFC1123], MUST be refused by the FTP ALG without relaying those attempts. For the purpose of Telnet option negotiation, an FTP ALG MUST follow the behavior of an FTP server as specified in [RFC1123], Section This avoids the situation where the client and the server negotiate Telnet options that are unimplemented by the FTP ALG.

IPv6-to-IPv4 FTP ALG截获通向端口21的所有TCP会话,以查找映射到可通过IPv6-to-IPv4转换器访问的IPv4目标的IPv6目标地址。FTP ALG实现用于控制通道交互的Telnet协议([RFC0854]),达到解释命令和响应并重新发出这些命令和响应所需的程度,并按如下所述对其进行修改。FTP ALG必须拒绝客户机或服务器的Telnet选项协商尝试(RFC1123允许的尝试除外),而不中继这些尝试。就Telnet选项协商而言,FTP ALG必须遵循[RFC1123]第4.1.2.12节中规定的FTP服务器行为。这避免了客户端和服务器协商FTP ALG未实现的Telnet选项的情况。

There are two ways to implement the control channel ALG:


1. 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.

1. ALG终止IPv6 TCP会话,向IPv4 FTP服务器建立新的IPv4 TCP会话,并在两个会话之间来回转发命令和响应。

2. Packets that are part of the control channel are translated individually.

2. 作为控制通道一部分的数据包被单独翻译。

As they ultimately provide the same result, either implementation strategy, or any other that is functionally equivalent, can be used.


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.


Some FTP clients use the TCP urgent data feature when interrupting transfers. An ALG MUST either maintain the semantics of the urgent pointer when translating control channel interactions, even when crossing packet boundaries, or clear the URG bit in the TCP header.


If the client issues the AUTH command, then the client is attempting to negotiate [RFC2228] security mechanisms that are likely to be incompatible with the FTP ALG function. For instance, if the client attempts to negotiate Transport Layer Security (TLS) protection of the control channel ([RFC4217]), an ALG can do one of three things:

如果客户端发出AUTH命令,则客户端正试图协商可能与FTP ALG功能不兼容的[RFC2228]安全机制。例如,如果客户端尝试协商控制通道的传输层安全(TLS)保护([RFC4217]),ALG可以执行以下三项操作之一:

1. Transparently copy data transmitted over the control channel back and forth, so the TLS session works as expected but the client commands and server responses are now hidden from the ALG.

1. 透明地来回复制通过控制通道传输的数据,因此TLS会话可以按预期工作,但客户端命令和服务器响应现在对ALG隐藏。

2. Block the negotiation of additional security, which will likely make the client and/or the server break off the session, or if not, perform actions in the clear that were supposed to be encrypted.

2. 阻止额外安全性的协商,这可能会使客户端和/或服务器中断会话,或者如果没有中断,则执行本应加密的清除操作。

3. Negotiate with both the client and the server so two separate protected sessions are set up and the ALG is still able to modify client commands and server responses. Again, clients and servers are likely to reject the session because this will be perceived as a man-in-the-middle attack.

3. 与客户端和服务器协商,以便设置两个单独的受保护会话,并且ALG仍然能够修改客户端命令和服务器响应。同样,客户端和服务器可能会拒绝会话,因为这将被视为中间人攻击。

An ALG MUST adopt the first option and allow a client and a server to negotiate security mechanisms. To ensure consistent behavior, as soon as the initial AUTH command is issued by the client, an ALG MUST stop translating commands and responses, and start transparently copying TCP data sent by the server to the client and vice versa. The ALG SHOULD ignore the AUTH command and not go into transparent mode if the server response is in the 4xx or 5xx ranges.


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 (Section 11) 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.


5.1. Language Negotiation
5.1. 语言谈判

[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. Thus, the situation where the client and server try to negotiate a language not supported by the ALG is unavoidable. 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:

[RFC2640]指定客户端和服务器在服务器响应代码附带的描述性文本中协商两者之间使用的语言的能力。理想情况下,IPv6-to-IPv4 FTP ALG将支持此功能,因此,如果客户机和服务器协商非默认语言,ALG也会传输其文本消息,以便以协商语言进行翻译响应。但是,即使ALG支持特性协商,也无法确保ALG具有所有可能语言的文本字符串。因此,客户端和服务器尝试协商ALG不支持的语言的情况是不可避免的。FTP ALG在这种情况下的正确行为可能会在未来的规范中解决,因为IPv4到IPv4 FTP ALG中也存在同样的问题。目前,ALG实现可能会采用以下关于语言协商的策略之一:

1. 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.

1. 监控语言协商并发送协商语言的文本(如果该语言的文本可用)。如果不是,则以默认语言发送文本。

2. Not monitor LANG negotiation. Text is sent in the default language.

2. 不监督谈判。文本以默认语言发送。

3. Block LANG negotiation by translating the LANG command to a NOOP command and translating the resulting 200 response into a 502 response, which is appropriate for unsupported commands. Text is sent in the default language.

3. 通过将LANG命令转换为NOOP命令并将生成的200响应转换为502响应(适用于不受支持的命令),阻止LANG协商。文本以默认语言发送。

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 [RFC3629] 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.


Note that Section 3.1 of [RFC2640] specifies new handling for spaces and the carriage return (CR) character in pathnames. ALGs that do not 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.


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.


6. EPSV to PASV Translation

Although many IPv4 FTP servers support the EPSV command, some servers react adversely to this command (see Section 1 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 gained through administrative configuration or learned dynamically, that EPSV will be successful without translation to PASV.

尽管许多IPv4 FTP服务器支持EPSV命令,但一些服务器对此命令做出了负面反应(示例请参见第1节),并且没有可靠的方法提前检测到这种情况。因此,FTP ALG应将客户端发出的所有EPSV命令转换为PASV命令,并将227响应重新格式化为相应的229响应。然而,如果ALG通过管理配置或动态学习获得了EPSV在不转换为PASV的情况下会成功的积极知识,则ALG可能会放弃EPSV到PASV的转换。

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 then responds with:

例如,如果客户机发出EPSV(或EPSV 2以指示IPv6作为网络协议),这将转换为PASV命令。如果地址为192.0.2.31的服务器随后响应:

227 Entering Passive Mode (192,0,2,31,237,19)


The FTP ALG reformats this as:

FTP ALG将其重新格式化为:

229 Entering Extended Passive Mode (|||60691|)

229进入扩展被动模式(| | | 60691 |)

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 [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, for example:

ALG应该忽略服务器227响应中的IPv4地址。这是大多数客户机所展示的行为,并且需要与在其227响应中包含[RFC1918]地址的服务器一起工作。然而,如果227响应包含与控制信道的目的地不匹配的IPv4地址,则FTP ALG可以向客户端发送425响应而不是229响应,例如:

425 Can't open data connection


It is important that the response is in the 4xx range to indicate a temporary condition.


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, for example:


522 Network protocol not supported


If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command to the server, but respond with a 504 error, for example:

如果客户机发出EPSV ALL,FTP ALG不得将此命令传递给服务器,而是以504错误响应,例如:

504 Command not implemented for that parameter


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.

这避免了FTP服务器在客户端使用EPSV ALL命令指示它将在此会话期间仅使用EPSV后,对接收到PASV命令作出不利反应的情况。

7. EPRT to PORT Translation
7. 端口转换

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.

如果IPv6客户端发出EPRT命令,FTP ALG可以将该EPRT命令转换为端口命令。根据翻译器是无状态的一对一翻译器还是有状态的一对多翻译器,翻译是不同的。

7.1. Stateless EPRT Translation
7.1. 无状态EPRT翻译

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:

如果EPRT命令中指定的地址是客户端用于控制通道会话的IPv6地址,则FTP ALG将EPRT命令重新格式化为端口命令,该端口命令具有映射到客户端IPv6地址的IPv4地址。为了与无状态转换器兼容,必须保留端口号。例如,如果IPv6地址为2001:db8:2::31的客户端发出以下EPRT命令:

      EPRT |2|2001:db8:2::31|5282|
      EPRT |2|2001:db8:2::31|5282|

Assuming the IPv4 address that goes with 2001:db8:2::31 is, the FTP ALG reformats this as:

假设2001:db8:2::31附带的IPv4地址为192.0.2.31,FTP ALG将其重新格式化为:

PORT 192,0,2,31,20,162


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.


7.2. Stateful EPRT Translation
7.2. 有状态EPRT翻译

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.


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.


If the client with IPv6 address 2001:db8:2::31 issues the EPRT command:


      EPRT |2|2001:db8:2::31|5282|
      EPRT |2|2001:db8:2::31|5282|

And the stateful translator uses the address on its IPv4 interface, a mapping with destination address and destination port 60192 towards 2001:db8:2::31 port 5282 may be created, after which the FTP ALG reformats the EPRT command as:

并且有状态转换器在其IPv4接口上使用地址192.0.2.31,可以创建目标地址192.0.2.31和目标端口60192到2001:db8:2::31端口5282的映射,之后FTP ALG将EPRT命令重新格式化为:

PORT 192,0,2,31,235,32


8. Default Port 20 Translation
8. 默认端口20转换

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.


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.


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.


9. Both PORT and PASV
9. 端口和PASV

[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, translate commands as they occur. So, if a client issues PASV, PASV is then translated to EPSV. If after that, but before any transfers have occurred, the client issues PORT and the ALG supports PORT translation for this session, the ALG translates PORT to EPRT.


10. Default Behavior
10. 默认行为

Whenever the client issues a command that the ALG is not set up to translate (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 is passed on to the client transparently.


11. The ALGS Command
11. ALGS命令

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. However, FTP servers MUST still send a response. If FTP servers recognize the ALGS command, the best course of action would be to return a 202 response:

ALG必须支持新的ALG(ALG status)命令,该命令允许客户端查询和设置ALG的状态。FTP服务器(与ALGs相反)在收到ALGs命令后不得执行任何操作。但是,FTP服务器仍必须发送响应。如果FTP服务器识别ALGS命令,最好的做法是返回202响应:

202 Command not implemented, superfluous at this site


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.


A client can use the ALGS command to request the ALG's status and to enable and disable EPSV to PASV translation and, if implemented, EPRT to PORT translation. There are three possible arguments to the ALGS command:


ALGS STATUS64 The ALG is requested to return the EPSV and EPRT translation status.


ALGS ENABLE64 The ALG is requested to enable translation.


ALGS DISABLE64 The ALG is requested to disable translation.


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 MUST 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.

ALG必须根据请求启用或禁用EPSV到PASV的转换。如果支持EPRT到端口转换,ALGS ENABLE64应启用该转换,ALGS DISABLE64必须分别在启用或禁用EPSV到PASV转换时禁用该转换。如果不支持EPRT到端口的转换,ALGS ENABLE64仅启用EPSV到PASV的转换。使用三个受支持的参数中的任何一个执行ALGS命令后,ALG必须返回216响应,指示将执行的翻译类型。

216 NONE Neither EPSV nor EPRT translation is performed.


216 EPSV EPSV is translated to PASV; no EPRT translation is performed.

216 EPSV EPSV被翻译成PASV;未执行EPRT翻译。

216 EPSVEPRT EPSV is translated to PASV; EPRT is translated to PORT.


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 returns a 216 response followed by the keyword that indicates the current translation status of the ALG.


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.


The Augmented Backus-Naur Form (ABNF) notation (see [RFC5234]) of the ALGS command and its response are as follows:


   algs-command      = "ALGS" SP algs-token CRLF
   algs-token        = "STATUS64" / "ENABLE64" / "DISABLE64"
   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" / "EPSVEPRT"
   error-response    = not-implemented / invalid-parameter
   not-implemented   = "502" [ freetext ]
   invalid-parameter = "504" [ freetext ]
   freetext          = (SP *VCHAR)
   algs-response     = (ok-response / error-response) CRLF
   ok-response       = "216" SP response-token [ freetext ]
   response-token    = "NONE" / "EPSV" / "EPSVEPRT"
   error-response    = not-implemented / invalid-parameter
   not-implemented   = "502" [ freetext ]
   invalid-parameter = "504" [ freetext ]
   freetext          = (SP *VCHAR)
12. Timeouts and Translating to NOOP
12. 超时和转换为NOOP

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.

在可能的情况下,当存在活动数据通道时,控制通道不应超时。对于等待初始数据包的FTP ALG创建的数据通道映射,建议至少超时30秒。

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 a 200 response to the NOOP command, the ALG SHOULD tear down the control channel session and log an error.

每当来自客户端的命令没有传播到服务器时,FTP ALG就会发出NOOP命令,以保持客户端和服务器之间的keepalive状态同步。对NOOP命令的响应不得中继回客户端。实现可以等待服务器将200响应返回到NOOP命令,并将该200响应转换为ALG需要返回到客户端的响应。这样,ALG就不必创建新的数据包来发送给客户机,但它可以限制自己修改服务器发送的数据包。如果服务器对NOOP命令的响应不是200,则ALG应中断控制通道会话并记录错误。

13. IANA Considerations
13. IANA考虑

IANA has added the following entry to the "FTP Commands and Extensions" registry:


Command Name ALGS


FEAT Code -N/A-


Description FTP64 ALG status

说明FTP64 ALG状态

Command Type -N/A-


Conformance Requirements o


Reference RFC 6384 Section 11

参考RFC 6384第11节

14. Security Considerations
14. 安全考虑

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 [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.

在大多数情况下,使用FTP时没有进一步的安全机制。这使具有被动拦截功能的攻击者能够获得登录凭据,并使攻击者能够修改数据包以更改传输的数据。但是,FTP可以与TLS一起使用,以解决这些问题。IPv6到IPv4的转换和FTP ALG不会影响前一种情况下的安全问题,也不会影响后一种情况下TLS的使用。但是,如果按照[RFC4217]或ALG知道的其他身份验证机制,将FTP与TLS一起使用,则不会执行ALG功能,因此只有来自实现EPSV的服务器或支持PASV的客户端的被动传输才会成功。

For general FTP security considerations, see [RFC2577].


15. Contributors
15. 贡献者

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, Ed Jankiewicz Pekka Savola, Fernando Gont, Rockson Li, and Donald Eastlake contributed ideas and comments. Dan Wing's experiments with a large number of FTP servers were very illuminating; many of the choices underlying this document are based on his results.

Dan Wing、Kentaro Ebisawa、Remi Denis Courmon、Mayuresh Bakshi、Sarat Kamisetty、Reinaldo Penno、Alun Jones、Dave Thaler、Mohammed Boucadair、Mikael Abrahamsson、Dapeng Liu、Michael Liu、Andrew Sullivan、Anthony Bryan、Ed Jankiewicz Pekka Savola、Fernando Gont、Rockson Li和Donald Eastlake提出了一些想法和评论。Dan Wing对大量FTP服务器的实验非常有启发性;这份文件的许多选择都是基于他的结果。

16. Acknowledgements
16. 致谢

Iljitsch van Beijnum is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.

Iljitsch van Beijnum的部分资金来自Trilogy,这是一个由欧盟委员会第七个框架计划支持的研究项目。

17. References
17. 工具书类
17.1. Normative References
17.1. 规范性引用文件

[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.

[RFC0854]Postel,J.和J.Reynolds,“Telnet协议规范”,STD 8,RFC 854,1983年5月。

[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.

[RFC0959]Postel,J.和J.Reynolds,“文件传输协议”,标准9,RFC 959,1985年10月。

[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

[RFC1123]Braden,R.,“互联网主机的要求-应用和支持”,STD 3,RFC 1123,1989年10月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, October 1997.


[RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998.

[RFC2428]Allman,M.,Ostermann,S.,和C.Metz,“IPv6和NAT的FTP扩展”,RFC 24281998年9月。

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

[RFC3629]Yergeau,F.,“UTF-8,ISO 10646的转换格式”,STD 63,RFC 3629,2003年11月。

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5234]Crocker,D.和P.Overell,“语法规范的扩充BNF:ABNF”,STD 68,RFC 5234,2008年1月。

17.2. Informative References
17.2. 资料性引用

[RFC1639] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994.


[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC1918]Rekhter,Y.,Moskowitz,R.,Karrenberg,D.,Groot,G.,和E.Lear,“私人互联网地址分配”,BCP 5,RFC 1918,1996年2月。

[RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998.

[RFC2389]Hethmon,P.和R.Elz,“文件传输协议的特征协商机制”,RFC 2389,1998年8月。

[RFC2577] Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, May 1999.

[RFC2577]Allman,M.和S.Ostermann,“FTP安全注意事项”,RFC 2577,1999年5月。

[RFC2640] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999.

[RFC2640]Curtin,B.,“文件传输协议的国际化”,RFC 26401999年7月。

[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.

[RFC4217]Ford Hutchinson,P.,“使用TLS保护FTP”,RFC 42172005年10月。

[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.

[RFC6145]Li,X.,Bao,C.,和F.Baker,“IP/ICMP翻译算法”,RFC 61452011年4月。

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.

[RFC6146]Bagnulo,M.,Matthews,P.,和I.van Beijnum,“有状态NAT64:从IPv6客户端到IPv4服务器的网络地址和协议转换”,RFC 61462011年4月。

Author's Address


Iljitsch van Beijnum Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain

Iljitsch van Beijnum研究所IMDEA Networks Avda。德尔马尔地中海,22勒加内斯,马德里28918西班牙