Network Working Group L. Coene
Request for Comments: 3257 Siemens
Category: Informational April 2002
Network Working Group L. Coene
Request for Comments: 3257 Siemens
Category: Informational April 2002
Stream Control Transmission Protocol Applicability Statement
流控制传输协议适用性声明
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes the applicability of the Stream Control Transmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) & Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP.
本文件描述了流控制传输协议（SCTP）的适用性。它还将SCTP与两种主要的传输协议，用户数据报协议（UDP）和传输控制协议（TCP）进行了对比，并给出了何时最好使用SCTP和何时不最好使用SCTP的一些指导原则。
Table of contents
目录
1. Introduction .................................................. 2
1.1 Terminology .................................................. 2
2 Transport protocols ............................................ 2
2.1 TCP service model ............................................ 2
2.2 SCTP service model ........................................... 3
2.3 UDP service model ............................................ 4
3 SCTP Multihoming issues ........................................ 4
4 SCTP Network Address Translators (NAT) issues [RFC2663] ........ 5
5 Security Considerations ........................................ 6
5.1 Security issues with TCP ..................................... 6
5.2 Security issues with SCTP .................................... 7
5.3 Security issues with both TCP and SCTP ....................... 8
6 References and related work .................................... 9
7 Acknowledgments ................................................ 10
Appendix A: Major functions provided by SCTP ..................... 11
Editor's Address ................................................. 12
Full Copyright Statement ......................................... 13
1. Introduction .................................................. 2
1.1 Terminology .................................................. 2
2 Transport protocols ............................................ 2
2.1 TCP service model ............................................ 2
2.2 SCTP service model ........................................... 3
2.3 UDP service model ............................................ 4
3 SCTP Multihoming issues ........................................ 4
4 SCTP Network Address Translators (NAT) issues [RFC2663] ........ 5
5 Security Considerations ........................................ 6
5.1 Security issues with TCP ..................................... 6
5.2 Security issues with SCTP .................................... 7
5.3 Security issues with both TCP and SCTP ....................... 8
6 References and related work .................................... 9
7 Acknowledgments ................................................ 10
Appendix A: Major functions provided by SCTP ..................... 11
Editor's Address ................................................. 12
Full Copyright Statement ......................................... 13
1 Introduction
1导言
SCTP is a reliable transport protocol [RFC2960], which along with TCP [RFC793], RTP [RFC1889], and UDP [RFC768], provides transport-layer services for upper layer protocols and services. UDP, RTP, TCP, and SCTP are currently the IETF standards-track transport-layer protocols. Each protocol has a domain of applicability and services it provides, albeit with some overlaps.
SCTP是一种可靠的传输协议[RFC2960]，它与TCP[RFC793]、RTP[RFC1889]和UDP[RFC768]一起，为上层协议和服务提供传输层服务。UDP、RTP、TCP和SCTP是目前的IETF标准跟踪传输层协议。每个协议都有一个适用范围和它提供的服务，尽管有一些重叠。
By clarifying the situations where the functionality of these protocols are applicable, this document can guide implementers and protocol designers in selecting which protocol to use.
通过澄清这些协议的功能适用的情况，本文档可以指导实施者和协议设计者选择使用哪个协议。
Special attention is given to services SCTP provides which would make a decision to use SCTP the right one.
特别注意SCTP提供的服务，这些服务将决定使用正确的SCTP。
Major functions provided by SCTP can be found in Appendix A.
SCTP提供的主要功能见附录A。
The following terms are commonly identified in this work:
以下术语通常在本工作中确定：
Association: SCTP connection between two endpoints.
关联：两个端点之间的SCTP连接。
Transport address: A combination of IP address and SCTP port number.
传输地址：IP地址和SCTP端口号的组合。
Upper layer: The user of the SCTP protocol, which may be an adaptation layer, a session layer protocol, or the user application directly.
上层：SCTP协议的用户，可以是适配层、会话层协议或直接的用户应用程序。
Multihoming: Assigning more than one IP network interface to a single endpoint.
多主：将多个IP网络接口分配给单个端点。
2 Transport protocols
2传输协议
TCP is a connection-oriented (a.k.a., session-oriented) transport protocol. This means that it requires both the establishment of a connection prior to the exchange of application data and a connection tear-down to release system resources after the completion of data transfer.
TCP是一种面向连接（也称为面向会话）的传输协议。这意味着它需要在交换应用程序数据之前建立连接，并在完成数据传输后断开连接以释放系统资源。
TCP is currently the most widely used connection-oriented transport protocol for the Internet.
TCP是目前互联网上使用最广泛的面向连接的传输协议。
TCP provides the upper layer with the following transport services:
TCP为上层提供以下传输服务：
- data reliability;
- 数据可靠性；
- data sequence preservation; and
- 数据序列保存；和
- flow and congestion control.
- 流量和拥塞控制。
SCTP is also connection-oriented and provides all the transport services that TCP provides. Many Internet applications therefore should find that either TCP or SCTP will meet their transport requirements. Note, for applications conscious about processing cost, there might be a difference in processing cost associated with running SCTP with only a single ordered stream and one address pair in comparison to running TCP.
SCTP也是面向连接的，提供TCP提供的所有传输服务。因此，许多互联网应用程序应该发现TCP或SCTP都能满足其传输要求。注意，对于关注处理成本的应用程序，与运行TCP相比，仅使用单个有序流和一个地址对运行SCTP的处理成本可能有所不同。
However, SCTP has some additional capabilities that TCP lacks and This can make SCTP a better choice for some applications and environments:
但是，SCTP具有TCP所缺乏的一些附加功能，这可以使SCTP成为某些应用程序和环境的更好选择：
- multi-streams support:
- 多流支持：
SCTP supports the delivery of multiple independent user message streams within a single SCTP association. This capability, when properly used, can alleviate the so-called head-of-line-blocking problem caused by the strict sequence delivery constraint imposed to the user data by TCP.
SCTP支持在单个SCTP关联中传递多个独立的用户消息流。如果正确使用此功能，可以缓解TCP对用户数据施加的严格序列传递约束所导致的所谓的行首阻塞问题。
This can be particularly useful for applications that need to exchange multiple, logically separate message streams between two endpoints.
这对于需要在两个端点之间交换多个逻辑上独立的消息流的应用程序特别有用。
- multi-homing support:
- 多归宿支持：
SCTP provides transparent support for communications between two endpoints of which one or both is multi-homed.
SCTP为一个或两个端点都是多宿的两个端点之间的通信提供透明支持。
SCTP provides monitoring of the reachability of the addresses on the remote endpoint and in the case of failure can transparently failover from the primary address to an alternate address, without upper layer intervention.
SCTP提供远程端点上地址可达性的监控，并且在发生故障时，可以透明地从主地址故障切换到备用地址，而无需上层干预。
This capability can be used to build redundant paths between two SCTP endpoints and can be particularly useful for applications that seek transport-level fault tolerance.
此功能可用于在两个SCTP端点之间构建冗余路径，对于寻求传输级容错的应用程序尤其有用。
Achieving path redundancy between two SCTP endpoints normally requires that the two endpoints being equipped with multiple interfaces assigned with multiple addresses and that routing is configured appropriately (see Section 3).
实现两个SCTP端点之间的路径冗余通常要求两个端点配备多个分配有多个地址的接口，并适当配置路由（参见第3节）。
- preservation of message boundaries:
- 保留消息边界：
SCTP preserves application messages boundaries. This is useful when the application data is not a continuous byte stream but comes in logical chunks that the receiver handles separately.
SCTP保留应用程序消息边界。当应用程序数据不是一个连续的字节流，而是以逻辑块的形式出现并由接收方单独处理时，这非常有用。
In contrast, TCP offers a reliable data stream that has no indication of what an application may consider logical chunks of the data.
相比之下，TCP提供了一个可靠的数据流，没有应用程序可以考虑数据的逻辑块的指示。
- unordered reliable message delivery:
- 无序可靠的消息传递：
SCTP supports the transportation of user messages that have no application-specified order, yet need guaranteed reliable delivery.
SCTP支持传输没有应用程序指定顺序但需要保证可靠传递的用户消息。
Applications that need to send un-ordered reliable messages or prefer using their own message sequencing and ordering mechanisms may find this SCTP capability useful.
需要发送未排序的可靠消息或更喜欢使用自己的消息排序和排序机制的应用程序可能会发现此SCTP功能非常有用。
UDP is connectionless. This means that applications that use UDP do not need to perform connection establishment or tear-down.
UDP是无连接的。这意味着使用UDP的应用程序不需要执行连接建立或断开。
As transport services to its upper layer, UDP provides only:
作为上层的传输服务，UDP仅提供：
- best-effort data delivery, and
- 尽力而为的数据交付，以及
- preservation of message boundaries.
- 保留消息边界。
Applications that do not require a reliable transfer of more than a packet's worth of data will find UDP adequate. Some transaction-based applications fall into this category.
不需要可靠传输超过数据包价值的数据的应用程序将发现UDP是足够的。一些基于事务的应用程序属于这一类。
3 SCTP Multihoming Issues
3 SCTP多宿问题
SCTP provides transport-layer support for multihoming. Multihoming has the potential of providing additional robustness against network failures. In some applications, this may be extremely important, for example, in signaling transport of PSTN signaling messages [RFC2719].
SCTP为多宿提供传输层支持。多宿主技术有可能提供额外的抗网络故障的鲁棒性。在一些应用中，这可能非常重要，例如，在PSTN信令消息的信令传输中[RFC2719]。
It should be noted that SCTP multihoming support only deals with communication between two endpoints of which one or both is assigned with multiple IP addresses on possibly multiple network interfaces. It does NOT deal with communication ends that contain multiple endpoints (i.e., clustered endpoints) that can switch over to an alternate endpoint in case of failure of the original endpoint.
应该注意的是，SCTP多宿主支持仅处理两个端点之间的通信，其中一个或两个端点在可能的多个网络接口上分配了多个IP地址。它不处理包含多个端点（即集群端点）的通信端，这些端点可以在原始端点出现故障时切换到备用端点。
Generally, for truly fault resilient communication between two end-points, the multihoming feature needs more than one IP network interface for each endpoint. The number of paths used is the minimum of network interfaces used by any of the endpoints. When an endpoint selects its source address, careful consideration must be taken. If the same source address is always used, then it is possible that the endpoint will be subject to the same single point of failure. When the endpoint chooses a source address, it should always select the source address of the packet to correspond to the IP address of the Network interface where the packet will be emitted subject to the binding address constraint. The binding address constraint is, put simply, that the endpoint must never choose a source address that is not part of the association i.e., the peer endpoint must recognize any source address used as being part of the association.
通常，对于两个端点之间真正具有故障恢复能力的通信，多宿功能需要每个端点有多个IP网络接口。使用的路径数是任何端点使用的最小网络接口数。当端点选择其源地址时，必须仔细考虑。如果始终使用相同的源地址，则端点可能会发生相同的单点故障。当端点选择源地址时，它应始终选择数据包的源地址，以对应于网络接口的IP地址，在该网络接口中，数据包将根据绑定地址约束发出。简单地说，绑定地址约束是端点不得选择不属于关联的源地址，即对等端点必须识别用作关联一部分的任何源地址。
The availability of the association will benefit greatly from having multiple addresses bound to the association endpoint when the endpoint is on a multi-homed host.
当端点位于多宿主主机上时，将多个地址绑定到关联端点将极大地提高关联的可用性。
4 SCTP Network Address Translators (NAT) issues [RFC2663]
4 SCTP网络地址转换器（NAT）问题[RFC2663]
When two endpoints are to setup an SCTP association and one (or both) of them is behind a NAT (i.e., it does not have any publicly available network addresses), the endpoint(s) behind the NAT should consider one of the following options:
当两个端点设置一个SCTP关联时，其中一个（或两个）都在NAT后面（即，它没有任何公开可用的网络地址），NAT后面的端点应该考虑以下选项之一：
(1) When single homed sessions are to be used, no transport addresses should be sent in the INIT or INIT ACK chunk(Refer to section 3.3 of RFC2960 for chunk definitions). This will force the endpoint that receives this initiation message to use the source address in the IP header as the only destination address for this association. This method can be used for a NAT, but any multi-homing configuration at the endpoint that is behind the NAT will not be visible to its peer, and thus not be taken advantage of. See figure 1.
(1) 当使用单宿主会话时，不应在INIT或INIT ACK块中发送传输地址（有关块定义，请参阅RFC2960的第3.3节）。这将强制接收此启动消息的端点使用IP标头中的源地址作为此关联的唯一目标地址。此方法可用于NAT，但NAT后面端点处的任何多主配置对其对等方都不可见，因此不会被利用。参见图1。
+-------+ +---------+ *~~~~~~~~~~* +------+
|Host A | | NAT | * Cloud * |Host B|
| 10.2 +--|10.1|2.1 |----|--------------|---------+ 1.2 |
| | | | | * * | |
+-------+ +---------+ *~~~~~~~~~~* +------+
+-------+ +---------+ *~~~~~~~~~~* +------+
|Host A | | NAT | * Cloud * |Host B|
| 10.2 +--|10.1|2.1 |----|--------------|---------+ 1.2 |
| | | | | * * | |
+-------+ +---------+ *~~~~~~~~~~* +------+
Fig 1: SCTP through NAT without multihoming
图1:SCTP通过NAT，无需多址
For multihoming the NAT must have a public IP address for each represented internal IP address. The host can preconfigure an IP address that the NAT can substitute, or, the NAT can have internal Application Layer Gateway (ALG) which will intelligently translate the IP addresses in the INIT and INIT ACK chunks. See Figure 2.
对于多宿主，NAT必须为每个表示的内部IP地址提供一个公共IP地址。主机可以预先配置NAT可以替代的IP地址，或者NAT可以具有内部应用层网关（ALG），该网关将智能地转换INIT和INIT ACK块中的IP地址。参见图2。
If Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a per-association basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association.
如果网络地址端口转换与多址SCTP端点一起使用，则必须基于每个关联应用任何端口转换，以便SCTP端点继续为给定关联内的所有消息接收相同的端口号。
+-------+ +----------+ *~~~~~~~~~~* +------+
|Host A | | NAT | * Cloud * |Host B|
| 10.2 +---+ 10.1|5.2 +-----+ 1.1<+->3.1--+---------+ 1.2 |
| 11.2 +---+ 11.1|6.2 | | +->4.2--+---------+ 2.2 |
| | | | * * | |
+-------+ +----------+ *~~~~~~~~~* +------+
+-------+ +----------+ *~~~~~~~~~~* +------+
|Host A | | NAT | * Cloud * |Host B|
| 10.2 +---+ 10.1|5.2 +-----+ 1.1<+->3.1--+---------+ 1.2 |
| 11.2 +---+ 11.1|6.2 | | +->4.2--+---------+ 2.2 |
| | | | * * | |
+-------+ +----------+ *~~~~~~~~~* +------+
Fig 2: SCTP through NAT with multihoming
图2:SCTP通过NAT的多址传输
(2) Another alternative is to use the hostname feature and DNS to resolve the addresses. The hostname is included in the INIT of the association or in the INIT ACK. The hostname must be resolved by DNS before the association is completely set up. There are special issues regarding NAT and DNS, refer to RFC2694 for details.
(2) 另一种选择是使用主机名功能和DNS解析地址。主机名包含在关联的INIT或INIT ACK中。在完全设置关联之前，必须通过DNS解析主机名。关于NAT和DNS存在特殊问题，请参阅RFC2694了解详细信息。
5 Security Considerations
5安全考虑
In this section, some relevant security issues found in the deployment of the connection-oriented transport protocols will be discussed.
在本节中，将讨论在部署面向连接的传输协议时发现的一些相关安全问题。
Some TCP implementations have been known to be vulnerable to blind denial of service attacks, i.e., attacks that had been executed by an attacker that could not see most of the traffic to or from the target host.
已知某些TCP实现易受盲目拒绝服务攻击的攻击，即攻击者执行的攻击无法看到目标主机的大部分通信量。
The attacker would send a large number of connection establishment requests (TCP-SYN packets) to the attacked target, possibly from faked IP source addresses. The attacked host would reply by sending SYN-ACK packets and entering SYN-received state, thereby allocating space for a TCB. At some point the SYN-queue would fill up, (i.e., the number of connections waiting to be established would rise to a limit) and the host under attack would have to start turning down new connection establishment requests.
攻击者可能从伪造的IP源地址向受攻击目标发送大量连接建立请求（TCP-SYN数据包）。受到攻击的主机将通过发送SYN-ACK数据包并进入SYN接收状态进行应答，从而为TCB分配空间。在某个时刻，SYN队列将被填满（即，等待建立的连接数将上升到一个极限），受攻击的主机将不得不开始拒绝新的连接建立请求。
TCP implementations with SYN-cookies algorithm [SYN-COOK] reduce the risk of such blind denial of service attacks. TCP implementations can switch to using this algorithm in times when their SYN-queues are filled up while still fully conforming to the TCP specification [RFC793]. However, use of options such as a window scale [RFC1323], is not possible, then. With the SYN-cookie mechanism, a TCB is only created when the client sends back a valid ACK packet to the server, and the 3-way handshake has thus been successfully completed.
TCP implementations with SYN-cookies algorithm [SYN-COOK] reduce the risk of such blind denial of service attacks. TCP implementations can switch to using this algorithm in times when their SYN-queues are filled up while still fully conforming to the TCP specification [RFC793]. However, use of options such as a window scale [RFC1323], is not possible, then. With the SYN-cookie mechanism, a TCB is only created when the client sends back a valid ACK packet to the server, and the 3-way handshake has thus been successfully completed.translate error, please retry
Blind connection forgery is another potential threat to TCP. By guessing valid sequence numbers, an attacker would be able to forge a connection. However, with a secure hashsum algorithm, for some of the current SYN-cookie implementations the likelihood of achieving this attack is on the order of magnitude of 1 in 2^24, i.e., the attacker would have to send 2^24 packets before obtaining one forged connection when SYN-cookies are used.
盲连接伪造是TCP的另一个潜在威胁。通过猜测有效的序列号，攻击者将能够伪造连接。但是，使用安全哈希和算法，对于某些当前的SYN cookie实现，实现此攻击的可能性为1/2^24，即，当使用SYN cookie时，攻击者必须先发送2^24个数据包，然后才能获得一个伪造连接。
SCTP has been designed with the experiences made with TCP in mind. To make it hard for blind attackers (i.e., attackers that are not man-in-the-middle) to inject forged SCTP datagrams into existing associations, each side of an SCTP association uses a 32 bit value called "Verification Tag" to ensure that a datagram really belongs to the existing association. So in addition to a combination of source and destination transport addresses that belong to an established association, a valid SCTP datagram must also have the correct tag to be accepted by the recipient.
SCTP的设计考虑到了使用TCP的经验。为了使盲攻击者（即非中间人的攻击者）难以将伪造的SCTP数据报注入现有关联，SCTP关联的每一方都使用一个称为“验证标签”的32位值，以确保数据报真正属于现有关联。因此，除了属于已建立关联的源和目标传输地址的组合之外，有效的SCTP数据报还必须具有正确的标记，以便接收方接受。
Unlike in TCP, usage of cookie in association establishment is made mandatory in SCTP. For the server, a new association is fully established after three messages (containing INIT, INIT-ACK, COOKIE-ECHO chunks) have been exchanged. The cookie is a variable length parameter that contains all relevant data to initialize the TCB on the server side, plus a HMAC used to secure it. This HMAC (MD5 as per [RFC1321] or SHA-1 [SHA1]) is computed over the cookie and a secret, server-owned key.
与TCP不同，SCTP强制在关联建立中使用cookie。对于服务器，在交换三条消息（包含INIT、INIT-ACK、COOKIE-ECHO块）后，将完全建立新的关联。cookie是一个可变长度参数，它包含用于在服务器端初始化TCB的所有相关数据，以及用于保护TCB的HMAC。此HMAC（MD5根据[RFC1321]或SHA-1[SHA1]）是通过cookie和服务器拥有的密钥计算的。
As specifically prescribed for SCTP implementations [RFC2960], additional resources for new associations may only be reserved in case a valid COOKIE-ECHO chunk is received by a client, and the computed HMAC for this new cookie matches that contained in the cookie.
正如针对SCTP实现[RFC2960]所特别规定的，只有当客户端接收到有效的COOKIE-ECHO块，并且该新COOKIE的计算HMAC与COOKIE中包含的匹配时，才能保留新关联的额外资源。
With SCTP the chances of an attacker being able to blindly forge a connection are even lower than in the case of TCP using SYN-cookies, since the attacker would have to guess a correct value for the HMAC contained in the cookie, i.e., lower than 1 in 2^128 which for all practical purposes is negligible.
使用SCTP，攻击者能够盲目伪造连接的几率甚至低于使用SYN cookie的TCP，因为攻击者必须猜测cookie中包含的HMAC的正确值，即低于1/2^128，这对于所有实际目的来说都是可以忽略的。
It should be noted that SCTP only tries to increase the availability of a network. SCTP does not contain any protocol mechanisms that are directly related to user message authentication, integrity and confidentiality functions. For such features, it depends on the IPsec protocols and architecture and/or on security features of the application protocols.
应该注意的是，SCTP只是试图提高网络的可用性。SCTP不包含任何与用户消息身份验证、完整性和机密性功能直接相关的协议机制。对于这些特性，它取决于IPsec协议和体系结构和/或应用程序协议的安全特性。
Transport Layer security(TLS)[RFC2246] using SCTP must always use in-order streams.
使用SCTP的传输层安全性（TLS）[RFC2246]必须始终使用顺序流。
Currently the IPSEC working group is investigating the support of multi-homing by IPSEC protocols. At the present time to use IPSEC, one must use 2 * N * M security associations if one endpoint uses N addresses and the other M addresses.
目前，IPSEC工作组正在调查IPSEC协议对多宿主的支持。目前要使用IPSEC，如果一个端点使用N个地址，而另一个端点使用M个地址，则必须使用2*N*M安全关联。
It is important to note that neither TCP nor SCTP protect itself from man-in-the-middle attacks where an established session might be hijacked (assuming the attacker can see the traffic from and inject its own packets to either endpoints).
需要注意的是，TCP和SCTP都不能保护自己免受中间人攻击，在这种攻击中，已建立的会话可能会被劫持（假设攻击者可以看到来自任一端点的流量，并将自己的数据包注入任一端点）。
Also, to prevent blind connection/session setup forgery, both TCP implementations supporting SYN-cookies and SCTP implementations rely on a server-known, secret key to protect the HMAC data. It must be ensured that this key is created subject to the recommendations mentioned in [RFC1750].
此外，为了防止盲目连接/会话设置伪造，支持SYN Cookie的TCP实现和SCTP实现都依赖于服务器已知的密钥来保护HMAC数据。必须确保根据[RFC1750]中提到的建议创建此密钥。
Although SCTP has been designed carefully as to avoid some of the problems that have appeared with TCP, it has as of yet not been widely deployed. It is therefore possible that new security issues will be identified that will have to be addressed in further revisions of [RFC2960].
尽管SCTP经过了精心设计，以避免TCP出现的一些问题，但它尚未得到广泛部署。因此，可能会发现新的安全问题，这些问题必须在[RFC2960]的进一步修订中解决。
6 References and related work
6参考资料和相关工作
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[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月。
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
[RFC2694]Srisuresh，P.，Tsirtsis，G.，Akkiraju，P.和A.Heffernan，“网络地址转换器的DNS扩展（DNS_ALG）”，RFC 26941999年9月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Architectural Framework for Signaling Transport", RFC 2719, October 1999.
[RFC2719]Ong，L.，Rytina，I.，Garcia，M.，Schwarzbauer，H.，Coene，L.，Lin，H.，Juhasz，I.，Holdrege，M.和C.Sharp，“信号传输的架构框架”，RFC 2719，1999年10月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]Eastlake，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, April 1995.
[SHA1]NIST FIPS PUB 180-1，“安全哈希标准”，美国商务部国家标准与技术研究所，1995年4月。
[SYNCOOK] Dan J. Bernstein, SYN cookies, 1997, see also
<http://cr.yp.to/syncookies.html>
[SYNCOOK] Dan J. Bernstein, SYN cookies, 1997, see also
<http://cr.yp.to/syncookies.html>
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RFC1889]Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
7 Acknowledgments
7致谢
This document was initially developed by a design team consisting of Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart, Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas Jungmaier, Gery Verwimp and Lyndon Ong.
本文件最初由Lode Coene、John Loughney、Michel Tuexen、Randall R.Stewart、Xiaobing Xie、Matt Holdrege、Maria Carmen Belinchon、Andreas Jungmaier、Gery Verwimp和Lyndon Ong组成的设计团队开发。
The authors wish to thank Renee Revis, I. Rytina, H.J. Schwarzbauer, J.P. Martin-Flatin, T. Taylor, G. Sidebottom, K. Morneault, T. George, M. Stillman, N. Makinae, S. Bradner, A. Mankin, G. Camarillo, H. Schulzrinne, R. Kantola, J. Rosenberg, R.J. Atkinson, and many others for their invaluable comments.
作者要感谢雷尼·雷维斯、I.雷蒂娜、H.J.施瓦茨鲍尔、J.P.马丁·弗拉廷、T.泰勒、G.西德巴顿、K.莫诺、T.乔治、M.斯蒂尔曼、N.马基纳、S.布拉德纳、A.曼金、G.卡马里洛、H.舒尔兹林纳、R.坎托拉、J.罗森博格、R.J.阿特金森和其他许多人的宝贵评论。
Appendix A: Major functions provided by SCTP
附录A：SCTP提供的主要功能
- Reliable Data Transfer
- 可靠的数据传输
- Multiple streams to help avoid head-of-line blocking
- 多个流有助于避免线头阻塞
- Ordered and unordered data delivery on a per-stream basis
- 基于每个流的有序和无序数据交付
- Bundling and fragmentation of user data
- 用户数据的捆绑和碎片化
- TCP friendly Congestion and flow control
- TCP友好的拥塞和流量控制
- Support continuous monitoring of reachability
- 支持对可达性的持续监控
- Graceful termination of association
- 结社的优雅终止
- Support of multi-homing for added reliability
- 支持多归宿以增加可靠性
- Some protection against blind denial-of-service attacks
- 针对盲目拒绝服务攻击的一些保护措施
- Some protection against blind masquerade attacks
- 一些针对盲人伪装攻击的保护措施
8 Editor's Address
8编辑地址
Lode Coene Siemens Atea Atealaan 34 B-2200 Herentals Belgium
Lode Coene Siemens Atea Atealan 34 B-2200比利时海伦塔斯酒店
Phone: +32-14-252081
EMail: lode.coene@siemens.atea.be
Phone: +32-14-252081
EMail: lode.coene@siemens.atea.be
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。