[要約] RFC 2393は、IPComp（IP Payload Compression Protocol）に関する規格であり、IPパケットのペイロードを圧縮するためのプロトコルを定義しています。その目的は、ネットワークの帯域幅を節約し、通信の効率を向上させることです。
Network Working Group A. Shacham
Request for Comments: 2393 Cisco
Category: Standards Track R. Monsour
Hi/fn
R. Pereira
TimeStep
M. Thomas
AltaVista Internet
December 1998
IP Payload Compression Protocol (IPComp)
IPペイロード圧縮プロトコル（IPComp）
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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 [RFC-1962]) ineffective. If both compression and encryption are required, compression MUST be applied before encryption.
IPペイロード圧縮は、暗号化がIPデータグラムに適用される場合に特に役立ちます。 IPデータグラムを暗号化すると、データの性質がランダムになり、下位のプロトコルレイヤーでの圧縮（PPP圧縮制御プロトコル[RFC-1962]など）が無効になります。圧縮と暗号化の両方が必要な場合は、暗号化の前に圧縮を適用する必要があります。
This document defines the IP payload compression protocol (IPComp), the IPComp packet structure, the IPComp Association (IPCA), and several methods to negotiate the IPCA.
このドキュメントでは、IPペイロード圧縮プロトコル（IPComp）、IPCompパケット構造、IPComp 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 [RFC-2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC-2119]で説明されているように解釈されます。
The compression processing of IP datagrams has two phases: compressing of outbound IP datagrams ("compression") and decompressing of inbound datagrams ("decompression"). The compression processing MUST be lossless, ensuring that the IP datagram, after being compressed and decompressed, is identical to the original IP datagram.
IPデータグラムの圧縮処理には、送信IPデータグラムの圧縮（「圧縮」）と受信データグラムの圧縮解除（「解凍」）の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.
インバウンド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 [RFC-2460], the compression of outbound IP datagrams MUST be done before the addition of either a Hop-by-Hop Options header or a Routing Header, since both carry information that must be examined and processed by possibly every node along a packet's delivery path, and therefore MUST be sent in the original form.
発信IPデータグラムの圧縮は、暗号化や認証などのIPセキュリティ処理の前、およびIPデータグラムの断片化の前に実行する必要があります。さらに、IPバージョン6 [RFC-2460]では、送信と送信のIPデータグラムの圧縮は、ホップバイホップオプションヘッダーまたはルーティングヘッダーを追加する前に行わなければなりません。おそらくパケットの配信パスに沿ったすべてのノードによって、したがって、元の形式で送信する必要があります。
Similarly, the decompression of inbound IP datagrams MUST be done after the reassembly of the IP datagrams, and after the completion of all IP security processing, such as authentication and decryption.
同様に、インバウンドIPデータグラムの解凍は、IPデータグラムの再構成後、および認証や復号化などのすべてのIPセキュリティ処理の完了後に行う必要があります。
The compression is applied to a single array of octets, which are contiguous in the IP datagram. This array of octets always ends at the last octet of the IP packet payload. Note: a contiguous array of octets in the IP datagram may be not contiguous in physical memory.
圧縮は、IPデータグラム内で隣接するオクテットの単一の配列に適用されます。このオクテットの配列は、常にIPパケットペイロードの最後のオクテットで終わります。注：IPデータグラム内の連続したオクテット配列は、物理メモリ内で連続していない場合があります。
In IP version 4 [RFC-0791], the compression is applied to the upper layer protocol (ULP) payload of the IP datagram. No portion of the IP header or the IP header options is compressed.
IPバージョン4 [RFC-0791]では、圧縮はIPデータグラムの上位層プロトコル（ULP）ペイロードに適用されます。 IPヘッダーまたはIPヘッダーオプションのどの部分も圧縮されません。
In the IPv6 context, IPComp is viewed as an end-to-end payload, and MUST not apply to hop-by-hop, routing, and fragmentation extension headers. The compression is applied starting at the first IP Header Option field that does not carry information that must be examined and processed by nodes along a packet's delivery path, if such IP Header Option field exists, and continues to the ULP payload of the IP datagram.
IPv6のコンテキストでは、IPCompはエンドツーエンドのペイロードと見なされ、ホップバイホップ、ルーティング、およびフラグメンテーション拡張ヘッダーには適用されません（MUST NOT）。このようなIPヘッダーオプションフィールドが存在する場合、パケットの配信パスに沿ったノードが検査および処理する必要のある情報を含まない最初のIPヘッダーオプションフィールドから圧縮が適用され、IPデータグラムのULPペイロードに続きます。
The size of a compressed payload, generated by the compression algorithm, MUST be in whole octet units.
圧縮アルゴリズムによって生成された圧縮ペイロードのサイズは、全体がオクテット単位でなければなりません。
As defined in section 3, an IPComp header is inserted immediately preceding the compressed payload. The original IP header is modified to indicate the usage of the IPComp protocol and the reduced size of the IP datagram. The original content of the Next Header (IPv6) or protocol (IPv4) field is stored in the IPComp header.
セクション3で定義されているように、IPCompヘッダーは、圧縮されたペイロードの直前に挿入されます。元のIPヘッダーは、IPCompプロトコルの使用とIPデータグラムの縮小サイズを示すように変更されています。次のヘッダー（IPv6）またはプロトコル（IPv4）フィールドの元のコンテンツは、IPCompヘッダーに格納されます。
The decompression is applied to a single contiguous array of octets in the IP datagram. The start of the array of octets immediately follows the IPComp header and ends at the last octet of the IP payload. If the decompression process is successfully completed, the IP header is modified to indicate the size of the decompressed IP datagram, and the original next header as stored in the IPComp header. The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header.
解凍は、IPデータグラム内の単一の連続したオクテット配列に適用されます。オクテットの配列の始まりは、IPCompヘッダーの直後に続き、IPペイロードの最後のオクテットで終わります。解凍プロセスが正常に完了すると、IPヘッダーが変更され、解凍されたIPデータグラムのサイズと、IPCompヘッダーに格納されている元の次のヘッダーが示されます。 IPCompヘッダーはIPデータグラムから削除され、解凍されたペイロードはIPヘッダーの直後に続きます。
If the total size of a compressed ULP payload and the IPComp header, as defined in section 3, is not smaller than the size of the original ULP payload, the IP datagram MUST be sent in the original non-compressed form. To clarify: If an IP datagram is sent non-compressed, no IPComp header is added to the datagram. This policy ensures saving the decompression processing cycles and avoiding incurring IP datagram fragmentation when the expanded datagram is larger than MTU.
セクション3で定義されているように、圧縮ULPペイロードとIPCompヘッダーの合計サイズが元のULPペイロードのサイズより小さくない場合、IPデータグラムは元の非圧縮形式で送信する必要があります。明確にするために：IPデータグラムが非圧縮で送信される場合、IPCompヘッダーはデータグラムに追加されません。このポリシーは、展開されたデータグラムがMTUより大きい場合に、解凍処理サイクルを節約し、IPデータグラムの断片化を回避することを保証します。
Small IP datagrams are likely to expand as a result of compression. Therefore, a numeric threshold should be applied before compression, where IP datagrams of size smaller than the threshold are sent in the original form without attempting compression. The numeric threshold is implementation dependent.
小さいIPデータグラムは、圧縮の結果として拡張される可能性があります。したがって、数値のしきい値を圧縮の前に適用する必要があります。しきい値よりも小さいサイズのIPデータグラムは、圧縮を試行せずに元の形式で送信されます。数値のしきい値は実装に依存します。
An IP datagram with payload that has been previously compressed tends not to compress any further. The previously compressed payload may be the result of external processes, such as compression applied by an upper layer in the communication stack, or by an off-line compression utility. An adaptive algorithm should be implemented to avoid the performance hit. For example, if the compression of i consecutive IP datagrams of an IPCA fails, the next k IP datagrams are sent without attempting compression. If the next j datagrams are also failing to compress, the next k+n datagrams are sent without attempting compression. Once a datagram is compressed successfully, the normal process of IPComp restarts. Such an adaptive algorithm, including all the related thresholds, is implementation dependent.
以前に圧縮されたペイロードを持つIPデータグラムは、それ以上圧縮されない傾向があります。以前に圧縮されたペイロードは、通信スタックの上位層またはオフライン圧縮ユーティリティによって適用される圧縮などの外部プロセスの結果である可能性があります。パフォーマンスへの影響を回避するために、適応アルゴリズムを実装する必要があります。たとえば、IPCAのi個の連続するIPデータグラムの圧縮が失敗した場合、次のk個のIPデータグラムが圧縮を試行せずに送信されます。次のjデータグラムも圧縮に失敗した場合、次のk + nデータグラムは圧縮を試行せずに送信されます。データグラムが正常に圧縮されると、IPCompの通常のプロセスが再開されます。関連するすべてのしきい値を含むこのような適応アルゴリズムは、実装に依存します。
During the processing of the payload, the compression algorithm MAY periodically apply a test to determine the compressibility of the processed data, similar to the requirements of [V42BIS]. The nature of the test is algorithm dependent. Once the compression algorithm detects that the data is non-compressible, the algorithm SHOULD stop processing the data, and the payload is sent in the original non-compressed form.
ペイロードの処理中、圧縮アルゴリズムは定期的にテストを適用して、[V42BIS]の要件と同様に、処理されたデータの圧縮率を決定してもよい（MAY）。テストの性質はアルゴリズムに依存します。圧縮アルゴリズムがデータが非圧縮であることを検出すると、アルゴリズムはデータの処理を停止する必要があり（SHOULD）、ペイロードは元の非圧縮形式で送信されます。
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, [RFC-1700].
Protocolフィールドは108、IPComp Datagram、[RFC-1700]に設定されています。
Header Checksum
ヘッダーチェックサム
The Internet Header checksum [RFC-0791] of the IP header.
IPヘッダーのインターネットヘッダーチェックサム[RFC-0791]。
All other IPv4 header fields are kept unchanged, including any header options.
ヘッダーオプションを含め、他のすべてのIPv4ヘッダーフィールドは変更されません。
The following IPv6 header fields are set before transmitting the compressed IP datagram:
次のIPv6ヘッダーフィールドは、圧縮IPデータグラムを送信する前に設定されます。
Payload Length
ペイロードの長さ
The length of the compressed IP payload.
圧縮されたIPペイロードの長さ。
Next Header
次のヘッダー
The Next Header field is set to 108, IPComp Datagram, [RFC-1700].
Next Headerフィールドは108、IPComp Datagram、[RFC-1700]に設定されています。
All other IPv6 header fields are kept unchanged, including any non-compressed header options.
他のすべてのIPv6ヘッダーフィールドは、非圧縮ヘッダーオプションを含め、変更されずに保持されます。
The IPComp header is placed in an IPv6 packet using the same rules as the IPv6 Fragment Header. However if an IPv6 packet contains both an IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header MUST precede the IPComp header in the packet.
IPCompヘッダーは、IPv6フラグメントヘッダーと同じルールを使用してIPv6パケットに配置されます。ただし、IPv6パケットにIPv6フラグメントヘッダーとIPCompヘッダーの両方が含まれている場合、IPv6フラグメントヘッダーはパケットのIPCompヘッダーの前に配置する必要があります。
The four-octet header has the following structure:
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 define well-known compression algorithms, which require no additional information, and are used for manual setup. The values themselves are identical to IPCOMP Transform identifiers as defined in [SECDOI]. Consult [SECDOI] for an initial set of defined values and for instructions on how to assign new values. The values 64-255 are reserved for future use. The values 256-61439 are negotiated between the two nodes in definition of an IPComp Association, as defined in section 4. Note: When negotiating one of the well-known algorithms, the nodes MAY select a CPI in the pre-defined range 0-63. The values 61440-65535 are for private use among mutually consenting parties. Both nodes participating can select a CPI value independently of each other and there is no relationships between the two separately chosen CPIs. The outbound IPComp header MUST use the CPI value chosen by the decompressing node. The CPI in combination with the destination IP address uniquely identifies the compression algorithm characteristics for the datagram.
16ビットインデックス。 CPIはネットワーク順に保存されます。 0〜63の値は、追加の情報を必要としない既知の圧縮アルゴリズムを定義し、手動設定に使用されます。値自体は、[SECDOI]で定義されているIPCOMP変換識別子と同じです。定義済みの値の初期セットと新しい値を割り当てる方法については、[SECDOI]を参照してください。値64-255は将来の使用のために予約されています。値256-61439は、セクション4で定義されているように、IPCompアソシエーションの定義で2つのノード間でネゴシエートされます。注：既知のアルゴリズムの1つをネゴシエートする場合、ノードは事前定義された範囲0- 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. The IPComp mode of operation is either a node-to-node policy where IPComp is applied to every IP packet between the nodes, or an ULP session based policy where only selected ULP sessions between the nodes are using IPComp. For each IPCA, a different compression algorithm may be negotiated in each direction, or only one direction may be compressed. The default is "no IPComp compression".
IPCompプロトコルを利用するには、2つのノードが最初にそれらの間にIPCompアソシエーション（IPCA）を確立する必要があります。 IPCAには、圧縮パラメーターインデックス（CPI）、操作モード、使用する圧縮アルゴリズム、および選択した圧縮アルゴリズムに必要なパラメーターなど、IPCompの操作に必要なすべての情報が含まれています。 IPCompの動作モードは、ノード間のすべてのIPパケットにIPCompが適用されるノード間ポリシー、またはノード間の選択されたULPセッションのみがIPCompを使用するULPセッションベースのポリシーのいずれかです。 IPCAごとに、異なる圧縮アルゴリズムが各方向でネゴシエートされるか、1つの方向のみが圧縮されます。デフォルトは「IPComp圧縮なし」です。
The IPCA is established by dynamic negotiations or by manual configuration. The dynamic negotiations SHOULD use the Internet Security Association and Key Management Protocol [ISAKMP], where IPSec is present. The dynamic negotiations MAY be implemented through a different protocol.
IPCAは、動的ネゴシエーションまたは手動構成によって確立されます。動的ネゴシエーションは、IPSecが存在するInternet Security Association and Key Management Protocol [ISAKMP]を使用する必要があります（SHOULD）。動的ネゴシエーションは、異なるプロトコルを介して実装される場合があります。
For IPComp in the context of IP Security, ISAKMP provides the necessary mechanisms to establish IPCA. IPComp Association is negotiated by the initiator using a Proposal Payload, which would include one or more Transform Payloads. The Proposal Payload would specify a compression protocol in the protocol id field and each Transform Payload would contain the specific compression method(s) being offered to the responder.
IPセキュリティのコンテキストでIPCompの場合、ISAKMPはIPCAを確立するために必要なメカニズムを提供します。 IPCompアソシエーションは、1つ以上の変換ペイロードを含む提案ペイロードを使用して、開始者によってネゴシエートされます。プロポーザルペイロードは、プロトコルIDフィールドで圧縮プロトコルを指定し、各変換ペイロードには、レスポンダに提供される特定の圧縮方法が含まれます。
In the Internet IP Security Domain of Interpretation (DOI), IPComp is negotiated as the Protocol ID PROTO_IPCOMP. The compression algorithm is negotiated as one of the defined IPCOMP Transform Identifiers.
解釈のインターネットIPセキュリティドメイン（DOI）では、IPCompはプロトコルID PROTO_IPCOMPとしてネゴシエートされます。圧縮アルゴリズムは、定義されたIPCOMP変換識別子の1つとしてネゴシエートされます。
The dynamic negotiations MAY be implemented through a protocol other than ISAKMP. Such protocol is beyond the scope of this document.
ダイナミックネゴシエーションは、ISAKMP以外のプロトコルを介して実装される場合があります。このようなプロトコルは、このドキュメントの範囲を超えています。
Nodes may establish IPComp Associations using manual configuration. For this method, a limited number of Compression Parameters Indexes (CPIs) is designated to represent a list of specific compression methods.
ノードは、手動構成を使用してIPCompアソシエーションを確立できます。この方法では、特定の圧縮方法のリストを表すために、限られた数の圧縮パラメーターインデックス（CPI）が指定されます。
When IPComp is used in the context of IPSec, it is believed not to have an effect on the underlying security functionality provided by the IPSec protocol; i.e., the use of compression is not known to degrade or alter the nature of the underlying security architecture or the encryption technologies used to implement it.
IPCompがIPSecのコンテキストで使用される場合、IPSecプロトコルによって提供される基本的なセキュリティ機能に影響を与えないと考えられています。つまり、圧縮を使用しても、基盤となるセキュリティアーキテクチャまたはその実装に使用される暗号化テクノロジの性質が低下または変更されることはありません。
When IPComp is used without IPSec, IP payload compression potentially reduces the security of the Internet, similar to the effects of IP encapsulation [RFC-2003]. For example, IPComp may make it difficult for border routers to filter datagrams based on header fields. In particular, the original value of the Protocol field in the IP header is not located in its normal positions within the datagram, and any transport layer header fields within the datagram, such as port numbers, are neither located in their normal positions within the datagram nor presented in their original values after compression. A filtering border router can filter the datagram only if it shares the IPComp Association used for the compression. To allow this sort of compression in environments in which all packets need to be filtered (or at least accounted for), a mechanism must be in place for the receiving node to securely communicate the IPComp Association to the border router. This might, more rarely, also apply to the IPComp Association used for outgoing datagrams.
IPSecを使用せずにIPCompを使用すると、IPカプセル化の効果と同様に、IPペイロード圧縮によってインターネットのセキュリティが低下する可能性があります[RFC-2003]。たとえば、IPCompでは、境界ルーターがヘッダーフィールドに基づいてデータグラムをフィルター処理することが困難になる場合があります。特に、IPヘッダーのプロトコルフィールドの元の値は、データグラム内の通常の位置にありません。また、ポート番号などのデータグラム内のトランスポート層ヘッダーフィールドも、データグラム内の通常の位置にありません。圧縮後の元の値でも表示されません。フィルタリング境界ルーターは、圧縮に使用されるIPCompアソシエーションを共有している場合にのみ、データグラムをフィルタリングできます。すべてのパケットをフィルタリングする（または少なくとも説明する）必要がある環境でこの種の圧縮を可能にするには、受信ノードがIPCompアソシエーションを境界ルーターに安全に通信するためのメカニズムが必要です。これは、まれに、発信データグラムに使用されるIPCompアソシエーションにも適用される場合があります。
[RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC-0791] Postel、J。、編集者、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. Or see:
http://www.iana.org/numbers.html
[RFC-2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460] Deering、S。、およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[RFC-1962]ランド、D。、「PPP圧縮制御プロトコル（CCP）」、RFC 1962、1996年6月。
[RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC-2003]パーキンス、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[ISAKMP] Maughan、D.、Schertler、M.、Schneider、M。、およびJ. Turner、「インターネットセキュリティアソシエーションおよびキー管理プロトコル（ISAKMP）」、RFC 2408、1998年11月。
[SECDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[SECDOI] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[V42BIS] CCITT, "Data Compression Procedures for Data Circuit Terminating Equipment (DCE) Using Error Correction Procedures", Recommendation V.42 bis, January 1990.
[V42BIS] CCITT、「エラー訂正手順を使用したデータ回線終端装置（DCE）のデータ圧縮手順」、勧告V.42 bis、1990年1月。
Authors' Addresses
著者のアドレス
Abraham Shacham Cisco Systems 170 West Tasman Drive San Jose, California 95134 United States of America
Abraham Shacham Cisco Systems 170 West Tasman Driveサンノゼ、カリフォルニア95134アメリカ合衆国
EMail: shacham@cisco.com
Robert Monsour Hi/fn Inc. 2105 Hamilton Avenue, Suite 230 San Jose, California 95125 United States of America
Robert Monsour Hi / fn Inc. 2105 Hamilton Avenue、Suite 230 San Jose、California 95125アメリカ合衆国
EMail: rmonsour@hifn.com
Roy Pereira TimeStep Corporation 362 Terry Fox Drive Kanata, Ontario K2K 2P5 Canada
Roy Pereira TimeStep Corporation 362 Terry Fox Driveカナタオンタリオ州K2K 2P5カナダ
EMail: rpereira@timestep.com
Matt Thomas AltaVista Internet Software 30 Porter Road Littleton, Massachusetts 01460 United States of America
マットトーマスアルタビスタインターネットソフトウェア30 Porter Roadリトルトン、マサチューセッツ01460アメリカ合衆国
EMail: matt.thomas@altavista-software.com
Working Group
ワーキンググループ
The IP Payload Compression Protocol (IPPCP) working group can be contacted through its chair:
IPペイロード圧縮プロトコル（IPPCP）ワーキンググループは、その議長を通じて連絡を取ることができます。
Naganand Dorswamy Bay Networks
Naganand Dorswamy Bay Networks
EMail: naganand@baynetworks.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。