Network Working Group M. Allman
Request for Comments: 2428 NASA Lewis/Sterling Software
Category: Standards Track S. Ostermann
Ohio University
C. Metz
The Inner Net
September 1998
Network Working Group M. Allman
Request for Comments: 2428 NASA Lewis/Sterling Software
Category: Standards Track S. Ostermann
Ohio University
C. Metz
The Inner Net
September 1998
FTP Extensions for IPv6 and NATs
IPv6和NAT的FTP扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
The specification for the File Transfer Protocol assumes that the underlying network protocol uses a 32-bit network address (specifically IP version 4). With the deployment of version 6 of the Internet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. In addition, the framework defined can support additional network protocols in the future.
文件传输协议的规范假定基础网络协议使用32位网络地址（特别是IP版本4）。随着Internet协议版本6的部署，网络地址将不再是32位。本文指定了允许协议在IPv4和IPv6上工作的FTP扩展。此外，定义的框架可以在将来支持其他网络协议。
The keywords, such as MUST and SHOULD, found in this document are used as defined in RFC 2119 [Bra97].
本文档中的关键词，如必须和应该，按照RFC 2119[Bra97]中的定义使用。
The File Transfer Protocol [PR85] only provides the ability to communicate information about IPv4 data connections. FTP assumes network addresses will be 32 bits in length. However, with the deployment of version 6 of the Internet Protocol [DH96] addresses will no longer be 32 bits long. RFC 1639 [Pis94] specifies extensions to FTP to enable its use over various network protocols. Unfortunately, the mechanism can fail in a multi-protocol environment. During the transition between IPv4 and IPv6, FTP needs the ability to negotiate the network protocol that will be used for data transfer.
文件传输协议[PR85]仅提供有关IPv4数据连接的通信信息。FTP假定网络地址的长度为32位。然而，随着第6版互联网协议的部署，[DH96]地址将不再是32位长。RFC1639[Pis94]指定了FTP的扩展，以使其能够通过各种网络协议使用。不幸的是，该机制在多协议环境中可能会失败。在IPv4和IPv6之间的过渡期间，FTP需要能够协商将用于数据传输的网络协议。
This document provides a specification for a way that FTP can communicate data connection endpoint information for network protocols other than IPv4. In this specification, the FTP commands PORT and PASV are replaced with EPRT and EPSV, respectively. This document is organized as follows. Section 2 outlines the EPRT command and Section 3 outlines the EPSV command. Section 4 defines the utilization of these two new FTP commands. Section 5 briefly presents security considerations. Finally, Section 6 provides conclusions.
本文档提供了一种规范，说明了FTP可以为IPv4以外的网络协议传递数据连接端点信息的方法。在本规范中，FTP命令PORT和PASV分别替换为EPRT和EPSV。本文件的组织结构如下。第2节概述了EPRT命令，第3节概述了EPSV命令。第4节定义了这两个新FTP命令的使用。第5节简要介绍了安全注意事项。最后，第6节给出了结论。
The EPRT command allows for the specification of an extended address for the data connection. The extended address MUST consist of the network protocol as well as the network and transport addresses. The format of EPRT is:
EPRT命令允许为数据连接指定扩展地址。扩展地址必须包括网络协议以及网络和传输地址。EPRT的格式为：
EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
The EPRT command keyword MUST be followed by a single space (ASCII 32). Following the space, a delimiter character (<d>) MUST be specified. The delimiter character MUST be one of the ASCII characters in range 33-126 inclusive. The character "|" (ASCII 124) is recommended unless it coincides with a character needed to encode the network address.
EPRT命令关键字后面必须跟一个空格（ASCII 32）。空格后必须指定分隔符（<d>）。分隔符字符必须是33-126（含）范围内的ASCII字符之一。建议使用字符“|”（ASCII 124），除非它与编码网络地址所需的字符一致。
The <net-prt> argument MUST be an address family number defined by IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the writing of this document). This number indicates the protocol to be used (and, implicitly, the address length). This document will use two of address family numbers from [RP94] as examples, according to the following table:
<net prt>参数必须是IANA在最新的分配编号RFC（本文档撰写时的RFC 1700[RP94]）中定义的地址族编号。此数字表示要使用的协议（以及隐式的地址长度）。本文件将使用[RP94]中的两个地址系列号作为示例，如下表所示：
AF Number Protocol
--------- --------
1 Internet Protocol, Version 4 [Pos81a]
2 Internet Protocol, Version 6 [DH96]
AF Number Protocol
--------- --------
1 Internet Protocol, Version 4 [Pos81a]
2 Internet Protocol, Version 6 [DH96]
The <net-addr> is a protocol specific string representation of the network address. For the two address families specified above (AF Number 1 and 2), addresses MUST be in the following format:
<net addr>是网络地址的特定于协议的字符串表示形式。对于上面指定的两个地址系列（AF编号1和2），地址必须采用以下格式：
AF Number Address Format Example
--------- -------------- -------
1 dotted decimal 132.235.1.2
2 IPv6 string 1080::8:800:200C:417A
representations
defined in [HD96]
AF Number Address Format Example
--------- -------------- -------
1 dotted decimal 132.235.1.2
2 IPv6 string 1080::8:800:200C:417A
representations
defined in [HD96]
The <tcp-port> argument must be the string representation of the number of the TCP port on which the host is listening for the data connection.
<tcp port>参数必须是主机正在侦听数据连接的tcp端口号的字符串表示形式。
The following are sample EPRT commands:
以下是示例EPRT命令：
EPRT |1|132.235.1.2|6275|
EPRT | 1 | 132.235.1.2 | 6275|
EPRT |2|1080::8:800:200C:417A|5282|
EPRT |2|1080::8:800:200C:417A|5282|
The first command specifies that the server should use IPv4 to open a data connection to the host "132.235.1.2" on TCP port 6275. The second command specifies that the server should use the IPv6 network protocol and the network address "1080::8:800:200C:417A" to open a TCP data connection on port 5282.
第一个命令指定服务器应使用IPv4打开到TCP端口6275上主机“132.235.1.2”的数据连接。第二个命令指定服务器应使用IPv6网络协议和网络地址“1080:：8:800:200C:417A”在端口5282上打开TCP数据连接。
Upon receipt of a valid EPRT command, the server MUST return a code of 200 (Command OK). The standard negative error code 500 and 501 [PR85] are sufficient to handle most errors (e.g., syntax errors) involving the EPRT command. However, an additional error code is needed. The response code 522 indicates that the server does not support the requested network protocol. The interpretation of this new error code is:
收到有效的EPRT命令后，服务器必须返回代码200（命令OK）。标准的负错误代码500和501[PR85]足以处理涉及EPRT命令的大多数错误（例如语法错误）。但是，需要额外的错误代码。响应代码522指示服务器不支持请求的网络协议。此新错误代码的解释如下：
5yz Negative Completion x2z Connections xy2 Extended Port Failure - unknown network protocol
5yz负完成x2z连接xy2扩展端口故障-未知网络协议
The text portion of the response MUST indicate which network protocols the server does support. If the network protocol is unsupported, the format of the response string MUST be:
响应的文本部分必须指明服务器支持哪些网络协议。如果不支持网络协议，则响应字符串的格式必须为：
<text stating that the network protocol is unsupported> \ (prot1,prot2,...,protn)
<text说明网络协议不受支持>\（prot1，prot2，…，protn）
Both the numeric code specified above and the protocol information between the characters '(' and ')' are intended for the software automata receiving the response; the textual message between the numeric code and the '(' is intended for the human user and can be any arbitrary text, but MUST NOT include the characters '(' and ')'. In the above case, the text SHOULD indicate that the network protocol in the EPRT command is not supported by the server. The list of protocols inside the parenthesis MUST be a comma separated list of address family numbers. Two example response strings follow:
上面指定的数字代码和字符“（”和“）”之间的协议信息都是用于接收响应的软件自动机的；数字代码和“（”之间的文本消息适用于人类用户，可以是任意文本，但不得包含字符“（”和“）“。在上述情况下，文本应表明服务器不支持EPRT命令中的网络协议。括号内的协议列表必须是以逗号分隔的地址系列号列表。下面是两个响应字符串示例：
Network protocol not supported, use (1)
不支持网络协议，请使用（1）
Network protocol not supported, use (1,2)
不支持网络协议，请使用（1,2）
The EPSV command requests that a server listen on a data port and wait for a connection. The EPSV command takes an optional argument. The response to this command includes only the TCP port number of the listening connection. The format of the response, however, is similar to the argument of the EPRT command. This allows the same parsing routines to be used for both commands. In addition, the format leaves a place holder for the network protocol and/or network address, which may be needed in the EPSV response in the future. The response code for entering passive mode using an extended address MUST be 229. The interpretation of this code, according to [PR85] is:
EPSV命令请求服务器监听数据端口并等待连接。EPSV命令接受一个可选参数。对此命令的响应仅包括侦听连接的TCP端口号。但是，响应的格式类似于EPRT命令的参数。这允许对这两个命令使用相同的解析例程。此外，该格式为网络协议和/或网络地址留有一个占位符，这在将来的EPSV响应中可能需要。使用扩展地址进入被动模式的响应代码必须为229。根据[PR85]，本规范的解释为：
2yz Positive Completion x2z Connections xy9 Extended Passive Mode Entered
2yz正向完成x2z连接xy9扩展被动模式已进入
The text returned in response to the EPSV command MUST be:
响应EPSV命令返回的文本必须是：
<text indicating server is entering extended passive mode> \
(<d><d><d><tcp-port><d>)
<text indicating server is entering extended passive mode> \
(<d><d><d><tcp-port><d>)
The portion of the string enclosed in parentheses MUST be the exact string needed by the EPRT command to open the data connection, as specified above.
括号中的字符串部分必须是EPRT命令打开数据连接所需的确切字符串，如上所述。
The first two fields contained in the parenthesis MUST be blank. The third field MUST be the string representation of the TCP port number on which the server is listening for a data connection. The network protocol used by the data connection will be the same network protocol used by the control connection. In addition, the network address used to establish the data connection will be the same network address used for the control connection. An example response string follows:
括号中包含的前两个字段必须为空。第三个字段必须是服务器正在侦听数据连接的TCP端口号的字符串表示形式。数据连接使用的网络协议将与控制连接使用的网络协议相同。此外，用于建立数据连接的网络地址将与用于控制连接的网络地址相同。下面是一个响应字符串示例：
Entering Extended Passive Mode (|||6446|)
进入扩展被动模式（| | | 6446 |）
The standard negative error codes 500 and 501 are sufficient to handle all errors involving the EPSV command (e.g., syntax errors).
标准的负错误代码500和501足以处理涉及EPSV命令的所有错误（例如语法错误）。
When the EPSV command is issued with no argument, the server will choose the network protocol for the data connection based on the protocol used for the control connection. However, in the case of proxy FTP, this protocol might not be appropriate for communication between the two servers. Therefore, the client needs to be able to request a specific protocol. If the server returns a protocol that is not supported by the host that will be connecting to the port, the
当发出无参数的EPSV命令时，服务器将根据用于控制连接的协议选择数据连接的网络协议。但是，在代理FTP的情况下，此协议可能不适用于两台服务器之间的通信。因此，客户机需要能够请求特定的协议。如果服务器返回将连接到端口的主机不支持的协议，则
client MUST issue an ABOR (abort) command to allow the server to close down the listening connection. The client can then send an EPSV command requesting the use of a specific network protocol, as follows:
客户端必须发出ABOR（abort）命令，以允许服务器关闭侦听连接。然后，客户端可以发送一个EPSV命令，请求使用特定的网络协议，如下所示：
EPSV<space><net-prt>
EPSV<space><net-prt>
If the requested protocol is supported by the server, it SHOULD use the protocol. If not, the server MUST return the 522 error messages as outlined in section 2.
如果服务器支持请求的协议，则应使用该协议。如果没有，服务器必须返回第2节中概述的522错误消息。
Finally, the EPSV command can be used with the argument "ALL" to inform Network Address Translators that the EPRT command (as well as other data commands) will no longer be used. An example of this command follows:
最后，EPSV命令可以与参数“ALL”一起使用，以通知网络地址转换器EPRT命令（以及其他数据命令）将不再使用。此命令的示例如下所示：
EPSV<space>ALL
EPSV<space>ALL
Upon receipt of an EPSV ALL command, the server MUST reject all data connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, et al.). This use of the EPSV command is further explained in section 4.
收到EPSV ALL命令后，服务器必须拒绝EPSV以外的所有数据连接设置命令（即EPRT、端口、PASV等）。EPSV命令的使用将在第4节中进一步解释。
For all FTP transfers where the control and data connection(s) are being established between the same two machines, the EPSV command MUST be used. Using the EPSV command benefits performance of transfers that traverse firewalls or Network Address Translators (NATs). RFC 1579 [Bel94] recommends using the passive command when behind firewalls since firewalls do not generally allow incoming connections (which are required when using the PORT (EPRT) command). In addition, using EPSV as defined in this document does not require NATs to change the network address in the traffic as it is forwarded. The NAT would have to change the address if the EPRT command was used. Finally, if the client issues an "EPSV ALL" command, NATs may be able to put the connection on a "fast path" through the translator, as the EPRT command will never be used and therefore, translation of the data portion of the segments will never be needed. When a client only expects to do two-way FTP transfers, it SHOULD issue this command as soon as possible. If a client later finds that it must do a three-way FTP transfer after issuing an EPSV ALL command, a new FTP session MUST be started.
对于在同两台机器之间建立控制和数据连接的所有FTP传输，必须使用EPSV命令。使用EPSV命令有助于提高穿越防火墙或网络地址转换器（NAT）的传输性能。RFC 1579[Bel94]建议在防火墙后面使用被动命令，因为防火墙通常不允许传入连接（使用端口（EPRT）命令时需要传入连接）。此外，使用本文档中定义的EPSV不需要NAT在转发流量时更改流量中的网络地址。如果使用EPRT命令，NAT将不得不更改地址。最后，如果客户端发出“EPSV ALL”命令，NAT可能能够通过转换器将连接置于“快速路径”上，因为永远不会使用EPRT命令，因此，永远不需要翻译段的数据部分。当客户端只希望进行双向FTP传输时，它应该尽快发出此命令。如果客户端在发出EPSV ALL命令后发现必须进行三向FTP传输，则必须启动新的FTP会话。
The authors do not believe that these changes to FTP introduce new security problems. A companion Work in Progress [AO98] is a more general discussion of FTP security issues and techniques to reduce these security problems.
作者不相信FTP的这些变化会带来新的安全问题。另一个正在进行的工作[AO98]是对FTP安全问题和减少这些安全问题的技术的更一般性的讨论。
The extensions specified in this paper will enable FTP to operate over a variety of network protocols.
本文中指定的扩展将使FTP能够在各种网络协议上运行。
References
工具书类
[AO98] Allman, M., and S. Ostermann, "FTP Security Considerations", Work in Progress.
[AO98]Allman，M.和S.Ostermann，“FTP安全注意事项”，正在进行中。
[Bel94] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February 1994.
[Bel94]Bellovin，S.，“防火墙友好FTP”，RFC 15791994年2月。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[DH96] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[DH96]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 1883，1995年12月。
[HD96] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[HD96]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[Pis94] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994.
[Pis94]Piscitello，D.，“大地址记录上的FTP操作（FOOBAR）”，RFC163994年6月。
[Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[Pos81a]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[Pos81b]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[PR85] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[PR85]Postel，J.和J.Reynolds，“文件传输协议（FTP）”，标准9，RFC 959，1985年10月。
[RP94] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[RP94] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
Authors' Addresses
作者地址
Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
美国宇航局刘易斯研究中心/斯特林软件公司俄亥俄州克利夫兰布鲁克帕克路21000号，邮编：44135
Phone: (216) 433-6586
EMail: mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman/
Phone: (216) 433-6586
EMail: mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman/
Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens, OH 45701
俄亥俄大学肖恩·奥斯特曼电气工程与计算机科学学院，俄亥俄州雅典莫顿大厅416号，邮编：45701
Phone: (740) 593-1234 EMail: ostermann@cs.ohiou.edu
电话：（740）593-1234电子邮件：ostermann@cs.ohiou.edu
Craig Metz The Inner Net Box 10314-1954 Blacksburg, VA 24062-0314
克雷格·梅茨内网信箱10314-1954弗吉尼亚州布莱克斯堡24062-0314
Phone: (DSN) 754-8590 EMail: cmetz@inner.net
电话：（DSN）754-8590电子邮件：cmetz@inner.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。