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
用于IPv6到IPv4转换的FTP应用层网关（ALG）
Abstract
摘要
The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers, FTP is still in common use. As such, 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）有着很长的历史，尽管今天存在其他选项来执行文件传输，但FTP仍在普遍使用。因此，在某些客户端计算机只有IPv6连接，而许多服务器仍然只有IPv4，并且使用IPv6到IPv4转换器来弥合这一差距的情况下，让FTP尽可能地通过这些转换器工作是很重要的。
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.
FTP具有主动和被动模式，既作为特定于IPv4的原始命令，也作为扩展的IP版本无关命令。通过IPv6到IPv4转换器工作而不进行更改的唯一FTP模式是扩展被动模式。但是，许多现有的FTP服务器不支持这种模式，有些客户端也不要求这种模式。本文档指定了一个可以解决此不匹配问题的中间盒。
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 http://www.rfc-editor.org/info/rfc6384.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6384.
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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请审阅这些文件
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.
请仔细阅读，因为他们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
[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.
2009年4月对25个随机挑选的和/或通过IPv4访问的知名FTP站点进行的调查显示，其中只有12个站点通过IPv4支持EPSV。此外，这12个中只有2个表示支持EPSV，以响应[RFC2389]中引入的FEAT命令，该命令要求服务器列出其支持的功能。一个支持EPSV，但不支持壮举。在5个案例中，向服务器发出EPSV命令导致了显著的延迟；在其中的3种情况下，控制通道在延迟后复位。由于缺乏其他信息，因此无法确定某些FTP服务器在发出EPSV命令一段时间后重置控制通道连接的原因。但是，一个合理的解释是，这些FTP服务器位于监控控制通道会话的应用程序感知防火墙后面，只允许创建到PASV（可能还有端口）命令响应中列出的端口的数据通道会话。由于对EPSV命令的响应不同（229代码而不是227代码），因此不知道EPSV命令的防火墙将阻止后续的数据通道设置尝试。如果一段时间后没有建立数据通道连接，FTP服务器可能会决定终止控制通道会话，以尝试离开此不明确状态。
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.
所有25台测试服务器都能够按照[RFC1123]的要求，在传统PASV被动模式下成功完成传输。更多的测试表明，在服务器中使用带有EPSV命令的address系列参数的做法普遍存在错误或未实现的情况。对更多服务器的额外测试表明，大约65%的FTP服务器成功支持EPSV，大约96%的服务器成功支持PASV。客户端没有经过广泛的测试，但作者以前的经验表明，大多数客户端都支持PASV，Windows附带的命令行客户端除外，它只支持活动模式。此FTP客户端在IPv4上运行时使用原始端口命令，在IPv6上运行时使用EPRT。
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.
希望参与更复杂行为（如服务器到服务器传输）的客户端可以通过发出ALGS命令使FTP应用层网关（ALG）进入透明模式，如第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].
本文档中的建议和规范适用于所有形式的IPv6到IPv4转换，包括无状态转换（如[RFC6145]）以及有状态转换（如[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.
本文档不涉及[RFC1639]中指定的LPRT和LPSV命令，因为这些命令似乎没有被大量使用。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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.
在本文档的上下文中，“客户端”和“服务器”分别指FTP客户端和服务器实现。FTP服务器被理解为在具有稳定地址的服务器系统上运行的FTP协议的实现，等待客户端连接并发出最终启动数据传输的命令。客户端使用FTP协议与服务器交互；它们将文件存储（上载）到一个或多个服务器，并从中检索（下载）文件。这要么在用户的控制下以交互方式进行，要么作为无人参与的后台进程进行。大多数操作系统都提供了一个web浏览器，它实现了基本的FTP客户端和命令行客户端。第三方FTP客户端也广泛可用。
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.
其他术语来源于参考资料部分列出的文件。请注意，本文件本身无法完全理解；这取决于参考文献中概述的背景和术语。
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.
解决FTP客户端和FTP服务器之间IP版本不匹配的最可靠方法是更改客户端和服务器，而不是为数据通道使用IPv6到IPv4转换器，并在控制通道上使用应用层网关。因此，建议尽可能根据IPv6到IPv4转换支持的需要更新FTP客户端和服务器，以便在不需要ALG的情况下正确操作FTP协议。
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
另一方面，组织内的网络运营商甚至网络管理员通常对网络上使用的FTP客户端和服务器实现几乎没有影响。对于这些操作员和管理员来说，部署ALG可能是解决问题的唯一方法
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.
提供令人满意的客户体验。因此，尽管不是首选解决方案，但本文件对此类ALG的功能进行了标准化，以促进ALG之间的一致行为，从而尽量减少其有害影响。
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.
请注意，通过所有翻译人员翻译EPSV和通过无状态翻译人员翻译EPRT相对简单，但通过有状态翻译人员支持EPRT翻译相对困难，因为在后一种情况下，必须使用必须通过控制通道从客户机/服务器交互中学习的参数为每次数据传输设置转换映射。这需要在EPRT命令转换为端口命令并传递到服务器之前完成。因此，与有状态翻译器一起使用的ALG必须支持EPSV翻译，并且可能支持EPRT翻译。但是，与无状态翻译器一起使用的ALG必须支持EPSV翻译，并且还应该支持EPRT翻译。
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.
ALG功能被描述为独立于IPv6到IPv4转换功能的功能。然而，在EPRT转换的情况下，ALG和转换器功能需要紧密耦合，因此如果支持EPRT转换，则假定ALG和IPv6到IPv4转换功能集成在单个设备中。
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 4.1.2.12. 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:
有两种方法可以实现控制通道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.
在第二种情况下，实现必须具有在转换数据包时跟踪和更新TCP序列号的能力，以及在转换后将数据包分解为更小的数据包的能力，因为控制信道转换可以修改所讨论数据包的有效负载部分的长度。此外，FTP命令/响应或Telnet协商可能跨越数据包边界，因此为了能够执行ALG功能，有必要从多个数据包中重新组合Telnet协商和FTP命令及响应。
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.
某些FTP客户端在中断传输时使用TCP紧急数据功能。ALG必须在转换控制通道交互时（即使跨越数据包边界时）保持紧急指针的语义，或者清除TCP报头中的URG位。
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.
ALG必须采用第一个选项，并允许客户端和服务器协商安全机制。为确保行为一致，一旦客户端发出初始AUTH命令，ALG必须停止转换命令和响应，并开始透明地将服务器发送的TCP数据复制到客户端，反之亦然。如果服务器响应在4xx或5xx范围内，ALG应忽略AUTH命令，而不进入透明模式。
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.
可能在发出AUTH命令之前通过ALG发送的命令或响应的长度发生了变化，因此进入ALG的数据包和退出ALG的数据包中的TCP序列号不再匹配。在透明模式下，ALG必须继续调整序列号，如果它在作为AUTH命令的结果进入透明模式之前这样做的话。ALGS命令（第11节）也可用于禁用ALG功能，但仍必须监控控制通道，以获取重新启用ALG功能的后续ALGS命令。
[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.
在前两种情况下，如果协商语言，则必须假定客户端或服务器传输的文本以UTF-8[RFC3629]编码，而不是限于7位ASCII。实现第一个或第二个选项的ALG必须翻译和/或转发包含UTF-8编码文本的命令和响应。ALG本身不得生成7位ASCII范围以外的字符，除非它实现了第一个选项并协商了一种语言。
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.
请注意，[RFC2640]的第3.1节指定了路径名中空格和回车符（CR）的新处理。不阻止LANG协商的ALG应遵守指定的路径处理规则。实现者应该特别注意，每当路径名中出现CR字符时，NUL（%x00）字符就用作转义符。
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.
在接下来的部分中，将显示一些众所周知的响应号，以及与该响应号相关联的描述性文本。但是，本文不是响应规范的一部分。因此，实现可以使用所示的响应文本，也可以针对给定的响应编号显示不同的响应文本。需求语言仅适用于响应编号。
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 192.0.2.31 then responds with:
例如，如果客户机发出EPSV（或EPSV 2以指示IPv6作为网络协议），这将转换为PASV命令。如果地址为192.0.2.31的服务器随后响应：
227 Entering Passive Mode (192,0,2,31,237,19)
227进入被动模式（192,0,2,31237,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
425无法打开数据连接
It is important that the response is in the 4xx range to indicate a temporary condition.
重要的是，响应应在4xx范围内，以指示临时状况。
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:
如果客户机发出的EPSV命令带有除2以外的数值参数，ALG不得将该命令传递给服务器，而是以522错误响应，例如：
522 Network protocol not supported
522不支持网络协议
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
504未对该参数执行命令
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命令作出不利反应的情况。
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命令转换为端口命令。根据翻译器是无状态的一对一翻译器还是有状态的一对多翻译器，翻译是不同的。
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 192.0.2.31, the FTP ALG reformats this as:
假设2001:db8:2:：31附带的IPv4地址为192.0.2.31，FTP ALG将其重新格式化为：
PORT 192,0,2,31,20,162
端口192,0,2,31,20162
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.
如果EPRT命令中指定的地址是IPv4地址或不是客户端用于控制会话的IPv6地址的IPv6地址，则ALG不应尝试任何转换，而应原封不动地传递该命令。
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.
如果EPRT命令中的地址是客户端用于控制通道的IPv6地址，则有状态转换器将选择一个未使用的端口号和用于控制通道的IPv4地址组合到FTP服务器，并设置从该传输地址到客户端在EPRT命令中指定的地址的映射。只有在创建映射后，才会向服务器发出具有IPv4地址和在映射的IPv4端使用的端口的PORT命令。最初，映射是这样的，即任何传输地址或具有任何端口号的FTP服务器的IPv4地址都可以被接受为源，但一旦三方握手完成，映射范围应缩小到仅匹配协商的TCP会话。
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.
如果EPRT命令中指定的地址是IPv4地址或不是客户端用于控制会话的IPv6地址的IPv6地址，则ALG不应尝试任何转换，而应原封不动地传递该命令。
If the client with IPv6 address 2001:db8:2::31 issues the EPRT command:
如果IPv6地址为2001:db8:2:：31的客户端发出EPRT命令：
EPRT |2|2001:db8:2::31|5282|
EPRT |2|2001:db8:2::31|5282|
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:
并且有状态转换器在其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
端口192,0,2,31235,32
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.
如果客户端在启动文件传输之前未发出EPSV/PASV或EPRT/PORT命令，则它将调用默认的活动FTP行为，其中服务器将向客户端设置TCP会话。
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.
在这种情况下，源端口号是默认的FTP数据端口（端口20），目标端口是客户端用作控制通道会话源端口的端口。
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.
对于无状态翻译器，这不会造成任何问题。在有状态转换器的情况下，如果传输地址与现有FTP控制通道会话的传输地址匹配，则转换器可以接受来自IPv4侧服务器的传入连接请求，但控制通道会话使用端口21和新会话端口20的情况除外。在这种情况下，将在IPv6端设置映射到用于匹配FTP控制通道会话的相同传输地址。
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.
ALG/转换器可以监视FTP控制通道的进度，并且仅在FTP客户端启动文件传输时才尝试执行映射，而不发出EPSV、PASV、EPRT或PORT命令。
[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.
[RFC0959]允许客户端同时发出端口和PASV以使用连接两侧的非默认端口。但是，这与使用PASV时，数据连接是从客户机到服务器，而端口重申服务器连接到客户机的默认行为的概念是不兼容的。因此，当客户端同时发出PASV和端口时，ALG的行为是未定义的。实现不应该试图检测在启动传输的命令之前发出PASV和PORT命令的情况，而是在命令发生时转换命令。因此，如果客户机发出PASV，则PASV将被转换为EPSV。如果在此之后，但在任何传输发生之前，客户端发出端口，并且ALG支持此会话的端口转换，则ALG将端口转换为EPRT。
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.
每当客户机发出ALG未设置为翻译的命令时（因为本文档中未指定该命令，该命令不属于任何FTP规范的一部分，该命令的ALG功能在管理上被禁用，或者翻译不适用于任何其他原因），命令必须在不修改的情况下传递到服务器，服务器响应必须在不修改的情况下传递到客户端。例如，如果客户机发出PASV命令，该命令将透明地传递给服务器，服务器的响应将透明地传递给客户机。
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
202命令未执行，在该站点是多余的
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.
但是，FTP服务器没有理由专门识别此命令；当命令无法识别时，返回通常返回的任何50倍响应是合适的。
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命令请求ALG的状态，并启用和禁用EPSV到PASV的转换，以及EPRT到端口的转换（如果实现）。ALGS命令有三个可能的参数：
ALGS STATUS64 The ALG is requested to return the EPSV and EPRT translation status.
ALGS状态64请求ALG返回EPSV和EPRT转换状态。
ALGS ENABLE64 The ALG is requested to enable translation.
ALG启用64请求ALG启用翻译。
ALGS DISABLE64 The ALG is requested to disable translation.
ALG禁用64请求ALG禁用翻译。
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或EPRT翻译均未执行。
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.
216 EPSVEPRT EPSV被翻译成PASV；EPRT被转换为端口。
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
翻译类型后面可以跟一个空格和额外的描述性文本，直到行尾。如果ALG无法设置请求的翻译模式，例如，由于缺少特定的
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.
资源，这不被视为错误条件。在这些情况下，ALG返回216响应，后跟指示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.
如果ALGS命令没有参数，或者参数不是STATUS64、ENABLE64或DISABLE64中的一个（或受支持的较新文档指定的参数），则应返回504或502错误。
The Augmented Backus-Naur Form (ABNF) notation (see [RFC5234]) of the ALGS command and its response are as follows:
ALGS命令的增广巴科斯诺尔形式（ABNF）符号（见[RFC5234]）及其响应如下：
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)
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应中断控制通道会话并记录错误。
IANA has added the following entry to the "FTP Commands and Extensions" registry:
IANA已将以下条目添加到“FTP命令和扩展”注册表中：
Command Name ALGS
命令名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节
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].
有关一般FTP安全注意事项，请参阅[RFC2577]。
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服务器的实验非常有启发性；这份文件的许多选择都是基于他的结果。
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，这是一个由欧盟委员会第七个框架计划支持的研究项目。
[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.
[RFC2228]Horowitz，M.，“FTP安全扩展”，RFC2228，1997年10月。
[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月。
[RFC1639] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994.
[RFC1639]Piscitello，D.，“大地址记录上的FTP操作（FOOBAR）”，RFC1639，1994年6月。
[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西班牙
EMail: iljitsch@muada.com
EMail: iljitsch@muada.com