Network Working Group J. Heffner
Request for Comments: 4963 M. Mathis
Category: Informational B. Chandler
PSC
July 2007
Network Working Group J. Heffner
Request for Comments: 4963 M. Mathis
Category: Informational B. Chandler
PSC
July 2007
IPv4 Reassembly Errors at High Data Rates
高数据速率下的IPv4重新组装错误
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations.
在当今互联网的某些条件下，IPv4碎片不够健壮。在高数据速率下，16位IP标识字段不足以防止频繁错误组装的IP片段，TCP和UDP校验和不足以防止产生的损坏数据报被传送到更高的协议层。本说明描述了一些演示该问题的容易复制的实验，并讨论了这些观察结果的一些操作含义。
The IPv4 header was designed at a time when data rates were several orders of magnitude lower than those achievable today. This document describes a consequent scale-related failure in the IP identification (ID) field, where fragments may be incorrectly assembled at a rate high enough that it is likely to invalidate assumptions about data integrity failure rates.
IPv4报头是在数据速率比今天的数据速率低几个数量级的时候设计的。本文档描述了IP标识（ID）字段中与规模相关的后续故障，其中碎片可能以足够高的速率错误组装，从而可能使关于数据完整性故障率的假设失效。
That IP fragmentation results in inefficient use of the network has been well documented [Kent87]. This note presents a different kind of problem, which can result not only in significant performance degradation, but also frequent data corruption. This is especially pertinent due to the recent proliferation of UDP bulk transport tools that sometimes fragment every datagram.
IP碎片化导致网络使用效率低下，这一点已得到充分证明[87]。本说明提出了另一种问题，它不仅会导致性能显著下降，还会导致频繁的数据损坏。这一点尤其重要，因为最近UDP批量传输工具激增，有时会对每个数据报进行分段。
Additionally, there is some network equipment that ignores the Don't Fragment (DF) bit in the IP header to work around MTU discovery problems [RFC2923]. This equipment indirectly exposes properly implemented protocols and applications to corrupt data.
此外，有些网络设备会忽略IP报头中的不分段（DF）位，以解决MTU发现问题[RFC2923]。该设备间接地将正确实施的协议和应用程序暴露于损坏的数据中。
The Internet Protocol standard [RFC0791] specifies:
互联网协议标准[RFC0791]规定：
"The choice of the Identifier for a datagram is based on the need to provide a way to uniquely identify the fragments of a particular datagram. The protocol module assembling fragments judges fragments to belong to the same datagram if they have the same source, destination, protocol, and Identifier. Thus, the sender must choose the Identifier to be unique for this source, destination pair and protocol for the time the datagram (or any fragment of it) could be alive in the Internet."
“数据报标识符的选择是基于需要提供一种唯一标识特定数据报片段的方法。组装片段的协议模块判断片段是否属于同一数据报，前提是它们具有相同的源、目标、协议和标识符。因此，发送方必须选择要识别的标识符。”在数据报（或数据报的任何片段）在互联网上存在的时间内，此源、目标对和协议必须是唯一的。”
Strict conformance to this standard limits transmissions in one direction between any address pair to no more than 65536 packets per protocol (e.g., TCP, UDP, or ICMP) per maximum packet lifetime.
严格遵守本标准将任何地址对之间的单向传输限制为每个协议（例如TCP、UDP或ICMP）每个最大数据包生存期内不超过65536个数据包。
Clearly, not all hosts follow this standard because it implies an unreasonably low maximum data rate. For example, a host sending 1500-byte packets with a 30-second maximum packet lifetime could send at only about 26 Mbps before exceeding 65535 packets per packet lifetime. Or, filling a 1 Gbps interface with 1500-byte packets requires sending 65536 packets in less than 1 second, an unreasonably short maximum packet lifetime, being less than the round-trip time on some paths. This requirement is widely ignored.
显然，并非所有主机都遵循此标准，因为它意味着不合理的低最大数据速率。例如，发送最大数据包生存期为30秒的1500字节数据包的主机在每个数据包生存期超过65535个数据包之前只能以大约26 Mbps的速率发送数据包。或者，用1500字节的数据包填充1 Gbps接口需要在不到1秒的时间内发送65536个数据包，这是一个不合理的最短数据包生存期，小于某些路径上的往返时间。这一要求被广泛忽视。
Additionally, it is worth noting that reusing values in the IP ID field once per 65536 datagrams is the best case. Some implementations randomize the IP ID to prevent leaking information out of the kernel [Bellovin02], which causes reuse of the IP ID field to occur probabilistically at all sending rates.
此外，值得注意的是，每65536个数据报重用一次IP ID字段中的值是最好的情况。一些实现将IP ID随机化，以防止从内核中泄漏信息[Bellovin02]，这会导致在所有发送速率下都可能重复使用IP ID字段。
IP receivers store fragments in a reassembly buffer until all fragments in a datagram arrive, or until the reassembly timeout expires (15 seconds is suggested in [RFC0791]). Fragments in a datagram are associated with each other by their protocol number, the value in their ID field, and by the source/destination address pair. If a sender wraps the ID field in less than the reassembly timeout, it becomes possible for fragments from different datagrams to be incorrectly spliced together ("mis-associated"), and delivered to the upper layer protocol.
IP接收器将片段存储在重组缓冲区中，直到数据报中的所有片段到达，或者直到重组超时（在[RFC0791]中建议为15秒）为止。数据报中的片段通过协议号、ID字段中的值以及源/目标地址对相互关联。如果发送方在小于重新组装超时的时间内包装ID字段，则来自不同数据报的片段可能被错误地拼接在一起（“错误关联”），并传递到上层协议。
A case of particular concern is when mis-association is self-propagating. This occurs, for example, when there is reliable ordering of packets and the first fragment of a datagram is lost in the network. The rest of the fragments are stored in the fragment reassembly buffer, and when the sender wraps the ID field, the first fragment of the new datagram will be mis-associated with the rest of the old datagram. The new datagram will be now be incomplete (since it is missing its first fragment), so the rest of it will be saved in the fragment reassembly buffer, forming a cycle that repeats every 65536 datagrams. It is possible to have a number of simultaneous cycles, bounded by the size of the fragment reassembly buffer.
一个特别令人关注的情况是当错误关联是自传播的。例如，当存在数据包的可靠排序且数据报的第一个片段在网络中丢失时，就会发生这种情况。其余的片段存储在片段重组缓冲区中，当发送方包装ID字段时，新数据报的第一个片段将与旧数据报的其余部分错误关联。新的数据报现在将是不完整的（因为它缺少第一个片段），因此剩余的数据报将保存在片段重组缓冲区中，形成一个循环，每65536个数据报重复一次。有可能有许多同时的循环，以片段重组缓冲区的大小为界限。
IPv6 is considerably less vulnerable to this type of problem, since its fragment header contains a 32-bit identification field [RFC2460]. Mis-association will only be a problem at packet rates 65536 times higher than for IPv4.
IPv6不易受到此类问题的攻击，因为其片段头包含一个32位标识字段[RFC2460]。只有当数据包速率比IPv4高65536倍时，Mis关联才会成为问题。
When the mis-associated fragments are delivered, transport-layer checksumming should detect these datagrams as incorrect and discard them. When the datagrams are discarded, it could create a performance problem for loss-feedback congestion control algorithms, particularly when a large congestion window is required, since it will introduce a certain amount of non-congestive loss.
当交付mis关联的片段时，传输层校验和应检测到这些数据报不正确并丢弃它们。当数据报被丢弃时，它可能会给丢失反馈拥塞控制算法带来性能问题，特别是当需要较大的拥塞窗口时，因为它会引入一定数量的非拥塞丢失。
Transport checksums, however, may not be designed to handle such high error rates. The TCP/UDP checksum is only 16 bits in length. If these checksums follow a uniform random distribution, we expect mis-associated datagrams to be accepted by the checksum at a rate of one per 65536. With only one mis-association cycle, we expect corrupt data delivered to the application layer once per 2^32 datagrams.
然而，传输校验和可能无法处理如此高的错误率。TCP/UDP校验和的长度只有16位。如果这些校验和遵循统一的随机分布，我们期望校验和以每65536个一个的速率接受错误关联的数据报。由于只有一个mis关联周期，我们希望每2^32个数据报向应用层发送一次损坏的数据。
This number can be significantly higher with multiple concurrent cycles.
在多个并发周期中，该数字可能会显著增加。
With non-random data, the TCP/UDP checksum may be even weaker still. It is possible to construct datasets where mis-associated fragments will always have the same checksum. Such a case may be considered unlikely, but is worth considering. "Real" data may be more likely than random data to cause checksum hot spots and increase the probability of false checksum match [Stone98]. Also, some applications or higher-level protocols may turn off checksumming to increase speed, though this practice has been found to be dangerous for other reasons when data reliability is important [Stone00].
对于非随机数据，TCP/UDP校验和可能更弱。可以构造数据集，其中错误关联的片段将始终具有相同的校验和。这种情况可能被认为不太可能，但值得考虑。“真实”数据可能比随机数据更有可能导致校验和热点，并增加错误校验和匹配的概率[98]。此外，一些应用程序或更高级别的协议可能会关闭校验和以提高速度，尽管在数据可靠性很重要的情况下，由于其他原因，这种做法是危险的[Stone00]。
To test the practical impact of fragmentation on UDP, we ran a series of experiments using a UDP bulk data transport protocol that was designed to be used as an alternative to TCP for transporting large data sets over specialized networks. The tool, Reliable Blast UDP (RBUDP), part of the QUANTA networking toolkit [QUANTA], was selected because it has a clean interface which facilitated automated experiments. The decision to use RBUDP had little to do with the details of the transport protocol itself. Any UDP transport protocol that does not have additional means to detect corruption, and that could be configured to use IP fragmentation, would have the same results.
为了测试碎片对UDP的实际影响，我们使用UDP批量数据传输协议进行了一系列实验，该协议被设计为TCP的替代协议，用于在专用网络上传输大型数据集。之所以选择QUANTA networking toolkit[QUANTA]的一部分，即可靠的Blast UDP（RBUDP），是因为它有一个干净的接口，方便了自动化实验。使用RBUDP的决定与传输协议本身的细节关系不大。任何UDP传输协议，如果没有额外的方法来检测损坏，并且可以配置为使用IP碎片，都会有相同的结果。
In order to diagnose corruption on files transferred with the UDP bulk transfer tool, we used a file format that included embedded sequence numbers and MD5 checksums in each fragment of each datagram. Thus, it was possible to distinguish random corruption from that caused by mis-associated fragments. We used two different types of files. One was constructed so that all the UDP checksums were constant -- we will call this the "constant" dataset. The other was constructed so that UDP checksums were uniformly random -- the "random" dataset. All tests were done using 400 MB files, sent in 1524-byte datagrams so that they were fragmented on standard Fast Ethernet with a 1500-byte MTU.
为了诊断使用UDP批量传输工具传输的文件的损坏，我们使用了一种文件格式，其中包括每个数据报的每个片段中嵌入的序列号和MD5校验和。因此，有可能区分随机损坏和由错误关联的片段引起的损坏。我们使用了两种不同类型的文件。其中一个是为了使所有UDP校验和都是常量而构造的——我们将其称为“常量”数据集。另一个是这样构造的，UDP校验和是一致随机的——“随机”数据集。所有测试都是使用400 MB的文件完成的，这些文件以1524字节的数据报发送，因此它们在标准快速以太网上以1500字节的MTU进行分段。
The UDP bulk file transport tool was used to send the datasets between a pair of hosts at slightly less than the available data rate (100 Mbps). Near the beginning of each flow, a brief secondary flow was started to induce packet loss in the primary flow. Throughout the life of the primary flow, we typically observed mis-association rates on the order of a few hundredths of a percent.
UDP批量文件传输工具用于在一对主机之间以略低于可用数据速率（100 Mbps）的速度发送数据集。在每个流的开始附近，一个简短的二次流开始，以导致主流中的数据包丢失。在一次流的整个生命周期内，我们通常观察到错误关联率约为百分之几百。
Tests run with the "constant" dataset resulted in corruption on all mis-associated fragments, that is, corruption on the order of a few hundredths of a percent. In sending approximately 10 TB of "random" datasets, we observed 8847668 UDP checksum errors and 121 corruptions of the data due to mis-associated fragments.
使用“常量”数据集运行的测试导致所有错误关联片段的损坏，也就是说，损坏程度为百分之几百。在发送大约10 TB的“随机”数据集时，我们观察到8847668个UDP校验和错误以及121个由于错误关联的片段而导致的数据损坏。
The most straightforward way to avoid mis-association is to avoid fragmentation altogether by implementing Path MTU Discovery [RFC1191] [RFC4821]. However, this is not always feasible for all applications. Further, as a work-around for MTU discovery problems [RFC2923], some TCP implementations and communications gear provide mechanisms to disable path MTU discovery by clearing or ignoring the DF bit. Doing so will expose all protocols using IPv4, even those that participate in MTU discovery, to mis-association errors.
避免mis关联的最直接的方法是通过实现路径MTU发现[RFC1191][RFC4821]来完全避免碎片。然而，这并不总是适用于所有应用程序。此外，为了解决MTU发现问题[RFC2923]，一些TCP实现和通信设备提供了通过清除或忽略DF位来禁用路径MTU发现的机制。这样做将使所有使用IPv4的协议，甚至那些参与MTU发现的协议，暴露于错误关联错误。
If IP fragmentation is in use, it may be possible to reduce the timeout sufficiently so that mis-association will not occur. However, there are a number of difficulties with such an approach. Since the sender controls the rate of packets sent and the selection of IP ID, while the receiver controls the reassembly timeout, there would need to be some mutual assurance between each party as to participation in the scheme. Further, it is not generally possible to set the timeout low enough so that a fast sender's fragments will not be mis-associated, yet high enough so that a slow sender's fragments will not be unconditionally discarded before it is possible to reassemble them. Therefore, the timeout and IP ID selection would need to be done on a per-peer basis. Also, it is likely NAT will break any per-peer tables keyed by IP address. It is not within the scope of this document to recommend solutions to these problems, though we believe a per-peer adaptive timeout is likely to prevent mis-association under circumstances where it would most commonly occur.
如果正在使用IP碎片，则可以充分减少超时时间，以避免发生错误关联。然而，这种方法有许多困难。由于发送方控制发送数据包的速率和IP ID的选择，而接收方控制重新组装超时，因此各方需要相互保证参与该方案。此外，通常不可能将超时设置得足够低，以使快速发送者的片段不会被错误关联，但是设置得足够高，以使慢速发送者的片段在能够重新组装之前不会被无条件丢弃。因此，超时和IP ID选择需要在每个对等机的基础上进行。此外，NAT很可能会破坏由IP地址键控的每个对等表。虽然我们认为每个对等点自适应超时可能会在最常见的情况下防止错误关联，但建议这些问题的解决方案不在本文档的范围内。
A case particularly worth noting is that of tunnels encapsulating payload in IPv4. To deal with difficulties in MTU Discovery [RFC4459], tunnels may rely on fragmentation between the two endpoints, even if the payload is marked with a DF bit [RFC4301]. In such a mode, the two tunnel endpoints behave as IP end hosts, with all tunneled traffic having the same protocol type. Thus, the aggregate rate of tunneled packets may not exceed 65536 per maximum packet lifetime, or tunneled data becomes exposed to possible mis-association. Even protocols doing MTU discovery such as TCP will be affected. Operators of tunnels should ensure that the receiving end's reassembly timeout is short enough that mis-association cannot occur given the tunnel's maximum rate.
一个特别值得注意的例子是在IPv4中封装有效负载的隧道。为了解决MTU发现[RFC4459]中的困难，隧道可能依赖于两个端点之间的碎片，即使有效负载用DF位[RFC4301]标记。在这种模式下，两个隧道端点充当IP端主机，所有隧道流量具有相同的协议类型。因此，隧道数据包的聚合速率每最大数据包生存期不得超过65536，或者隧道数据暴露于可能的错误关联。即使是执行MTU发现的协议（如TCP）也会受到影响。隧道运营商应确保接收端的重新组装超时足够短，以确保在隧道的最大速率下不会发生错误关联。
It is difficult to concisely describe all possible situations under which fragments might be mis-associated. Even if an end host carefully follows the specification, ensuring unique IP IDs, the presence of NATs or tunnels may expose applications to IP ID space conflicts. Further, devices in the network that the end hosts cannot see or control, such as tunnels, may cause mis-association. Even a fragmenting application that sends at a low rate might possibly be exposed when running simultaneously with a non-fragmenting application that sends at a high rate. As described above, the receiver might implement to reduce or eliminate the possibility of conflict, but there is no mechanism in place for a sender to know what the receiver is doing in this respect. As a consequence, there is no general mechanism for an application that is using IPv4 fragmentation to know if it is deterministically or statistically protected from mis-associated fragments.
很难简明扼要地描述碎片可能被错误关联的所有可能情况。即使终端主机严格遵守规范，确保唯一的IP ID，NAT或隧道的存在也可能使应用程序暴露于IP ID空间冲突中。此外，网络中终端主机无法看到或控制的设备（如隧道）可能导致错误关联。即使是以低速率发送的碎片化应用程序，在与以高速率发送的非碎片化应用程序同时运行时也可能会暴露。如上所述，接收方可以实现减少或消除冲突的可能性，但是没有机制让发送方知道接收方在这方面做什么。因此，对于使用IPv4碎片的应用程序来说，没有通用的机制来知道它是否受到了确定性或统计性的保护，不受错误关联碎片的影响。
Under circumstances when it is impossible or impractical to prevent mis-association, its effects may be mitigated by use of stronger integrity checking at any layer above IP. This is a natural side effect of using cryptographic authentication. For example, IPsec AH [RFC4302] will discard any corrupted datagrams, preventing their deliver to upper layers. A stronger transport layer checksum such as SCTP's, which is 32 bits in length [RFC2960], may help significantly. At the application layer, SSH message authentication codes [RFC4251] will prevent delivery of corrupted data, though since the TCP connection underneath is not protected, it is considered invalid and the session is immediately terminated. While stronger integrity checking may prevent data corruption, it will not prevent the potential performance impact described above of non-congestive loss on congestion control at high congestion windows.
在不可能或不实际防止mis关联的情况下，可以通过在IP之上的任何层使用更强的完整性检查来减轻其影响。这是使用加密身份验证的自然副作用。例如，IPsec AH[RFC4302]将丢弃任何损坏的数据报，从而阻止将其传送到上层。更强大的传输层校验和，如长度为32位的SCTP[RFC2960]，可能会有很大帮助。在应用层，SSH消息身份验证代码[RFC4251]将阻止传输损坏的数据，但由于下面的TCP连接未受到保护，因此被视为无效，会话将立即终止。虽然更强的完整性检查可以防止数据损坏，但它无法防止上述高拥塞窗口下非拥塞丢失对拥塞控制的潜在性能影响。
It should also be noted that mis-association is not the only possible source of data corruption above the network layer [Stone00]. Most applications for which data integrity is critically important should implement strong integrity checking regardless of exposure to mis-association.
还应注意，mis关联不是网络层以上数据损坏的唯一可能来源[Stone00]。对于数据完整性至关重要的大多数应用程序，无论是否存在mis关联，都应该实现强大的完整性检查。
In general, applications that rely on IPv4 fragmentation should be written with these issues in mind, as well as those issues documented in [Kent87]. Applications that rely on IPv4 fragmentation while sending at high speeds (the order of 100 Mbps or higher) and devices that deliberately introduce fragmentation to otherwise unfragmented traffic (e.g., tunnels) should be particularly cautious, and introduce strong mechanisms to ensure data integrity.
一般来说，在编写依赖IPv4分段的应用程序时，应考虑到这些问题，以及[87]中记录的问题。在高速（100 Mbps或更高）发送时依赖IPv4碎片的应用程序和有意将碎片引入未碎片化流量（如隧道）的设备应特别小心，并引入强大的机制以确保数据完整性。
If a malicious entity knows that a pair of hosts are communicating using a fragmented stream, it may be presented with an opportunity to corrupt the flow. By sending "high" fragments (those with offset greater than zero) with a forged source address, the attacker can deliberately cause corruption as described above. Exploiting this vulnerability requires only knowledge of the source and destination addresses of the flow, its protocol number, and fragment boundaries. It does not require knowledge of port or sequence numbers.
如果恶意实体知道一对主机正在使用碎片流进行通信，则可能会破坏流。通过发送带有伪造源地址的“高”片段（偏移量大于零的片段），攻击者可以故意造成如上所述的损坏。利用此漏洞只需要知道流的源地址和目标地址、协议编号和片段边界。它不需要知道端口号或序列号。
If the attacker has visibility of packets on the path, the attack profile is similar to injecting full segments. Using this attack makes blind disruptions easier and might possibly be used to cause degradation of service. We believe only streams using IPv4 fragmentation are likely vulnerable. Because of the nature of the problems outlined in this document, the use of IPv4 fragmentation for critical applications may not be advisable, regardless of security concerns.
如果攻击者能够看到路径上的数据包，则攻击模式类似于注入完整数据段。使用此攻击会使盲目中断更容易，并且可能会导致服务降级。我们认为，只有使用IPv4分段的流可能易受攻击。由于本文档中概述的问题的性质，对于关键应用程序使用IPv4碎片可能不可取，无论安全问题如何。
[Kent87] Kent, C. and J. Mogul, "Fragmentation considered harmful", Proc. SIGCOMM '87 vol. 17, No. 5, October 1987.
[Kent87]Kent，C.和J.Mogul，“碎片被认为是有害的”，Proc。SIGCOMM'87第17卷，第5期，1987年10月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[Stone98] Stone, J., Greenwald, M., Partridge, C., and J. Hughes, "Performance of Checksums and CRC's over Real Data", IEEE/ ACM Transactions on Networking vol. 6, No. 5, October 1998.
[Stone98]Stone，J.，Greenwald，M.，Partridge，C.，和J.Hughes，“校验和和和CRC对真实数据的性能”，IEEE/ACM网络交易第6卷，第5期，1998年10月。
[Stone00] Stone, J. and C. Partridge, "When The CRC and TCP Checksum Disagree", Proc. SIGCOMM 2000 vol. 30, No. 4, October 2000.
[Stone00]Stone，J.和C.Partridge，“当CRC和TCP校验和不一致时”，Proc。SIGCOMM 2000第30卷，第4期，2000年10月。
[QUANTA] He, E., Alimohideen, J., Eliason, J., Krishnaprasad, N., Leigh, J., Yu, O., and T. DeFanti, "Quanta: a toolkit for high performance data delivery over photonic networks", Future Generation Computer Systems Vol. 19, No. 6, August 2003.
[QUANTA]He，E.，Alimohideen，J.，Eliason，J.，Krishnaprasad，N.，Leigh，J.，Yu，O.，和T.Devanti，“量子：光子网络高性能数据传输工具包”，未来一代计算机系统第19卷，第6期，2003年8月。
[Bellovin02] Bellovin, S., "A Technique for Counting NATted Hosts", Internet Measurement Conference, Proceedings of the 2nd ACM SIGCOMM Workshop on Internet Measurement, November 2002.
[Bellovin02]Bellovin，S.，“计算NATED主机的技术”，互联网测量会议，第二届ACM SIGCOM互联网测量研讨会论文集，2002年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[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月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251]Ylonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]Savola，P.，“网络隧道中的MTU和碎片问题”，RFC 4459，2006年4月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
This work was supported by the National Science Foundation under Grant No. 0083285.
这项工作得到了国家科学基金会第0083285号资助。
Authors' Addresses
作者地址
John W. Heffner Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
美国宾夕法尼亚州匹兹堡第五大道4400号约翰·W·赫夫纳匹兹堡超级计算中心，邮编15213
Phone: 412-268-2329 EMail: jheffner@psc.edu
电话：412-268-2329电子邮件：jheffner@psc.edu
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
美国宾夕法尼亚州匹兹堡第五大道4400号马特·马蒂斯匹兹堡超级计算中心，邮编15213
Phone: 412-268-3319 EMail: mathis@psc.edu
电话：412-268-3319电子邮件：mathis@psc.edu
Ben Chandler Pittsburgh Supercomputing Center 4400 Fifth Avenue Pittsburgh, PA 15213 US
美国宾夕法尼亚州匹兹堡第五大道4400号本·钱德勒匹兹堡超级计算中心15213
Phone: 412-268-9783 EMail: bchandle@gmail.com
电话：412-268-9783电子邮件：bchandle@gmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。