Network Working Group G. Fairhurst
Request for Comments: 5596 University of Aberdeen
Updates: 4340 September 2009
Category: Standards Track
Network Working Group G. Fairhurst
Request for Comments: 5596 University of Aberdeen
Updates: 4340 September 2009
Category: Standards Track
Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
数据报拥塞控制协议（DCCP）同时开放技术，以促进NAT/Middlebox遍历
Abstract
摘要
This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near-simultaneous manner to establish necessary middlebox state.
本文件规定了数据报拥塞控制协议（DCCP）的更新，DCCP是一种面向连接和基于数据报的传输协议。更新增加了对DCCP侦听数据包的支持。这有助于DCCP应用程序通过中间箱（例如，网络地址端口转换器或防火墙后面的DCCP服务器）进行通信，其中对等端点需要以几乎同时的方式启动通信以建立必要的中间箱状态。
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 and License Notice
版权及许可证公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 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 BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。未从控制人处获得足够的许可证
the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
此类材料、本文件的版权不得在IETF标准流程之外进行修改，其衍生作品不得在IETF标准流程之外创建，除非将其格式化为RFC或将其翻译为英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 3
1.2. DCCP NAT Traversal . . . . . . . . . . . . . . . . . . . . 4
1.3. Structure of This Document . . . . . . . . . . . . . . . . 4
2. Procedure for Near-Simultaneous-Open . . . . . . . . . . . . . 5
2.1. Conventions and Terminology . . . . . . . . . . . . . . . 5
2.2. Protocol Method . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. DCCP-Listen Packet Format . . . . . . . . . . . . . . 6
2.2.2. Protocol Method for DCCP Server Endpoints . . . . . . 7
2.2.3. Protocol Method for DCCP Client Endpoints . . . . . . 11
2.2.4. Processing by Routers and Middleboxes . . . . . . . . 11
2.3. Examples of Use . . . . . . . . . . . . . . . . . . . . . 12
2.3.1. Repetition of DCCP-Listen . . . . . . . . . . . . . . 13
2.3.2. Optional Triggered Retransmission of DCCP-Request . . 14
2.4. Backwards Compatibility with RFC 4340 . . . . . . . . . . 16
3. Discussion of Design Decisions . . . . . . . . . . . . . . . . 16
3.1. Rationale for a New Packet Type . . . . . . . . . . . . . 17
3.1.1. Use of Sequence Numbers . . . . . . . . . . . . . . . 18
3.2. Generation of Listen Packets . . . . . . . . . . . . . . . 18
3.3. Repetition of DCCP-Listen Packets . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Discussion of Existing NAT Traversal Techniques . . . 23
A.1. NAT Traversal Based on a Simultaneous-Request . . . . . . 24
A.2. Role Reversal . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 3
1.2. DCCP NAT Traversal . . . . . . . . . . . . . . . . . . . . 4
1.3. Structure of This Document . . . . . . . . . . . . . . . . 4
2. Procedure for Near-Simultaneous-Open . . . . . . . . . . . . . 5
2.1. Conventions and Terminology . . . . . . . . . . . . . . . 5
2.2. Protocol Method . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. DCCP-Listen Packet Format . . . . . . . . . . . . . . 6
2.2.2. Protocol Method for DCCP Server Endpoints . . . . . . 7
2.2.3. Protocol Method for DCCP Client Endpoints . . . . . . 11
2.2.4. Processing by Routers and Middleboxes . . . . . . . . 11
2.3. Examples of Use . . . . . . . . . . . . . . . . . . . . . 12
2.3.1. Repetition of DCCP-Listen . . . . . . . . . . . . . . 13
2.3.2. Optional Triggered Retransmission of DCCP-Request . . 14
2.4. Backwards Compatibility with RFC 4340 . . . . . . . . . . 16
3. Discussion of Design Decisions . . . . . . . . . . . . . . . . 16
3.1. Rationale for a New Packet Type . . . . . . . . . . . . . 17
3.1.1. Use of Sequence Numbers . . . . . . . . . . . . . . . 18
3.2. Generation of Listen Packets . . . . . . . . . . . . . . . 18
3.3. Repetition of DCCP-Listen Packets . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Discussion of Existing NAT Traversal Techniques . . . 23
A.1. NAT Traversal Based on a Simultaneous-Request . . . . . . 24
A.2. Role Reversal . . . . . . . . . . . . . . . . . . . . . . 25
The Datagram Congestion Control Protocol (DCCP) [RFC4340] is both datagram-based and connection-oriented. According to RFC 4340, DCCP servers establish connections by passively listening for incoming connection requests that are actively transmitted by DCCP clients. These asymmetric roles can cause problems when the server is 'inside' a middlebox, such as a Network Address Port Translation (NAPT), that only allows connection requests to be initiated from inside (e.g., due to port overloading) [RFC5597]. Host-based and network firewalls can also implement policies that lead to similar problems. This behaviour is currently the default for many firewalls.
数据报拥塞控制协议（DCCP）[RFC4340]既基于数据报，又面向连接。根据RFC 4340，DCCP服务器通过被动侦听DCCP客户端主动传输的传入连接请求来建立连接。当服务器“在”一个只允许从内部启动连接请求（例如，由于端口过载）的中间盒（如网络地址端口转换（NAPT））内时，这些非对称角色可能会导致问题[RFC5597]。基于主机和网络的防火墙也可以实施导致类似问题的策略。这种行为目前是许多防火墙的默认行为。
UDP can support middlebox traversal using various techniques [RFC4787] that leverage the connectionless nature of UDP and are therefore not suitable for DCCP. TCP supports middlebox traversal through the use of its simultaneous-open procedure [RFC5382]. The concepts of the TCP solution are applicable to DCCP, but DCCP cannot simply reuse the same methods (see Appendix A).
UDP可以使用各种技术[RFC4787]支持中间箱遍历，这些技术利用UDP的无连接特性，因此不适用于DCCP。TCP通过使用其同步打开过程[RFC5382]支持中间盒遍历。TCP解决方案的概念适用于DCCP，但DCCP不能简单地重用相同的方法（见附录A）。
After discussing the problem space for DCCP, this document specifies an update to the DCCP state machine to offer native support that allows a DCCP client to establish a connection to a DCCP server that is inside one or more middleboxes. This reduces dependence on external aids such as data relay servers [STUN] by explicitly supporting a widely used principle known as 'hole punching'.
在讨论了DCCP的问题空间之后，本文档指定了对DCCP状态机的更新，以提供本机支持，从而允许DCCP客户端与位于一个或多个中间盒内的DCCP服务器建立连接。通过明确支持一种广泛使用的称为“打孔”的原理，这减少了对外部辅助设备（如数据中继服务器[STUN]）的依赖。
The method requires only a minor change to the standard DCCP operational procedure. The use of a dedicated DCCP packet type ties usage to a specific condition, ensuring the method is inter-operable with hosts that do not implement this update or that choose to disable it (see Section 4).
该方法只需对标准DCCP操作程序进行微小更改。专用DCCP数据包类型的使用将使用情况与特定条件联系起来，确保该方法可与未实现此更新或选择禁用此更新的主机互操作（参见第4节）。
This method is useful in scenarios when a DCCP server is located inside the perimeter controlled by a middlebox. It is relevant to both client/server and peer-to-peer applications, such as Voice over IP (VoIP), file sharing, or online gaming, and assists connections that utilise prior out-of-band signaling (e.g., via a well-known rendezvous server ([RFC3261], [H.323])) to notify both endpoints of the connection parameters ([RFC3235], [NAT-APP]).
当DCCP服务器位于由中间箱控制的外围内时，此方法非常有用。它与客户端/服务器和点对点应用程序（如IP语音（VoIP）、文件共享或在线游戏）相关，并帮助利用先前带外信令（例如，通过知名的会合服务器（[RFC3261]，[H.323]）的连接，以通知两个端点连接参数（[RFC3235]，[NAT-APP]）。
The behavioural requirements for NAT devices supporting DCCP are described in [RFC5597]. A "traditional NAT" [RFC3022] that directly maps an IP address to a different IP address does not require the simultaneous-open technique described in this document.
[RFC5597]中描述了支持DCCP的NAT设备的行为要求。直接将IP地址映射到不同IP地址的“传统NAT”[RFC3022]不需要本文档中描述的同步开放技术。
The method is required when the DCCP server is positioned behind one or more NAPT devices in the path (hierarchies of nested NAPT devices are possible). This document refers to DCCP hosts located inside the perimeter controlled by one or more NAPT devices as having "private" addresses, and to DCCP hosts located in the global address realm as having "public" addresses.
当DCCP服务器位于路径中一个或多个NAPT设备的后面时，需要使用该方法（嵌套NAPT设备的层次结构是可能的）。本文档将位于由一个或多个NAPT设备控制的周界内的DCCP主机称为具有“专用”地址，将位于全局地址域中的DCCP主机称为具有“公用”地址。
DCCP NAT traversal is considered for the following scenarios:
DCCP NAT穿越考虑用于以下场景：
1. Private client connects to public server.
1. 专用客户端连接到公共服务器。
2. Public client connects to private server.
2. 公用客户端连接到专用服务器。
3. Private client connects to private server.
3. 专用客户端连接到专用服务器。
A defining characteristic of traditional NAT devices [RFC3022] is that private hosts can connect to external hosts, but not vice versa. Hence, case (1) is possible using the protocol defined in [RFC4340]. A pre-configured, static NAT address map would allow outside hosts to establish connections in cases (2) and (3).
传统NAT设备[RFC3022]的一个定义特征是，私有主机可以连接到外部主机，但不能连接到外部主机。因此，情况（1）可以使用[RFC4340]中定义的协议。在（2）和（3）种情况下，预先配置的静态NAT地址映射将允许外部主机建立连接。
A DCCP implementation conforming to [RFC4340] and a NAT device conforming to [RFC5597] would require a DCCP relay server to perform NAT traversal for cases (2) and (3).
符合[RFC4340]的DCCP实现和符合[RFC5597]的NAT设备需要DCCP中继服务器对情况（2）和（3）执行NAT遍历。
This document describes a method to support cases (2) and (3) without the aid of a DCCP relay server. This method updates RFC 4340 and requires the DCCP server to discover the IP address and the DCCP port that correspond to the DCCP client. Such signaling may be performed out-of-band (e.g., using the Session Description Protocol (SDP) [RFC4566]).
本文档描述了一种在不借助DCCP中继服务器的情况下支持案例（2）和（3）的方法。此方法更新RFC 4340，并要求DCCP服务器查找与DCCP客户端对应的IP地址和DCCP端口。这种信令可以在带外执行（例如，使用会话描述协议（SDP）[rfc456]）。
For background information on existing NAT traversal techniques, please consult Appendix A.
有关现有NAT穿越技术的背景信息，请参阅附录A。
The normative specification of the update is presented in Section 2. An informative discussion of underlying design decisions then follows in Section 3. Security considerations are provided in Section 4 and IANA considerations are provided in the concluding Section 5.
更新的规范性规范见第2节。第3节将对基础设计决策进行详细讨论。安全注意事项见第4节，IANA注意事项见最后第5节。
This section is normative and specifies the simultaneous-open technique for DCCP. It updates the connection-establishment procedures of [RFC4340].
本节是规范性的，规定了DCCP的同时开放技术。它更新了[RFC4340]的连接建立程序。
The document uses the terms and definitions provided in [RFC4340]. Familiarity with this specification is assumed. In particular, the following convention from Section 3.2 of [RFC4340] is used:
本文件使用[RFC4340]中提供的术语和定义。假设熟悉本规范。具体而言，使用[RFC4340]第3.2节中的以下约定：
Each DCCP connection runs between two hosts, which we often name DCCP A and DCCP B. Each connection is actively initiated by one of the hosts, which we call the client; the other, initially passive host is called the server.
每个DCCP连接在两台主机之间运行，我们通常将其命名为DCCP A和DCCP B。每个连接都由其中一台主机主动启动，我们称之为客户端；另一个最初是被动主机的主机称为服务器。
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]中所述进行解释。
The term "session" is used as defined in ([RFC2663], Section 2.3): DCCP sessions are uniquely identified by the 4-tuple of <source IP-address, source port, target IP-address, target port>.
术语“会话”的使用如（[RFC2663]第2.3节）中所定义：DCCP会话由<source IP address，source port，target IP address，target port>的4元组唯一标识。
DCCP, in addition, introduces Service Codes, which can be used to identify different services available via the same port [RFC5595].
此外，DCCP还引入了服务代码，可用于识别通过同一端口提供的不同服务[RFC5595]。
This document adds a new DCCP packet type, DCCP-Listen, whose format is shown below.
本文档添加了一种新的DCCP数据包类型DCCP Listen，其格式如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Type |X| Reserved | Sequence Number High Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Low Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Type |X| Reserved | Sequence Number High Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Low Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of a DCCP-Listen Packet
图1:DCCP侦听数据包的格式
o The Source Port field indicates the port on which the DCCP server is listening for a connection from the IP address that appears as the destination IP address in the packet.
o Source Port（源端口）字段表示DCCP服务器正在其上侦听来自数据包中显示为目标IP地址的IP地址的连接的端口。
o The Destination Port field indicates the port selected by a DCCP client to identify the connection. In this technique, this value must be communicated out-of-band to the server.
o Destination Port（目标端口）字段表示DCCP客户端为标识连接而选择的端口。在这种技术中，该值必须在带外传送到服务器。
o The value of X MUST be set to 1. A DCCP-Listen packet is sent before a connection is established; therefore, there is no way to negotiate use of short sequence numbers ([RFC4340], Section 5.1).
o X的值必须设置为1。在建立连接之前发送DCCP侦听数据包；因此，无法协商短序列号的使用（[RFC4340]，第5.1节）。
o The value of the Sequence Number field in a DCCP-Listen packet is not related to the DCCP sequence number used in normal DCCP messages (see Section 3 for a description of the use of the DCCP sequence number). Thus, for DCCP-Listen packets:
o DCCP侦听数据包中序列号字段的值与正常DCCP消息中使用的DCCP序列号无关（有关DCCP序列号的使用说明，请参阅第3节）。因此，对于DCCP侦听数据包：
* A DCCP server SHOULD set the high and low bits of the Sequence Number field to 0.
* DCCP服务器应将序列号字段的高位和低位设置为0。
* A DCCP client MUST ignore the value of the Sequence Number field.
* DCCP客户端必须忽略序列号字段的值。
* Middleboxes MUST NOT interpret sequence numbers in DCCP-Listen packets.
* 中间盒不得解释DCCP侦听数据包中的序列号。
o The Service Code field contains the Service Code value for which the server is listening for a connection (Section 8.1.2 of [RFC4340] and [RFC5595]). This value MUST correspond to a Service Code that the server is actually offering for a connection identified by the same source IP address and the same source port as that of the DCCP-Listen packet. Since the server may use multiple Service Codes, the specific value of the Service Code field needs to be communicated out-of-band, from client to server, prior to sending the DCCP-Listen packet, e.g., described using the Session Description Protocol (SDP) [RFC4566].
o 服务代码字段包含服务器正在侦听连接的服务代码值（参见[RFC4340]和[RFC5595]第8.1.2节）。此值必须对应于服务器实际为连接提供的服务代码，该连接由与DCCP侦听数据包相同的源IP地址和相同的源端口标识。由于服务器可以使用多个服务代码，因此在发送DCCP侦听数据包之前，服务代码字段的特定值需要在带外从客户端传送到服务器，例如，使用会话描述协议（SDP）[rfc456]进行描述。
o At the time of writing, there are no known uses of header options ([RFC4340], Section 5.8) with a DCCP-Listen packet. Clients MUST ignore all options in received DCCP-Listen packets. Therefore, feature values cannot be negotiated using a DCCP-Listen packet.
o 在撰写本文时，没有已知的使用DCCP侦听数据包的报头选项（[RFC4340]，第5.8节）。客户端必须忽略接收到的DCCP侦听数据包中的所有选项。因此，不能使用DCCP侦听数据包协商特征值。
o At the time of writing, there are no known uses of payload data with a DCCP-Listen packet. Since DCCP-Listen packets are issued before an actual connection is established, endpoints MUST ignore any payload data encountered in DCCP-Listen packets.
o 在编写本文时，没有已知的使用DCCP侦听数据包的有效负载数据。由于DCCP侦听数据包是在建立实际连接之前发出的，因此端点必须忽略DCCP侦听数据包中遇到的任何有效负载数据。
o The following protocol fields are required to have specific values:
o 以下协议字段必须具有特定值：
* Data Offset MUST have a value of five or more (i.e., at least 20 bytes).
* 数据偏移量必须具有五个或更多的值（即，至少20个字节）。
* CCVal MUST be zero (a connection has not been established).
* CCVal必须为零（尚未建立连接）。
* CsCov MUST be zero (use of the CsCov feature cannot be negotiated).
* CsCov必须为零（不能协商使用CsCov特性）。
* Type has the value 10, assigned by IANA to denote a DCCP-Listen packet.
* 类型的值为10，由IANA分配以表示DCCP侦听数据包。
* X MUST be 1 (the generic header must be used).
* X必须为1（必须使用通用标头）。
The remaining fields, including the "Res" and "Reserved" fields are specified by [RFC4340] and its successors. The interpretation of these fields is not modified by this document.
剩余字段（包括“Res”和“Reserved”字段）由[RFC4340]及其后续字段指定。本文件不修改这些字段的解释。
This document updates Section 8.1 of [RFC4340] for the case of a fully specified DCCP server endpoint. The update modifies the way the server performs a passive-open.
本文件更新了[RFC4340]第8.1节中关于完全指定的DCCP服务器端点的内容。更新将修改服务器执行被动打开的方式。
Prior to connection setup, it is common for a DCCP server endpoint to not be fully specified: before the connection is established, a server usually specifies only the destination port and Service Code. (Sometimes the destination address is also specified.) This leaves the source address and source port unspecified. The endpoint only becomes fully specified after performing the handshake for an incoming connection. For such cases, this document does not update Section 8.4 of [RFC4340], i.e., the server adheres to the existing state transitions in the left half of Figure 2 (CLOSED => LISTEN => RESPOND).
在建立连接之前，通常不完全指定DCCP服务器端点：在建立连接之前，服务器通常只指定目标端口和服务代码。（有时还指定了目标地址。）这使得源地址和源端口未指定。只有在对传入连接执行握手后，端点才会完全指定。对于这种情况，本文档不更新[RFC4340]的第8.4节，即服务器遵循图2左半部分中的现有状态转换（CLOSED=>LISTEN=>RESPOND）。
A fully specified DCCP server endpoint permits exactly one client, identified by source IP-address:port, destination IP-address:port, plus a single Service Code, to set up the connection. Such a server SHOULD perform the actions and state transitions shown in the right half of Figure 2 and specified below.
完全指定的DCCP服务器端点只允许一个客户机（由源IP地址：端口、目标IP地址：端口和单个服务代码标识）建立连接。这样的服务器应该执行图2右半部分所示的操作和状态转换，并在下面指定。
unspecified remote +--------+ fully specified remote
+---------------------| CLOSED |---------------------+
| +--------+ send DCCP-Listen |
| |
v v
+--------+ timeout +---------+
| LISTEN | +---+-----------| INVITED |
+--------+ | | +---------+
| | | 1st / 2nd ^ |
| more than 2 | | retransm. | | receive
| retransmissions | +-------------+ | Request
| | resend Listen v
| | +---------+
| +-------------->| LISTEN1 |
| +---------+
| |
| receive Request +---------+ receive Request* |
+------------------->| RESPOND |<--------------------+
send Response +---------+ send Response
unspecified remote +--------+ fully specified remote
+---------------------| CLOSED |---------------------+
| +--------+ send DCCP-Listen |
| |
v v
+--------+ timeout +---------+
| LISTEN | +---+-----------| INVITED |
+--------+ | | +---------+
| | | 1st / 2nd ^ |
| more than 2 | | retransm. | | receive
| retransmissions | +-------------+ | Request
| | resend Listen v
| | +---------+
| +-------------->| LISTEN1 |
| +---------+
| |
| receive Request +---------+ receive Request* |
+------------------->| RESPOND |<--------------------+
send Response +---------+ send Response
* Note: The case of a server that responds to a DCCP-Request in the INVITED state, transitions to the LISTEN1 state, and then immediately transitions to the RESPOND state does not require reception of an additional DCCP-Request packet.
* 注意：如果服务器在受邀请状态下响应DCCP请求，然后转换到LISTEN1状态，然后立即转换到RESPOND状态，则不需要接收额外的DCCP请求数据包。
Figure 2: Updated State Transition Diagram for DCCP-Listen
图2:DCCP侦听的更新状态转换图
This diagram introduces two additional DCCP server states in addition to those listed in Section 4.3 of [RFC4340]:
除了[RFC4340]第4.3节中列出的状态外，此图还介绍了两种额外的DCCP服务器状态：
INVITED The INVITED state is associated with a specific DCCP connection and represents a fully specified server socket in the listening state that is generating DCCP-Listen packets towards the client.
受邀请的状态与特定的DCCP连接相关联，并表示处于侦听状态的完全指定的服务器套接字，该套接字正在向客户端生成DCCP侦听数据包。
LISTEN1 The LISTEN1 state is associated with a specific DCCP connection and represents a fully specified server socket in the passive listening state that will not generate further DCCP-Listen packets towards the client.
LISTEN1 LISTEN1状态与特定的DCCP连接相关联，表示被动侦听状态下的完全指定的服务器套接字，该套接字将不会向客户端生成进一步的DCCP侦听数据包。
A fully specified server endpoint performs a passive-open from the CLOSED state by inviting the remote client to connect. This is performed by sending a single DCCP-Listen packet to the specified remote IP-address:port, using the format specified in Section 2.2.1. The figure below provides pseudocode describing the packet processing in the INVITED state. This processing step follows Step 2 in Section 8.5 of [RFC4340]).
完全指定的服务器端点通过邀请远程客户端进行连接，从关闭状态执行被动打开。这是通过使用第2.2.1节中指定的格式向指定的远程IP地址：端口发送单个DCCP侦听数据包来实现的。下图提供了描述被邀请状态下的数据包处理的伪代码。该处理步骤遵循[RFC4340]第8.5节中的步骤2。
The INVITED state is, like LISTEN, a passive state, characterised by waiting in the absence of an established connection. If the server endpoint in the INVITED state receives a DCCP-Request that matches the set of bound ports and addresses, it transitions to the LISTEN1 state and then immediately transitions to the RESPOND state, where further processing resumes as specified in [RFC4340].
被邀请的状态与“倾听”一样，是一种被动状态，其特点是在没有建立连接的情况下等待。如果处于受邀请状态的服务器端点接收到与绑定端口和地址集匹配的DCCP请求，它将转换到LISTEN1状态，然后立即转换到RESPOND状态，在该状态下，将按照[RFC4340]中的规定恢复进一步的处理。
The server SHOULD repeat sending a DCCP-Listen packet while in the INVITED state, at a 200-millisecond interval with up to at most 2 repetitions (Section 3 discusses this choice of time interval). If the server is still in the INVITED state after a further period of 200ms following transmission of the third DCCP-Listen packet, it SHOULD progress to the LISTEN1 state.
服务器应在被邀请状态下以200毫秒的间隔重复发送DCCP侦听数据包，最多重复2次（第3节讨论了时间间隔的选择）。如果在传输第三个DCCP Listen数据包后的200ms内，服务器仍处于受邀请状态，则应进入LISTEN1状态。
Fully specified server endpoints SHOULD treat ICMP error messages received in response to a DCCP-Listen packet as "soft errors" that do not cause a state transition. Reception of an ICMP error message as a result of sending a DCCP-Listen packet does not necessarily indicate a failure of the following connection request, and therefore should not result in a server state change. This reaction to soft errors exploits the valuable feature of the Internet that, for many network failures, the network can be dynamically reconstructed without any disruption of the endpoints.
完全指定的服务器端点应将响应DCCP侦听数据包而收到的ICMP错误消息视为不会导致状态转换的“软错误”。由于发送DCCP侦听数据包而接收到ICMP错误消息并不一定表示以下连接请求失败，因此不应导致服务器状态更改。这种对软错误的反应利用了互联网的宝贵功能，即对于许多网络故障，可以在不中断端点的情况下动态重建网络。
Server endpoints SHOULD ignore any incoming DCCP-Listen packets. A DCCP server in the LISTEN, INVITED, or LISTEN1 states MAY generate a
服务器端点应忽略任何传入的DCCP侦听数据包。处于LISTEN、invested或LISTEN1状态的DCCP服务器可能会生成
DCCP-Reset packet (Code 7, "Connection Refused") in response to a received DCCP-Listen packet. This DCCP-Reset packet is an indication that two servers are simultaneously awaiting connections on the same port.
DCCP重置数据包（代码7，“连接被拒绝”），以响应接收到的DCCP侦听数据包。此DCCP重置数据包表示两台服务器同时在同一端口上等待连接。
Further details on the design rationale are discussed in Section 3.
第3节讨论了设计原理的更多细节。
The figure below provides pseudocode describing the packet processing in the INVITED state. This processing step follows Step 2 in Section 8.5 of RFC 4340 [RFC4340].
下图提供了描述被邀请状态下的数据包处理的伪代码。该处理步骤遵循RFC 4340[RFC4340]第8.5节中的步骤2。
Step 2a: Process INVITED state
If S.state == INVITED,
/* State only entered for fully specified server endpoints */
/* on entry S will have been set to a socket */
If P.type == Request
/* Exit INVITED state and continue to process the packet */
S.state = LISTEN1
Continue with S.state := LISTEN1
Otherwise,
If P.type == Listen
/* The following line is optional */
Generate Reset(Connection Refused)
/* Otherwise, drop packet and return */
Otherwise,
Generate Reset(No Connection) unless P.type == Reset
Step 2a: Process INVITED state
If S.state == INVITED,
/* State only entered for fully specified server endpoints */
/* on entry S will have been set to a socket */
If P.type == Request
/* Exit INVITED state and continue to process the packet */
S.state = LISTEN1
Continue with S.state := LISTEN1
Otherwise,
If P.type == Listen
/* The following line is optional */
Generate Reset(Connection Refused)
/* Otherwise, drop packet and return */
Otherwise,
Generate Reset(No Connection) unless P.type == Reset
Step 2b: Process LISTEN1 state
If S.state == LISTEN1,
/* State only entered for fully specified server endpoints */
/* Follows receipt of a Response packet */
/* or sending third Listen packet (after timer expiry) */
If P.type == Request,
S.state = RESPOND
Choose S.ISS (initial seqno) or set from Init Cookies
Initialize S.GAR := S.ISS
Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookies
Continue with S.state == RESPOND
/* A Response packet will be generated in Step 11 */
Otherwise,
If P.type == Listen
/* The following line is optional */
Generate Reset(Connection Refused)
/* Otherwise, drop packet and return */
Otherwise,
Generate Reset(No Connection) unless P.type == Reset
Step 2b: Process LISTEN1 state
If S.state == LISTEN1,
/* State only entered for fully specified server endpoints */
/* Follows receipt of a Response packet */
/* or sending third Listen packet (after timer expiry) */
If P.type == Request,
S.state = RESPOND
Choose S.ISS (initial seqno) or set from Init Cookies
Initialize S.GAR := S.ISS
Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookies
Continue with S.state == RESPOND
/* A Response packet will be generated in Step 11 */
Otherwise,
If P.type == Listen
/* The following line is optional */
Generate Reset(Connection Refused)
/* Otherwise, drop packet and return */
Otherwise,
Generate Reset(No Connection) unless P.type == Reset
Figure 3: Updated DCCP Pseudocode for INVITED and LISTEN1 States
图3：被邀请和被邀请状态的更新DCCP伪代码1
This document updates Section 8.1.1 of [RFC4340] by adding the following rule for the reception of DCCP-Listen packets by clients:
本文件更新了[RFC4340]第8.1.1节，增加了以下客户端接收DCCP侦听数据包的规则：
Endpoints are required to ignore any header options or payload data encountered in DCCP-Listen packets (Section 2.2.1) and hence do not provide meaningful communication to a client. A client in any state MUST silently discard any received DCCP-Listen packet, unless it implements the optional procedure defined in the following section.
端点需要忽略DCCP侦听数据包（第2.2.1节）中遇到的任何头选项或有效负载数据，因此不向客户端提供有意义的通信。处于任何状态的客户机都必须以静默方式丢弃任何接收到的DCCP侦听数据包，除非它实现了以下部分中定义的可选过程。
This section describes an optional optimisation at the client that can allow the client to avoid having to wait for a timeout following a dropped DCCP-Request. The operation requires clients to respond to reception of DCCP-Listen packets when received in the REQUEST state. DCCP-Listen packets MUST be silently discarded in all other states.
本节描述了客户端的可选优化，该优化允许客户端避免在丢弃DCCP请求后等待超时。该操作要求客户端在请求状态下接收DCCP侦听数据包时响应接收。DCCP侦听数据包必须在所有其他状态下以静默方式丢弃。
A client implementing this optimisation MAY immediately perform a retransmission of a DCCP-Request following the reception of the first DCCP-Listen packet. The retransmission is performed in the same manner as a timeout in the REQUEST state [RFC4340]. A triggered retransmission SHOULD result in the client increasing the exponential-backoff timer interval.
实现该优化的客户端可在接收到第一DCCP侦听分组之后立即执行DCCP请求的重传。以与请求状态下的超时相同的方式执行重传[RFC4340]。触发的重新传输应导致客户端增加指数退避计时器间隔。
Note that a path delay greater than 200ms will result in multiple DCCP-Listen packets arriving at the client before a DCCP-Response is received. Clients MUST therefore perform only one such retransmission for each DCCP connection. This requires maintaining local state (e.g., one flag per connection).
请注意，大于200ms的路径延迟将导致多个DCCP侦听数据包在收到DCCP响应之前到达客户端。因此，对于每个DCCP连接，客户端只能执行一次这样的重传。这需要维护本地状态（例如，每个连接一个标志）。
Implementors and users of this optional method need to be aware that host timing or path reordering can result in a server receiving two DCCP-Requests (i.e., the server sending one unnecessary packet). This would, in turn, trigger a client to send a second corresponding DCCP-Response (also unnecessary). These additional packets are not expected to modify or delay the DCCP open procedure [RFC4340].
此可选方法的实现者和用户需要知道，主机定时或路径重新排序可能导致服务器接收两个DCCP请求（即，服务器发送一个不必要的数据包）。这将反过来触发客户机发送第二个相应的DCCP响应（也不需要）。预计这些附加数据包不会修改或延迟DCCP打开过程[RFC4340]。
Section 2.3.2 provides examples of the use of triggered retransmission.
第2.3.2节提供了使用触发重传的示例。
DCCP-Listen packets do not require special treatment and should thus be forwarded end-to-end across Internet paths, by routers and middleboxes alike.
DCCP侦听数据包不需要特殊处理，因此应该通过路由器和中间盒通过Internet路径端到端地转发。
Middleboxes may utilise the connection information (address, port, Service Code) to establish local forwarding state. The DCCP-Listen packet carries the necessary information to uniquely identify a DCCP session in combination with the source and destination addresses (found in the enclosing IP header), including the DCCP Service Code value [RFC5595]. The processing of the DCCP-Listen packet by NAT devices is specified in [RFC5597].
中间盒可利用连接信息（地址、端口、服务代码）建立本地转发状态。DCCP侦听数据包携带必要的信息，以便结合源地址和目标地址（位于封闭的IP报头中）唯一标识DCCP会话，包括DCCP服务代码值[RFC5595]。[RFC5597]中规定了NAT设备对DCCP侦听数据包的处理。
In the examples below, DCCP A is the client and DCCP B is the server. A middlebox device (NAT/Firewall), NA, is placed before DCCP A, and another middlebox, NB, is placed before DCCP B. Both NA and NB use a policy that permits DCCP packets to traverse the device for outgoing links, but only permits incoming DCCP packets when a previous packet has been sent out for the same connection.
在下面的示例中，DCCP A是客户端，DCCP B是服务器。一个中间盒设备（NAT/防火墙）NA放在DCCP A之前，另一个中间盒NB放在DCCP B之前。NA和NB都使用一种策略，允许DCCP数据包通过设备进行传出链接，但仅在为同一连接发送前一个数据包时才允许传入DCCP数据包。
In the figure below, DCCP A and DCCP B decide to communicate using an out-of-band mechanism (in this case, labelled SDP), whereupon the client and server are started. DCCP B actively indicates its listening state by sending a DCCP-Listen message. This fulfills the requirement of punching a hole in NB (also creating the binding to the external address and port). This message is dropped by NA since no hole exists there yet. DCCP A initiates a connection by entering the REQUEST state and sending a DCCP-Request. (It is assumed that if NA were a NAT device, then this would also result in a binding that maps the pinhole to the external address and port.) The DCCP-Request is received by DCCP B, via the binding at NB. DCCP B transmits the DCCP-Response and connects through the bindings now in place at NA and NB.
在下图中，DCCP A和DCCP B决定使用带外机制（在本例中，标记为SDP）进行通信，然后启动客户端和服务器。DCCP B通过发送DCCP Listen消息主动指示其侦听状态。这满足了在NB中打孔的要求（也创建了到外部地址和端口的绑定）。由于还不存在漏洞，NA将删除此消息。DCCP A通过进入请求状态并发送DCCP请求来启动连接。（假设NA是NAT设备，则这也会导致将针孔映射到外部地址和端口的绑定。）DCCP B通过NB处的绑定接收DCCP请求。DCCP B传输DCCP响应，并通过现在位于NA和NB的绑定进行连接。
DCCP A DCCP B
------ NA NB ------
+-----------------+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
| SDP --> |--+-+----+-+->| | State = INVITED
| | | |X---+-+--|<-- DCCP-Listen |
|(State=REQUEST) | | | | | | |
|DCCP-Request --> |--+-+----+-+->| |
|(State=PARTOPEN) | <+-+----+-+--|<-- DCCP-Response| State = RESPOND
|DCCP-Ack --> |--+-+----+-+> | |
| | | | | | | |
| | | | | | | |
|DCCP-Data --> |--+-+----+-+->| | State = OPEN
+-----------------+ +-+ +-+ +-----------------+
DCCP A DCCP B
------ NA NB ------
+-----------------+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
| SDP --> |--+-+----+-+->| | State = INVITED
| | | |X---+-+--|<-- DCCP-Listen |
|(State=REQUEST) | | | | | | |
|DCCP-Request --> |--+-+----+-+->| |
|(State=PARTOPEN) | <+-+----+-+--|<-- DCCP-Response| State = RESPOND
|DCCP-Ack --> |--+-+----+-+> | |
| | | | | | | |
| | | | | | | |
|DCCP-Data --> |--+-+----+-+->| | State = OPEN
+-----------------+ +-+ +-+ +-----------------+
Figure 4: Event Sequence When the Server Is Started Before the Client
图4：在客户端之前启动服务器时的事件序列
This section examines the effect of not receiving the DCCP-Request.
本节检查未接收DCCP请求的影响。
The figure below shows the sequence of packets where the DCCP server enters the INVITED state after reception of out-of-band signaling (e.g., SDP). The key timer operations at the client and server are respectively shown on the left and right of the diagram. It considers the case when the server does not receive a DCCP-Request within the first 600ms (often the request would be received within this interval).
下图显示了DCCP服务器在接收带外信令（例如SDP）后进入邀请状态的数据包序列。客户机和服务器上的键计时器操作分别显示在图的左侧和右侧。它考虑了服务器在前600毫秒内没有收到DCCP请求的情况（请求通常在此间隔内收到）。
The repetition of DCCP-Listen packets may be implemented using a timer. The timer is restarted with an interval of 200ms when sending each DCCP-Listen packet. It is cancelled when the server leaves the INVITED state. If the timer expires after the first and second transmission, it triggers a transmission of another DCCP-Listen packet. If it expires after sending the third DCCP-Listen packet, the server leaves the INVITED state to enter the LISTEN1 state (where it passively waits for a DCCP-Request).
可以使用定时器来实现DCCP侦听分组的重复。发送每个DCCP侦听数据包时，计时器以200ms的间隔重新启动。当服务器离开“受邀请”状态时，它将被取消。如果计时器在第一次和第二次传输后过期，它将触发另一个DCCP侦听数据包的传输。如果在发送第三个DCCP Listen数据包后过期，服务器将离开邀请状态，进入LISTEN1状态（被动等待DCCP请求）。
DCCP A DCCP B
------ NA NB ------
+----+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
| -->|--+-+----+-+--|--> SDP |
| | | | | | | | State = INVITED
| | | | | | | |
| | | |X---+-+--|<-- DCCP-Listen | Timer Starts
| | | | | | | | |
DCCP-Request | -->|--->+--X | | | (dropped) | |
Timer Starts | | | | | | | | |
| | | | | | | | | 1st Timer Expiry
| | |<-+-+----+++--|<-- DCCP-Listen |
| | | | | | | | | Timer Starts
| | | | | | | | | |
| | | | | | | | | 2nd Timer Expiry
| | | | | | | | |
| | |<-+-+----+-+--|<-- DCCP-Listen | Timer Starts
| | | | | | | | | |
| | | | | | | | | 3rd Timer Expiry
| | | | | | | | |
| | | | | | | | | State = LISTEN1
| ~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | | |
Timer Expiry | -->|--+-+----+-+--|--> DCCP-Request |
| | | | | | | | State = RESPOND
| <--|--+-+----+-+--|<-- DCCP-Response|
+----+ +-+ +-+ +-----------------+
DCCP A DCCP B
------ NA NB ------
+----+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
| -->|--+-+----+-+--|--> SDP |
| | | | | | | | State = INVITED
| | | | | | | |
| | | |X---+-+--|<-- DCCP-Listen | Timer Starts
| | | | | | | | |
DCCP-Request | -->|--->+--X | | | (dropped) | |
Timer Starts | | | | | | | | |
| | | | | | | | | 1st Timer Expiry
| | |<-+-+----+++--|<-- DCCP-Listen |
| | | | | | | | | Timer Starts
| | | | | | | | | |
| | | | | | | | | 2nd Timer Expiry
| | | | | | | | |
| | |<-+-+----+-+--|<-- DCCP-Listen | Timer Starts
| | | | | | | | | |
| | | | | | | | | 3rd Timer Expiry
| | | | | | | | |
| | | | | | | | | State = LISTEN1
| ~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | | |
Timer Expiry | -->|--+-+----+-+--|--> DCCP-Request |
| | | | | | | | State = RESPOND
| <--|--+-+----+-+--|<-- DCCP-Response|
+----+ +-+ +-+ +-----------------+
Figure 5: Repetition of the DCCP-Listen Packet
图5:DCCP侦听数据包的重复
The following figure illustrates a triggered retransmission. In this figure, the first DCCP-Listen is assumed to be lost in the network (e.g., does not open a pinhole at NB). A later DCCP-Request is also not received (perhaps as a side effect of the first loss). After 200ms, the DCCP-Listen packet is retransmitted and correctly received. This triggers the retransmission of the DCCP-Request, which, when received, results in a corresponding DCCP-Response.
下图说明了触发的重新传输。在该图中，假设第一个DCCP侦听在网络中丢失（例如，没有在NB处打开针孔）。随后的DCCP请求也没有收到（可能是第一次丢失的副作用）。200ms后，重新传输并正确接收DCCP侦听数据包。这将触发DCCP请求的重新传输，当接收到该请求时，将导致相应的DCCP响应。
DCCP A DCCP B
------ NA NB ------
+-----------------+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
|SDP |--+-+----+-+->| | State = INVITED
|(State= REQUEST) | | | | | | |
| | | | | |X-|<-- DCCP-Listen |
|DCCP-Request --> |--+-+---X| | | |
| | <+-+----+-+--|<-- DCCP-Listen |(retransmit)
| | | | | | | |
|DCCP-Request --> |--+-+----+-+->| | State = RESPOND
| (Triggered) | | | | | | |
| |<-+-+----+-+--|<-- DCCP-Response|
|(State= PARTOPEN)| | | | | | |
|DCCP-Ack --> |--+-+----+-+->| | State = OPEN
+-----------------+ +-+ +-+ +-----------------+
DCCP A DCCP B
------ NA NB ------
+-----------------+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
|SDP |--+-+----+-+->| | State = INVITED
|(State= REQUEST) | | | | | | |
| | | | | |X-|<-- DCCP-Listen |
|DCCP-Request --> |--+-+---X| | | |
| | <+-+----+-+--|<-- DCCP-Listen |(retransmit)
| | | | | | | |
|DCCP-Request --> |--+-+----+-+->| | State = RESPOND
| (Triggered) | | | | | | |
| |<-+-+----+-+--|<-- DCCP-Response|
|(State= PARTOPEN)| | | | | | |
|DCCP-Ack --> |--+-+----+-+->| | State = OPEN
+-----------------+ +-+ +-+ +-----------------+
Figure 6: Example Showing a Triggered DCCP-Request
图6：显示触发的DCCP请求的示例
The figure below illustrates the sequence of packets exchanged when a DCCP-Listen and DCCP-Request are processed out of order. Reception of the DCCP-Listen packet by the client triggers retransmission of the DCCP-Request. The server responds to the first DCCP-Request and enters the RESPOND state. The server subsequently responds to the second DCCP-Request with another DCCP-Response, which is ignored by the client (already in the PARTOPEN state).
下图说明了当DCCP侦听和DCCP请求被无序处理时交换的数据包序列。客户端接收到DCCP侦听数据包时，会触发DCCP请求的重新传输。服务器响应第一个DCCP请求并进入响应状态。服务器随后用另一个DCCP响应响应第二个DCCP请求，该响应被客户机忽略（已处于PARTOPEN状态）。
DCCP A DCCP B
------ NA NB ------
+-----------------+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
|SDP |--+-+----+-+->| | State = INVITED
|(State = REQUEST)| | | | | | |
|DCCP-Request --> |--+-+- -+-+--|<-- DCCP-Listen |
| | | | \/ | | | |
| | | | /\ | | | |
| |<-+-+- -+-+->| |
|DCCP-Request --> |--+-+- -+-+--|<-- DCCP-Response| State = RESPOND
| (Triggered) | | | \/ | | | |
| | | | /\ | | | |
| |<-+-+- -+-+->| |
|(State= PARTOPEN)| | | | | | |
|DCCP-Ack --> |--+-+- -+-+--|<-- DCCP-Response|
| (Triggered) | | | \/ | | | |
| | | | /\ | | | |
| (Ignored) |<-+-+- -+-+->| | State = OPEN
| | | | | | | |
+-----------------+ +-+ +-+ +-----------------+
DCCP A DCCP B
------ NA NB ------
+-----------------+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
|SDP |--+-+----+-+->| | State = INVITED
|(State = REQUEST)| | | | | | |
|DCCP-Request --> |--+-+- -+-+--|<-- DCCP-Listen |
| | | | \/ | | | |
| | | | /\ | | | |
| |<-+-+- -+-+->| |
|DCCP-Request --> |--+-+- -+-+--|<-- DCCP-Response| State = RESPOND
| (Triggered) | | | \/ | | | |
| | | | /\ | | | |
| |<-+-+- -+-+->| |
|(State= PARTOPEN)| | | | | | |
|DCCP-Ack --> |--+-+- -+-+--|<-- DCCP-Response|
| (Triggered) | | | \/ | | | |
| | | | /\ | | | |
| (Ignored) |<-+-+- -+-+->| | State = OPEN
| | | | | | | |
+-----------------+ +-+ +-+ +-----------------+
Figure 7: Example Showing an Unnecessary Triggered DCCP-Request
图7：显示不必要的触发DCCP请求的示例
No changes are required if a DCCP client conforming to this document communicates with a DCCP server conforming to [RFC4340].
如果符合本文件要求的DCCP客户端与符合[RFC4340]要求的DCCP服务器通信，则无需进行任何更改。
If a client implements only [RFC4340], an incoming DCCP-Listen packet would be ignored due to step 1 in Section 8.1 of [RFC4340], which at the same time also conforms to the behaviour specified by this document.
如果客户端仅实现[RFC4340]，由于[RFC4340]第8.1节中的步骤1，传入的DCCP侦听数据包将被忽略，同时也符合本文档规定的行为。
This document further does not modify communication for any DCCP server that implements a passive-open without fully binding the addresses, ports, and Service Codes to be used. The authors therefore do not expect practical deployment problems with existing, conformant DCCP implementations.
本文档还不修改任何DCCP服务器的通信，该服务器在未完全绑定要使用的地址、端口和服务代码的情况下实现被动打开。因此，作者并不期望现有的、一致的DCCP实现会出现实际的部署问题。
This is an informative section that reviews the rationale for the design of this method.
这是一个资料性章节，回顾了该方法设计的基本原理。
The DCCP-Listen packet specified in Section 2.2.1 has the same format as the DCCP-Request packet ([RFC4340], Section 5.1), the only difference is in the value of the Type field. The usage, however, differs. The DCCP-Listen packet serves as an advisory message, not as part of the actual connection setup: sequence numbers have no meaning, and no payload can be communicated.
第2.2.1节中指定的DCCP侦听数据包与DCCP请求数据包具有相同的格式（[RFC4340]，第5.1节），唯一的区别在于类型字段的值。然而，用法不同。DCCP Listen数据包用作建议消息，而不是实际连接设置的一部分：序列号没有任何意义，也没有有效负载可以通信。
A DCCP-Request packet could, in theory, also have been used for the same purpose. The following arguments were against this:
理论上，DCCP请求包也可以用于相同的目的。以下论点反对这一点：
The first problem was that of semantic overloading: the DCCP-Request defined in [RFC4340] serves a well-defined purpose, being the initial packet of the 3-way handshake. Additional use in the manner of a DCCP-Listen packet would have required DCCP processors to have two different processing paths: one where a DCCP-Request was interpreted as part of the initial handshake, and another where the same packet was interpreted as an indication of an intention to accept a new connection. This would complicate packet processing in hosts and, in particular, stateful middleboxes (which may have restricted computational resources).
第一个问题是语义重载：在[RFC4340]中定义的DCCP请求用于定义明确的目的，是3路握手的初始数据包。如果以DCCP侦听数据包的方式进行额外使用，则需要DCCP处理器具有两个不同的处理路径：一个是DCCP请求被解释为初始握手的一部分，另一个是同一数据包被解释为接受新连接的意图的指示。这将使主机中的数据包处理复杂化，尤其是有状态的中间盒（可能会限制计算资源）。
The second problem is that a client receiving a DCCP-Request from a server could generate a DCCP-Reset packet if it had not yet entered the REQUEST state (step 7 in Section 8.5 of [RFC4340]). The method specified in this document lets client endpoints ignore DCCP-Listen packets. Adding a similar rule for the DCCP-Request packet would have been cumbersome: clients would not have been able to distinguish between a DCCP-Request packet meant to indicate an intention to accept a new connection and a genuinely erratic connection initiation.
第二个问题是，从服务器接收DCCP请求的客户机如果尚未进入请求状态（RFC4340第8.5节中的步骤7），可能会生成DCCP重置数据包。此文档中指定的方法允许客户端端点忽略DCCP侦听数据包。为DCCP请求数据包添加一个类似的规则会很麻烦：客户端将无法区分用于表示接受新连接的意图的DCCP请求数据包和真正不稳定的连接启动。
The third problem is similar and refers to a client receiving the indication after having itself sent a (connection-initiation) DCCP-Request. Step 7 in Section 8.5 of [RFC4340] requires the client to reply to a DCCP-Request from the server with a DCCP-Sync packet. Since sequence numbers are ignored for this type of message, additional and complex processing would become necessary: either to ask the client not to respond to a DCCP-Request when the request is used as an indication, or to ask middleboxes and servers to ignore DCCP-Sync packets generated in response to DCCP-Request packets that are used as indications. Furthermore, since no initial sequence numbers have been negotiated at this stage, sending a DCCP-SyncAck would not be meaningful.
第三个问题与此类似，是指客户端在自身发送（连接启动）DCCP请求后接收到指示。[RFC4340]第8.5节中的步骤7要求客户机使用DCCP同步数据包回复来自服务器的DCCP请求。由于这种类型的消息忽略了序列号，因此需要进行额外的复杂处理：当请求用作指示时，要求客户端不要响应DCCP请求，或者要求中间盒和服务器忽略响应用作指示的DCCP请求数据包而生成的DCCP同步数据包。此外，由于在此阶段没有协商初始序列号，因此发送DCCP SyncAck将没有意义。
The use of a separate packet type therefore allows simpler and clearer processing.
因此，使用单独的数据包类型允许更简单、更清晰的处理。
Although the DCCP-Listen Sequence Number fields are ignored, they have been retained in the DCCP-Listen packet header to reuse the generic header format from Section 5.1 of [RFC4340].
尽管忽略了DCCP侦听序列号字段，但它们已保留在DCCP侦听数据包报头中，以重用[RFC4340]第5.1节中的通用报头格式。
DCCP assigns a random initial value to the sequence number when a DCCP connection is established [RFC4340]. However, a sender is required to set this value to zero for a DCCP-Listen packet. Both clients and middleboxes are also required to ignore this value.
当建立DCCP连接时，DCCP将随机初始值分配给序列号[RFC4340]。但是，对于DCCP侦听数据包，发送方需要将该值设置为零。客户端和中间盒都需要忽略此值。
The rationale for ignoring the Sequence Number fields of DCCP-Listen packets is that, at the time the DCCP-Listen is exchanged, the endpoints have not yet entered connection setup: the DCCP-Listen packet is sent while the server is still in the passive-open (INVITED) state, i.e., it has not yet allocated state, other than binding to the client's IP-address:port and Service Code.
忽略DCCP侦听数据包的序列号字段的理由是，在交换DCCP侦听数据包时，端点尚未进入连接设置：DCCP侦听数据包在服务器仍处于被动打开（邀请）状态（即尚未分配状态）时发送，除了绑定到客户端的IP地址之外：端口和服务代码。
A DCCP server should by default permit generation of DCCP-Listen packets. Since DCCP-Listen packets solve a particular problem with NAT and/or firewall traversal, the generation of DCCP-Listen packets on passive sockets is tied to a condition (binding to a remote address and Service Code that are both known a priori) to ensure this does not interfere with the general case of "normal" DCCP connections (where client addresses are generally not known in advance).
默认情况下，DCCP服务器应允许生成DCCP侦听数据包。由于DCCP侦听数据包解决了NAT和/或防火墙穿越的特定问题，因此被动套接字上DCCP侦听数据包的生成与条件（绑定到事先已知的远程地址和服务代码）相关联，以确保这不会干扰“正常”DCCP连接的一般情况（通常事先不知道客户地址）。
In the TCP world, the analogue is a transition from LISTEN to SYN_SENT by virtue of sending data: "A fully specified passive call can be made active by the subsequent execution of a SEND" ([RFC0793], Section 3.8). Unlike TCP, this update does not perform a role change from passive to active. Like TCP, DCCP-Listen packets are only sent by a DCCP-server when the endpoint is fully specified (Section 2.2).
在TCP世界中，模拟是从侦听到通过发送数据发送的SYN_的过渡：“完全指定的被动呼叫可以通过后续执行发送而变为主动”（[RFC0793]，第3.8节）。与TCP不同，此更新不会执行从被动到主动的角色更改。与TCP一样，DCCP侦听数据包仅在完全指定端点时由DCCP服务器发送（第2.2节）。
Repetition is a necessary requirement to increase robustness and the chance of successful connection establishment when a DCCP-Listen packet is lost due to congestion, link loss, or some other reason.
当DCCP侦听数据包由于拥塞、链路丢失或其他原因丢失时，重复是增强健壮性和成功建立连接的机会的必要条件。
The decision to recommend a maximum number of 3 timeouts (2 repeated copies of the original DCCP-Listen packet) results from the following consideration: the repeated copies need to be spaced sufficiently far apart in time to avoid suffering from correlated loss. The interval of 200ms was chosen to accommodate a wide range of wireless and wired network paths.
建议最多3次超时（原始DCCP侦听数据包的2个重复副本）的决定源于以下考虑：重复副本需要在时间上间隔足够远，以避免遭受相关丢失。选择200ms的间隔以适应广泛的无线和有线网络路径。
Another constraint is given by the retransmission interval for the DCCP-Request ([RFC4340], Section 8.1.1). To establish state, intermediate systems need to receive a (retransmitted) DCCP-Listen packet before the DCCP-Request times out (1 second). With three timeouts, each spaced 200 milliseconds apart, the overall time is still below one second. The sum of 600 milliseconds is sufficiently large to provide for longer one-way delays, as is the case, e.g., on some wireless links.
另一个约束是DCCP请求的重传间隔（[RFC4340]，第8.1.1节）。为了建立状态，中间系统需要在DCCP请求超时（1秒）之前接收（重新传输的）DCCP侦听数据包。有三次超时，每次间隔200毫秒，总时间仍低于1秒。600毫秒的总和足以提供更长的单向延迟，例如在某些无线链路上。
The rationale behind transitioning to the LISTEN1 state after two repetitions is that other problems, independent of establishing middlebox state, may occur (such as delay or loss of the initial DCCP-Request). Any late or retransmitted DCCP-Request packets will then still reach the server, allowing connection establishment to successfully complete.
在两次重复之后转换到LISTEN1状态的基本原理是，可能会出现与建立中间箱状态无关的其他问题（例如延迟或丢失初始DCCP请求）。任何延迟或重新传输的DCCP请求数据包仍将到达服务器，从而允许连接建立成功完成。
General security considerations for DCCP are described in [RFC4340]. Security considerations for Service Codes are further described in [RFC5595].
[RFC4340]中描述了DCCP的一般安全注意事项。[RFC5595]中进一步描述了服务代码的安全注意事项。
The method specified in this document generates a DCCP-Listen packet addressed to a specific DCCP client. This exposes the state of a DCCP server that is in a passive listening state (i.e., waiting to accept a connection from a known client).
本文档中指定的方法生成一个DCCP侦听数据包，该数据包发往特定的DCCP客户端。这会暴露处于被动侦听状态（即等待接受来自已知客户端的连接）的DCCP服务器的状态。
The exposed information is not encrypted and therefore could be seen on the network path to the DCCP client. An attacker on this return path could observe a DCCP-Listen packet and then exploit this by spoofing a packet (e.g., DCCP-Request or DCCP-Reset) with the IP addresses, DCCP ports, and Service Code that correspond to the values to be used for the connection. As in other on-path attacks, this could be used to inject data into a connection or to deny a connection request. A similar on-path attack is also possible for any DCCP connection, once the session is initiated by the client ([RFC4340], Section 18).
公开的信息未加密，因此可以在DCCP客户端的网络路径上看到。此返回路径上的攻击者可以观察到DCCP侦听数据包，然后通过使用IP地址、DCCP端口和服务代码欺骗数据包（例如，DCCP请求或DCCP重置）利用此漏洞进行攻击，这些IP地址、DCCP端口和服务代码对应于要用于连接的值。与其他路径攻击一样，这可用于将数据注入连接或拒绝连接请求。一旦客户端启动会话，任何DCCP连接也可能发生类似的路径攻击（[RFC4340]，第18节）。
The DCCP-Listen packet is only sent in response to explicit, prior out-of-band signaling from a DCCP client to the DCCP server (e.g., SDP [RFC4566] information communicated via the Session Initiation Protocol [RFC3261]) and will normally directly precede a DCCP-Request sent by the client (which carries the same information).
DCCP侦听数据包仅响应于从DCCP客户机到DCCP服务器的显式、预先带外信令（例如，通过会话发起协议[RFC3261]传送的SDP[RFC4566]信息）而发送，并且通常直接在客户机发送的DCCP请求（其携带相同信息）之前发送。
This update does not significantly increase the complexity or vulnerability of a DCCP implementation that conforms to [RFC4340]. A DCCP server SHOULD therefore, by default, permit generation of DCCP-Listen packets. A server that wishes to prevent disclosing this
此更新不会显著增加符合[RFC4340]的DCCP实现的复杂性或漏洞。因此，默认情况下，DCCP服务器应允许生成DCCP侦听数据包。希望防止泄露此信息的服务器
information MAY refrain from generating DCCP-Listen packets without impacting subsequent DCCP state transitions, but possibly inhibiting middlebox traversal.
在不影响后续DCCP状态转换的情况下，信息可以避免生成DCCP侦听数据包，但可能会抑制中间盒遍历。
The DCCP base specification in RFC 4340 defines an Init Cookie option, which lets a DCCP server avoid having to hold any state until the three-way, connection-setup handshake has completed. This specification enables an out-of-band mechanism that forces the server to hold state for a connection that has not yet been established. This is a change in the security profile of DCCP, although the impact is expected to be minimal and depends on the security features of the out-of-band mechanism (SIP SDP is one such mechanism that provides sufficient security features).
RFC 4340中的DCCP基本规范定义了一个Init Cookie选项，该选项允许DCCP服务器在三向连接设置握手完成之前不必保持任何状态。此规范启用带外机制，强制服务器保持尚未建立的连接的状态。这是DCCP安全配置文件中的一个变化，尽管影响预计最小，并且取决于带外机制的安全特性（SIP SDP是提供足够安全特性的此类机制之一）。
The method creates a new way for a client to set up a DCCP connection to a server using out-of-band data, transported over a signaling connection. If the signaling connection is not encrypted, an eavesdropper could see the client IP address and the port for the to-be-established DCCP connection, and generate a DCCP-Listen packet towards the client using its own server IP address and port. However, a client will only respond to a received DCCP-Listen packet if the server IP address and port match an existing DCCP connection that is in the REQUEST state (Section 2.3.2). The method therefore cannot be used to redirect the connection to a different server IP address.
该方法为客户端创建了一种新的方式，即使用通过信令连接传输的带外数据建立到服务器的DCCP连接。如果信令连接未加密，窃听者可以看到客户端IP地址和要建立的DCCP连接的端口，并使用其自己的服务器IP地址和端口向客户端生成DCCP侦听数据包。但是，只有当服务器IP地址和端口与处于请求状态的现有DCCP连接匹配时，客户端才会响应接收到的DCCP侦听数据包（第2.3.2节）。因此，无法使用该方法将连接重定向到其他服务器IP地址。
The IANA registered a new packet type, "DCCP-Listen", in the IANA DCCP Packet Types Registry. The decimal value 10 has been assigned to this type. This registry entry references this document.
IANA在IANA DCCP数据包类型注册表中注册了一个新的数据包类型“DCCP侦听”。十进制值10已分配给此类型。此注册表项引用此文档。
This update was originally co-authored by Dr. Gerrit Renker, University of Aberdeen, and the present author acknowledges his insight in design of the protocol mechanism and in careful review of the early revisions of the document text. Dan Wing assisted on issues relating to the use of NAT and NAPT.
这一更新最初是由阿伯丁大学的Gerrit Renker博士共同撰写的，作者承认了他在设计协议机制和仔细审查文档文本的早期修订方面的见解。Dan Wing协助处理与NAT和NAPT使用相关的问题。
[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月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC5595] Fairhurst, G., "The DCCP Service Code", RFC 5595, September 2009.
[RFC5595]Fairhurst，G.，“DCCP服务代码”，RFC 55952009年9月。
[Epp05] Eppinger, J-L., "TCP Connections for P2P Apps: A Software Approach to Solving the NAT Problem", Carnegie Mellon University/ISRI Technical Report CMU-ISRI-05-104, January 2005.
[Epp05]Eppinger，J-L.“P2P应用程序的TCP连接：解决NAT问题的软件方法”，卡内基梅隆大学/ISRI技术报告CMU-ISRI-05-104，2005年1月。
[FSK05] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer Communication Across Network Address Translators", Proceedings of USENIX-05, pages 179-192, 2005.
[FSK05]Ford，B.，Srisuresh，P.，和D.Kegel，“跨网络地址转换器的点对点通信”，USENIX-05会议记录，第179-192页，2005年。
[GF05] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of Internet Measurement Conference (IMC-05), pages 199- 211, 2005.
[GF05]Guha，S.和P.Francis，“通过NAT和防火墙的TCP穿越的特征和测量”，互联网测量会议记录（IMC-05），第199-211页，2005年。
[GTF04] Guha, S., Takeda, Y., and P. Francis, "NUTSS: A SIP based approach to UDP and TCP connectivity", Proceedings of SIGCOMM-04 Workshops, Portland, OR, pages 43-48, 2004.
[GTF04]Guha，S.，Takeda，Y.，和P.Francis，“NUTSS：基于SIP的UDP和TCP连接方法”，SIGCOMM-04研讨会论文集，波特兰，或，第43-48页，2004年。
[H.323] ITU-T, "Packet-based Multimedia Communications Systems", Recommendation H.323, July 2003.
[H.323]ITU-T，“基于分组的多媒体通信系统”，建议H.323，2003年7月。
[ICE] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, July 2008.
[ICE]Rosenberg，J.，“具有交互式连接建立（ICE）的TCP候选者”，正在进行的工作，2008年7月。
[NAT-APP] Ford, B., "Application Design Guidelines for Traversal through Network Address Translators", Work in Progress, March 2007.
[NAT-APP]Ford，B.，“通过网络地址转换器进行遍历的应用程序设计指南”，进展中的工作，2007年3月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[RFC3235]Senie，D.，“网络地址转换器（NAT）-友好的应用程序设计指南”，RFC 32352002年1月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]Guha，S.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月。
[RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol", BCP 150, RFC 5597, September 2009.
[RFC5597]Denis Courmont，R.，“数据报拥塞控制协议的网络地址转换（NAT）行为要求”，BCP 150，RFC 5597，2009年9月。
[STUN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, June 2009.
[STUN]Rosenberg，J.，Mahy，R.，和P.Matthews，“使用NAT周围的中继进行遍历（TURN）：NAT会话遍历实用程序的中继扩展（STUN）”，正在进行的工作，2009年6月。
This appendix provides a brief review of existing techniques to establish connectivity across NAT devices, with the aim of providing background information. It first considers TCP NAT traversal based on simultaneous-open, and then discusses a second technique based on role reversal. Further information can be found in [GTF04] and [GF05].
本附录简要回顾了用于跨NAT设备建立连接的现有技术，旨在提供背景信息。首先考虑了基于同步开放的TCP NAT穿越，然后讨论了基于角色反转的第二种技术。更多信息请参见[GTF04]和[GF05]。
A central idea shared by these techniques is to make peer-to-peer sessions look like "outbound" sessions on each NAT device. Often a rendezvous server, located in the public address realm, is used to enable clients to discover their NAT topology and the addresses of peers.
这些技术共享的一个中心思想是使对等会话看起来像每个NAT设备上的“出站”会话。通常，位于公共地址领域的集合服务器用于使客户端能够发现其NAT拓扑和对等方的地址。
The term 'hole punching' was coined in [FSK05] and refers to creating soft state in a traditional NAT device by initiating an outbound connection. A well-behaved NAT can subsequently exploit this to allow a reverse connection back to the host in the private address realm.
术语“打孔”是在[FSK05]中创造的，指通过启动出站连接在传统NAT设备中创建软状态。行为良好的NAT随后可以利用此漏洞，允许反向连接回专用地址域中的主机。
UDP and TCP hole punching use nearly the same technique [RFC4787]. The adaptation of the basic UDP hole punching principle to TCP NAT traversal [RFC5382] was introduced in Section 4 of [FSK05] and relies on the simultaneous-open feature of TCP [RFC0793]. A further difference between UDP and TCP lies in the way the clients perform connectivity checks after obtaining suitable address pairs for connection establishment. Whereas in UDP a single socket is sufficient, TCP clients require several sockets for the same address and port tuple:
UDP和TCP打孔使用几乎相同的技术[RFC4787]。[FSK05]第4节介绍了基本UDP打孔原理对TCP NAT遍历[RFC5382]的适应性，并依赖于TCP[RFC0793]的同时打开功能。UDP和TCP之间的另一个区别在于客户端在获得合适的地址对以建立连接后执行连接检查的方式。而在UDP中，一个套接字就足够了，TCP客户端需要多个套接字用于相同的地址和端口元组：
o a passive socket to listen for connectivity tests from peers, and
o 被动套接字，用于侦听来自对等方的连接测试，以及
o multiple active connections from the same address to test reachability of other peers.
o 来自同一地址的多个活动连接，以测试其他对等方的可达性。
The SYN sent out by client A to its peer B creates soft state in A's NAT. At the same time, B tries to connect to A:
客户端A向其对等方B发送的SYN在A的NAT中创建软状态。同时，B尝试连接到A：
o if the SYN from B has left B's NAT before the arrival of A's SYN, both endpoints perform simultaneous-open (4-way handshake of SYN/ SYNACK);
o 如果来自B的SYN在A的SYN到达之前离开了B的NAT，则两个端点同时执行open（SYN/SYNACK的4路握手）；
o otherwise, A's SYN may not enter B's NAT, which leads to B performing a normal open (SYN_SENT => ESTABLISHED) and A performing a simultaneous-open (SYN_SENT => SYN_RCVD => ESTABLISHED).
o 否则，A的SYN可能不会进入B的NAT，这导致B执行正常打开（SYN_SENT=>已建立）和A执行同时打开（SYN_SENT=>SYN_RCVD=>已建立）。
In the latter case, it is necessary that the NAT does not interfere with a RST segment (REQ-4 in [RFC5382]). The simultaneous-open solution is convenient due to its simplicity, and is thus a preferred mode of operation in the TCP extension for Interactive Connectivity Establishment (ICE) ([ICE], Section 2).
在后一种情况下，NAT必须不干扰RST段（RFC5382中的REQ-4）。同时开放解决方案因其简单性而方便，因此是交互式连接建立TCP扩展（ICE）（[ICE]，第2节）中的首选操作模式。
Among the various TCP NAT traversal approaches, the one using a TCP simultaneous-open suggests itself as a candidate for DCCP due to its simplicity ([GF05], [NAT-APP]).
在各种TCP NAT遍历方法中，使用TCP同时打开的方法由于其简单性而被认为是DCCP的候选方法（[GF05]，[NAT-APP]）。
A characteristic of TCP simultaneous-open is that this erases the clear distinction between client and server: both sides enter through active (SYN_SENT) as well as passive (SYN_RCVD) states. This characteristic conflicts with the DCCP design decision to provide a clear separation between client and server functions ([RFC4340], Section 4.6).
TCP同时打开的一个特点是，这消除了客户端和服务器之间的明显区别：双方都通过主动（SYN_SENT）和被动（SYN_RCVD）状态进入。该特性与DCCP设计决策相冲突，DCCP设计决策在客户端和服务器功能之间提供了明确的分离（[RFC4340]，第4.6节）。
In DCCP, several mechanisms implicitly rely on clearly defined client/server roles:
在DCCP中，有几种机制隐式地依赖于明确定义的客户机/服务器角色：
o Feature Negotiation: with few exceptions, almost all of DCCP's negotiable features use the "server-priority" reconciliation rule ([RFC4340], Section 6.3.1), whereby a peer exchanges its preference lists of feature values, and the server decides the outcome.
o 功能协商：除了少数例外，几乎所有DCCP的可协商功能都使用“服务器优先级”调节规则（[RFC4340]，第6.3.1节），通过该规则，对等方交换其功能值的首选列表，服务器决定结果。
o Closing States: only a server may generate DCCP-CloseReq packets (asking the peer to hold timewait state), while a client is only permitted to send DCCP-Close or DCCP-Reset packets to terminate a connection ([RFC4340], Section 8.3).
o 关闭状态：只有服务器可以生成DCCP CloseReq数据包（要求对等方保持timewait状态），而客户端只允许发送DCCP Close或DCCP Reset数据包来终止连接（[RFC4340]，第8.3节）。
o Service Codes [RFC5595]: a server may be associated with multiple Service Codes, while a client must be associated with exactly one ([RFC4340], Section 8.1.2).
o 服务代码[RFC5595]：一台服务器可以与多个服务代码关联，而一台客户端必须与一个服务代码关联（[RFC4340]，第8.1.2节）。
o Init Cookies: may only be used by a server and on DCCP-Response packets ([RFC4340], Section 8.1.4).
o 初始化Cookies：只能由服务器和DCCP响应数据包使用（[RFC4340]，第8.1.4节）。
The latter two points are not obstacles per se, but would have hindered the transition from a passive to an active socket. In DCCP, a DCCP-Request is only generated by a client. The assumption that "all DCCP hosts may be clients" was dismissed, since it would require undesirable changes to the state machine and would limit application programming. As a consequence, the retro-fitting of a TCP-style simultaneous-open into DCCP to allow simultaneous exchange of DCCP-Connect packets was not recommended.
后两点本身不是障碍，但会阻碍从被动插座到主动插座的过渡。在DCCP中，DCCP请求仅由客户端生成。“所有DCCP主机都可能是客户端”的假设被驳回，因为这将需要对状态机进行不必要的更改，并限制应用程序编程。因此，不建议将TCP样式的同时打开重新安装到DCCP中，以允许同时交换DCCP连接数据包。
Another simple TCP NAT traversal scheme uses role traversal ([Epp05], [GTF04]), where a peer first opens an active connection for the single purpose of punching a hole in the firewall, and then reverts to a listening socket, accepting connections that arrive via the new path.
另一个简单的TCP NAT遍历方案使用角色遍历（[Epp05]，[GTF04]），其中对等方首先打开一个活动连接，用于在防火墙上穿孔，然后返回到侦听套接字，接受通过新路径到达的连接。
This solution would have had several disadvantages if used with DCCP. First, a DCCP server would be required to change its role to temporarily become a 'client'. This would have required modification to the state machine -- in particular, the treatment of Service Codes and perhaps Init Cookies. Further, the method would have needed to follow feature negotiation, since an endpoint's choice of initial options can rely on its role (i.e., an endpoint that knows it is the server can make a priori assumptions about the preference lists of features it is negotiating with the client, thereby enforcing a particular policy). Finally, the server would have needed additional processing to ensure that the connection arriving at the listening socket matches the previously opened active connection.
如果与DCCP一起使用，此解决方案将有几个缺点。首先，DCCP服务器需要将其角色更改为临时“客户端”。这需要对状态机进行修改——特别是对服务代码和Init cookie的处理。此外，该方法将需要遵循特征协商，因为端点对初始选项的选择可以依赖于其角色（即，知道它是服务器的端点可以对它正在与客户端协商的特征的偏好列表进行先验假设，从而强制执行特定策略）。最后，服务器将需要额外的处理，以确保到达侦听套接字的连接与先前打开的活动连接匹配。
This approach was therefore not recommend for DCCP.
因此，不建议将此方法用于DCCP。
Author's Address
作者地址
Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland
GoRead FelHurt阿伯丁大学工程学院弗雷泽贵族大厦阿伯丁Ab24 3UE苏格兰
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk