Network Working Group A. Shacham
Request for Comments: 2393 Cisco
Category: Standards Track R. Monsour
Hi/fn
R. Pereira
TimeStep
M. Thomas
AltaVista Internet
December 1998
Network Working Group A. Shacham
Request for Comments: 2393 Cisco
Category: Standards Track R. Monsour
Hi/fn
R. Pereira
TimeStep
M. Thomas
AltaVista Internet
December 1998
IP Payload Compression Protocol (IPComp)
IP有效负载压缩协议（IPComp）
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment.
本文档描述了一种协议，旨在为Internet环境中的Internet协议数据报提供无损压缩。
IP payload compression is a protocol to reduce the size of IP datagrams. This protocol will increase the overall communication performance between a pair of communicating hosts/gateways ("nodes") by compressing the datagrams, provided the nodes have sufficient computation power, through either CPU capacity or a compression coprocessor, and the communication is over slow or congested links.
IP有效负载压缩是一种减少IP数据报大小的协议。该协议将通过压缩数据报来提高一对通信主机/网关（“节点”）之间的整体通信性能，前提是节点通过CPU容量或压缩协处理器具有足够的计算能力，并且通信速度过慢或拥塞链路。
IP payload compression is especially useful when encryption is applied to IP datagrams. Encrypting the IP datagram causes the data to be random in nature, rendering compression at lower protocol layers (e.g., PPP Compression Control Protocol [RFC-1962]) ineffective. If both compression and encryption are required, compression MUST be applied before encryption.
当对IP数据报应用加密时，IP有效负载压缩特别有用。加密IP数据报会导致数据本质上是随机的，从而导致较低协议层的压缩（例如，PPP压缩控制协议[RFC-1962]）无效。如果同时需要压缩和加密，则必须在加密之前应用压缩。
This document defines the IP payload compression protocol (IPComp), the IPComp packet structure, the IPComp Association (IPCA), and several methods to negotiate the IPCA.
本文档定义了IP有效负载压缩协议（IPComp）、IPComp数据包结构、IPComp关联（IPCA）以及协商IPCA的几种方法。
Other documents shall specify how a specific compression algorithm can be used with the IP payload compression protocol. Such algorithms are beyond the scope of this document.
其他文件应规定特定压缩算法如何与IP有效负载压缩协议一起使用。此类算法超出了本文件的范围。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC-2119]中的说明进行解释。
The compression processing of IP datagrams has two phases: compressing of outbound IP datagrams ("compression") and decompressing of inbound datagrams ("decompression"). The compression processing MUST be lossless, ensuring that the IP datagram, after being compressed and decompressed, is identical to the original IP datagram.
IP数据报的压缩处理分为两个阶段：出站IP数据报的压缩（“压缩”）和入站数据报的解压缩（“解压缩”）。压缩处理必须是无损的，确保压缩和解压缩后的IP数据报与原始IP数据报相同。
Each IP datagram is compressed and decompressed by itself without any relation to other datagrams ("stateless compression"), as IP datagrams may arrive out of order or not arrive at all. Each compressed IP datagram encapsulates a single IP payload.
每个IP数据报都是自己压缩和解压缩的，与其他数据报没有任何关系（“无状态压缩”），因为IP数据报可能会无序到达或根本不到达。每个压缩IP数据报封装一个IP有效负载。
Processing of inbound IP datagrams MUST support both compressed and non-compressed IP datagrams, in order to meet the non-expansion policy requirements, as defined in section 2.2.
入站IP数据报的处理必须支持压缩和非压缩IP数据报，以满足第2.2节中定义的非扩展策略要求。
The compression of outbound IP datagrams MUST be done before any IP security processing, such as encryption and authentication, and before any fragmentation of the IP datagram. In addition, in IP version 6 [RFC-2460], the compression of outbound IP datagrams MUST be done before the addition of either a Hop-by-Hop Options header or a Routing Header, since both carry information that must be examined and processed by possibly every node along a packet's delivery path, and therefore MUST be sent in the original form.
出站IP数据报的压缩必须在任何IP安全处理（如加密和身份验证）之前以及在IP数据报的任何碎片之前完成。此外，在IP版本6[RFC-2460]中，出站IP数据报的压缩必须在添加逐跳选项报头或路由报头之前完成，因为这两个报头都携带信息，可能每个节点都必须沿着数据包的传递路径检查和处理这些信息，因此必须以原始形式发送。
Similarly, the decompression of inbound IP datagrams MUST be done after the reassembly of the IP datagrams, and after the completion of all IP security processing, such as authentication and decryption.
类似地，入站IP数据报的解压缩必须在重新组装IP数据报之后以及在完成所有IP安全处理（如身份验证和解密）之后进行。
The compression is applied to a single array of octets, which are contiguous in the IP datagram. This array of octets always ends at the last octet of the IP packet payload. Note: a contiguous array of octets in the IP datagram may be not contiguous in physical memory.
压缩应用于在IP数据报中连续的单个八位字节数组。此八位字节数组始终以IP数据包有效负载的最后一个八位字节结束。注意：IP数据报中的连续八位字节数组在物理内存中可能不连续。
In IP version 4 [RFC-0791], the compression is applied to the upper layer protocol (ULP) payload of the IP datagram. No portion of the IP header or the IP header options is compressed.
在IP版本4[RFC-0791]中，压缩应用于IP数据报的上层协议（ULP）有效载荷。没有压缩IP头或IP头选项的任何部分。
In the IPv6 context, IPComp is viewed as an end-to-end payload, and MUST not apply to hop-by-hop, routing, and fragmentation extension headers. The compression is applied starting at the first IP Header Option field that does not carry information that must be examined and processed by nodes along a packet's delivery path, if such IP Header Option field exists, and continues to the ULP payload of the IP datagram.
在IPv6上下文中，IPComp被视为端到端有效负载，不能应用于逐跳、路由和分段扩展头。压缩从第一IP报头选项字段开始应用，该字段不携带必须由节点沿着分组的递送路径检查和处理的信息（如果该IP报头选项字段存在），并继续到IP数据报的ULP有效载荷。
The size of a compressed payload, generated by the compression algorithm, MUST be in whole octet units.
由压缩算法生成的压缩有效负载的大小必须以整个八位字节为单位。
As defined in section 3, an IPComp header is inserted immediately preceding the compressed payload. The original IP header is modified to indicate the usage of the IPComp protocol and the reduced size of the IP datagram. The original content of the Next Header (IPv6) or protocol (IPv4) field is stored in the IPComp header.
如第3节所定义，IPComp报头插入压缩有效负载的正前方。修改原始IP报头以指示IPComp协议的使用情况和IP数据报的缩减大小。下一个报头（IPv6）或协议（IPv4）字段的原始内容存储在IPComp报头中。
The decompression is applied to a single contiguous array of octets in the IP datagram. The start of the array of octets immediately follows the IPComp header and ends at the last octet of the IP payload. If the decompression process is successfully completed, the IP header is modified to indicate the size of the decompressed IP datagram, and the original next header as stored in the IPComp header. The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header.
解压应用于IP数据报中的单个连续八位字节数组。八位字节数组的开始紧跟在IPComp头之后，并在IP有效负载的最后一个八位字节结束。如果解压缩过程成功完成，则修改IP报头以指示解压缩的IP数据报的大小，以及存储在IPComp报头中的原始下一个报头。IPComp报头从IP数据报中删除，解压缩的有效负载紧跟在IP报头之后。
If the total size of a compressed ULP payload and the IPComp header, as defined in section 3, is not smaller than the size of the original ULP payload, the IP datagram MUST be sent in the original non-compressed form. To clarify: If an IP datagram is sent non-compressed, no IPComp header is added to the datagram. This policy ensures saving the decompression processing cycles and avoiding incurring IP datagram fragmentation when the expanded datagram is larger than MTU.
如果第3节中定义的压缩ULP有效负载和IPComp报头的总大小不小于原始ULP有效负载的大小，则必须以原始非压缩形式发送IP数据报。澄清：如果IP数据报以非压缩方式发送，则不会向数据报添加IPComp头。当扩展数据报大于MTU时，此策略可确保节省解压缩处理周期并避免产生IP数据报碎片。
Small IP datagrams are likely to expand as a result of compression. Therefore, a numeric threshold should be applied before compression, where IP datagrams of size smaller than the threshold are sent in the original form without attempting compression. The numeric threshold is implementation dependent.
小型IP数据报可能由于压缩而扩展。因此，在压缩之前应应用数字阈值，其中大小小于阈值的IP数据报以原始形式发送，而不尝试压缩。数字阈值取决于实现。
An IP datagram with payload that has been previously compressed tends not to compress any further. The previously compressed payload may be the result of external processes, such as compression applied by an upper layer in the communication stack, or by an off-line compression utility. An adaptive algorithm should be implemented to avoid the performance hit. For example, if the compression of i consecutive IP datagrams of an IPCA fails, the next k IP datagrams are sent without attempting compression. If the next j datagrams are also failing to compress, the next k+n datagrams are sent without attempting compression. Once a datagram is compressed successfully, the normal process of IPComp restarts. Such an adaptive algorithm, including all the related thresholds, is implementation dependent.
具有先前已压缩的有效负载的IP数据报倾向于不再进一步压缩。先前压缩的有效载荷可以是外部处理的结果，例如由通信堆栈中的上层或由离线压缩实用程序应用的压缩。应实施自适应算法以避免性能受到影响。例如，如果IPCA的i个连续IP数据报的压缩失败，则发送下一个k个IP数据报而不尝试压缩。如果下一个j数据报也无法压缩，则发送下一个k+n数据报而不尝试压缩。数据报成功压缩后，IPComp的正常进程将重新启动。这种自适应算法（包括所有相关阈值）依赖于实现。
During the processing of the payload, the compression algorithm MAY periodically apply a test to determine the compressibility of the processed data, similar to the requirements of [V42BIS]. The nature of the test is algorithm dependent. Once the compression algorithm detects that the data is non-compressible, the algorithm SHOULD stop processing the data, and the payload is sent in the original non-compressed form.
在有效载荷处理期间，压缩算法可定期应用测试，以确定处理数据的可压缩性，类似于[V42BIS]的要求。测试的性质取决于算法。一旦压缩算法检测到数据不可压缩，该算法应停止处理数据，并以原始非压缩形式发送有效负载。
A compressed IP datagram is encapsulated by modifying the IP header and inserting an IPComp header immediately preceding the compressed payload. This section defines the IP header modifications both in IPv4 and IPv6, and the structure of the IPComp header.
压缩IP数据报通过修改IP报头并在压缩有效负载之前插入IPComp报头进行封装。本节定义了IPv4和IPv6中的IP报头修改，以及IPComp报头的结构。
The following IPv4 header fields are set before transmitting the compressed IP datagram:
在传输压缩的IP数据报之前设置以下IPv4标头字段：
Total Length
全长
The length of the entire encapsulated IP datagram, including the IP header, the IPComp header and the compressed payload.
整个封装IP数据报的长度，包括IP报头、IPComp报头和压缩有效负载。
Protocol
协议
The Protocol field is set to 108, IPComp Datagram, [RFC-1700].
协议字段设置为108，IPComp数据报[RFC-1700]。
Header Checksum
报头校验和
The Internet Header checksum [RFC-0791] of the IP header.
IP报头的Internet报头校验和[RFC-0791]。
All other IPv4 header fields are kept unchanged, including any header options.
所有其他IPv4标头字段保持不变，包括任何标头选项。
The following IPv6 header fields are set before transmitting the compressed IP datagram:
在传输压缩的IP数据报之前，设置以下IPv6标头字段：
Payload Length
净荷长度
The length of the compressed IP payload.
压缩IP有效负载的长度。
Next Header
下一包头
The Next Header field is set to 108, IPComp Datagram, [RFC-1700].
下一个报头字段设置为108，IPComp数据报[RFC-1700]。
All other IPv6 header fields are kept unchanged, including any non-compressed header options.
所有其他IPv6标头字段保持不变，包括任何非压缩标头选项。
The IPComp header is placed in an IPv6 packet using the same rules as the IPv6 Fragment Header. However if an IPv6 packet contains both an IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header MUST precede the IPComp header in the packet.
IPComp头使用与IPv6片段头相同的规则放置在IPv6数据包中。但是，如果IPv6数据包同时包含IPv6片段头和IPComp头，则IPv6片段头必须位于数据包中IPComp头之前。
The four-octet header has the following structure:
四个八位字节头具有以下结构：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Flags | Compression Parameter Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Flags | Compression Parameter Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
下一包头
8-bit selector. Stores the IPv4 Protocol field or the IPv6 Next Header field of the original IP header.
8位选择器。存储原始IP标头的IPv4协议字段或IPv6下一个标头字段。
Flags
旗帜
8-bit field. Reserved for future use. MUST be set to zero. MUST be ignored by the receiving node.
8位字段。保留供将来使用。必须设置为零。接收节点必须忽略。
Compression Parameter Index (CPI)
压缩参数指数（CPI）
16-bit index. The CPI is stored in network order. The values 0-63 define well-known compression algorithms, which require no additional information, and are used for manual setup. The values themselves are identical to IPCOMP Transform identifiers as defined in [SECDOI]. Consult [SECDOI] for an initial set of defined values and for instructions on how to assign new values. The values 64-255 are reserved for future use. The values 256-61439 are negotiated between the two nodes in definition of an IPComp Association, as defined in section 4. Note: When negotiating one of the well-known algorithms, the nodes MAY select a CPI in the pre-defined range 0-63. The values 61440-65535 are for private use among mutually consenting parties. Both nodes participating can select a CPI value independently of each other and there is no relationships between the two separately chosen CPIs. The outbound IPComp header MUST use the CPI value chosen by the decompressing node. The CPI in combination with the destination IP address uniquely identifies the compression algorithm characteristics for the datagram.
16位索引。CPI按网络顺序存储。值0-63定义了众所周知的压缩算法，该算法不需要额外信息，用于手动设置。这些值本身与[SECDOI]中定义的IPCOMP转换标识符相同。有关定义值的初始集以及如何分配新值的说明，请参阅[SECDOI]。值64-255保留供将来使用。值256-61439在第4节定义的IPComp关联的两个节点之间协商。注意：当协商一个众所周知的算法时，节点可以选择预定义范围0-63内的CPI。价值61440-65535供双方同意的各方私人使用。参与的两个节点可以彼此独立地选择CPI值，并且两个单独选择的CPI之间没有关系。出站IPComp标头必须使用解压缩节点选择的CPI值。CPI结合目标IP地址唯一地标识数据报的压缩算法特征。
To utilize the IPComp protocol, two nodes MUST first establish an IPComp Association (IPCA) between them. The IPCA includes all required information for the operation of IPComp, including the Compression Parameter Index (CPI), the mode of operation, the compression algorithm to be used, and any required parameter for the selected compression algorithm. The IPComp mode of operation is either a node-to-node policy where IPComp is applied to every IP packet between the nodes, or an ULP session based policy where only selected ULP sessions between the nodes are using IPComp. For each IPCA, a different compression algorithm may be negotiated in each direction, or only one direction may be compressed. The default is "no IPComp compression".
要使用IPComp协议，两个节点必须首先在它们之间建立IPComp关联（IPCA）。IPCA包括IPComp操作所需的所有信息，包括压缩参数指数（CPI）、操作模式、要使用的压缩算法以及所选压缩算法所需的任何参数。IPComp操作模式是一种节点到节点策略，其中IPComp应用于节点之间的每个IP数据包，或者是一种基于ULP会话的策略，其中只有节点之间选定的ULP会话使用IPComp。对于每个IPCA，可以在每个方向上协商不同的压缩算法，或者只能压缩一个方向。默认值为“无IPComp压缩”。
The IPCA is established by dynamic negotiations or by manual configuration. The dynamic negotiations SHOULD use the Internet Security Association and Key Management Protocol [ISAKMP], where IPSec is present. The dynamic negotiations MAY be implemented through a different protocol.
IPCA通过动态协商或手动配置建立。动态协商应使用Internet安全关联和密钥管理协议[ISAKMP]，其中存在IPSec。动态协商可以通过不同的协议来实现。
For IPComp in the context of IP Security, ISAKMP provides the necessary mechanisms to establish IPCA. IPComp Association is negotiated by the initiator using a Proposal Payload, which would
对于IP安全上下文中的IPComp，ISAKMP提供了建立IPCA的必要机制。IPComp关联由发起方使用建议有效负载进行协商，这将
include one or more Transform Payloads. The Proposal Payload would specify a compression protocol in the protocol id field and each Transform Payload would contain the specific compression method(s) being offered to the responder.
包括一个或多个变换有效载荷。建议有效载荷将在协议id字段中指定压缩协议，并且每个转换有效载荷将包含提供给响应者的特定压缩方法。
In the Internet IP Security Domain of Interpretation (DOI), IPComp is negotiated as the Protocol ID PROTO_IPCOMP. The compression algorithm is negotiated as one of the defined IPCOMP Transform Identifiers.
在Internet IP安全解释域（DOI）中，IPComp被协商为协议ID PROTO_IPComp。压缩算法作为定义的IPCOMP转换标识符之一进行协商。
The dynamic negotiations MAY be implemented through a protocol other than ISAKMP. Such protocol is beyond the scope of this document.
动态协商可以通过ISAKMP以外的协议实现。此类协议超出了本文件的范围。
Nodes may establish IPComp Associations using manual configuration. For this method, a limited number of Compression Parameters Indexes (CPIs) is designated to represent a list of specific compression methods.
节点可以使用手动配置建立IPComp关联。对于该方法，指定数量有限的压缩参数索引（CPI）来表示特定压缩方法的列表。
When IPComp is used in the context of IPSec, it is believed not to have an effect on the underlying security functionality provided by the IPSec protocol; i.e., the use of compression is not known to degrade or alter the nature of the underlying security architecture or the encryption technologies used to implement it.
当IPComp在IPSec的上下文中使用时，人们认为它不会对IPSec协议提供的底层安全功能产生影响；i、 例如，不知道使用压缩会降低或改变底层安全体系结构或用于实现它的加密技术的性质。
When IPComp is used without IPSec, IP payload compression potentially reduces the security of the Internet, similar to the effects of IP encapsulation [RFC-2003]. For example, IPComp may make it difficult for border routers to filter datagrams based on header fields. In particular, the original value of the Protocol field in the IP header is not located in its normal positions within the datagram, and any transport layer header fields within the datagram, such as port numbers, are neither located in their normal positions within the datagram nor presented in their original values after compression. A filtering border router can filter the datagram only if it shares the IPComp Association used for the compression. To allow this sort of compression in environments in which all packets need to be filtered (or at least accounted for), a mechanism must be in place for the receiving node to securely communicate the IPComp Association to the border router. This might, more rarely, also apply to the IPComp Association used for outgoing datagrams.
如果在没有IPSec的情况下使用IPComp，IP有效负载压缩可能会降低Internet的安全性，类似于IP封装的效果[RFC-2003]。例如，IPComp可能使边界路由器难以根据报头字段过滤数据报。特别地，IP报头中的协议字段的原始值不位于其在数据报中的正常位置，并且数据报中的任何传输层报头字段，例如端口号，既不位于其在数据报中的正常位置，也不在压缩后以其原始值呈现。过滤边界路由器只能在共享用于压缩的IPComp关联时过滤数据报。为了在需要过滤（或至少说明）所有数据包的环境中允许这种压缩，必须为接收节点提供一种机制，以便将IPComp关联安全地传送到边界路由器。这可能（很少）也适用于用于传出数据报的IPComp关联。
[RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC-0791]Postel，J.，编辑，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. Or see:
http://www.iana.org/numbers.html
[RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. Or see:
http://www.iana.org/numbers.html
[RFC-2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[RFC-1962]兰德博士，“PPP压缩控制协议（CCP）”，RFC 1962，1996年6月。
[RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC-2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[ISAKMP]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[SECDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[SECDOI]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[V42BIS] CCITT, "Data Compression Procedures for Data Circuit Terminating Equipment (DCE) Using Error Correction Procedures", Recommendation V.42 bis, January 1990.
[V42BIS]CCITT，“使用纠错程序的数据电路终端设备（DCE）的数据压缩程序”，建议V.42之二，1990年1月。
Authors' Addresses
作者地址
Abraham Shacham Cisco Systems 170 West Tasman Drive San Jose, California 95134 United States of America
美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: shacham@cisco.com
EMail: shacham@cisco.com
Robert Monsour Hi/fn Inc. 2105 Hamilton Avenue, Suite 230 San Jose, California 95125 United States of America
Robert Monsour Hi/fn Inc.美国加利福尼亚州圣何塞市汉密尔顿大道2105号230室95125
EMail: rmonsour@hifn.com
EMail: rmonsour@hifn.com
Roy Pereira TimeStep Corporation 362 Terry Fox Drive Kanata, Ontario K2K 2P5 Canada
Roy Pereira TimeStep Corporation 362 Terry Fox Drive Kanata，加拿大安大略省K2K 2P5
EMail: rpereira@timestep.com
EMail: rpereira@timestep.com
Matt Thomas AltaVista Internet Software 30 Porter Road Littleton, Massachusetts 01460 United States of America
Matt Thomas AltaVista互联网软件美国马萨诸塞州利特尔顿波特路30号01460
EMail: matt.thomas@altavista-software.com
EMail: matt.thomas@altavista-software.com
Working Group
工作组
The IP Payload Compression Protocol (IPPCP) working group can be contacted through its chair:
IP有效负载压缩协议（IPPCP）工作组可通过其主席联系：
Naganand Dorswamy Bay Networks
纳加南多斯瓦米湾网络
EMail: naganand@baynetworks.com
EMail: naganand@baynetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。