[要約] RFC 3173は、IPComp（IP Payload Compression Protocol）に関する規格であり、IPパケットのペイロードを圧縮するためのプロトコルです。その目的は、ネットワークの帯域幅を節約し、通信の効率を向上させることです。
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、IPペイロード圧縮プロトコル（IPComp）、IPCompパケット構造、IPComp Association（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].
この文書のキーワード "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データグラムは、他のデータグラム（「Stateless Compression」）との関係なしにそれ自体によって圧縮および減圧されています。各圧縮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データグラムの処理は、セクション2.2で定義されているように、非拡張ポリシー要件を満たすために、圧縮および非圧縮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データグラムのULPペイロードに継続する場合、パケットの配信パスに沿ってノードで処理する必要がある情報を掲載しない情報を運ばない最初のIPヘッダーオプションフィールドから圧縮が適用されます。。
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 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.
セクション3で定義されている圧縮ペイロードとIPCompヘッダーの合計サイズが元のペイロードのサイズよりも小さくない場合、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 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ヘッダー、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:
圧縮された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:
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ビットセレクター。元の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 Associationの定義の2つのノード間でネゴシエートされます。注：有名なアルゴリズムの1つを交渉する場合、ノードは事前定義範囲0-でCPIを選択できます。63。値61440-65535は、相互に同意する当事者の間で私的に使用するためのものです。参加する両方のノードは、互いに独立してCPI値を選択でき、2つの個別に選択された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 Association（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アソシエーションは、1つ以上の変換ペイロードを含む提案ペイロードを使用して、イニシエーターによって交渉されます。提案のペイロードは、プロトコル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は16-bit CPI数は、SPIフィールドの2つの最も重要なオクテットに配置する必要がありますが、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変換識別子の1つとしてネゴシエートされます。
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を提供する場合があります。2つ以上の変換ペイロードを提案する場合、ノードは複数のIPCOMP提案を使用して事前定義された範囲でCPIを提供する場合があります。それぞれには単一の変換ペイロードが含まれている必要があります。明確にするために：提案ペイロードに2つ以上の変換ペイロードが含まれている場合、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.
IPCAは、2つのノードの間に2つ以上のIPCompセッションが確立されると非不合理になり、少なくとも2つのセッションで同じよく知られたCPIが使用されます。非ユニークIPCAは、各IPCAに固有の属性を維持する際に問題を引き起こします。2つのノード間のIPCAの一意性を確保するために、2つ以上のIPCAが同じ圧縮アルゴリズムを使用する場合、CPIは交渉範囲にある必要があります。ただし、IPCAが一意である必要がない場合、たとえばこれらのIPCAに属性が使用されていない場合、よく知られているCPIが使用される場合があります。明確にするために：2つのノードの間に特定の有名なCPIを使用した1つのセッションのみが確立されている場合、この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 Associationを共有する場合にのみ、データグラムをフィルタリングできます。すべてのパケットをフィルター処理する（または少なくとも説明する）環境でこの種の圧縮を可能にするには、受信ノードがIPCOMPアソシエーションをボーダールーターに安全に通信するためのメカニズムを整える必要があります。これは、よりめったに、発信データグラムに使用されるIPComp Associationにも適用される可能性があります。
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を定義しました：2オクテットフィールドは、5月に4オクテットです。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) サポートされている属性のリストにLifetime属性を追加しました（輸送モードとともに）。
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 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] Reynolds、J。and J. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[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] Rand、D。、「PPP圧縮制御プロトコル（CCP）」、RFC 1962、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、「The Internet Key Exchange（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 BIS、1990年1月。
Authors' Addresses
著者のアドレス
Abraham Shacham Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, California 94089 United States of America
Abraham Shacham Juniper Networks、Inc。1194 North Mathilda Avenue Sunnyvale、California 94089アメリカ合衆国アメリカ
EMail: shacham@shacham.net
Bob Monsour 18 Stout Road Princeton, New Jersey 08540 United States of America
ボブ・モンスール18スタウトロードプリンストン、ニュージャージー08540アメリカ合衆国アメリカ
EMail: bob@bobmonsour.com
Roy Pereira Cisco Systems, Inc. 55 Metcalfe Street Ottawa, Ontario K1P 6L5 Canada
Roy Pereira Cisco Systems、Inc。55 Metcalfe Street Ottawa、オンタリオK1P 6L5カナダ
EMail: royp@cisco.com
Matt Thomas 3am Software Foundry 8053 Park Villa Circle Cupertino, California 95014 United States of America
Matt Thomas 3am Software Foundry 8053 Park Villa Circle Cupertino、カリフォルニア95014アメリカ合衆国アメリカ
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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。