azarasi / RFC 2428: FTP Extensions for IPv6 and NATs IPv6和NAT的FTP扩展

Created Fri, 01 Mar 2024 21:05:49 +0800 Modified Wed, 18 Sep 2024 14:00:22 +0000
4633 Words
rfc

Network Working Group

M. Allman, NASA Lewis/Sterling Software

S. Ostermann, Ohio University

C. Metz, The Inner Net

Request for Comments: 2428

Category: Standards Track

September 1998

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 (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）。随着互联网协议第6版的部署，网络地址将不再是32位。本文规定了FTP的扩展，这些扩展将允许协议在IPv4和IPv6上工作。此外，定义的框架未来可以支持额外的网络协议。

1. Introduction 引言

The keywords, such as MUST and SHOULD, found in this document are used as defined in RFC 2119 [Bra97].

本文档中出现的关键词，如MUST和SHOULD，按照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. 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.

文件传输协议[PR85]仅提供了传达有关IPv4数据连接的信息的能力。FTP假设网络地址将是32位长度。然而，随着互联网协议第6版[DH96]的部署，地址将不再是32位长。RFC 1639 [Pis94]规定了FTP的扩展，以使其能够在各种网络协议上使用。不幸的是，该机制在多协议环境中可能会失败。在IPv4与IPv6的过渡期间，FTP需要能够协商将用于数据传输的网络协议。本文档提供了一种规范，说明FTP如何为IPv4之外的网络协议传达数据连接端点信息。在本规范中，FTP命令PORT和PASV分别被EPRT和EPSV替代。本文档的组织如下。第2节概述了EPRT命令，第3节概述了EPSV命令。第4节定义了这两个新FTP命令的利用。第5节简要介绍了安全考虑。最后，第6节提供了结论。

2. The EPRT Command EPRT命令

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>

The EPRT command keyword MUST be followed by a single space (ASCII 32). Following the space, a delimiter character () 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）。空格之后，必须指定一个分隔符字符（）。分隔符字符必须是33-126范围内的ASCII字符之一。除非与编码网络地址所需的字符重合，否则建议使用字符"|"（ASCII 124）。

The 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:

参数必须是IANA在最新的已分配数字RFC（本文档编写时为RFC 1700 [RP94]）中定义的地址族编号。此编号指示将使用的协议（以及隐含的地址长度）。本文档将使用[RP94]中的两个地址族编号作为示例，根据以下表格：

AF Number AF编号Protocol 协议
1Internet Protocol, Version 4 [Pos81a]
2Internet Protocol, Version 6 [DH96]

The 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:

是网络地址的协议特定字符串表示。对于上述指定的两个地址族（AF编号1和2），地址必须按照以下格式：

AF Number AF编号Address Format 地址格式Example 示例
1dotted decimal 点分十进制132.235.1.2
2IPv6 string representations defined in [HD96] IPv6字符串表示，定义在[HD96]中1080::8:800:200C:417A

The following are sample EPRT commands:

以下是EPRT命令的示例：

EPRT |1|132.235.1.2|6275|
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打开到主机"132.235.1.2"的TCP端口6275上的数据连接。第二个命令指定服务器应使用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

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)

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)
Network protocol not supported, use (1,2)

3. The EPSV Command EPSV命令

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

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>)

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|)

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 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:

当没有参数发出EPSV命令时，服务器将基于控制连接使用的协议为数据连接选择网络协议。然而，在代理FTP的情况下，此协议可能不适合两个服务器之间的通信。因此，客户端需要能够请求特定的协议。如果服务器返回的协议不被将要连接到该端口的主机支持，客户端必须发出ABOR（中止）命令，以允许服务器关闭监听连接。然后客户端可以发送一个EPSV命令，请求使用特定的网络协议，如下所示：

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

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，PORT，PASV等）。EPSV命令的这种用法在第4节中进一步解释。

4. Command Usage 命令使用

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]推荐在防火墙后使用被动命令，因为防火墙通常不允许传入连接（使用PORT（EPRT）命令时需要）。此外，根据本文档定义的EPSV不需要NAT更改转发流量时的网络地址。如果使用EPRT命令，NAT将不得不更改地址。最后，如果客户端发出“EPSV ALL”命令，NAT可能能够通过转换器将连接放在“快速路径”上，因为永远不会使用EPRT命令，因此，永远不需要转换数据部分的段。当客户端只期望进行双向FTP传输时，它应尽可能早地发出此命令。如果客户端在发出EPSV ALL命令后发现必须进行三方FTP传输，则必须启动新的FTP会话。

5. Security Issues 安全问题

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安全问题和减少这些安全问题的技术。

6. Conclusions 结论

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.

  • [Bel94] Bellovin, S., “Firewall-Friendly FTP”, RFC 1579, February 1994.

  • [Bra97] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

  • [DH96] Deering, S., and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 1883, December 1995.

  • [HD96] Hinden, R., and S. Deering, “IP Version 6 Addressing Architecture”, RFC 2373, July 1998.

  • [Pis94] Piscitello, D., “FTP Operation Over Big Address Records (FOOBAR)”, RFC 1639, June 1994.

  • [Pos81a] Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981.

  • [Pos81b] Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, September 1981.

  • [PR85] Postel, J., and J. Reynolds, “File Transfer Protocol (FTP)”, STD 9, RFC 959, October 1985.

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

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

Phone: (740) 593-1234 EMail: ostermann@cs.ohiou.edu

Craig Metz The Inner Net Box 10314-1954 Blacksburg, VA 24062-0314

Phone: (DSN) 754-8590 EMail: cmetz@inner.net