Network Working Group L-E. Jonsson
Request for Comments: 4163 Ericsson
Category: Informational August 2005
Network Working Group L-E. Jonsson
Request for Comments: 4163 Ericsson
Category: Informational August 2005
RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression
健壮的报头压缩（ROHC）：对TCP/IP报头压缩的要求
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression (ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC.
本文件包含由ROHC工作组制定的TCP/IP报头压缩方案（概要文件）的要求。该文档讨论了TCP压缩的范围、性能考虑、对周围环境的假设以及知识产权问题。本文件的结构继承自RFC 3096，它定义了ROHC的IP/UDP/RTP要求。
Table of Contents
目录
1. Introduction ....................................................2
2. Header Compression Requirements .................................2
2.1. Impact on Internet Infrastructure ..........................2
2.2. Supported Headers and Kinds of TCP Streams .................3
2.3. Performance Issues .........................................4
2.4. Requirements Related to Link Layer Characteristics .........6
2.5. Intellectual Property Rights (IPR) .........................7
3. Security Consideration ..........................................7
4. IANA Considerations .............................................7
5. Acknowledgements ................................................7
6. Informative References ..........................................7
1. Introduction ....................................................2
2. Header Compression Requirements .................................2
2.1. Impact on Internet Infrastructure ..........................2
2.2. Supported Headers and Kinds of TCP Streams .................3
2.3. Performance Issues .........................................4
2.4. Requirements Related to Link Layer Characteristics .........6
2.5. Intellectual Property Rights (IPR) .........................7
3. Security Consideration ..........................................7
4. IANA Considerations .............................................7
5. Acknowledgements ................................................7
6. Informative References ..........................................7
The goal of the ROHC WG is to develop header compression schemes that perform well over links with high error rates and long link roundtrip times. The schemes must perform well for cellular links that use technologies such as Wideband Code Division Multiple Access (W-CDMA), Enhanced Data rates for GSM Evolution (EDGE), and CDMA2000. However, the schemes should also be applicable to other link technologies with high loss and long roundtrip times.
ROHC工作组的目标是开发在高错误率和长链路往返时间的链路上表现良好的报头压缩方案。这些方案必须适用于使用宽带码分多址（W-CDMA）、GSM演进增强数据速率（EDGE）和CDMA2000等技术的蜂窝链路。然而，这些方案也应适用于其他具有高损耗和长往返时间的链路技术。
The main objective for ROHC has been robust compression of IP/UDP/RTP
[5], but the WG is also chartered to develop new header compression
solutions for IP/TCP [1], [2]. Because TCP traffic, in contrast to
RTP, has usually been sent over reliable links, existing schemes for
TCP, [3] and [4], have not experienced the same robustness problems
as RTP compression. However, there are still many scenarios where
TCP header compression will be implemented over less reliable links
[11], [12], making robustness an important objective for the new TCP
compression scheme. Other, equally important, objectives for ROHC
TCP compression are: improved compression efficiency, enhanced
capabilities for compression of header fields including TCP options,
and finally incorporation of TCP compression into the ROHC framework
[6].
The main objective for ROHC has been robust compression of IP/UDP/RTP
[5], but the WG is also chartered to develop new header compression
solutions for IP/TCP [1], [2]. Because TCP traffic, in contrast to
RTP, has usually been sent over reliable links, existing schemes for
TCP, [3] and [4], have not experienced the same robustness problems
as RTP compression. However, there are still many scenarios where
TCP header compression will be implemented over less reliable links
[11], [12], making robustness an important objective for the new TCP
compression scheme. Other, equally important, objectives for ROHC
TCP compression are: improved compression efficiency, enhanced
capabilities for compression of header fields including TCP options,
and finally incorporation of TCP compression into the ROHC framework
[6].
The following requirements have, more or less arbitrarily, been divided into five groups. The first group deals with requirements concerning the impact of a header compression scheme on the rest of the Internet infrastructure. The second group defines what kind of headers must be compressed efficiently. The third and fourth groups concern performance requirements and capability requirements that stem from the properties of link technologies where ROHC TCP is expected to be used. Finally, the fifth section discusses Intellectual Property Rights related to ROHC TCP compression.
以下要求或多或少被任意分为五类。第一组处理关于报头压缩方案对互联网基础设施其余部分的影响的需求。第二组定义了必须有效压缩的头类型。第三组和第四组涉及性能要求和能力要求，这些要求源于预期使用ROHC TCP的链路技术的特性。最后，第五部分讨论了ROHC TCP压缩相关的知识产权。
1. Transparency: When a header is compressed and then decompressed, the resulting header must be semantically identical to the original header. If this cannot be achieved, the packet containing the erroneous header must be discarded.
1. 透明性：当一个头被压缩然后被解压时，得到的头在语义上必须与原始头相同。如果无法实现，则必须丢弃包含错误报头的数据包。
Justification: The header compression process must not produce headers that might cause problems for any current or future part of the Internet infrastructure.
理由：标头压缩过程不得产生可能会对Internet基础设施的任何当前或未来部分造成问题的标头。
Note: The ROHC WG has not found a case where "semantically identical" is not the same as "bitwise identical".
注：ROHC工作组未发现“语义相同”与“按位相同”不相同的情况。
2. Ubiquity: Must not require modifications to existing IP (v4 or v6) or TCP implementations.
2. 普遍性：不得要求修改现有IP（v4或v6）或TCP实现。
Justification: Ease of deployment.
理由：易于部署。
Note: The ROHC WG may recommend changes that would increase the compression efficiency for the TCP streams emitted by implementations. However, ROHC cannot assume such recommendations will be followed.
注意：ROHC工作组可能会建议进行一些更改，以提高实现所发出的TCP流的压缩效率。然而，ROHC不能假定这些建议会得到遵守。
Note: Several TCP variants are currently in use on the Internet. This requirement implies that the header compression scheme must work efficiently and correctly for all expected TCP variants.
注意：Internet上目前正在使用几种TCP变体。这一要求意味着报头压缩方案必须有效且正确地适用于所有预期的TCP变体。
1. IPv4 and IPv6: Must support both IPv4 and IPv6. This means that all expected changes in the IP header fields must be handled by the compression scheme, and commonly changing fields should be compressed efficiently. Compression must still be possible when IPv6 Extensions are present in the header. When designing the compression scheme, the usage of Explicit Congestion Notification (ECN) [10] should be considered as a common behavior. Therefore, the scheme must also compress efficiently in the case when the ECN bits are used.
1. IPv4和IPv6:必须同时支持IPv4和IPv6。这意味着IP报头字段中的所有预期更改都必须由压缩方案处理，并且通常更改的字段应该被有效压缩。当标头中存在IPv6扩展时，必须仍然可以进行压缩。在设计压缩方案时，应将使用显式拥塞通知（ECN）[10]视为一种常见行为。因此，在使用ECN比特的情况下，该方案还必须有效地压缩。
Justification: IPv4 and IPv6 will both be around for the foreseeable future, and Options/Extensions are expected to be more commonly used. ECN is expected to have a breakthrough and be widely deployed, especially in combination with TCP.
理由：在可预见的未来，IPv4和IPv6都将出现，选项/扩展预计将更普遍地使用。ECN有望取得突破并得到广泛部署，特别是与TCP结合使用时。
2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be supported and should be compressed efficiently. For IPv4 these include headers of tunneled packets. For IPv6 they include headers containing the Routing Header and the Home Address Option.
2. mobileip：mobileip{v4，v6}所使用的头类型必须得到支持，并且应该得到有效压缩。对于IPv4，这些包括隧道数据包的头。对于IPv6，它们包括包含路由标头和家庭地址选项的标头。
Justification: It is very likely that Mobile IP will be used by cellular devices.
理由：移动IP很可能会被蜂窝设备使用。
3. Generality: Must handle all headers from arbitrary TCP streams.
3. 通用性：必须处理来自任意TCP流的所有头。
Justification: There must be a generic scheme that can compress reasonably well for any TCP traffic pattern. This does not preclude optimizations for certain traffic patterns.
理由：必须有一个通用的方案，可以很好地压缩任何TCP流量模式。这并不排除对某些流量模式进行优化。
4. IPSEC: The scheme should be able to compress headers containing IPSEC subheaders where the NULL encryption algorithm is used.
4. IPSEC：该方案应该能够压缩包含使用空加密算法的IPSEC子标题的标题。
Justification: IPSEC is expected to be used to provide necessary end-to-end security.
理由：IPSEC预计将用于提供必要的端到端安全性。
Note: It is not possible to compress the encrypted part of an ESP header, nor the cryptographic data in an AH header.
注意：不可能压缩ESP头的加密部分，也不可能压缩AH头中的加密数据。
5. TCP: All fields supported by [4] should be handled with efficient compression, as should be the cases when the SYN, FIN or TCP ECN [10] bits are set.
5. TCP:[4]支持的所有字段都应进行有效压缩，设置SYN、FIN或TCP ECN[10]位时也应如此。
Justification: These bits are expected to be commonly used.
对齐：这些位预计将被广泛使用。
6. TCP options: The scheme must support compression of packets with any TCP option present, even if the option itself is not compressed. Further, for some commonly used options the scheme should also provide compression mechanisms for the options.
6. TCP选项：该方案必须支持在存在任何TCP选项的情况下压缩数据包，即使该选项本身未被压缩。此外，对于一些常用选项，方案还应为选项提供压缩机制。
Justification: Because various TCP options are commonly used, applicability of the compression scheme would be significantly reduced if packets with options could not be compressed.
理由：由于通常使用各种TCP选项，如果无法压缩带有选项的数据包，则压缩方案的适用性将显著降低。
Note: Options that should be compressed are: - Selective Acknowledgement (SACK), [8], [9] - Timestamp, [7]
注意：应该压缩的选项有：-选择性确认（SACK），[8]，[9]-时间戳[7]
1. Performance/Spectral Efficiency: The scheme must provide low relative overhead under expected operating conditions; compression efficiency should be better than for RFC 2507 [4] under equivalent operating conditions.
1. 性能/频谱效率：方案必须在预期运行条件下提供较低的相对开销；在同等操作条件下，压缩效率应优于RFC 2507[4]。
Justification: Spectrum efficiency is a primary goal.
理由：频谱效率是主要目标。
Note: The relative overhead is the average header overhead relative to the payload. Any auxiliary (e.g., control or feedback) channels used by the scheme should be taken into account when calculating the header overhead.
注意：相对开销是相对于有效负载的平均报头开销。在计算报头开销时，应考虑方案使用的任何辅助（如控制或反馈）通道。
2. Losses between compressor and decompressor: The scheme should make sure losses between compressor and decompressor do not result in losses of subsequent packets, or cause damage to the context that results in incorrect decompression of subsequent packet headers.
2. 压缩器和解压缩器之间的丢失：方案应确保压缩器和解压缩器之间的丢失不会导致后续数据包的丢失，或对上下文造成损害，从而导致后续数据包头的错误解压缩。
Justification: Even though link layer retransmission in most cases is expected to almost eliminate losses between compressor and decompressor, there are still many scenarios where TCP header compression will be implemented over less reliable links [11], [12]. In such cases, loss propagation due to header compression could affect certain TCP mechanisms that are capable of handling some losses; loss propagation could also have a negative impact on the performance of TCP loss recovery.
理由：尽管在大多数情况下，链路层重传有望几乎消除压缩器和解压缩器之间的损失，但仍有许多情况下，TCP报头压缩将在可靠性较低的链路上实现[11]，[12]。在这种情况下，由于报头压缩导致的丢失传播可能会影响某些能够处理某些丢失的TCP机制；丢失传播也可能对TCP丢失恢复的性能产生负面影响。
3. Residual errors in compressed headers: Residual errors in compressed headers may result in delivery of incorrectly decompressed headers not only for the damaged packet itself, but also for subsequent packets, because errors may be saved in the context state. For TCP, the compression scheme is not required to implement explicit mechanisms for residual error detection, but the compression scheme must not affect TCP's end-to-end mechanisms for error detection.
3. 压缩报头中的残余错误：压缩报头中的残余错误可能导致不正确的解压缩报头的传递，不仅针对损坏的数据包本身，而且针对后续的数据包，因为错误可能保存在上下文状态中。对于TCP，压缩方案不需要实现显式的残余错误检测机制，但压缩方案不得影响TCP的端到端错误检测机制。
Justification: For links carrying TCP traffic, the residual error rate is expected to be insignificant. However, residual errors may still occur, especially in the end-to-end path. Therefore, it is crucial that TCP is not prevented from handling these.
理由：对于承载TCP流量的链路，剩余错误率预计是微不足道的。但是，仍然可能发生残余错误，尤其是在端到端路径中。因此，关键是不要阻止TCP处理这些问题。
Note: This requirement implies that the TCP checksum must be carried unmodified in all compressed headers.
注意：此要求意味着TCP校验和必须在所有压缩头中未经修改地进行。
Note: The error detection mechanism in TCP may be able to detect residual bit errors, but the mechanism is not designed for this purpose, and might actually provide rather weak protection. Therefore, although it is not a requirement of the compression scheme, it should be possible for the decompressor to detect residual errors and discard such packets.
注意：TCP中的错误检测机制可能能够检测残余的位错误，但该机制不是为此目的设计的，实际上可能提供相当弱的保护。因此，尽管这不是压缩方案的要求，但解压器应该能够检测残余错误并丢弃这样的分组。
4. Short-lived TCP transfers: The scheme should provide mechanisms for efficient compression of short-lived TCP transfers, minimizing the size of context initiation headers.
4. 短命TCP传输：该方案应提供有效压缩短命TCP传输的机制，以最小化上下文启动头的大小。
Justification: Many TCP transfers are short-lived. This may lead to a low gain for header compression schemes that, for each new packet stream, requires full headers to be sent initially and allows small compressed headers only after the initialization phase.
理由：许多TCP传输都是短期的。这可能导致报头压缩方案的低增益，对于每个新的分组流，最初需要发送完整的报头，并且只允许在初始化阶段之后发送小的压缩报头。
Note: This requirement implies that mechanisms for building new contexts that are based on information from previous contexts or for concurrent packet streams to share context information should be considered.
注：此要求意味着应考虑基于先前上下文中的信息构建新上下文的机制或用于共享上下文信息的并发数据包流的机制。
5a. Moderate Packet Misordering: The scheme should efficiently handle moderate misordering (2-3 packets) in the packet stream reaching the compressor.
5a。中度分组误序：该方案应有效处理到达压缩器的分组流中的中度误序（2-3个分组）。
Justification: This kind of misordering is common.
理由：这种错误排序是常见的。
5b. Packet Misordering: The scheme must be able to correctly handle packet misordering and preferably compress when misordered packets are in the TCP stream reaching the compressor.
5b。数据包误序：该方案必须能够正确处理数据包误序，并且在到达压缩器的TCP流中出现误序数据包时，最好进行压缩。
Justification: Misordering happens regularly in the Internet. However, because the Internet is engineered to run TCP reasonably well, excessive misordering will not be common and need not be handled with optimum efficiency.
理由：在互联网上，乱序经常发生。然而，由于互联网的设计使TCP运行得相当好，过度的错误排序将不会很常见，也不需要以最佳效率进行处理。
6. Processing delay: The scheme should not contribute significantly to the system delay budget.
6. 处理延迟：方案不应对系统延迟预算做出重大贡献。
1. Unidirectional links: Must be possible to implement (possibly with less efficiency) without explicit feedback messages from decompressor to compressor.
1. 单向链接：必须能够在没有从解压器到压缩器的明确反馈消息的情况下实现（可能效率较低）。
Justification: There are links that do not provide a feedback channel or where feedback is not desirable for other reasons.
理由：有些链接不提供反馈渠道，或者由于其他原因不需要反馈。
2. Link delay: Must operate under all expected link delay conditions.
2. 链路延迟：必须在所有预期链路延迟条件下运行。
3. Header compression coexistence: The scheme must fit into the ROHC framework together with other ROHC profiles (e.g., [6]).
3. 头压缩共存：该方案必须与其他ROHC配置文件（如[6]）一起适应ROHC框架。
4. Note on misordering between compressor and decompressor:
4. 压缩机和减压器之间的误序说明：
When compression is applied over tunnels, misordering often cannot be completely avoided. The header compression scheme should not prohibit misordering between compressor and decompressor, as it would therefore not be applicable in many tunneling scenarios. However, in the case of tunneling, it is usually possible to get misordering indications. Therefore, the compression scheme does not have to support detection of misordering, but can assume that such information is available from lower layers when misordering occurs.
当在隧道上施加压缩时，通常无法完全避免顺序错误。标头压缩方案不应禁止压缩机和解压缩器之间的错误排序，因为它因此不适用于许多隧道场景。然而，在隧道的情况下，通常可能会出现排列错误的指示。因此，压缩方案不必支持错误排序的检测，但可以假设当错误排序发生时，这些信息可以从较低的层获得。
The ROHC WG must spend effort to achieve a high degree of confidence that there are no known IPR claims that cover the final compression solution for TCP.
ROHC工作组必须努力实现高度信心，即不存在涉及TCP最终压缩解决方案的已知IPR声明。
Justification: Currently there is no TCP header compression scheme available that can efficiently compress the packet headers of modern TCP, e.g., with SACK, ECN, etc. ROHC is expected to fill this gap by providing a ROHC TCP scheme that is applicable in the wide area Internet, not only over error-prone radio links. It must thus attempt to be as future-proof as possible, and only unencumbered solutions, or solutions where the terms of any IPR are such that there is no hindrance on implementation and deployment, will be acceptable to the Internet at large.
理由：目前没有可用的TCP报头压缩方案可以有效地压缩现代TCP的数据包报头，例如使用SACK、ECN等。ROHC有望通过提供适用于广域互联网的ROHC TCP方案来填补这一空白，而不仅仅是在易出错的无线链路上。因此，它必须尽可能地证明未来，并且只有无阻碍的解决方案，或者任何知识产权的条款不妨碍实施和部署的解决方案，才能为整个互联网所接受。
A protocol specified to meet these requirements must be able to compress packets containing IPSEC headers according to the IPSEC requirement, 2.2.4. There may be other security aspects to consider in such protocols. This document by itself, however, does not add any security risks.
根据IPSEC要求2.2.4，为满足这些要求而指定的协议必须能够压缩包含IPSEC头的数据包。在这些协议中可能需要考虑其他安全方面。然而，本文件本身并不增加任何安全风险。
A protocol that meets these requirements will require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement.
满足这些要求的协议将要求IANA分配各种号码。然而，本文件本身不需要IANA的参与。
This document has evolved through fruitful discussions with and input from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West, Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk. The document quality was significantly improved thanks to Peter Eriksson, who made a thorough linguistic review.
本文件通过与Gorry Fairhurst、Carsten Bormann、Mikael Degermark、Mark West、Jan Kullander、Qian Zhang、Richard Price和Aaron Falk的富有成果的讨论和投入而形成。由于彼得·埃里克森（Peter Eriksson）进行了彻底的语言审查，文档质量显著提高。
Last, but not least, Ghyslain Pelletier and Kristofer Sandlund served as committed working group document reviewers.
最后，但并非最不重要的一点是，Ghyslain Pelletier和Kristofer Sandlund担任了工作组文件审查员。
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[1] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[2] 《传输控制协议》，标准7，RFC 793，1981年9月。
[3] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[3] Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC 1144，1990年2月。
[4] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[4] Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[5] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[5] Degermark，M.“鲁棒IP/UDP/RTP报头压缩的要求”，RFC 3096，2001年7月。
[6] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[6] Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[7] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[7] Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[8] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[8] Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[9] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[9] Floyd，S.，Mahdavi，J.，Mathis，M.，和M.Podolsky，“TCP选择性确认（SACK）选项的扩展”，RFC 28832000年7月。
[10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[10] Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[11] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[11] Dawkins，S.，黑山，G.，Kojo，M.，和V.Magret，“慢链路的端到端性能影响”，BCP 48，RFC 3150，2001年7月。
[12] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[12] Fairhurst，G.和L.Wood，“关于链路自动重复请求（ARQ）的链路设计者建议”，BCP 62，RFC 3366，2002年8月。
Author's Address
作者地址
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
Lars Erik Jonsson Ericsson AB信箱920 SE-971 28瑞典卢利亚
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。