Network Working Group A. Shacham
Request for Comments: 3173 Juniper
Obsoletes: 2393 B. Monsour
Category: Standards Track Consultant
R. Pereira
Cisco
M. Thomas
Consultant
September 2001
Network Working Group A. Shacham
Request for Comments: 3173 Juniper
Obsoletes: 2393 B. Monsour
Category: Standards Track Consultant
R. Pereira
Cisco
M. Thomas
Consultant
September 2001
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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 [RFC1962]) ineffective. If both compression and encryption are required, compression must be applied before encryption.
当对IP数据报应用加密时，IP有效负载压缩特别有用。加密IP数据报会导致数据本质上是随机的，从而导致较低协议层（例如PPP压缩控制协议[RFC1962]）的压缩无效。如果同时需要压缩和加密，则必须在加密之前应用压缩。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
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 [RFC2460], 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[RFC2460]中，出站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 [RFC0791], the compression is applied to the payload of the IP datagram, starting at the first octet following the IP header, and continuing through the last octet of the datagram. No portion of the IP header or the IP header options is compressed. Note: In the case of an encapsulated IP header (e.g., tunnel mode encapsulation in IPsec), the datagram payload is defined to start immediately after the outer IP header; accordingly, the inner IP header is considered part of the payload and is compressed.
在IP版本4[RFC0791]中，压缩应用于IP数据报的有效负载，从IP报头后的第一个八位字节开始，一直到数据报的最后一个八位字节。没有压缩IP头或IP头选项的任何部分。注意：对于封装的IP报头（例如，IPsec中的隧道模式封装），数据报有效负载定义为在外部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 an 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 payload and the IPComp header, as defined in section 3, is not smaller than the size of the original payload, the IP datagram MUST be sent in the original non-compressed form. To clarify: If an IP datagram is sent non-compressed, no
如果第3节中定义的压缩有效负载和IPComp报头的总大小不小于原始有效负载的大小，则必须以原始非压缩形式发送IP数据报。澄清：如果IP数据报以非压缩方式发送，则不会
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 the MTU.
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 several IP datagrams, say k, are sent without attempting compression. If then the next j datagrams also fail to compress, a larger number of datagrams, say k+n, 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数据报的压缩失败，则在不尝试压缩的情况下发送下几个IP数据报，例如k。如果接下来的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, [RFC1700].
协议字段设置为108，IPComp数据报[RFC1700]。
Header Checksum
报头校验和
The Internet Header checksum [RFC0791] of the IP header.
IP报头的Internet报头校验和[RFC0791]。
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, [RFC1700].
下一个报头字段设置为108，IPComp数据报[RFC1700]。
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. Note: Other IPv6 headers may be present between the IPv6 Fragment Header and the IPComp header.
IPComp头使用与IPv6片段头相同的规则放置在IPv6数据包中。但是，如果IPv6数据包同时包含IPv6片段头和IPComp头，则IPv6片段头必须位于数据包中IPComp头之前。注意：IPv6片段头和IPComp头之间可能存在其他IPv6头。
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 designate 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 relationship 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.
要使用IPComp协议，两个节点必须首先在它们之间建立IPComp关联（IPCA）。IPCA包括IPComp操作所需的所有信息，包括压缩参数指数（CPI）、操作模式、要使用的压缩算法以及所选压缩算法所需的任何参数。
The policy for establishing IPComp may be either a node-to-node policy where IPComp is applied to every IP packet between the nodes, or a session-based policy where only selected sessions between the nodes employ IPComp.
用于建立IPComp的策略可以是节点到节点策略，其中IPComp应用于节点之间的每个IP分组，或者是基于会话的策略，其中仅节点之间的选定会话使用IPComp。
Two nodes may choose to negotiate IPComp in either or both directions, and they may choose to employ a different compression algorithm in each direction. The nodes MUST, however, negotiate a compression algorithm in each direction for which they establish an IPCA: there is no default compression algorithm.
两个节点可以选择在任一或两个方向协商IPComp，并且可以选择在每个方向使用不同的压缩算法。但是，节点必须在其建立IPCA的每个方向协商压缩算法：没有默认的压缩算法。
No compression algorithm is mandatory for an IPComp implementation.
IPComp实现不强制使用压缩算法。
The IPCA is established by dynamic negotiations or by manual configuration. The dynamic negotiations SHOULD use the Internet Key Exchange protocol [IKE], where IPsec is present. The dynamic negotiations MAY be implemented through a different protocol.
IPCA通过动态协商或手动配置建立。动态协商应使用存在IPsec的Internet密钥交换协议[IKE]。动态协商可以通过不同的协议来实现。
For IPComp in the context of IP Security, IKE provides the necessary mechanisms and guidelines for establishing IPCA. Using IKE, IPComp can be negotiated as stand-alone or in conjunction with other IPsec protocols.
对于IP安全上下文中的IPComp，IKE为建立IPCA提供了必要的机制和指南。使用IKE，IPComp可以作为独立协议或与其他IPsec协议一起协商。
An IPComp Association is negotiated by the initiator using a Proposal Payload, which includes one or more Transform Payloads. The Proposal Payload specifies the IP Payload Compression Protocol in the protocol ID field and each Transform Payload contains the specific compression algorithm(s) being offered to the responder.
IPComp关联由发起方使用建议有效负载进行协商，建议有效负载包括一个或多个转换有效负载。提案有效负载在协议ID字段中指定IP有效负载压缩协议，每个转换有效负载包含提供给响应者的特定压缩算法。
The CPI is sent in the SPI field of the proposal, with the SPI size field set to match. The CPI SHOULD be sent as a 16-bit number, with the SPI size field set to 2. Alternatively, the CPI MAY be sent as a 32-bit value, with the SPI size field set to 4. In this case, the 16-bit CPI number MUST be placed in the two least significant octets of the SPI field, while the two most significant octets MUST be set to zero, and MUST be ignored by the receiving node. The receiving node MUST be able to process both forms of the CPI proposal.
CPI在建议书的SPI字段中发送，SPI大小字段设置为匹配。CPI应作为16位数字发送，SPI大小字段设置为2。或者，CPI可以作为32位值发送，SPI大小字段设置为4。在这种情况下，16位CPI编号必须放在SPI字段的两个最低有效八位字节中，而两个最高有效八位字节必须设置为零，并且必须被接收节点忽略。接收节点必须能够处理两种形式的CPI提案。
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 following attributes are applicable to IPComp proposals:
以下属性适用于IPComp提案：
Encapsulation Mode
封装模式
To propose a non-default Encapsulation Mode (such as Tunnel Mode), an IPComp proposal MUST include an Encapsulation Mode attribute. If the Encapsulation Mode is unspecified, the default value of Transport Mode is assumed.
要提出非默认封装模式（如隧道模式），IPComp方案必须包含封装模式属性。如果封装模式未指定，则假定默认值为传输模式。
Lifetime
一生
An IPComp proposal uses the Life Duration and Life Type attributes to suggest life duration to the IPCA.
IPComp提案使用寿命和寿命类型属性向IPCA建议寿命。
When IPComp is negotiated as part of a Protection Suite, all the logically related offers must be consistent. However, an IPComp proposal SHOULD NOT include attributes that are not applicable to IPComp. An IPComp proposal MUST NOT be rejected because it does not include attributes of other protocols in the Protection Suite that are not relevant to IPComp. When an IPComp proposal includes such attributes, those attributes MUST be ignored when setting the IPCA, and therefore ignored in the operation of IPComp.
当IPComp作为保护套件的一部分进行协商时，所有逻辑相关的报价必须一致。但是，IPComp提案不应包含不适用于IPComp的属性。不得拒绝IPComp提案，因为它不包括保护套件中与IPComp无关的其他协议的属性。当IPComp提案包含此类属性时，在设置IPCA时必须忽略这些属性，因此在IPComp的操作中必须忽略这些属性。
Implementation note:
实施说明：
A node can avoid the computation necessary for determining the compression algorithm from the CPI if it is using one of the well-known algorithms; this can save time in the decompression process. A node can do this by negotiating a CPI equal in value to the pre-defined Transform identifier of that compression algorithm. Specifically: A node MAY offer a CPI in the pre-defined range by sending a Proposal Payload that MUST contain a single Transform Payload, which is identical to the CPI. When proposing two or more Transform Payloads, a node MAY offer CPIs in the pre-defined range by using multiple IPComp proposals -- each MUST include a single Transform Payload. To clarify: If a Proposal Payload contains two or more Transform Payloads, the CPI MUST be in the negotiated range. A receiving node MUST be able to process each of these proposal forms.
如果节点使用已知算法之一，则可以避免从CPI确定压缩算法所需的计算；这可以节省解压缩过程中的时间。节点可以通过协商CPI值等于该压缩算法的预定义变换标识符来实现这一点。具体地说：节点可以通过发送必须包含与CPI相同的单个变换有效载荷的提议有效载荷来提供预定义范围内的CPI。当建议两个或多个转换有效负载时，节点可以通过使用多个IPComp建议来提供预定义范围内的CPI——每个建议必须包括单个转换有效负载。澄清：如果提案有效载荷包含两个或多个变换有效载荷，则CPI必须在协商范围内。接收节点必须能够处理这些提案表单中的每一个。
Implementation note:
实施说明：
IPCAs become non-unique when two or more IPComp sessions are established between two nodes, and the same well-known CPI is used in at least two of the sessions. Non-unique IPCAs pose problems in maintaining attributes specific to each IPCA, either negotiated (e.g., lifetime) or internal (e.g., the counters of the adaptive algorithm for handling previously compressed payload). To ensure the uniqueness of IPCAs between two nodes, when two or more of the IPCAs use the same compression algorithm, the CPIs SHOULD be in the negotiated range. However, when the IPCAs are not required to be unique, for example when no attribute is being utilized for these IPCAs, a well-known CPI MAY be used. To clarify: When only a single session using a particular well-known CPI is established between two nodes, this IPCA is unique.
当在两个节点之间建立两个或多个IPComp会话，并且在至少两个会话中使用相同的众所周知的CPI时，IPCA将变得非唯一。非唯一的IPCA在维护每个IPCA的特定属性方面存在问题，这些属性可以是协商的（例如，生存期）属性，也可以是内部属性（例如，用于处理先前压缩的有效负载的自适应算法的计数器）。为确保两个节点之间IPCA的唯一性，当两个或多个IPCA使用相同的压缩算法时，CPI应在协商范围内。然而，当不要求ipca是唯一的时，例如当没有为这些ipca使用属性时，可以使用众所周知的CPI。澄清一下：当在两个节点之间仅建立使用特定已知CPI的单个会话时，此IPCA是唯一的。
The dynamic negotiations MAY be implemented through a protocol other than IKE. Such a protocol is beyond the scope of this document.
动态协商可以通过IKE以外的协议来实现。这种协议超出了本文件的范围。
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 [RFC2003]. 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
如果在没有IPsec的情况下使用IPComp，IP有效负载压缩可能会降低Internet的安全性，类似于IP封装的效果[RFC2003]。例如，IPComp可能使边界路由器难以根据报头字段过滤数据报。特别地，IP报头中的协议字段的原始值不位于其在数据报中的正常位置，并且数据报中的任何传输层报头字段，例如端口号，既不位于其在数据报中的正常位置，也不在压缩后以其原始值呈现。过滤边界路由器只能在共享用于压缩的IPComp关联时过滤数据报。在需要过滤所有数据包的环境中允许这种压缩
(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.
（或至少考虑到这一点），接收节点必须有一种机制来安全地将IPComp关联与边界路由器通信。这可能（很少）也适用于用于传出数据报的IPComp关联。
This document does not require any IANA actions. The well-known numbers used in this document are defined elsewhere; see [SECDOI].
本文件不要求IANA采取任何行动。本文件中使用的知名编号在其他地方有定义；见[SECDOI]。
This section summarizes the changes in this document from RFC 2393 of which an implementer of RFC 2393 should be aware. All the changes are meant to clarify the negotiation of an IPComp Association (IPCA) using IKE [IKE] in the context of IPsec.
本节总结了RFC 2393在本文档中的更改，RFC 2393的实施者应该了解这些更改。所有这些更改都是为了澄清在IPsec上下文中使用IKE[IKE]的IPComp关联（IPCA）的协商。
1) Added a clarification that IPComp can be negotiated stand-alone or bundled with other protocols in a Protection Suite.
1) 增加了一项澄清，即IPComp可以单独协商，也可以与保护套件中的其他协议捆绑。
2) Defined the CPI in the SPI field of an IKE proposal: two-octet field is a SHOULD, four-octet a MAY. Defined the placement of the 16-bit CPI in a four-octet field. Specified that a receiver MUST process both field sizes.
2) 在IKE提案的SPI字段中定义了CPI：两个八位组字段为宜，四个八位组为可。定义了16位CPI在四个八位组字段中的位置。指定接收器必须处理两个字段大小。
3) Added wording to define the default Encapsulation Mode to be Transport Mode. Required that an IPComp proposal MUST include an Encapsulation Mode attribute when it suggests a non-default encapsulation, such as Tunnel Mode.
3) 添加了将默认封装模式定义为传输模式的措辞。要求IPComp提案在建议非默认封装（如隧道模式）时必须包含封装模式属性。
4) Added the Lifetime attribute to the list of supported attributes (along with Transport Mode).
4) 将生存期属性添加到支持的属性列表中（以及传输模式）。
5) Specified the handling of attributes of transforms in a Protection Suite that are not applicable to IPComp: These attributes SHOULD NOT be included in an IPComp proposal and MUST be ignored when setting IPCA and in the operation of IPComp. IPComp implementations MUST never reject an IPCOMP proposal that does not include attributes of other transforms.
5) 指定了保护套件中不适用于IPComp的转换属性的处理：这些属性不应包含在IPComp建议中，并且在设置IPCA和IPComp操作时必须忽略。IPComp实现决不能拒绝不包含其他转换属性的IPComp建议。
6) Added implementation notes on the negotiation and usage of CPIs in the predefined (well-known) range.
6) 增加了预定义（众所周知）范围内CPI协商和使用的实施说明。
[RFC0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，编辑，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. Or see:
http://www.iana.org/numbers.html
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. Or see:
http://www.iana.org/numbers.html
[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月。
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[RFC1962]兰德，D.“PPP压缩控制协议（CCP）”，RFC1962，1996年6月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，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 Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, California 94089 United States of America
美国加利福尼亚州桑尼维尔北马蒂尔达大道1194号Abraham Shacham Juniper Networks，Inc.94089
EMail: shacham@shacham.net
EMail: shacham@shacham.net
Bob Monsour 18 Stout Road Princeton, New Jersey 08540 United States of America
美国新泽西州普林斯顿市斯托特路18号鲍勃·蒙苏尔08540
EMail: bob@bobmonsour.com
EMail: bob@bobmonsour.com
Roy Pereira Cisco Systems, Inc. 55 Metcalfe Street Ottawa, Ontario K1P 6L5 Canada
Roy Pereira Cisco Systems，Inc.加拿大安大略省渥太华Metcalfe街55号K1P 6L5
EMail: royp@cisco.com
EMail: royp@cisco.com
Matt Thomas 3am Software Foundry 8053 Park Villa Circle Cupertino, California 95014 United States of America
马特·托马斯3am软件铸造厂8053美国加利福尼亚州库比蒂诺公园别墅圆95014
EMail: matt@3am-software.com
EMail: matt@3am-software.com
Comments
评论
Comments should be addressed to the ippcp@external.cisco.com mailing list and/or the author(s).
评论意见应提交给ippcp@external.cisco.com邮件列表和/或作者。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。