Network Working Group
Request for Comments: 2509 M. Engan
Category: Standards Track Effnet
S. Casner
Cisco Systems
C. Bormann
Universitaet Bremen TZI
February 1999
Network Working Group
Request for Comments: 2509 M. Engan
Category: Standards Track Effnet
S. Casner
Cisco Systems
C. Bormann
Universitaet Bremen TZI
February 1999
IP Header Compression over PPP
基于PPP的IP报头压缩
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol [RFC1661]. It defines extensions to the PPP Control Protocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in [IPHC] and [CRTP].
本文档描述了一种用于协商在点到点协议[RFC1661]上传输的IP数据报上使用报头压缩的选项。它定义了IPv4和IPv6的PPP控制协议的扩展[RFC1332，RFC2023]。头压缩可与[IPHC]和[CRTP]中规定的TCP、UDP和RTP传输协议结合应用于IPv4和IPv6数据报。
The IP Header Compression (IPHC) defined in [IPHC] may be used for compression of both IPv4 and IPv6 datagrams or packets encapsulated with multiple IP headers. IPHC is also capable of compressing both TCP and UDP transport protocol headers. The IP/UDP/RTP header compression defined in [CRTP] fits within the framework defined by IPHC so that it may also be applied to both IPv4 and IPv6 packets.
[IPHC]中定义的IP报头压缩（IPHC）可用于压缩IPv4和IPv6数据报或用多个IP报头封装的数据包。IPHC还能够压缩TCP和UDP传输协议头。[CRTP]中定义的IP/UDP/RTP报头压缩适合IPHC定义的框架，因此它也可以应用于IPv4和IPv6数据包。
In order to establish compression of IP datagrams sent over a PPP link each end of the link must agree on a set of configuration parameters for the compression. The process of negotiating link parameters for network layer protocols is handled in PPP by a family of network control protocols (NCPs). Since there are separate NCPs for IPv4 and IPv6, this document defines configuration options to be
为了对通过PPP链路发送的IP数据报进行压缩，链路的每一端必须就压缩的一组配置参数达成一致。网络层协议的链路参数协商过程由一系列网络控制协议（NCP）在PPP中处理。由于IPv4和IPv6有单独的NCP，因此本文档定义了要使用的配置选项
used in both NCPs to negotiate parameters for the compression scheme.
在两个NCP中用于协商压缩方案的参数。
IPHC relies on the link layer's ability to indicate the types of datagrams carried in the link layer frames. In this document nine new types for the PPP Data Link Layer Protocol Field are defined along with their meaning.
IPHC依赖于链路层指示链路层帧中承载的数据报类型的能力。本文定义了PPP数据链路层协议字段的九种新类型及其含义。
In general, header compression schemes that use delta encoding of compressed packets require that the lower layer does not reorder packets between compressor and decompressor. IPHC uses delta encoding of compressed packets for TCP and RTP. The IPHC specification [IPHC] includes methods that allow link layers that may reorder packets to be used with IPHC. Since PPP does not reorder packets these mechanisms are disabled by default. When using reordering mechanisms such as multiclass multilink PPP [MCML], care must be taken so that packets that share the same compression context are not reordered.
通常，使用压缩数据包的增量编码的报头压缩方案要求较低层不在压缩器和解压缩器之间重新排序数据包。IPHC对TCP和RTP使用压缩数据包的增量编码。IPHC规范[IPHC]包括允许链路层对IPHC使用的数据包重新排序的方法。由于PPP不会对数据包重新排序，因此默认情况下禁用这些机制。当使用诸如多类多链路PPP[MCML]之类的重新排序机制时，必须注意不要对共享相同压缩上下文的数据包进行重新排序。
This document specifies a new compression protocol value for the IPCP IP-Compression-Protocol option as specified in [RFC1332]. The new value and the associated option format are described in section 2.1.
本文档为[RFC1332]中指定的IPCP IP压缩协议选项指定了一个新的压缩协议值。第2.1节描述了新值和相关选项格式。
The option format is structured to allow future extensions to the IPHC scheme.
选项格式的结构允许将来扩展到IPHC方案。
NOTE: The specification of link and network layer parameter negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not prohibit multiple instances of one configuration option but states that the specification of a configuration option must explicitly allow multiple instances. From the current specification of the IPCP IP-Compression-Protocol configuration option [RFC1332, p 6] it follows that it can only be used to select a single compression protocol at any time.
注：PPP[RFC1661]、[RFC1331]、[RFC1332]的链路和网络层参数协商规范不禁止一个配置选项的多个实例，但规定一个配置选项的规范必须明确允许多个实例。根据IPCP IP压缩协议配置选项[RFC1332，P6]的当前规范，它在任何时候都只能用于选择单个压缩协议。
NOTE: [RFC1332] is not explicit about whether the option negotiates the capabilities of the receiver or of the sender. In keeping with current practice, we assume that the option describes the capabilities of the decompressor (receiving side) of the peer that sends the Config-Req.
注意：[RFC1332]未明确说明该选项是协商接收方还是发送方的能力。根据当前的实践，我们假设该选项描述发送配置请求的对等方的解压缩器（接收端）的功能。
Both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2023] may be used to negotiate IP Header Compression parameters for their respective protocols. The format of the configuration option is the same for both IPCP and IPV6CP.
IPv4、IPCP[RFC1332]和IPv6 NCP、IPV6CP[RFC2023]的网络控制协议均可用于协商各自协议的IP报头压缩参数。IPCP和IPV6CP的配置选项格式相同。
Description
描述
This NCP configuration option is used to negotiate parameters for IP Header Compression. The option format is summarized below. The fields are transmitted from left to right.
此NCP配置选项用于协商IP标头压缩的参数。选项格式概述如下。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP_SPACE | NON_TCP_SPACE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F_MAX_PERIOD | F_MAX_TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_HEADER | suboptions...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP_SPACE | NON_TCP_SPACE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F_MAX_PERIOD | F_MAX_TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_HEADER | suboptions...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
类型2
Length >= 14
长度>=14
The length may be increased if the presence of additional parameters is indicated by additional suboptions.
如果附加子选项指示存在附加参数，则长度可能会增加。
IP-Compression-Protocol 0061 (hex)
IP压缩协议0061（十六进制）
TCP_SPACE The TCP_SPACE field is two octets and indicates the maximum value of a context identifier in the space of context identifiers allocated for TCP.
TCP_SPACE TCP_SPACE字段是两个八位字节，表示在为TCP分配的上下文标识符空间中上下文标识符的最大值。
Suggested value: 15
建议值：15
TCP_SPACE must be at least 0 and at most 255 (The value 0 implies having one context).
TCP_空间必须至少为0，最多为255（值0表示有一个上下文）。
NON_TCP_SPACE The NON_TCP_SPACE field is two octets and indicates the maximum value of a context identifier in the space of context identifiers allocated for non-TCP. These context identifiers are carried in COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet headers.
NON_TCP_SPACE NON_TCP_SPACE字段是两个八位字节，表示分配给非TCP的上下文标识符空间中上下文标识符的最大值。这些上下文标识符包含在压缩的\u非\u TCP、压缩的\u UDP和压缩的\u RTP数据包头中。
Suggested value: 15
建议值：15
NON_TCP_SPACE must be at least 0 and at most 65535 (The value 0 implies having one context).
非TCP_空间必须至少为0，最多为65535（值0表示有一个上下文）。
F_MAX_PERIOD Maximum interval between full headers. No more than F_MAX_PERIOD COMPRESSED_NON_TCP headers may be sent between FULL_HEADER headers.
F_MAX_PERIOD完整标题之间的最大间隔。在完整的\u头标头之间发送的压缩\u非\u TCP头不得超过F_MAX \u PERIOD。
Suggested value: 256
建议值：256
A value of zero implies infinity, i.e. there is no limit to the number of consecutive COMPRESSED_NON_TCP headers.
值为零意味着无穷大，即对连续压缩的\u非\u TCP头的数量没有限制。
F_MAX_TIME Maximum time interval between full headers. COMPRESSED_NON_TCP headers may not be sent more than F_MAX_TIME seconds after sending the last FULL_HEADER header.
F_MAX_TIME完整标头之间的最大时间间隔。在发送最后一个完整的\u头后，压缩的\u非\u TCP头的发送时间不得超过F_MAX \u时间秒。
Suggested value: 5 seconds
建议值：5秒
A value of zero implies infinity.
值为零意味着无穷大。
MAX_HEADER The largest header size in octets that may be compressed.
MAX_HEADER可压缩的最大头大小（以八位字节为单位）。
Suggested value: 168 octets
建议值：168个八位字节
The value of MAX_HEADER should be large enough so that at least the outer network layer header can be compressed. To increase compression efficiency MAX_HEADER should be set to a value large enough to cover common combinations of network and transport layer headers.
MAX_头的值应该足够大，以便至少可以压缩外部网络层头。为了提高压缩效率，应将MAX_头设置为足够大的值，以覆盖网络和传输层头的常见组合。
suboptions The suboptions field consists of zero or more suboptions. Each suboption consists of a type field, a length field and zero or more parameter octets, as defined by the suboption type. The value of the length field indicates the length of the suboption in its entirety, including the lengths of the type and length fields.
子选项“子选项”字段由零个或多个子选项组成。每个子选项由一个类型字段、一个长度字段和零个或多个由子选项类型定义的参数八位字节组成。长度字段的值指示子选项的整个长度，包括类型字段和长度字段的长度。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Parameters...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Parameters...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTP-Compression suboption is included in the NCP IP-Compression-Protocol option for IPHC if IP/UDP/RTP compression is to be enabled.
如果要启用IP/UDP/RTP压缩，则IPHC的NCP IP压缩协议选项中包含RTP压缩子选项。
After successful negotiation of parameters for IP Header Compression the use of Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, COMPRESSED_TCP_NODELTA and COMPRESSED_NON_TCP is enabled, regardless of the prescence of an RTP-Compression suboption.
成功协商IP报头压缩参数后，启用协议标识符FULL_报头、COMPRESSED_TCP、COMPRESSED_TCP_NODELTA和COMPRESSED_NON_TCP，而不考虑RTP压缩子选项的存在。
Description
描述
Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP and CONTEXT_STATE as specified in [CRTP].
允许使用[CRTP]中指定的协议标识符COMPRESSED_RTP、COMPRESSED_UDP和CONTEXT_STATE。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1
类型1
Length 2
长度2
The IPHC protocol is able to compress both IPv6 and IPv4 datagrams. Both IPCP and IPV6CP are able to negotiate option parameter values for IPHC. These values apply to the compression of packets where the outer header is an IPv4 header and an IPv6 header, respectively.
IPHC协议能够压缩IPv6和IPv4数据报。IPCP和IPV6CP都能够协商IPHC的选项参数值。这些值适用于数据包的压缩，其中外部报头分别是IPv4报头和IPv6报头。
For the compression and decompression of IPv4 and IPv6 datagram headers the context identifier space is shared. While the parameter values are independently negotiated, sharing the context identifier spaces becomes more complex when the parameter values differ. Since
对于IPv4和IPv6数据报报头的压缩和解压缩，上下文标识符空间是共享的。虽然参数值是独立协商的，但当参数值不同时，共享上下文标识符空间变得更加复杂。自从
the compressed packets share context identifier space, the compression engine must allocate context identifiers out of a common pool; for compressed packets, the decompressor has to examine the context state to determine what parameters to use for decompression.
压缩包共享上下文标识符空间，压缩引擎必须从公共池中分配上下文标识符；对于压缩数据包，解压缩程序必须检查上下文状态，以确定用于解压缩的参数。
Context identifier spaces are not shared between TCP and non-TCP/UDP/RTP. Doing so would require additional mechanisms to ensure that no error can occur when switching from using a context identifier for TCP to non-TCP.
TCP和非TCP/UDP/RTP之间不共享上下文标识符空间。这样做需要额外的机制来确保从使用TCP上下文标识符切换到非TCP时不会发生错误。
The IPHC specification [IPHC] defines four header formats for different types of compressed headers. They are compressed TCP, compressed TCP with no delta encoding, compressed non-TCP with 8 bit CID and compressed non-TCP with 16 bit CID. The two non-TCP formats may be distinguished by their contents so both may use the same link-level identifier. A fifth header format, the full header is distinct from a regular header in that it carries additional information to establish shared context between the compressor and decompressor.
IPHC规范[IPHC]为不同类型的压缩头定义了四种头格式。它们是压缩TCP、无增量编码的压缩TCP、具有8位CID的压缩非TCP和具有16位CID的压缩非TCP。这两种非TCP格式可以通过其内容来区分，因此两者可以使用相同的链路级标识符。第五种报头格式，完整报头不同于常规报头，因为它携带附加信息以在压缩器和解压缩器之间建立共享上下文。
The specification of IP/UDP/RTP Header Compression [CRTP] defines four additional formats of compressed headers. They are for compressed UDP and compressed RTP (on top of UDP), both with either 8- or 16-bit CIDs. In addition, there is an explicit error message from the decompressor to the compressor.
IP/UDP/RTP报头压缩规范[CRTP]定义了四种额外的压缩报头格式。它们用于压缩UDP和压缩RTP（在UDP之上），两者都具有8位或16位CID。此外，从解压器到压缩器还有一条明确的错误消息。
The link layer must be able to indicate these header formats with distinct values. Nine PPP Data Link Layer Protocol Field values are specified below.
链接层必须能够用不同的值指示这些标题格式。下面指定了九个PPP数据链路层协议字段值。
FULL_HEADER The frame contains a full header as specified in [CRTP] Section 3.3.1. This is the same as the FULL_HEADER specified in [IPHC] Section 5.3. Value: 0061 (hex)
完整页眉框架包含[CRTP]第3.3.1节规定的完整页眉。这与[IPHC]第5.3节中规定的完整_标题相同。值：0061（十六进制）
COMPRESSED_TCP The frame contains a datagram with a compressed header with the format as specified in [IPHC] Section 6a. Value: 0063 (hex)
压缩的\u TCP帧包含具有[IPHC]第6a节规定格式的压缩头的数据报。值：0063（十六进制）
COMPRESSED_TCP_NODELTA The frame contains a datagram with a compressed header with the format as specified in [IPHC] Section 6b. Value: 2063 (hex)
COMPRESSED_TCP_NODELTA该帧包含一个数据报，该数据报具有[IPHC]第6b节规定格式的压缩报头。值：2063（十六进制）
COMPRESSED_NON_TCP The frame contains a datagram with a compressed header with the format as specified in either Section 6c or Section 6d of [IPHC]. Value: 0065 (hex)
压缩\u非\u TCP帧包含一个带有压缩头的数据报，其格式如[IPHC]第6c节或第6d节所述。值：0065（十六进制）
COMPRESSED_RTP_8 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.2, using 8-bit CIDs. Value: 0069 (hex)
压缩_RTP_8该帧包含一个数据报，该数据报具有[CRTP]第3.3.2节规定格式的压缩头，使用8位CID。值：0069（十六进制）
COMPRESSED_RTP_16 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.2, using 16-bit CIDs. Value: 2069 (hex)
压缩_RTP_16该帧包含一个数据报，该数据报具有[CRTP]第3.3.2节规定格式的压缩头，使用16位CID。值：2069（十六进制）
COMPRESSED_UDP_8 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.3, using 8-bit CIDs. Value: 0067 (hex)
压缩_UDP_8该帧包含一个数据报，该数据报带有一个压缩头，格式如[CRTP]第3.3.3节所述，使用8位CID。值：0067（十六进制）
COMPRESSED_UDP_16 The frame contains a datagram with a compressed header with the format as specified in [CRTP] Section 3.3.3, using 16-bit CIDs. Value: 2067 (hex)
压缩的_UDP_16该帧包含一个数据报，该数据报带有一个压缩的报头，格式如[CRTP]第3.3.3节所述，使用16位CID。值：2067（十六进制）
CONTEXT_STATE The frame is a link-level message sent from the decompressor to the compressor as specified in [CRTP] Section 3.3.5. Value: 2065 (hex)
上下文\状态帧是一条链路级消息，按照[CRTP]第3.3.5节的规定，从解压缩器发送到压缩器。值：2065（十六进制）
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTP]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[IPHC] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for IP", RFC 2507, February 1999.
[IPHC]Degermark，M.，Nordgren，B.和S.Pink，“IP的头压缩”，RFC 2507，1999年2月。
[RFC2023] Haskin, E. and E. Allan, "IP Version 6 over PPP", RFC 2023, October 1996.
[RFC2023]Haskin，E.和E.Allan，“PPP上的IP版本6”，RFC 2023，1996年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low- Speed Serial Links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC1144，1990年2月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[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月。
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[MCML] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", Work in Progress.
[MCML]Bormann，C.，“多链路PPP的多类扩展”，正在进行中。
Negotiation of the option defined here imposes no additional security considerations beyond those that otherwise apply to PPP [RFC1661].
此处定义的期权谈判不涉及除PPP以外的其他安全考虑因素[RFC1661]。
The use of header compression can, in rare cases, cause the misdelivery of packets. If necessary, confidentiality of packet contents should be assured by encryption.
在极少数情况下，使用报头压缩会导致数据包的误发。如有必要，应通过加密确保数据包内容的机密性。
Encryption applied at the IP layer (e.g., using IPSEC mechanisms) precludes header compression of the encrypted headers, though compression of the outer IP header and authentication/security headers is still possible as described in [IPHC]. For RTP packets, full header compression is possible if the RTP payload is encrypted by itself without encrypting the UDP or RTP headers, as described in [RFC1889]. This method is appropriate when the UDP and RTP header information need not be kept confidential.
在IP层应用的加密（例如，使用IPSEC机制）排除了加密报头的报头压缩，尽管外部IP报头和身份验证/安全报头的压缩仍然是可能的，如[IPHC]中所述。对于RTP数据包，如[RFC1889]中所述，如果RTP有效负载在不加密UDP或RTP报头的情况下自行加密，则完全报头压缩是可能的。当UDP和RTP报头信息不需要保密时，此方法适用。
Mathias Engan Effnet Aurorum 2 SE-977 75 Lulea, Sweden
Mathias Engan Effnet Aurorum 2 SE-977 75 Lulea，瑞典
Phone: +46 920 75600
Mobile: +46 70 833 8932
Fax: +46 920 75610
EMail: engan@effnet.com
Phone: +46 920 75600
Mobile: +46 70 833 8932
Fax: +46 920 75610
EMail: engan@effnet.com
Stephen L. Casner Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
Stephen L.Casner Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
EMail: casner@cisco.com
EMail: casner@cisco.com
Carsten Bormann Universitaet Bremen FB3 TZI Postfach 330440 D-28334 Bremen, GERMANY
德国不来梅卡斯滕·鲍曼大学FB3 TZI Postfach 330440 D-28334
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。