Internet Engineering Task Force (IETF) M. Tuexen
Request for Comments: 6951 Muenster Univ. of Appl. Sciences
Category: Standards Track R. Stewart
ISSN: 2070-1721 Adara Networks
May 2013
Internet Engineering Task Force (IETF) M. Tuexen
Request for Comments: 6951 Muenster Univ. of Appl. Sciences
Category: Standards Track R. Stewart
ISSN: 2070-1721 Adara Networks
May 2013
UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
用于端到端主机通信的流控制传输协议（SCTP）数据包的UDP封装
Abstract
摘要
This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.
本文档描述了一种将流控制传输协议（SCTP）数据包封装为UDP数据包的简单方法及其局限性。这允许在具有不支持SCTP的传统NAT的网络中使用SCTP。它还可用于在主机上实现SCTP，而无需直接访问IP层，例如，将其作为应用程序的一部分实现，而无需特殊权限。
Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document.
请注意，本文档仅描述SCTP堆栈中添加UDP封装所需的功能，仅提供两个终端主机通过UDP端口相互通信的机制。特别是，它不提供确定对等方是否正在使用UDP封装的机制，也不提供确定可以使用哪个远程UDP端口号的机制。这些功能超出了本文档的范围。
This document covers only end-hosts and not tunneling (egress or ingress) endpoints.
本文档仅涉及终端主机，不涉及隧道（出口或入口）端点。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6951.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6951.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Portable SCTP Implementations . . . . . . . . . . . . . . 3
3.2. Legacy NAT Traversal . . . . . . . . . . . . . . . . . . 4
4. Unilateral Self-Address Fixing (UNSAF) Considerations . . . . 4
5. SCTP over UDP . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Architectural Considerations . . . . . . . . . . . . . . 4
5.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Encapsulation Procedure . . . . . . . . . . . . . . . . . 6
5.4. Decapsulation Procedure . . . . . . . . . . . . . . . . . 7
5.5. ICMP Considerations . . . . . . . . . . . . . . . . . . . 7
5.6. Path MTU Considerations . . . . . . . . . . . . . . . . . 7
5.7. Handling of Embedded IP Addresses . . . . . . . . . . . . 8
5.8. Explicit Congestion Notification (ECN) Considerations . . 8
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 8
6.1. Get or Set the Remote UDP Encapsulation Port Number
(SCTP_REMOTE_UDP_ENCAPS_PORT) . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Portable SCTP Implementations . . . . . . . . . . . . . . 3
3.2. Legacy NAT Traversal . . . . . . . . . . . . . . . . . . 4
4. Unilateral Self-Address Fixing (UNSAF) Considerations . . . . 4
5. SCTP over UDP . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Architectural Considerations . . . . . . . . . . . . . . 4
5.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Encapsulation Procedure . . . . . . . . . . . . . . . . . 6
5.4. Decapsulation Procedure . . . . . . . . . . . . . . . . . 7
5.5. ICMP Considerations . . . . . . . . . . . . . . . . . . . 7
5.6. Path MTU Considerations . . . . . . . . . . . . . . . . . 7
5.7. Handling of Embedded IP Addresses . . . . . . . . . . . . 8
5.8. Explicit Congestion Notification (ECN) Considerations . . 8
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 8
6.1. Get or Set the Remote UDP Encapsulation Port Number
(SCTP_REMOTE_UDP_ENCAPS_PORT) . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
This document describes a simple method of encapsulating SCTP packets into UDP packets. SCTP, as defined in [RFC4960], runs directly over IPv4 or IPv6. There are two main reasons for encapsulating SCTP packets:
本文档描述了一种将SCTP数据包封装为UDP数据包的简单方法。[RFC4960]中定义的SCTP直接在IPv4或IPv6上运行。封装SCTP数据包有两个主要原因：
o To allow SCTP traffic to pass through legacy NATs, which do not provide native SCTP support as specified in [BEHAVE] and [NATSUPP].
o 允许SCTP流量通过传统NAT，传统NAT不提供[BEHAVE]和[NATSUPP]中指定的本机SCTP支持。
o To allow SCTP to be implemented on hosts that do not provide direct access to the IP layer. In particular, applications can use their own SCTP implementation if the operating system does not provide one.
o 允许在不提供对IP层的直接访问的主机上实现SCTP。特别是，如果操作系统不提供SCTP实现，应用程序可以使用自己的SCTP实现。
SCTP provides the necessary congestion control and reliability service that UDP does not perform.
SCTP提供UDP不执行的必要拥塞控制和可靠性服务。
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 section discusses two important use cases for encapsulating SCTP into UDP.
本节讨论将SCTP封装到UDP中的两个重要用例。
Some operating systems support SCTP natively. For other operating systems, implementations are available but require special privileges to install and/or use them. In some cases, a kernel implementation might not be available at all. When providing an SCTP implementation as part of a user process, most operating systems require special privileges to access the IP layer directly.
一些操作系统本机支持SCTP。对于其他操作系统，可以使用实现，但需要特殊权限才能安装和/或使用它们。在某些情况下，内核实现可能根本不可用。当作为用户进程的一部分提供SCTP实现时，大多数操作系统都需要特殊权限才能直接访问IP层。
Using UDP encapsulation makes it possible to provide an SCTP implementation as part of a user process that does not require any special privileges.
使用UDP封装可以提供SCTP实现，作为不需要任何特权的用户进程的一部分。
A crucial point for implementing SCTP in user space is that the source address of outgoing packets needs to be controlled. This is not an issue if the SCTP stack can use all addresses configured at
在用户空间中实现SCTP的一个关键点是需要控制传出数据包的源地址。如果SCTP堆栈可以使用在上配置的所有地址，则这不是问题
the IP layer as source addresses. However, it is an issue when also using the address management required for NAT traversal, described in Section 5.7.
IP层作为源地址。然而，在使用NAT遍历所需的地址管理时，这也是一个问题，如第5.7节所述。
Using UDP encapsulation allows SCTP communication when traversing
legacy NATs (i.e, those NATs not supporting SCTP as described in
[BEHAVE] and [NATSUPP]). For single-homed associations, IP addresses
MUST NOT be listed in the INIT and INIT-ACK chunks. To use multiple
addresses, the dynamic address reconfiguration extension described in
[RFC5061] MUST be used only with wildcard addresses in the ASCONF
chunks (Address Configuration Change Chunks) in combination with
[RFC4895].
Using UDP encapsulation allows SCTP communication when traversing
legacy NATs (i.e, those NATs not supporting SCTP as described in
[BEHAVE] and [NATSUPP]). For single-homed associations, IP addresses
MUST NOT be listed in the INIT and INIT-ACK chunks. To use multiple
addresses, the dynamic address reconfiguration extension described in
[RFC5061] MUST be used only with wildcard addresses in the ASCONF
chunks (Address Configuration Change Chunks) in combination with
[RFC4895].
For multihomed SCTP associations, the address management as described in Section 5.7 MUST be performed.
对于多宿SCTP关联，必须执行第5.7节所述的地址管理。
SCTP sends periodic HEARTBEAT chunks on all idle paths. These can keep the NAT state alive.
SCTP在所有空闲路径上定期发送心跳数据块。这些可以保持NAT状态。
As [RFC3424] requires a limited scope, this document only covers SCTP endpoints dealing with legacy constraints as described in Section 3. It doesn't cover generic tunneling endpoints.
由于[RFC3424]要求的范围有限，本文档仅涵盖处理第3节所述遗留约束的SCTP端点。它不包括通用隧道端点。
Obviously, the exit strategy is to use hosts supporting SCTP natively and middleboxes supporting SCTP as specified in [BEHAVE] and [NATSUPP].
显然，退出策略是按照[BEHAVE]和[NATSUPP]中的规定，使用本机支持SCTP的主机和支持SCTP的中间盒。
UDP-encapsulated SCTP is normally communicated between SCTP stacks using the IANA-assigned UDP port number 9899 (sctp-tunneling) on both ends. There are circumstances where other ports may be used on either end: As stated earlier, implementations in the application space might be required to use ports other than the registered port. Since NAT boxes might change UDP port numbers, the receiver might observe other UDP port numbers than were used by the sender. Discovery of alternate ports is outside of the scope of this document, but this section describes considerations for SCTP stack design in light of their potential use.
UDP封装的SCTP通常在两端使用IANA分配的UDP端口号9899（SCTP隧道）在SCTP堆栈之间进行通信。在某些情况下，任何一端都可以使用其他端口：如前所述，应用程序空间中的实现可能需要使用注册端口以外的端口。由于NAT框可能会更改UDP端口号，因此接收方可能会观察到发送方使用的其他UDP端口号。备用端口的发现不在本文档的范围内，但本节根据SCTP堆栈的潜在用途介绍了SCTP堆栈设计的注意事项。
Each SCTP stack uses a single local UDP encapsulation port number as the destination port for all its incoming SCTP packets. While the
每个SCTP堆栈使用一个本地UDP封装端口号作为其所有传入SCTP数据包的目标端口。而
uniqueness of the local UDP encapsulation port number is not necessarily required for the protocol, this greatly simplifies implementation design, since different ports for each address would require a sender implementation to choose the appropriate port while doing source address selection. Using a single local UDP encapsulation port number per host is not possible if the SCTP stack is implemented as part of each application, there are multiple applications, and some of the applications want to use the same IP address.
协议不一定要求本地UDP封装端口号的唯一性，这大大简化了实现设计，因为每个地址的不同端口需要发送方实现在选择源地址时选择适当的端口。如果SCTP堆栈作为每个应用程序的一部分实现，存在多个应用程序，并且某些应用程序希望使用相同的IP地址，则不可能为每个主机使用单个本地UDP封装端口号。
An SCTP implementation supporting UDP encapsulation MUST maintain a remote UDP encapsulation port number per destination address for each SCTP association. Again, because the remote stack may be using ports other than the well-known port, each port may be different from each stack. However, because of remapping of ports by NATs, the remote ports associated with different remote IP addresses may not be identical, even if they are associated with the same stack.
支持UDP封装的SCTP实现必须为每个SCTP关联的每个目标地址维护远程UDP封装端口号。同样，由于远程堆栈可能使用的端口不是已知端口，因此每个端口可能不同于每个堆栈。但是，由于NAT重新映射端口，与不同远程IP地址关联的远程端口可能不相同，即使它们与同一堆栈关联。
Implementation note: Because the well-known port might not be used, implementations need to allow other port numbers to be specified as a local or remote UDP encapsulation port number through APIs.
实现说明：由于可能不使用已知端口，实现需要允许通过API将其他端口号指定为本地或远程UDP封装端口号。
To encapsulate an SCTP packet, a UDP header as defined in [RFC0768] is inserted between the IP header as defined in [RFC0791] and the SCTP common header as defined in [RFC4960].
为了封装SCTP数据包，在[RFC0791]中定义的IP报头和[RFC4960]中定义的SCTP公共报头之间插入[RFC0768]中定义的UDP报头。
Figure 1 shows the packet format of an encapsulated SCTP packet when IPv4 is used.
图1显示了使用IPv4时封装的SCTP数据包的数据包格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: An SCTP/UDP/IPv4 Packet
Figure 1: An SCTP/UDP/IPv4 Packet
The packet format for an encapsulated SCTP packet when using IPv6 as defined in [RFC2460] is shown in Figure 2. Please note that the number m of IPv6 extension headers can be 0.
使用[RFC2460]中定义的IPv6时，封装的SCTP数据包的数据包格式如图2所示。请注意，IPv6扩展头的数量m可以是0。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Base Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Extension Header #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Extension Header #m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Base Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Extension Header #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Extension Header #m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Common Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: An SCTP/UDP/IPv6 Packet
Figure 2: An SCTP/UDP/IPv6 Packet
Within the UDP header, the source port MUST be the local UDP encapsulation port number of the SCTP stack, and the destination port MUST be the remote UDP encapsulation port number maintained for the association and the destination address to which the packet is sent (see Section 5.1).
在UDP报头中，源端口必须是SCTP堆栈的本地UDP封装端口号，目标端口必须是为关联和数据包发送到的目标地址维护的远程UDP封装端口号（参见第5.1节）。
Because the SCTP packet is the UDP payload, the length of the UDP packet MUST be the length of the SCTP packet plus the size of the UDP header.
因为SCTP数据包是UDP有效负载，所以UDP数据包的长度必须是SCTP数据包的长度加上UDP报头的大小。
The SCTP checksum MUST be computed for IPv4 and IPv6, and the UDP checksum SHOULD be computed for IPv4 and IPv6. (See [RFC0768] regarding IPv4; see [RFC2460] and [RFC6936] regarding IPv6.) Although UDP with a zero checksum over IPv6 is allowed under certain constraints [RFC6936], this document does not specify mechanisms for this mode. Deployed support may be limited; also, at the time of writing, the use of a zero UDP checksum would be counter to the goal of legacy NAT traversal.
必须为IPv4和IPv6计算SCTP校验和，并为IPv4和IPv6计算UDP校验和。（关于IPv4，请参见[RFC0768]；关于IPv6，请参见[RFC2460]和[RFC6936]）。尽管在某些约束[RFC6936]下允许在IPv6上使用校验和为零的UDP，但本文档并未指定此模式的机制。部署的支持可能有限；此外，在撰写本文时，使用零UDP校验和与传统NAT遍历的目标背道而驰。
When an encapsulated packet is received, the UDP header is removed. Then, the generic lookup is performed, as done by an SCTP stack whenever a packet is received, to find the association for the received SCTP packet. After finding the SCTP association (which includes checking the verification tag), the UDP source port MUST be stored as the encapsulation port for the destination address the SCTP packet is received from (see Section 5.1).
当收到封装的数据包时，UDP报头将被删除。然后，如每当接收到分组时由SCTP堆栈所做的那样，执行一般查找以查找所接收的SCTP分组的关联。找到SCTP关联（包括检查验证标记）后，UDP源端口必须存储为接收SCTP数据包的目标地址的封装端口（参见第5.1节）。
When a non-encapsulated SCTP packet is received by the SCTP stack, the encapsulation of outgoing packets belonging to the same association and the corresponding destination address MUST be disabled.
当SCTP堆栈接收到未封装的SCTP数据包时，必须禁用对属于同一关联和相应目标地址的传出数据包的封装。
When receiving ICMP or ICMPv6 response packets, there might not be enough bytes in the payload to identify the SCTP association that the SCTP packet triggering the ICMP or ICMPv6 packet belongs to. If a received ICMP or ICMPv6 packet cannot be related to a specific SCTP association or the verification tag cannot be verified, it MUST be discarded silently. In particular, this means that the SCTP stack MUST NOT rely on receiving ICMP or ICMPv6 messages. Implementation constraints could prevent processing received ICMP or ICMPv6 messages.
接收ICMP或ICMPv6响应数据包时，有效负载中可能没有足够的字节来标识触发ICMP或ICMPv6数据包的SCTP数据包所属的SCTP关联。如果接收到的ICMP或ICMPv6数据包无法与特定SCTP关联相关，或者无法验证验证标记，则必须以静默方式丢弃该数据包。特别是，这意味着SCTP堆栈不能依赖于接收ICMP或ICMPv6消息。实施约束可能会阻止处理收到的ICMP或ICMPv6消息。
If received ICMP or ICMPv6 messages are processed, the following mapping SHOULD apply:
如果已处理收到的ICMP或ICMPv6消息，则应应用以下映射：
1. ICMP messages with type 'Destination Unreachable' and code 'Port Unreachable' SHOULD be treated as ICMP messages with type 'Destination Unreachable' and code 'Protocol Unreachable'. See [RFC0792] for more details.
1. 类型为“Destination Unreachable”且代码为“Port Unreachable”的ICMP消息应视为类型为“Destination Unreachable”且代码为“Protocol Unreachable”的ICMP消息。有关更多详细信息，请参阅[RFC0792]。
2. ICMPv6 messages with type 'Destination Unreachable' and code 'Port Unreachable' SHOULD be treated as ICMPv6 messages with type 'Parameter Problem' and code 'unrecognized Next Header type encountered'. See [RFC4443] for more details.
2. 类型为“Destination Unreachable”且代码为“Port Unreachable”的ICMPv6消息应被视为类型为“Parameter Problem”且代码为“Unrecogned Next Header type Meeting”的ICMPv6消息。有关更多详细信息，请参阅[RFC4443]。
If an SCTP endpoint starts to encapsulate the packets of a path, it MUST decrease the Path MTU of that path by the size of the UDP header. If it stops encapsulating them, the Path MTU SHOULD be increased by the size of the UDP header.
如果SCTP端点开始封装路径的数据包，它必须将该路径的路径MTU减小UDP报头的大小。如果它停止封装它们，那么路径MTU应该增加UDP头的大小。
When performing Path MTU discovery as described in [RFC4820] and [RFC4821], it MUST be taken into account that one cannot rely on the feedback provided by ICMP or ICMPv6 due to the limitation laid out in Section 5.5.
在执行[RFC4820]和[RFC4821]中所述的路径MTU发现时，必须考虑到由于第5.5节规定的限制，不能依赖ICMP或ICMPv6提供的反馈。
If the implementation does not allow control of the Don't Fragment (DF) bit contained in the IPv4 header, then Path MTU discovery can't be used. In this case, an implementation-specific value should be used instead.
如果实现不允许控制IPv4标头中包含的不分段（DF）位，则无法使用路径MTU发现。在这种情况下，应该使用特定于实现的值。
When using UDP encapsulation for legacy NAT traversal, IP addresses that might require translation MUST NOT be put into any SCTP packet.
当使用UDP封装进行传统NAT遍历时，可能需要转换的IP地址不得放入任何SCTP数据包中。
This means that a multihomed SCTP association is set up initially as a single-homed one, and the protocol extension [RFC5061] in combination with [RFC4895] is used to add the other addresses. Only wildcard addresses are put into the SCTP packet.
这意味着多址SCTP关联最初设置为单址关联，协议扩展[RFC5061]结合[RFC4895]用于添加其他地址。只有通配符地址被放入SCTP数据包。
When addresses are changed during the lifetime of an association, the protocol extension [RFC5061] MUST be used with wildcard addresses only. If an SCTP endpoint receives an ABORT with the T-bit set, it MAY use this as an indication that the addresses seen by the peer might have changed.
当地址在关联的生存期内更改时，协议扩展[RFC5061]只能与通配符地址一起使用。如果SCTP端点接收到设置了T位的中止，它可以将此作为对等方看到的地址可能已更改的指示。
If the implementation supports the sending and receiving of the ECN bits for the IP protocols being used by an SCTP association, the ECN bits MUST NOT be changed during sending and receiving.
如果实现支持发送和接收SCTP关联使用的IP协议的ECN位，则在发送和接收期间不得更改ECN位。
This section describes how the socket API defined in [RFC6458] needs to be extended to provide a way for the application to control the UDP encapsulation.
本节描述了需要如何扩展[RFC6458]中定义的套接字API，以便为应用程序提供控制UDP封装的方法。
Please note that this section is informational only.
请注意，本节仅供参考。
A socket API implementation based on [RFC6458] is extended by supporting one new read/write socket option.
通过支持一个新的读/写套接字选项，扩展了基于[RFC6458]的套接字API实现。
6.1. Get or Set the Remote UDP Encapsulation Port Number (SCTP_REMOTE_UDP_ENCAPS_PORT)
6.1. 获取或设置远程UDP封装端口号（SCTP\U远程\U UDP\U封装\U端口）
This socket option can be used to set and retrieve the UDP encapsulation port number. This allows an endpoint to encapsulate initial packets.
此套接字选项可用于设置和检索UDP封装端口号。这允许端点封装初始数据包。
struct sctp_udpencaps {
sctp_assoc_t sue_assoc_id;
struct sockaddr_storage sue_address;
uint16_t sue_port;
};
struct sctp_udpencaps {
sctp_assoc_t sue_assoc_id;
struct sockaddr_storage sue_address;
uint16_t sue_port;
};
sue_assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, the application may fill in an association identifier or SCTP_FUTURE_ASSOC for this query. It is an error to use SCTP_{CURRENT|ALL}_ASSOC in sue_assoc_id.
sue_assoc_id：对于一对一样式的套接字，此参数被忽略。对于一对多样式套接字，应用程序可以为此查询填写关联标识符或SCTP_FUTURE_ASSOC。在sue_ASSOC_id中使用SCTP_{CURRENT | ALL}_ASSOC是一个错误。
sue_address: This specifies which address is of interest. If a wildcard address is provided, it applies only to future paths.
sue_address：指定感兴趣的地址。如果提供了通配符地址，则它仅适用于将来的路径。
sue_port: The UDP port number in network byte order; used as the destination port number for UDP encapsulation. Providing a value of 0 disables UDP encapsulation.
sue_port：按网络字节顺序排列的UDP端口号；用作UDP封装的目标端口号。提供值0将禁用UDP封装。
This document refers to the already assigned UDP port 9899 (sctp-tunneling). IANA has updated this assignment to refer to this document. As per [RFC6335], the Assignee is [IESG] and the Contact is [IETF_Chair].
本文档涉及已分配的UDP端口9899（sctp隧道）。IANA已更新本作业，以参考本文件。根据[RFC6335]，受让人为[IESG]，联系人为[IETF_主席]。
Please note that the TCP port 9899 (sctp-tunneling) assignment is not needed anymore, and IANA has removed this TCP port number assignment and marked TCP port 9899 as "Reserved".
请注意，不再需要TCP端口9899（sctp隧道）分配，IANA已删除此TCP端口号分配，并将TCP端口9899标记为“保留”。
Encapsulating SCTP into UDP does not add any additional security considerations to the ones given in [RFC4960] and [RFC5061].
将SCTP封装到UDP中不会给[RFC4960]和[RFC5061]中给出的安全注意事项增加任何额外的安全注意事项。
Firewalls inspecting SCTP packets must also be aware of the encapsulation and apply corresponding rules to the encapsulated packets.
检查SCTP数据包的防火墙还必须知道封装情况，并对封装的数据包应用相应的规则。
An attacker might send a malicious UDP packet towards an SCTP endpoint to change the encapsulation port for a single remote address of a particular SCTP association. However, as specified in
攻击者可能会向SCTP端点发送恶意UDP数据包，以更改特定SCTP关联的单个远程地址的封装端口。但是，按照
Section 5.4, this requires the usage of one of the two negotiated verification tags. This protects against blind attackers the same way as described in [RFC4960] for SCTP over IPv4 or IPv6. Non-blind attackers can affect SCTP association using the UDP encapsulation described in this document in the same way as SCTP associations not using the UDP encapsulation of SCTP described here.
第5.4节，这要求使用两个协商验证标签中的一个。这与[RFC4960]中针对IPv4或IPv6上的SCTP所述的方法相同，可防止盲攻击者的攻击。非盲攻击者可以使用本文档中描述的UDP封装影响SCTP关联，其方式与不使用此处描述的SCTP UDP封装的SCTP关联相同。
The authors wish to thank Stewart Bryant, Dave Crocker, Gorry Fairhurst, Tero Kivinen, Barry Leiba, Pete Resnick, Martin Stiemerling, Irene Ruengeler, and Dan Wing for their invaluable comments.
作者希望感谢Stewart Bryant、Dave Crocker、Gorry Fairhurst、Tero Kivinen、Barry Leiba、Pete Resnick、Martin Stiemerling、Irene Ruengeler和Dan Wing的宝贵评论。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[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月。
[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.E.和R.M.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007.
[RFC4820]Tuexen，M.，Stewart，R.，和P.Lei，“流控制传输协议（SCTP）的填充块和参数”，RFC 4820，2007年3月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
[RFC4895]Tuexen，M.，Stewart，R.，Lei，P.，和E.Rescorla，“流控制传输协议（SCTP）的认证块”，RFC 48952007年8月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061]Stewart，R.，Xie，Q.，Tuexen，M.，Maruyama，S.，和M.Kozuka，“流控制传输协议（SCTP）动态地址重新配置”，RFC 50612007年9月。
[BEHAVE] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation", Work in Progress, February 2013.
[BEHAVE]Stewart，R.，Tuexen，M.，和I.Ruengeler，“流控制传输协议（SCTP）网络地址转换”，正在进行的工作，2013年2月。
[NATSUPP] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", Work in Progress, February 2013.
[NATSUPP]Stewart，R.，Tuexen，M.，和I.Ruengeler，“流控制传输协议（SCTP）网络地址转换支持”，正在进行的工作，2013年2月。
[RFC3424] Daigle, L. 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月。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 63352011年8月。
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, December 2011.
[RFC6458]Stewart，R.，Tuexen，M.，Poon，K.，Lei，P.，和V.Yasevich，“流控制传输协议（SCTP）的套接字API扩展”，RFC 6458，2011年12月。
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013.
[RFC6936]Fairhurst，G.和M.Westerlund，“使用具有零校验和的IPv6 UDP数据报的适用性声明”，RFC 69362013年4月。
Authors' Addresses
作者地址
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt DE
米迦勒TuxEN明斯特应用科学大学StugWaldStasSE 39 48565 Stin Furt de
EMail: tuexen@fh-muenster.de
EMail: tuexen@fh-muenster.de
Randall R. Stewart Adara Networks Chapin, SC 29036 US
Randall R.Stewart Adara Networks Chapin，SC 29036美国
EMail: randall@lakerest.net
EMail: randall@lakerest.net