Network Working Group R. Denis-Courmont
Request for Comments: 5597 VideoLAN project
BCP: 150 September 2009
Category: Best Current Practice
Network Working Group R. Denis-Courmont
Request for Comments: 5597 VideoLAN project
BCP: 150 September 2009
Category: Best Current Practice
Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol
数据报拥塞控制协议的网络地址转换（NAT）行为要求
Abstract
摘要
This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly.
本文件定义了NAT处理数据报拥塞控制协议（DCCP）的一系列要求。这些要求允许DCCP应用程序（如流式应用程序）一致运行，并且与IETF已经发布的NAT的TCP要求非常相似。确保NAT满足这组要求将大大增加使用DCCP的应用程序正常运行的可能性。
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
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 the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，其衍生作品可能会
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标准流程之外创建，除非将其格式化以RFC形式发布，或将其翻译成英语以外的语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 3
4. DCCP Connection Initiation . . . . . . . . . . . . . . . . . . 4
5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . . 5
6. Application-Level Gateways . . . . . . . . . . . . . . . . . . 5
7. Other Requirements Applicable to DCCP . . . . . . . . . . . . . 5
8. Requirements Specific to DCCP . . . . . . . . . . . . . . . . . 6
9. DCCP without NAT Support . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 3
4. DCCP Connection Initiation . . . . . . . . . . . . . . . . . . 4
5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . . 5
6. Application-Level Gateways . . . . . . . . . . . . . . . . . . 5
7. Other Requirements Applicable to DCCP . . . . . . . . . . . . . 5
8. Requirements Specific to DCCP . . . . . . . . . . . . . . . . . 6
9. DCCP without NAT Support . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
For historical reasons, NAT devices are not typically capable of handling datagrams and flows for applications that use the Datagram Congestion Control Protocol (DCCP) [RFC4340].
由于历史原因，NAT设备通常不能为使用数据报拥塞控制协议（DCCP）的应用程序处理数据报和流[RFC4340]。
This memo discusses the technical issues involved and proposes a set of requirements for NAT devices to handle DCCP in a way that enables communications when either or both of the DCCP endpoints are located behind one or more NAT devices. All definitions and requirements in [RFC4787] are inherited here. The requirements are otherwise designed similarly to those in [RFC5382], from which this memo borrows its structure and much of its content.
本备忘录讨论了涉及的技术问题，并为NAT设备提出了一组要求，以便在其中一个或两个DCCP端点位于一个或多个NAT设备后面时，以能够实现通信的方式处理DCCP。[RFC4787]中的所有定义和要求在此继承。这些要求的设计与[RFC5382]中的要求类似，本备忘录借用了其结构和大部分内容。
Note however that, if both endpoints are hindered by NAT devices, the normal model for DCCP of asymmetric connection will not work. A simultaneous-open must be performed, as in [RFC5596]. Also, a separate, unspecified mechanism may be needed, such as Unilateral Self Address Fixing (UNSAF) [RFC3424] protocols, if an endpoint needs to learn its own external NAT mappings.
但是请注意，如果两个端点都受到NAT设备的阻碍，则非对称连接的DCCP的正常模型将无法工作。必须同时打开，如[RFC5596]中所述。此外，如果端点需要学习自己的外部NAT映射，则可能需要单独的、未指定的机制，例如单边自地址固定（UNSAF）[RFC3424]协议。
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]中所述进行解释。
This document uses the term "DCCP connection" to refer to individual DCCP flows, as uniquely identified by the quadruple (source and destination IP addresses and DCCP ports) at a given time.
本文档使用术语“DCCP连接”来指单个DCCP流，在给定时间由四个（源和目标IP地址以及DCCP端口）唯一标识。
This document uses the term "NAT mapping" to refer to a state at the NAT that is necessary for network address and port translation of DCCP connections. This document also uses the terms "endpoint-independent mapping", "address-dependent mapping", "address and port-dependent mapping", "filtering behavior", "endpoint-independent filtering", "address-dependent filtering", "address and port-dependent filtering", "port assignment", "port overloading", "hairpinning", and "external source IP address and port" as defined in [RFC4787].
本文档使用术语“NAT映射”来表示DCCP连接的网络地址和端口转换所需的NAT状态。本文档还使用了术语“端点无关映射”、“地址相关映射”、“地址和端口相关映射”、“过滤行为”、“端点无关过滤”、“地址相关过滤”、“地址和端口相关过滤”、“端口分配”、“端口重载”、“发夹”等[RFC4787]中定义的“外部源IP地址和端口”。
This document applies to NAT devices that want to handle DCCP datagrams. It is not the intent of this document to deprecate the overwhelming majority of deployed NAT devices. These NATs are simply not expected to handle DCCP, so this memo is not applicable to them.
本文档适用于希望处理DCCP数据报的NAT设备。本文档无意反对绝大多数已部署的NAT设备。这些NAT根本不需要处理DCCP，因此本备忘录不适用于它们。
Expected NAT behaviors applicable to DCCP connections are very similar to those applicable to TCP connections (with the exception of REQ-6 below). The following requirements are discussed and justified extensively in [RFC5382]. These justifications are not reproduced here for the sake of brevity.
适用于DCCP连接的预期NAT行为与适用于TCP连接的NAT行为非常相似（下面的REQ-6除外）。[RFC5382]对以下要求进行了详细讨论和论证。为了简洁起见，这里不重复这些理由。
In addition to the usual changes to the IP header (in particular, the IP addresses), NAT devices need to mangle:
除了对IP头（特别是IP地址）的常规更改外，NAT设备还需要：
o the DCCP source port for outgoing packets, depending on the NAT mapping,
o 传出数据包的DCCP源端口，取决于NAT映射，
o the DCCP destination port for incoming packets, depending on the NAT mapping, and
o 传入数据包的DCCP目标端口，具体取决于NAT映射，以及
o the DCCP checksum, to compensate for IP address and port number modifications.
o DCCP校验和，用于补偿IP地址和端口号修改。
Because changing the source or destination IP address of a DCCP packet will normally invalidate the DCCP checksum, it is not possible to use DCCP through a NAT without dedicated support. Some NAT devices are known to provide "generic" transport-protocol support, whereby only the IP header is mangled. That scheme is not sufficient to support DCCP.
由于更改DCCP数据包的源或目标IP地址通常会使DCCP校验和无效，因此在没有专用支持的情况下，不可能通过NAT使用DCCP。已知一些NAT设备提供“通用”传输协议支持，因此只有IP报头被损坏。该方案不足以支持DCCP。
A NAT uses a mapping to translate packets for each DCCP connection. A mapping is dynamically allocated for connections initiated from the internal side, and is potentially reused for certain subsequent connections. NAT behavior regarding when a mapping can be reused differs for different NATs, as described in [RFC4787].
NAT使用映射为每个DCCP连接转换数据包。映射是为从内部启动的连接动态分配的，并且可能会被某些后续连接重用。关于何时可以重用映射的NAT行为对于不同的NAT是不同的，如[RFC4787]中所述。
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior for DCCP.
REQ-1:NAT必须具有DCCP的“端点独立映射”行为。
REQ-2: A NAT MUST support all valid sequences of DCCP packets (defined in [RFC4340] and its updates) for connections initiated both internally as well as externally when the connection is permitted by the NAT. In particular, in addition to handling the DCCP 3-way handshake mode of connection initiation, A NAT MUST handle the DCCP simultaneous-open mode of connection initiation, defined in [RFC5596]. That mode updates DCCP by adding a new packet type: DCCP-Listen. The DCCP-Listen packet communicates the information necessary to uniquely identify a DCCP session. NATs may utilise the connection information (address, port, Service Code) to establish local forwarding state.
REQ-2:NAT必须支持所有有效的DCCP数据包序列（在[RFC4340]及其更新中定义），以便在NAT允许连接时，在内部和外部启动连接。特别是，除了处理连接启动的DCCP 3路握手模式外，NAT还必须处理[RFC5596]中定义的DCCP同时打开连接启动模式。该模式通过添加新的数据包类型来更新DCCP：DCCP侦听。DCCP侦听数据包传递唯一标识DCCP会话所需的信息。NAT可利用连接信息（地址、端口、服务代码）建立本地转发状态。
REQ-3: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-independent filtering" behavior for DCCP. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-dependent filtering" behavior for DCCP.
REQ-3：如果应用程序透明性是最重要的，建议NAT对DCCP具有“端点独立过滤”行为。如果更严格的过滤行为是最重要的，建议NAT对DCCP具有“地址相关过滤”行为。
o The filtering behavior MAY be an option configurable by the administrator of the NAT.
o 过滤行为可能是NAT管理员可配置的选项。
o The filtering behavior for DCCP MAY be independent of the filtering behavior for any other transport-layer protocol, such as UDP, UDP-Lite, TCP, and SCTP (Stream Control Transmission Protocol).
o DCCP的过滤行为可以独立于任何其他传输层协议的过滤行为，例如UDP、UDP Lite、TCP和SCTP（流控制传输协议）。
REQ-4: A NAT MUST wait for at least 6 seconds from the reception of an unsolicited, inbound DCCP-Listen or DCCP-Sync packet before it may respond with an ICMP Port Unreachable error, an ICMP Protocol Unreachable error, or a DCCP-Reset. If, during this interval, the NAT receives and translates an outbound DCCP-Request packet for the
REQ-4:NAT必须在收到未经请求的入站DCCP侦听或DCCP同步数据包后等待至少6秒，然后才能响应ICMP端口不可访问错误、ICMP协议不可访问错误或DCCP重置。如果在该时间间隔内，NAT接收并转换服务器的出站DCCP请求数据包
connection, the NAT MUST silently drop the original unsolicited, inbound DCCP-Listen packet. Otherwise, the NAT SHOULD send an ICMP Port Unreachable error (Type 3, Code 3) for the original DCCP-Listen unless the security policy forbids it.
连接时，NAT必须静默地丢弃原始的未经请求的入站DCCP侦听数据包。否则，NAT应为原始DCCP侦听发送ICMP端口不可访问错误（类型3，代码3），除非安全策略禁止。
The "established connection idle-timeout" for a NAT is defined as the minimum time a DCCP connection in the established phase must remain idle before the NAT considers the associated session a candidate for removal. The "transitory connection idle-timeout" for a NAT is defined as the minimum time a DCCP connection in the CLOSEREQ or CLOSING phases must remain idle before the NAT considers the associated session a candidate for removal. DCCP connections in the TIMEWAIT state are not affected by the "transitory connection idle-timeout".
NAT的“已建立连接空闲超时”定义为在NAT将相关会话视为删除候选会话之前，已建立阶段中的DCCP连接必须保持空闲的最短时间。NAT的“临时连接空闲超时”定义为DCCP连接在CLOSEREQ或Closeing阶段必须保持空闲的最短时间，然后NAT才会将相关会话视为删除的候选会话。处于TIMEWAIT状态的DCCP连接不受“临时连接空闲超时”的影响。
REQ-5: If a NAT cannot determine whether the endpoints of a DCCP connection are active, it MAY abandon the session if it has been idle for some time. Where a NAT implements session timeouts, the default value of the "established connection idle-timeout" MUST be of 124 minutes or longer, and the default value of the "transitory connection idle-timeout" MUST be of 4 minutes or longer. A NAT that implements session timeouts may be configurable to use smaller values for the NAT idle-timeouts.
REQ-5：如果NAT无法确定DCCP连接的端点是否处于活动状态，则如果会话已空闲一段时间，它可能会放弃会话。如果NAT实现会话超时，“已建立连接空闲超时”的默认值必须为124分钟或更长，“临时连接空闲超时”的默认值必须为4分钟或更长。实现会话超时的NAT可以配置为使用较小的NAT空闲超时值。
NAT behavior for handling DCCP-Reset packets or connections in the TIMEWAIT state is left unspecified.
未指定在TIMEWAIT状态下处理DCCP重置数据包或连接的NAT行为。
Contrary to TCP, DCCP is a loss-tolerant protocol. Therefore, modifying the payload of DCCP packets may present a significant additional challenge in maintaining any application-layer state needed for an Application Level Gateway (ALG) to function properly. Additionally, there are no known DCCP-capable ALGs at the time of writing this document.
与TCP相反，DCCP是一种容错协议。因此，修改DCCP分组的有效载荷可能会在维护应用层网关（ALG）正常工作所需的任何应用层状态方面带来重大的额外挑战。此外，在编写本文件时，还没有已知的支持DCCP的ALG。
REQ-6: If a NAT includes ALGs, these ALGs MUST NOT affect DCCP.
REQ-6：如果NAT包括ALG，这些ALG不得影响DCCP。
NOTE: This is not consistent with REQ-6 of [RFC5382].
注：这与[RFC5382]的REQ-6不一致。
A list of general and UDP-specific NAT behavioral requirements are described in [RFC4787]. A list of ICMP-specific NAT behavioral requirements are described in [RFC5508]. The requirements listed
[RFC4787]中描述了一般和UDP特定NAT行为要求的列表。[RFC5508]中描述了ICMP特定NAT行为要求的列表。列出的要求
below reiterate the requirements from these two documents that directly affect DCCP. The following requirements do not relax any requirements in [RFC4787] or [RFC5508].
下面重申直接影响DCCP的这两份文件的要求。以下要求并未放松[RFC4787]或[RFC5508]中的任何要求。
REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading" for DCCP.
REQ-7:NAT不得具有DCCP的“端口分配”行为“端口过载”。
REQ-8: A NAT MUST support "hairpinning" for DCCP. Furthermore, a NAT's hairpinning behavior MUST be of type "External source IP address and port".
REQ-8:NAT必须支持DCCP的“发夹”。此外，NAT的发夹行为必须是“外部源IP地址和端口”类型。
REQ-9: If a NAT translates DCCP, it SHOULD translate ICMP Destination Unreachable (Type 3) messages.
REQ-9：如果NAT翻译DCCP，它应该翻译ICMP目标不可访问（类型3）消息。
REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping or DCCP connection for which the ICMP was generated.
REQ-10：接收任何类型的ICMP消息不得终止为其生成ICMP的NAT映射或DCCP连接。
DCCP supports partial checksum coverage. A NAT will usually need to perform incremental changes to the packet Checksum field, as for other IETF-defined protocols. However, if it needs to recalculate a correct checksum value, it must take the checksum coverage into account, as described in Section 9.2 of [RFC4340].
DCCP支持部分校验和覆盖。与其他IETF定义的协议一样，NAT通常需要对数据包校验和字段执行增量更改。但是，如果需要重新计算正确的校验和值，则必须考虑校验和覆盖率，如[RFC4340]第9.2节所述。
REQ-11: If a NAT translates a DCCP packet with a valid DCCP checksum, it MUST ensure that the DCCP checksum is translated such that it is valid after the translation.
REQ-11：如果NAT使用有效的DCCP校验和翻译DCCP数据包，则必须确保DCCP校验和已翻译，以便在翻译后有效。
REQ-12: A NAT MUST NOT modify the value of the DCCP Checksum Coverage.
REQ-12:NAT不得修改DCCP校验和覆盖率的值。
The Checksum Coverage field in the DCCP header determines the parts of the packet that are covered by the Checksum field. This always includes the DCCP header and options, but some or all of the application data may be excluded as determined on a packet-by-packet basis by the application. Changing the Checksum Coverage in the network violates the integrity assumptions at the receiver and may result in unpredictable or incorrect application behaviour.
DCCP报头中的校验和覆盖范围字段确定校验和字段覆盖的数据包部分。这始终包括DCCP报头和选项，但是应用程序可以根据分组逐个分组确定排除部分或全部应用程序数据。更改网络中的校验和覆盖范围违反了接收方的完整性假设，并可能导致不可预测或不正确的应用程序行为。
DCCP specifies a Service Code as a 4-byte value (32 bits) that describes the application-level service to which a client application wishes to connect [RFC4340].
DCCP将服务代码指定为4字节值（32位），用于描述客户端应用程序希望连接到的应用程序级服务[RFC4340]。
REQ-13: If a NAT translates a DCCP packet, it MUST NOT modify its DCCP Service Code value.
REQ-13：如果NAT转换DCCP数据包，则不得修改其DCCP服务代码值。
Further guidance on the use of Service Codes by middleboxes, including NATs, can be found in [RFC5595].
关于中间盒（包括NAT）使用服务代码的更多指南，请参见[RFC5595]。
If the NAT device cannot be updated to support DCCP, DCCP datagrams can be encapsulated within a UDP transport header. Indeed, most NAT devices are already capable of handling UDP. This is however beyond the scope of this document.
如果无法更新NAT设备以支持DCCP，则可以将DCCP数据报封装在UDP传输头中。事实上，大多数NAT设备已经能够处理UDP。然而，这超出了本文件的范围。
[RFC4787] discusses security considerations for NATs that handle IP and unicast (UDP) traffic, all of which apply equally to this document. Security concerns specific to handling DCCP packets are discussed in this section.
[RFC4787]讨论了处理IP和单播（UDP）通信的NAT的安全注意事项，所有这些都同样适用于本文档。本节将讨论特定于处理DCCP数据包的安全问题。
REQ-1 and REQ-6 through REQ-13 do not introduce any new known security concerns.
REQ-1和REQ-6至REQ-13不会引入任何新的已知安全问题。
REQ-2 does not introduce any new known security concerns. While a NAT may elect to keep track of some DCCP-specific, per-flow state (compared to UDP), it has no obligations to do so.
REQ-2没有引入任何新的已知安全问题。虽然NAT可以选择跟踪特定于DCCP的每个流状态（与UDP相比），但它没有义务这样做。
REQ-3 allows a NAT to adopt either a more secure or a more application-transparent filtering policy. This is already addressed in [RFC4787] and [RFC5382].
REQ-3允许NAT采用更安全或更透明的应用程序过滤策略。[RFC4787]和[RFC5382]中已经提到了这一点。
Similar to [RFC5382], REQ-4 of this document recommends that a NAT respond to unsolicited, inbound Listen and Sync packets with an ICMP error delayed by a few seconds. Doing so may reveal the presence of a NAT to an external attacker. Silently dropping the Listen makes it harder to diagnose network problems and forces applications to wait for the DCCP stack to finish several retransmissions before reporting an error. An implementer must therefore understand and carefully weigh the effects of not sending an ICMP error or rate-limiting such ICMP errors to a very small number.
与[RFC5382]类似，本文档的REQ-4建议NAT响应未经请求的入站侦听和同步数据包，ICMP错误延迟几秒钟。这样做可能会向外部攻击者透露NAT的存在。静默地删除侦听会使诊断网络问题变得更加困难，并迫使应用程序在报告错误之前等待DCCP堆栈完成多次重新传输。因此，实施者必须理解并仔细权衡不发送ICMP错误或将此类ICMP错误限制在非常小的范围内的影响。
REQ-5 recommends that a NAT that passively monitors DCCP state keep idle sessions alive for at least 124 minutes or 4 minutes, depending on the state of the connection. To protect against denial-of-service attacks filling its state storage capacity, a NAT may attempt to actively determine the liveliness of a DCCP connection, or the NAT administrator could configure more conservative timeouts.
REQ-5建议被动监视DCCP状态的NAT将空闲会话保持活动状态至少124分钟或4分钟，具体取决于连接的状态。为了防止充满状态存储容量的拒绝服务攻击，NAT可能会尝试主动确定DCCP连接的活动性，或者NAT管理员可以配置更保守的超时。
The author would like to thank Gorry Fairhurst, Eddie Kohler, Dan Wing, Alfred Hoenes, Magnus Westerlund, Miguel Garcia, Catherine Meadows, Tim Polk, Lars Eggert, and Christian Vogt for their comments and help on this document.
作者要感谢Gorry Fairhurst、Eddie Kohler、Dan Wing、Alfred Hoenes、Magnus Westerlund、Miguel Garcia、Catherine Meadows、Tim Polk、Lars Eggert和Christian Vogt对本文件的评论和帮助。
This memo borrows heavily from [RFC5382] by S. Guha (editor), K. Biswas, B. Ford, S. Sivakumar, and P. Srisuresh.
本备忘录大量借鉴了S.Guha（编辑）、K.Biswas、B.Ford、S.Sivakumar和P.Srisuresh的[RFC5382]。
[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月。
[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月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508]Srisuresh，P.，Ford，B.，Sivakumar，S.，和S.Guha，“ICMP的NAT行为要求”，BCP 148，RFC 5508，2009年4月。
[RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/ Middlebox Traversal", RFC 5596, September 2009.
[RFC5596]Fairhurst，G.“数据报拥塞控制协议（DCCP）促进NAT/中间盒遍历的同时开放技术”，RFC 55962009年9月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[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月。
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
[RFC5595]Fairhurst，G.“数据报拥塞控制协议（DCCP）服务代码”，RFC5952009年9月。
Author's Address
作者地址
Remi Denis-Courmont VideoLAN project
雷米·丹尼斯·库蒙可视局域网项目
EMail: rem@videolan.org
URI: http://www.videolan.org/
EMail: rem@videolan.org
URI: http://www.videolan.org/