Internet Engineering Task Force (IETF) M. Tuexen
Request for Comments: 8261 Muenster Univ. of Appl. Sciences
Category: Standards Track R. Stewart
ISSN: 2070-1721 Netflix, Inc.
R. Jesup
WorldGate Communications
S. Loreto
Ericsson
November 2017
Internet Engineering Task Force (IETF) M. Tuexen
Request for Comments: 8261 Muenster Univ. of Appl. Sciences
Category: Standards Track R. Stewart
ISSN: 2070-1721 Netflix, Inc.
R. Jesup
WorldGate Communications
S. Loreto
Ericsson
November 2017
Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets
SCTP数据包的数据报传输层安全（DTLS）封装
Abstract
摘要
The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, the SCTP associations carried over DTLS can only be single-homed.
流控制传输协议（SCTP）是最初定义为在网络协议IPv4或IPv6之上运行的传输协议。本文档指定了如何在数据报传输层安全（DTLS）协议之上使用SCTP。使用本文档中描述的封装方法，SCTP不知道DTL下面使用的协议；因此，在SCTP控制块中不能使用显式IP地址。因此，通过DTL携带的SCTP关联只能是单宿的。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8261.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8261.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Encapsulation and Decapsulation Procedure . . . . . . . . . . 3
4. General Considerations . . . . . . . . . . . . . . . . . . . 4
5. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Encapsulation and Decapsulation Procedure . . . . . . . . . . 3
4. General Considerations . . . . . . . . . . . . . . . . . . . 4
5. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
The Stream Control Transmission Protocol (SCTP) as defined in [RFC4960] is a transport protocol running on top of the network protocols IPv4 [RFC0791] or IPv6 [RFC8200]. This document specifies how SCTP is used on top of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.0 is defined in [RFC4347], and the latest version when this RFC was published, DTLS 1.2, is defined in [RFC6347]. This encapsulation is used, for example, within the WebRTC protocol suite (see [RTC-OVERVIEW] for an overview) for transporting non-SRTP data between browsers. The architecture of this stack is described in [DATA-CHAN].
[RFC4960]中定义的流控制传输协议（SCTP）是运行在网络协议IPv4[RFC0791]或IPv6[RFC8200]之上的传输协议。本文档指定如何在数据报传输层安全（DTLS）协议之上使用SCTP。DTLS 1.0在[RFC4347]中定义，而发布此RFC时的最新版本DTLS 1.2在[RFC6347]中定义。例如，在WebRTC协议套件中（请参见[RTC-OVERVIEW]了解概述）使用此封装在浏览器之间传输非SRTP数据。[DATA-CHAN]中描述了该堆栈的体系结构。
+----------+
| SCTP |
+----------+
| DTLS |
+----------+
| ICE/UDP |
+----------+
+----------+
| SCTP |
+----------+
| DTLS |
+----------+
| ICE/UDP |
+----------+
Figure 1: Basic Stack Diagram
图1：基本堆栈图
This encapsulation of SCTP over DTLS over UDP or ICE/UDP (see [RFC5245]) can provide a NAT traversal solution in addition to confidentiality, source authentication, and integrity-protected transfers. Please note that using ICE does not necessarily imply that a different packet format is used on the wire.
通过UDP或ICE/UDP（参见[RFC5245]）将SCTP封装在DTLS上，除了机密性、源身份验证和完整性保护传输之外，还可以提供NAT穿越解决方案。请注意，使用ICE并不一定意味着在线路上使用不同的数据包格式。
Please note that the procedures defined in [RFC6951] for dealing with the UDP port numbers do not apply here. When using the encapsulation defined in this document, SCTP is unaware about the protocols used below DTLS.
请注意，[RFC6951]中定义的用于处理UDP端口号的程序在此不适用。当使用本文档中定义的封装时，SCTP不知道DTL下面使用的协议。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
When an SCTP packet is provided to the DTLS layer, the complete SCTP packet, consisting of the SCTP common header and a number of SCTP chunks, is handled as the payload of the application-layer protocol of DTLS. When the DTLS layer has processed a DTLS record containing
当向DTLS层提供SCTP数据包时，完整的SCTP数据包（由SCTP公共头和多个SCTP数据块组成）将作为DTLS应用层协议的有效负载处理。当DTLS层处理了包含
a message of the application-layer protocol, the payload is passed to the SCTP layer. The SCTP layer expects an SCTP common header followed by a number of SCTP chunks.
作为应用层协议的消息，有效负载被传递到SCTP层。SCTP层需要一个SCTP公共头，后面跟着多个SCTP块。
An implementation of SCTP over DTLS MUST implement and use a path maximum transmission unit (MTU) discovery method that functions without ICMP to provide SCTP/DTLS with an MTU estimate. An implementation of "Packetization Layer Path MTU Discovery" [RFC4821] either in SCTP or DTLS is RECOMMENDED.
通过DTL实现SCTP必须实现并使用路径最大传输单元（MTU）发现方法，该方法在没有ICMP的情况下运行，以向SCTP/DTL提供MTU估计。建议在SCTP或DTLS中实现“打包层路径MTU发现”[RFC4821]。
The path MTU discovery is performed by SCTP when SCTP over DTLS is used for data channels (see Section 5 of [DATA-CHAN]).
当DTLS上的SCTP用于数据信道时，路径MTU发现由SCTP执行（见[data-CHAN]第5节）。
The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD support the most recently published version of DTLS, which was DTLS 1.2 [RFC6347] when this RFC was published. In the absence of a revision to this document, the latter requirement applies to all future versions of DTLS when they are published as RFCs. This document will only be revised if a revision to DTLS or SCTP makes a revision to the encapsulation necessary.
DTLS实现必须支持DTLS 1.0[RFC4347]，并应支持最新发布的DTLS版本，即发布此RFC时的DTLS 1.2[RFC6347]。在本文件无修订的情况下，后一项要求适用于作为RFC发布的DTL的所有未来版本。仅当DTLS或SCTP的修订使封装的修订成为必要时，才对本文件进行修订。
SCTP performs segmentation and reassembly based on the path MTU. Therefore, the DTLS layer MUST NOT use any compression algorithm.
SCTP根据路径MTU执行分段和重新组装。因此，DTLS层不能使用任何压缩算法。
The DTLS MUST support sending messages larger than the current path MTU. This might result in sending IP-level fragmented messages.
DTL必须支持发送大于当前路径MTU的消息。这可能会导致发送IP级别的分段消息。
If path MTU discovery is performed by the DTLS layer, the method described in [RFC4821] MUST be used. For probe packets, the extension defined in [RFC6520] MUST be used.
如果路径MTU发现由DTLS层执行，则必须使用[RFC4821]中描述的方法。对于探测数据包，必须使用[RFC6520]中定义的扩展。
If path MTU discovery is performed by the SCTP layer and IPv4 is used as the network-layer protocol, the DTLS implementation SHOULD allow the DTLS user to enforce that the corresponding IPv4 packet is sent with the Don't Fragment (DF) bit set. If controlling the DF bit is not possible (for example, due to implementation restrictions), a safe value for the path MTU has to be used by the SCTP stack. It is RECOMMENDED that the safe value not exceed 1200 bytes. Please note that [RFC1122] only requires that end hosts be able to reassemble fragmented IP packets up to 576 bytes in length.
如果路径MTU发现由SCTP层执行，并且IPv4用作网络层协议，则DTLS实现应允许DTLS用户强制发送相应的IPv4数据包，并设置不分段（DF）位。如果无法控制DF位（例如，由于实现限制），SCTP堆栈必须使用路径MTU的安全值。建议安全值不超过1200字节。请注意，[RFC1122]只要求终端主机能够重新组装长度高达576字节的分段IP数据包。
The DTLS implementation SHOULD allow the DTLS user to set the Differentiated Services Code Point (DSCP) used for IP packets being sent (see [RFC2474]). This requires the DTLS implementation to pass
DTLS实现应允许DTLS用户设置用于发送IP数据包的区分服务代码点（DSCP）（请参阅[RFC2474]）。这需要DTLS实现通过
the value through and the lower layer to allow setting this value. If the lower layer does not support setting the DSCP, then the DTLS user will end up with the default value used by the protocol stack. Please note that only a single DSCP value can be used for all packets belonging to the same SCTP association.
通过和较低层设置该值。如果较低层不支持设置DSCP，则DTLS用户最终将使用协议堆栈使用的默认值。请注意，对于属于同一SCTP关联的所有数据包，只能使用单个DSCP值。
Using Explicit Congestion Notification (ECN) in SCTP requires the DTLS layer to pass the ECN bits through and its lower layer to expose access to them for sent and received packets (see [RFC3168]). The implementations of DTLS and its lower layer have to provide this support. If this is not possible (for example, due to implementation restrictions), ECN can't be used by SCTP.
在SCTP中使用显式拥塞通知（ECN）要求DTLS层传递ECN位，并要求其下层公开对发送和接收数据包的访问（请参见[RFC3168]）。DTL及其底层的实现必须提供这种支持。如果这是不可能的（例如，由于实现限制），则SCTP不能使用ECN。
This section describes the usage of the base protocol and the applicability of various SCTP extensions.
本节介绍基本协议的用法以及各种SCTP扩展的适用性。
This document uses SCTP [RFC4960] with the following restrictions, which are required to reflect that the lower layer is DTLS instead of IPv4 and IPv6 and that SCTP does not deal with the IP addresses or the transport protocol used below DTLS:
本文档使用的SCTP[RFC4960]具有以下限制，这些限制是为了反映下层是DTLS而不是IPv4和IPv6，并且SCTP不处理DTLS下面使用的IP地址或传输协议：
o A DTLS connection MUST be established before an SCTP association can be set up.
o 必须先建立DTLS连接，然后才能建立SCTP关联。
o Multiple SCTP associations MAY be multiplexed over a single DTLS connection. The SCTP port numbers are used for multiplexing and demultiplexing the SCTP associations carried over a single DTLS connection.
o 多个SCTP关联可以通过单个DTLS连接进行多路复用。SCTP端口号用于多路复用和解多路复用通过单个DTLS连接承载的SCTP关联。
o All SCTP associations are single-homed, because DTLS does not expose any address management to its upper layer. Therefore, it is RECOMMENDED to set the SCTP parameter path.max.retrans to association.max.retrans.
o 所有SCTP关联都是单宿的，因为DTL不向其上层公开任何地址管理。因此，建议将SCTP参数path.max.retrans设置为association.max.retrans。
o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or IPv6 Address parameters. The INIT chunk MUST NOT contain the Supported Address Types parameter.
o INIT和INIT-ACK区块不能包含任何IPv4地址或IPv6地址参数。INIT块不能包含受支持的地址类型参数。
o The implementation MUST NOT rely on processing ICMP or ICMPv6 packets, since the SCTP layer most likely is unable to access the SCTP common header in the plain text of the packet, which triggered the sending of the ICMP or ICMPv6 packet. This applies in particular to path MTU discovery when performed by SCTP.
o 实现不能依赖于处理ICMP或ICMPv6数据包，因为SCTP层很可能无法访问数据包纯文本中的SCTP公共头，这触发了ICMP或ICMPv6数据包的发送。这尤其适用于由SCTP执行的路径MTU发现。
o If the SCTP layer is notified about a path change by its lower layers, SCTP SHOULD retest the path MTU and reset the congestion state to the initial state. The window-based congestion control method specified in [RFC4960] resets the congestion window and slow-start threshold to their initial values.
o 如果SCTP层收到其较低层的路径更改通知，则SCTP应重新测试路径MTU，并将拥塞状态重置为初始状态。[RFC4960]中指定的基于窗口的拥塞控制方法将拥塞窗口和慢启动阈值重置为初始值。
When the SCTP layer performs path MTU discovery as specified in [RFC4821], the padding extension defined in [RFC4820] MUST be supported and used for probe packets (HEARTBEAT chunks bundled with PADDING chunks [RFC4820]).
当SCTP层按照[RFC4821]中的规定执行路径MTU发现时，[RFC4820]中定义的填充扩展必须支持并用于探测数据包（与填充数据块[RFC4820]捆绑的心跳数据块）。
If the dynamic address reconfiguration extension defined in [RFC5061] is used, ASCONF chunks MUST use wildcard addresses only.
如果使用[RFC5061]中定义的动态地址重新配置扩展，则ASCONF块必须仅使用通配符地址。
The SCTP authentication extension defined in [RFC4895] can be used with DTLS encapsulation, but does not provide any additional benefit.
[RFC4895]中定义的SCTP身份验证扩展可用于DTLS封装，但不提供任何其他好处。
Partial reliability as defined in [RFC3758] can be used in combination with DTLS encapsulation. It is also possible to use additional Partially Reliable Stream Control Transmission Protocol (PR-SCTP) policies, for example, the ones defined in [RFC7496].
[RFC3758]中定义的部分可靠性可与DTLS封装结合使用。还可以使用附加的部分可靠流控制传输协议（PR-SCTP）策略，例如[RFC7496]中定义的策略。
The SCTP stream reset extension defined in [RFC6525] can be used with DTLS encapsulation. It is used to reset SCTP streams and add SCTP streams during the lifetime of the SCTP association.
[RFC6525]中定义的SCTP流重置扩展可用于DTLS封装。它用于在SCTP关联的生存期内重置SCTP流和添加SCTP流。
SCTP as defined in [RFC4960] does not support the interleaving of large user messages that need to be fragmented and reassembled by the SCTP layer. The protocol extension defined in [RFC8260] overcomes this limitation and can be used with DTLS encapsulation.
[RFC4960]中定义的SCTP不支持需要由SCTP层分段和重新组装的大用户消息的交织。[RFC8260]中定义的协议扩展克服了这一限制，可以与DTLS封装一起使用。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
Security considerations for DTLS are specified in [RFC4347] and for SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP and DTLS introduces no new security considerations.
[RFC4347]中规定了DTL的安全注意事项，[RFC4960]、[RFC3758]和[RFC6525]中规定了SCTP的安全注意事项。SCTP和DTLS的结合没有引入新的安全考虑。
SCTP should not process the IP addresses used for the underlying communication since DTLS provides no guarantees about them.
SCTP不应处理用于底层通信的IP地址，因为DTL对这些地址不提供任何保证。
It should be noted that the inability to process ICMP or ICMPv6 messages does not add any security issue. When SCTP is carried over a connection-less lower layer like IPv4, IPv6, or UDP, processing of these messages is required to protect other nodes not supporting SCTP. Since DTLS provides a connection-oriented lower layer, this kind of protection is not necessary.
应注意，无法处理ICMP或ICMPv6消息不会增加任何安全问题。当SCTP通过连接较少的较低层（如IPv4、IPv6或UDP）传输时，需要处理这些消息以保护不支持SCTP的其他节点。由于DTLS提供了面向连接的底层，因此不需要这种保护。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<https://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, <https://www.rfc-editor.org/info/rfc4347>.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，DOI 10.17487/RFC4347，2006年4月<https://www.rfc-editor.org/info/rfc4347>.
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, <https://www.rfc-editor.org/info/rfc4820>.
[RFC4820]Tuexen，M.，Stewart，R.，和P.Lei，“流控制传输协议（SCTP）的填充块和参数”，RFC 4820，DOI 10.17487/RFC4820，2007年3月<https://www.rfc-editor.org/info/rfc4820>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 4821，DOI 10.17487/RFC4821，2007年3月<https://www.rfc-editor.org/info/rfc4821>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 4960，DOI 10.17487/RFC4960，2007年9月<https://www.rfc-editor.org/info/rfc4960>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <https://www.rfc-editor.org/info/rfc6520>.
[RFC6520]Seggelmann，R.，Tuexen，M.和M.Williams，“传输层安全性（TLS）和数据报传输层安全性（DTLS）心跳扩展”，RFC 6520，DOI 10.17487/RFC6520，2012年2月<https://www.rfc-editor.org/info/rfc6520>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[DATA-CHAN] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", Work in Progress, draft-ietf-rtcweb-data-channel-13, January 2015.
[DATA-CHAN]Jesup，R.，Loreto，S.，和M.Tuexen，“WebRTC数据通道”，正在进行的工作，草稿-ietf-rtcweb-DATA-channel-13，2015年1月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<https://www.rfc-editor.org/info/rfc791>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<https://www.rfc-editor.org/info/rfc2474>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<https://www.rfc-editor.org/info/rfc3168>.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <https://www.rfc-editor.org/info/rfc3758>.
[RFC3758]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，DOI 10.17487/RFC3758，2004年5月<https://www.rfc-editor.org/info/rfc3758>.
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007, <https://www.rfc-editor.org/info/rfc4895>.
[RFC4895]Tuexen，M.，Stewart，R.，Lei，P.，和E.Rescorla，“流控制传输协议（SCTP）的认证块”，RFC 4895，DOI 10.17487/RFC4895，2007年8月<https://www.rfc-editor.org/info/rfc4895>.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, <https://www.rfc-editor.org/info/rfc5061>.
[RFC5061]Stewart，R.，Xie，Q.，Tuexen，M.，Maruyama，S.，和M.Kozuka，“流控制传输协议（SCTP）动态地址重新配置”，RFC 5061，DOI 10.17487/RFC5061，2007年9月<https://www.rfc-editor.org/info/rfc5061>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <https://www.rfc-editor.org/info/rfc5245>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 5245，DOI 10.17487/RFC5245，2010年4月<https://www.rfc-editor.org/info/rfc5245>.
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, <https://www.rfc-editor.org/info/rfc6525>.
[RFC6525]Stewart，R.，Tuexen，M.，和P.Lei，“流控制传输协议（SCTP）流重新配置”，RFC 6525，DOI 10.17487/RFC6525，2012年2月<https://www.rfc-editor.org/info/rfc6525>.
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <https://www.rfc-editor.org/info/rfc6951>.
[RFC6951]Tuexen，M.和R.Stewart，“用于端主机到端主机通信的流控制传输协议（SCTP）数据包的UDP封装”，RFC 6951，DOI 10.17487/RFC6951，2013年5月<https://www.rfc-editor.org/info/rfc6951>.
[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension", RFC 7496, DOI 10.17487/RFC7496, April 2015, <https://www.rfc-editor.org/info/rfc7496>.
[RFC7496]Tuexen，M.，Seggelmann，R.，Stewart，R.，和S.Loreto，“部分可靠流控制传输协议扩展的附加策略”，RFC 7496，DOI 10.17487/RFC7496，2015年4月<https://www.rfc-editor.org/info/rfc7496>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，STD 86，RFC 8200，DOI 10.17487/RFC8200，2017年7月<https://www.rfc-editor.org/info/rfc8200>.
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", RFC 8260, November 2017.
[RFC8260]Stewart，R.，Tuexen，M.，Loreto，S.，和R.Seggelmann，“流控制传输协议的流调度器和用户消息交错”，RFC 8260，2017年11月。
[RTC-OVERVIEW] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-18, March 2017.
[RTC-OVERVIEW]Alvestrand，H.，“概述：基于浏览器的应用程序的实时协议”，正在进行的工作，草稿-ietf-rtcweb-OVERVIEW-18，2017年3月。
Acknowledgments
致谢
The authors wish to thank David Black, Benoit Claise, Spencer Dawkins, Francis Dupont, Gorry Fairhurst, Stephen Farrell, Christer Holmberg, Barry Leiba, Eric Rescorla, Tom Taylor, Joe Touch, and Magnus Westerlund for their invaluable comments.
作者希望感谢大卫·布莱克、贝诺特·克莱斯、斯宾塞·道金斯、弗朗西斯·杜邦、戈里·费尔赫斯特、斯蒂芬·法雷尔、克里斯特·霍姆伯格、巴里·莱巴、埃里克·雷斯科拉、汤姆·泰勒、乔·图奇和马格纳斯·韦斯特隆德的宝贵评论。
Authors' Addresses
作者地址
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt Germany
米迦勒TuxEN明斯特应用科学大学StugWaldStasSE 39 48565斯坦福特德国
Email: tuexen@fh-muenster.de
Email: tuexen@fh-muenster.de
Randall R. Stewart Netflix, Inc. Chapin, SC 29036 United States of America
Randall R.Stewart Netflix，Inc.Chapin，SC 29036美利坚合众国
Email: randall@lakerest.net
Email: randall@lakerest.net
Randell Jesup WorldGate Communications 3800 Horizon Blvd, Suite #103 Trevose, PA 19053-4947 United States of America
Randell Jesup WorldGate Communications 3800 Horizon Blvd，美国宾夕法尼亚州特雷沃斯103号套房，邮编：19053-4947
Phone: +1-215-354-5166
Email: randell-ietf@jesup.org
Phone: +1-215-354-5166
Email: randell-ietf@jesup.org
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
萨尔瓦托·洛雷托·爱立信·赫萨兰蒂11 Jorvas 02420芬兰
Email: Salvatore.Loreto@ericsson.com
Email: Salvatore.Loreto@ericsson.com