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)
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.
この文書は、インターネット環境でインターネットプロトコルデータグラムのためのロスレス圧縮を提供することを目的としたプロトコルについて説明します。
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.
この文書は、IPCAを交渉するIPペイロード圧縮プロトコル（のIPComp）のIPCompパケット構造のIPCompアソシエーション（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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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データグラムの圧縮処理は2つの段階があります。圧縮処理は、圧縮と解凍された後、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.
セクション2.2で定義されたインバウンドIPデータグラムの処理は、非拡張ポリシーの要件を満たすために、両方の圧縮と非圧縮IPデータグラムをサポートしなければなりません。
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:
以下のIPv4ヘッダフィールドは圧縮されたIPデータグラムを送信する前に設定されています。
Total Length
全長
The length of the entire encapsulated IP datagram, including the IP header, the IPComp header and the compressed payload.
全体の長さは、IPヘッダ、IPCompヘッダと圧縮ペイロードを含む、IPデータグラムをカプセル化。
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ヘッダのインターネットヘッダチェックサム[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:
次のIPv6ヘッダーフィールドは、圧縮されたIPデータグラムを送信する前に設定されています。
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ヘッダーは、IPv6フラグメントヘッダとIPCompヘッダとの間に存在してもよいです。
The four-octet header has the following structure:
4オクテットのヘッダは、以下の構造を有します。
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ビットセレクタ。記憶のIPv4プロトコルフィールドまたは元のIPヘッダの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は、将来の使用のために予約されています。周知のアルゴリズムのいずれかを交渉する場合、ノードは、事前定義された範囲0-でCPIを選択してもよい。部4注で定義された値256から61439は、のIPCompアソシエーションの定義内の2つのノード間で交渉されています63。値は61440から65535は、互いに同意当事者間の私的使用のためのものです。両方のノードは、互いに独立してCPI値を選択することができ、参加二つ別々に選択されたのCPIとの間には関係がありません。アウトバウンドIPCompヘッダが伸張ノードによって選択されたCPI値を使用しなければなりません。宛先IPアドレスとの組み合わせでCPIが一意のデータグラムのための圧縮アルゴリズムの特性を識別する。
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プロトコルを利用するために、2つのノードは最初、それらの間のIPCompアソシエーション（IPCA）を確立しなければなりません。 IPCAは、圧縮アルゴリズムが、使用される圧縮パラメータインデックス（CPI）、動作モードなどのIPCompの動作のために必要なすべての情報を含み、選択された圧縮アルゴリズムのための任意の必要なパラメータ。
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.
2つのノードがいずれかまたは両方の方向での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が存在しているインターネット鍵交換プロトコル[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協会は、一つ以上のトランスフォームペイロードを含むプロポーザルペイロードを使用して、イニシエータによってネゴシエートされます。 Proposalペイロードは、プロトコル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ビット数、あるいは2に設定SPIサイズフィールドと、CPIは、この場合には4に設定SPIサイズフィールドと、32ビット値として送信され、16として送信されるべきですビットCPIの数は2つの最も重要なオクテットはゼロに設定する必要がありますが、SPIフィールドの2つの最下位オクテットに配置する必要があり、受信ノードによって無視されなければなりません。受信ノードは、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.
解釈のインターネット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に関係のない保護Suiteの他のプロトコルの属性が含まれていないための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を提供することができる - 各単一変換ペイロードを含まなければなりません。明確にする：Proposalペイロードが二つ以上のトランスフォームペイロードが含まれている場合は、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セッションが2つのノード間で確立され、そして同一の周知のCPIがセッションの少なくとも二つで使用される場合IPCAs非ユニークになります。非固有IPCAs各IPCAに固有の属性、のいずれかでネゴシエート（例えば、寿命）または内部（以前に圧縮されたペイロードを処理する適応アルゴリズムの例えば、カウンタ）を維持することに問題を提起します。 IPCAsの2つ以上が同じ圧縮アルゴリズムを使用する場合、2つのノード間のIPCAsの一意性を保証するために、のCPIは、ネゴシエート範囲であるべきです。 IPCAs無し属性がこれらIPCAsに利用されていない場合、例えば、一意であることが要求されない場合しかし、よく知られたCPIを使用することができます。明確にする：特定のよく知られたCPIを使用して単一のセッションが2つのノード間で確立されると、この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プロトコルによって提供される基本的なセキュリティ機能に影響を与えることはないと考えられています。すなわち、圧縮の使用は基本的なセキュリティアーキテクチャの性質や、それを実現するために使用される暗号化技術を分解または変更することが知られていません。
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 (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がIPsecのなしで使用されている場合、IPペイロード圧縮は、潜在的にIPカプセル化[RFC2003]の効果と同様、インターネットのセキュリティを、減らします。例えば、のIPCompが困難境界ルータは、ヘッダフィールドに基づいてデータグラムをフィルタリングするために作ることができます。具体的には、IPヘッダのプロトコルフィールドの元の値は、データグラム内のその通常の位置に配置されていない、およびポート番号など、データグラム内の任意のトランスポート層ヘッダフィールドは、いずれもデータグラム内でそれらの通常の位置に配置されています圧縮後に元の値に提示。フィルタリング境界ルータは、それが圧縮のために使用されるIPComp協会を共有する場合にのみ、データグラムを絞り込むことができます。すべてのパケットがフィルタリング（または少なくとも会計処理）する必要のある環境での圧縮のこの種のを可能にするために、機構が確実ボーダールータへの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は、スタンドアローンで交渉または保護Suiteの他のプロトコルにバンドルすることができることを明確化を追加しました。
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を定義：2オクテットフィールドはSHOULD、4オクテットMAYです。 4オクテットフィールド内の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には適用されません保護Suiteの変換の属性の取り扱いを指定：これらの属性は、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]ポステル、J.、エディタ、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. Or see: http://www.iana.org/numbers.html
[RFC1700]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月または参照：http://www.iana.org/numbers.html
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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）"、RFC 1962、1996年6月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[SECDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[SECDOI]パイパー、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.
、勧告V.42ビス、1990年1月[V42BIS] CCITT、「エラー訂正手順を使用してデータ回線終端装置のためのデータ圧縮手順（DCE）」。
Authors' Addresses
著者のアドレス
Abraham Shacham Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, California 94089 United States of America
アブラハムShachamジュニパーネットワークス株式会社1194北マチルダアベニューアメリカのサニーベール、カリフォルニア94089米国
EMail: shacham@shacham.net
メールアドレス：shacham@shacham.net
Bob Monsour 18 Stout Road Princeton, New Jersey 08540 United States of America
ボブMonsour 18スタウト道路プリンストン、ニュージャージーアメリカの08540米国
EMail: bob@bobmonsour.com
メールアドレス：bob@bobmonsour.com
Roy Pereira Cisco Systems, Inc. 55 Metcalfe Street Ottawa, Ontario K1P 6L5 Canada
ロイ・ペレイラシスコシステムズ社55メトカーフストリートオタワ、オンタリオK1P 6L5カナダ
EMail: royp@cisco.com
メールアドレス：royp@cisco.com
Matt Thomas 3am Software Foundry 8053 Park Villa Circle Cupertino, California 95014 United States of America
マット・トーマス午前3時ソフトウェアファウンドリーアメリカの8053パークヴィラサークルクパチーノ、カリフォルニア95014米国
EMail: matt@3am-software.com
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。