RFC2393 日本語訳
2393 IP Payload Compression Protocol (IPComp). A. Shacham, R. Monsour,R. Pereira, M. Thomas. December 1998. (Format: TXT=20757 bytes) (Obsoleted by RFC3173) (Status: PROPOSED STANDARD)
RFC一覧
英語原文
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. この文書は、Internet community のための Internet standards track protocol を明細に記述し、改良のための討議と提案を要求する。このプロ トコルの標準化状態とステータスについては、"Internet Official Protocol Standards" (STD 1) の最新版を参照してもらいたい。このメモの 配布は、無制限である。 ----------------------------------------------------------------------- Copyright Notice 著作権表示 Copyright (C) The Internet Society (1998). All Rights Reserved. ----------------------------------------------------------------------- Abstract 要約 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. この文書は、Internet 環境での lossless な Internet Protocol データグ ラム圧縮を提供するのに意図されたプロトコルを記述する。 ----------------------------------------------------------------------- 1. Introduction 1. 序論 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 データグラムサイズを減らすためのプロトコルで ある。このプロトコルは、データグラムを圧縮することにより通信している ホスト/ゲートウェイ ("nodes") ペア間のコミュニケーションパフォーマン ス全体を増やすだろう。これは、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 Compression Control Protocol [RFC-1962]) での圧縮を効果のな いものにして、データに自然とランダムにさせる。もし圧縮と暗号化両方が 要求されるなら、圧縮は暗号化の前に適用されなければならない (MUST)。 This document defines the IP payload compression protocol (IPComp), the IPComp packet structure, the IPComp Association (IPCA), and several methods to negotiate the IPCA. この文書は、(次の 4 つの) 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 ペイロード圧縮プロトコルとど のように使用されることができるかを明細に記述するだろう。そのようなア ルゴリズムは、この文書の範囲外である。 1.1. Specification of Requirements 1.1. 要求の明細事項 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] で記述されたとして解釈されること ができる。 ----------------------------------------------------------------------- 2. Compression Process 2. 圧縮プロセス 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 データグラムの圧縮プロセスは、2 つのフェーズを持つ: それは outbound (外向けの) IP データグラムの圧縮 ("compression (圧縮)") と inbound (内向けの) IP データグラムの圧縮を外すこと ("decompression (伸長)") である。圧縮処理は、次のことを保証して、lossless でなければ ならない (MUST)。その保証とは、圧縮され、かつ伸長された後の 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 データグラムは、次に述べる性質のように他のデータグラム とどんな関係もなく ("stateless compression")、自分自身により圧縮され 伸長される。その性質とは、IP データグラムは異なった順序で到着するか まったく到着しないかもしれないというものである。それぞれの圧縮される IP データグラムは、たった 1 つの 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. inbound IP データグラムの処理は、section 2.2 で定義されるとして non-expansion policy (拡張のないポリシー) 要求に応じるために、圧縮さ れた IP データグラムと圧縮されていない IP データグラム両方をサポート しなければならない (MUST)。 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. outbound IP データグラムの処理は、どんな IP セキュリティ処理の前、ま たはどんな IP データグラムの分割処理の前におこなわなければならない (MUST)。ここで IP セキュリティ処理とは、暗号化や認証のような処理をさ す。さらに加えて、IP version 6 [RFC-2460] での outbound IP データグ ラムの処理は、Hop-by-Hop Options ヘッダ か Routing Header どちらかの 追加の前におこなわなければならない (MUST)。これは両方 (のヘッダ) と も、パケットの配送経路に沿って、ひょっとしたらすべてのノードにより調 査され処理されなければならない情報を運ぶからである。それゆえに、もと もとの形式で送信されなければならない (MUST)。 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. 同様に、inbound IP データグラムの伸長は、次に述べる処理の後におこな われなければならない (MUST)。それは、IP データグラム再構成の後と、認 証と復号化のようなすべての IP セキュリティ処理完了の後である。 2.1. Compressed Payload 2.1. 圧縮されたペイロード 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. 圧縮は、たった 1 つのオクテット配列に適用される。それは、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 version 4 [RFC-0791] では、圧縮は IP データグラムの upper layer protocol (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 は end-to-end ペイロードとして見られる。そして IPComp は、hop-by-hop, routing と fragmentation extension headers に 決して適用されない (MUST NOT)。圧縮は、次に述べるものを含まない最初 の IP Header Option フィールドで始まるものに適用される。その IP Header Option フィールドは、パケットの配送経路に沿ってノードにより調 査され処理されなければならない情報を運ばないものである。もしそのよう な IP Header Option フィールドが存在するなら、そのフィールドは (圧縮 されず) IP データグラムの ULP ペイロードへと続く。 The size of a compressed payload, generated by the compression algorithm, MUST be in whole octet units. 圧縮アルゴリズムにより生成される、その圧縮されたペイロードサイズは、 完全なオクテット単位でなければならない (MUST)。 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. section 3 で定義されるとして、IPComp ヘッダは、圧縮されたペイロード の直前に挿入される。もともとの IP ヘッダは、IPComp プロトコル使用と IP データグラムの減少されたサイズを指し示すために変更される。Next Header (次ヘッダ) (IPv6) や protocol (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データグラム内のたった 1 つの連続したオクテット配列に適用 される。オクテット配列の開始は IPComp ヘッダのすぐ後に来て、IP ペイ ロードの最後のオクテットで終わる。もし伸長プロセスがうまく完了するな ら、IP ヘッダは次に述べる 2 つの情報を指し示すために変更される。その 2 つの情報とは、伸長された IP データグラムのサイズと IPComp ヘッダに 格納されたもともとの次ヘッダである。IPComp ヘッダは IP データグラム から取り除かれ、伸長されたペイロードは IP ヘッダのすぐ後に来る。 2.2. Non-Expansion Policy 2.2. 拡張のないポリシー 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. section 3 で定義されたとして、もし圧縮された ULP ペイロードと IPComp ヘッダの全サイズがもともとの ULP ペイロードより小さくないなら、その IP データグラムは、もともとの圧縮されない形式で送信されなければなら ない (MUST)。(このことを) 明らかにすると (次のことが言える): もし IP データグラムが圧縮されないで送信されるなら、IPComp ヘッダはデータグ ラムに追加されることはない。このポリシーは、伸長されたデータグラムが MTU より大きい時、次に述べる 2 つのことを保証する。それは、伸長処理 の循環を不要にすることと、IP データグラム断片になるのを避けることの 2 つを保証することである。 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 データグラムは圧縮の結果として、たぶん拡張するであろう。そ れゆえに、数に関する threshold (閾値) は圧縮の前に適用されるべきであ る。そしてその threshold より小さいサイズの IP データグラムは、圧縮 の試みなしに、もともとの形式で送信される。数に関する threshold は、 実装依存である。 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 データグラムは、少しもそれ以上の 圧縮をおこなう傾向はない。以前に圧縮されたペイロードは、コミュニケー ションスタックでの上位層によるか、または off-line 圧縮ユーティリティ により適用される圧縮のような、外部プロセスの結果であるかもしれない。 適応あるアルゴリズムは、パフォーマンス障害を避けるために実装されるべ きである。たとえば、もし IPCA に関する連続した IP データグラム i 番 目の圧縮が失敗するなら、次の k 番目のデータグラムは圧縮の試みなしに 送信される。もし次の j 番目のデータグラムも圧縮に失敗するなら、次の k+n 番目のデータグラムは圧縮の試みなしに送信される。いったんデータグ ラムがうまく圧縮されると、IPComp の通常プロセスが再始動する。すべて の関連ある threshold を含んだ、そのような適応あるアルゴリズムは実装 依存である。 訳注) k+n の圧縮の試みなしとは、i, j, k, ... の連続した IP デー タグラムで、i と j 両方圧縮に失敗した場合、その後 n 個の 圧縮はない、と解釈できるように思われる。この時の n は実装 依存と思われる。 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)、ペイロードは、もとも との圧縮されない形式で送信される。 ----------------------------------------------------------------------- 3. Compressed IP Datagram Header Structure 3. 圧縮された IP データグラムヘッダ構造 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 ヘッダの構造を定 義する。 3.1. IPv4 Header Modifications 3.1. IPv4 ヘッダ変更 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 フィールドは、[RFC-1700] での IPComp Datagram, 108 に セットされる。 Header Checksum ヘッダチェックサム The Internet Header checksum [RFC-0791] of the IP header. IP ヘッダの Internet Header チェックサム [RFC-0791]。 All other IPv4 header fields are kept unchanged, including any header options. 他の IPv4 ヘッダフィールドすべては、なんらかのヘッダオプションを含ん で、変更されないままである。 3.2. IPv6 Header Modifications 3.2. IPv6 ヘッダ変更 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 フィールドは、[RFC-1700] での IPComp Datagram, 108 にセットされる。 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 Fragment Header と同じ規則を使用して、IPv6 パ ケットに置かれる。しかしながら、もし IPv6 パケットが IPv6 Fragment Header と IPComp ヘッダ両方を含むなら、IPv6 Fragment Header は、その パケットで IPComp ヘッダより前になければならない (MUST)。 3.3. IPComp Header Structure 3.3. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 次ヘッダ 8-bit selector. Stores the IPv4 Protocol field or the IPv6 Next Header field of the original IP header. 8-bit セレクタ。もともとの IP ヘッダの IPv4 プロトコルフィール ドか IPv6 Next Header フィールドを格納する。 Flags フラグ 8-bit field. Reserved for future use. MUST be set to zero. MUST be ignored by the receiving node. 8-bit フィールド。将来の使用のために予約される。zero にセットさ れなければならない (MUST)。受信側 node では、無視されなければな らない (MUST)。 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-bit インデックス。CPI は、ネットワークオーダで格納される。 0-63 の値は、well-known な圧縮アルゴリズムを定義する。そしてそ れは、追加の情報を必要としなく、手動セットアップのために使用さ れる。値それら自体は、[SECDOI] で定義されるとして、IPCOMP Transform 識別子と同一である。定義された値の初期セットと、新し い値をどのように割り当てるかの指示について、[SECDOI] を調べなさ い。値 64-255 は、将来の使用のために予約される。値 256-61439 は section 4 で定義されるとして、IPComp Association 定義での 2 つ のノード間で取り決められる。注意: well-known なアルゴリズムの 1 つを取り決める時、ノードは、すでに定義されている範囲 0-63 で CPI を選択するかもしれない (MAY)。値 61440-65535 は、相互に同意 しているパーティ間での、プライベート使用のためである。参加する ノード両方は、独立して互いの CPI 値を選択することができ、2 つの 別々に選択された CPI 間に関係はない。outbound IPComp ヘッダは、 (圧縮を) 伸長しているノードにより選択された CPI を使用しなけれ ばならない (MUST)。終点 IP アドレスで組み合わした CPI は、デー タグラムについての圧縮アルゴリズム特徴を一意に識別する。 ----------------------------------------------------------------------- 4. IPComp Association (IPCA) Negotiation 4. IPComp アソシエーション (IPCA) 取り決め 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 Association (IPCA) を最初に確立しなければならない (MUST)。 IPCA は、(次に述べる 4 つの情報) Compression Parameter Index (CPI)、 オペレーションモード、使用される圧縮アルゴリズムと、選択された圧縮ア ルゴリズムに必要とされる何らかのパラメータを含んで、IPComp オペレー ションについて必要とされるすべての情報を含む。IPComp のオペレーショ ンモードは、node-to-node ポリシーか ULP セッションに基づくポリシーど ちらかである。ここで node-to-node ポリシーとは、IPComp がノード間で すべての IP パケットに適用されることをいう。そして ULP に基づくポリ シーとは、ノード間で選択された (複数の) ULP セッションのみが IPComp を使用することをいう。それぞれの IPCA について、異なった圧縮アルゴリ ズムは、それぞれの方向で取り決められるかもしれないし、1 方向のみが圧 縮されるかもしれない。デフォルトは、"no IPComp compression (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 と Key Management Protocol [ISAKMP] を使用すべきである (SHOULD)。その動的な ネゴシエーションは、異なったプロトコルを通して実装されるかもしれない (MAY)。 4.1. Use of ISAKMP 4.1. ISAKMP の使用 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 Security 環境での IPComp について、ISAKMP は IPCA を確立するため の必要なメカニズムを提供する。IPComp Association は、Proposal Payload を使用して initiator (要求側) により取り決められる。そしてそ の Payload は、1 つかそれ以上の Transform Payloads を含むだろう。 Proposal Payload は、protocol id フィールド内に圧縮プロトコルを明細 に述べる。そしてそれぞれの Transform Payload は、responder (応答側) に提供されている (複数の) 特定の圧縮方法を含むだろう。 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 Security Domain of Interpretation (DOI) で、IPComp は Protocol ID PROTO_IPCOMP として取り決められる。その圧縮アルゴリズム は、定義された IPCOMP Transform Identifiers の 1 つとして取り決めら れる。 4.2. Use of Non-ISAKMP Protocol 4.2. ISAKMP でないプロトコルの使用 The dynamic negotiations MAY be implemented through a protocol other than ISAKMP. Such protocol is beyond the scope of this document. 動的なネゴシエーションは、ISAKMP でないプロトコルを通して実装される かもしれない (MAY)。そのようなプロトコルは、この文書の範囲外である。 4.3. Manual Configuration 4.3. 手動設定 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 Association を確立するかもしれな い。この方法について、限定された Compression Parameters Indexes (CPIs) 値は、特定の圧縮方法のリストを表すために示される。 ----------------------------------------------------------------------- 5. Security Considerations 5. セキュリティに関する考察 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 プロトコルにより提 供されるその基本的なセキュリティ機能上に影響を持たないと思われる; す なわち圧縮の使用は、次に述べる 2 つの性質を落としたり、変えたりする ことが知られていない。それらの性質とは、基本的なセキュリティアーキテ クチャや、これを実装するために使用される暗号技術のことである。 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. IPComp が IPSec なしで使用される時、IP ペイロード圧縮は、IP カプセル 化 [RFC-2003] の結果に似て Internet のセキュリティを潜在的に減少させ る。たとえば、IPComp は境界ルータに、ヘッダフィールドに基づくデータ グラムのフィルターを難しくする。特に、圧縮の後で IP ヘッダでの Protocol フィールドのもともとの値は、データグラム内のその通常の場所 に位置されていない。また圧縮の後で、ポート番号のような、データグラム 内のどんなトランスポート層ヘッダフィールドも、データグラム内のそれら 通常の場所に位置されていなく、もともとの値でも示されない。フィルター をおこなう境界ルータは、圧縮に使用される IPComp Association を共有す る場合に限り、データグラムをフィルターすることができる。この圧縮の一 種を許可するため、境界ルータに対し IPComp Association を安全に通信す る受信ノードのため、メカニズムは適していなければならない。上で述べた 圧縮の一種は、すべてのパケットが環境でフィルターされる (もしくは少な くとも捕えられる) ことを必要とし、その環境でのことをいう。これは、外 行きのデータグラムに使用される IPComp Association にも、それ以上めっ たに適用されないかもしれない。 ----------------------------------------------------------------------- 6. References 6. 参考文献 [RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981. [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-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996. [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [SECDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [V42BIS] CCITT, "Data Compression Procedures for Data Circuit Terminating Equipment (DCE) Using Error Correction Procedures", Recommendation V.42 bis, January 1990. ----------------------------------------------------------------------- Authors' Addresses 著者のアドレス Abraham Shacham Cisco Systems 170 West Tasman Drive San Jose, California 95134 United States of America EMail: shacham@cisco.com Robert Monsour Hi/fn Inc. 2105 Hamilton Avenue, Suite 230 San Jose, California 95125 United States of America EMail: rmonsour@hifn.com Roy Pereira TimeStep Corporation 362 Terry Fox Drive Kanata, Ontario K2K 2P5 Canada EMail: rpereira@timestep.com Matt Thomas AltaVista Internet Software 30 Porter Road Littleton, Massachusetts 01460 United States of America EMail: matt.thomas@altavista-software.com Working Group 分科会 The IP Payload Compression Protocol (IPPCP) working group can be contacted through its chair: IP Payload Compression Protocol (IPPCP) working group は、(次に示す) その議長を通して連絡されてもよい: Naganand Dorswamy Bay Networks EMail: naganand@baynetworks.com ----------------------------------------------------------------------- Full Copyright Statement 著作権表示全文 Copyright (C) The Internet Society (1998). All Rights Reserved. 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.
一覧
スポンサーリンク