RFC3173 日本語訳
3173 IP Payload Compression Protocol (IPComp). A. Shacham, B. Monsour,R. Pereira, M. Thomas. September 2001. (Format: TXT=15389 bytes) (Obsoletes RFC2393) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Shachamがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3173年の杜松は以下を時代遅れにします。 2393年のB.Monsourカテゴリ: 標準化過程コンサルタントR.ペレイラシスコM.トーマスコンサルタント2001年9月
IP Payload Compression Protocol (IPComp)
IP有効搭載量圧縮プロトコル(IPComp)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment.
このドキュメントはインターネットプロトコルデータグラムのための可逆圧縮をインターネット環境に提供することを意図するプロトコルについて説明します。
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データグラムのサイズを減少させるプロトコルです。このプロトコルは1組についてデータグラムを圧縮するのによるホスト/ゲートウェイ(「ノード」)を伝えるか、ノードで十分な計算パワーが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 Compression Controlプロトコル[RFC1962])での圧縮を効力がなくして。 圧縮と暗号化の両方が必要であるなら、暗号化の前に圧縮を適用しなければなりません。
Shacham, et al. Standards Track [Page 1] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[1ページ]。
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ペイロード圧縮プロトコルと共に特定の圧縮アルゴリズムをどう使用できるかを指定するものとします。 そのようなアルゴリズムはこのドキュメントの範囲を超えています。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
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データグラムの圧縮処理には、二相があります: 本国行きのデータグラム(「減圧」)は、外国行きのIPデータグラム(「圧縮」)を圧縮して、減圧されます。 圧縮処理はlosslessであるに違いありません、IPデータグラムが確実に圧縮されて、減圧された後にオリジナルのIPデータグラムと同じになるようにして。
Each IP datagram is compressed and decompressed by itself without any
relation to other datagrams ("stateless compression"), as IP
datagrams may arrive out of order or not arrive at all. Each
compressed IP datagram encapsulates a single IP payload.
それぞれのIPデータグラムは、他のデータグラム(「状態がない圧縮」)と無関係にそれ自体で圧縮されて、減圧されます、IPデータグラムが故障していた状態で到着するか、または全く届かないとき。 それぞれの圧縮されたIPデータグラムはただ一つのIPペイロードをカプセル化します。
Processing of inbound IP datagrams MUST support both compressed and non-compressed IP datagrams, in order to meet the non-expansion policy requirements, as defined in section 2.2.
本国行きのIPデータグラムの処理は、圧縮されて非圧縮の両方にされたIPがデータグラムであるとサポートしなければなりません、非拡張政策必要条件を満たすために、セクション2.2で定義されるように。
The compression of outbound IP datagrams MUST be done before any IP security processing, such as encryption and authentication, and before any fragmentation of the IP datagram. In addition, in IP version 6 [RFC2460], the compression of outbound IP datagrams MUST be done before the addition of either a Hop-by-Hop Options header or a Routing Header, since both carry information that must be examined and processed by possibly every node along a packet's delivery path, and therefore MUST be sent in the original form.
暗号化や認証などのどんなIPセキュリティ処理の前、およびIPデータグラムのどんな断片化の前にも外国行きのIPデータグラムの圧縮をしなければなりません。 さらに、IPバージョン6[RFC2460]では、ホップによるHop Optionsヘッダーかルート設定Headerのどちらかの追加の前に外国行きの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データグラムの減圧をしなければなりません、認証や復号化のように。
Shacham, et al. Standards Track [Page 2] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[2ページ]。
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.
圧縮は八重奏のただ一つの勢ぞろいに適用されます。(八重奏は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 Header Option分野で始まって、圧縮は適用されています、そのようなIP Header Option分野が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データグラムの減少しているサイズを示すように変更されます。 Next Header(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ヘッダーの保存されるとしての次のオリジナルのヘッダーを示すように変更されます。 IPデータグラムからIPCompヘッダーを取り除きます、そして、減圧されたペイロードはすぐに、IPヘッダーに続きます。
2.2. Non-Expansion Policy
2.2. 非拡張政策
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データグラムを送る、いいえなら
Shacham, et al. Standards Track [Page 3] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[3ページ]。
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データグラムは、さらにいずれも圧縮しない傾向があります。 以前に圧縮されたペイロードは外部過程の結果であるかもしれません、コミュニケーションスタックの上側の層、またはオフライン圧縮ユーティリティによって適用された圧縮などのように。 適応型のアルゴリズムは、性能ヒットを避けるために実装されるべきです。 圧縮を試みないで、例えば次の数個のIPデータグラムをIPCAのi連続した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]の要件と同様です。 テストの本質はアルゴリズムに依存しています。 圧縮アルゴリズムがいったんそれを検出すると、データは非圧縮性です、そして、アルゴリズム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:
圧縮されたIPデータグラムを送る前に、以下のIPv4ヘッダーフィールドは設定されます:
Shacham, et al. Standards Track [Page 4] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[4ページ]。
Total Length
全長
The length of the entire encapsulated IP datagram, including
the IP header, the IPComp header and the compressed payload.
全体の長さは、IPがIPヘッダー、IPCompヘッダー、および圧縮されたペイロードを含むデータグラムであるとカプセル化しました。
Protocol
プロトコル
The Protocol field is set to 108, IPComp Datagram, [RFC1700].
プロトコル分野は108、IPCompデータグラム[RFC1700]に設定されます。
Header Checksum
ヘッダーチェックサム
The Internet Header checksum [RFC0791] of the IP header.
IPヘッダーのインターネットHeaderチェックサム[RFC0791]。
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:
圧縮された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].
Next Header分野は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 Fragment Headerと同じ規則を使用することでIPv6パケットに置かれます。 しかしながら、IPv6パケットがIPv6 Fragment HeaderとIPCompヘッダーの両方を含んでいるなら、IPv6 Fragment HeaderはパケットでIPCompヘッダーに先行しなければなりません。 以下に注意してください。 他のIPv6ヘッダーはIPv6 Fragment HeaderとIPCompヘッダーの間に出席しているかもしれません。
Shacham, et al. Standards Track [Page 5] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[5ページ]。
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ビットのセレクタ。 IPv4プロトコル分野かIPv6 Next HeaderがさばくオリジナルのIPヘッダーのストア。
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 Transform識別子と同じです。 1人の始発の定義された値とどう新しい値を割り当てるかに関する指示のために[SECDOI]に相談してください。 値64-255は今後の使用のために予約されます。 値256-61439はセクション4で定義されるように2つのノードの間でIPComp Associationの定義で交渉されます。 以下に注意してください。 よく知られるアルゴリズムの1つを交渉するとき、ノードは事前に定義された範囲0-63でCPIを選択するかもしれません。 値61440-65535が私的使用目的で互いに同意しているパーティーにあります。 ノード参加は互いの如何にかかわらずCPI値を選択できます、そして、2つの別々に選ばれたCPIの間には、関係が全くありません。 外国行きのIPCompヘッダーは減圧ノードによって選ばれたCPI値を使用しなければなりません。 送付先IPアドレスと組み合わせたCPIはデータグラムのために唯一圧縮アルゴリズムの特性を特定します。
Shacham, et al. Standards Track [Page 6] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[6ページ]。
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.
IPCompプロトコルを利用するために、2つのノードが最初に、それらの間のIPComp Association(IPCA)を設立しなければなりません。 IPCAはIPCompの操作のためのすべての必須情報を含んでいます、Compression Parameter Index(CPI)、運転モード、使用されるべき圧縮アルゴリズム、および選択された圧縮アルゴリズムのためのどんな必要なパラメタも含んでいて。
The policy for establishing IPComp may be either a node-to-node policy where IPComp is applied to every IP packet between the nodes, or a session-based policy where only selected sessions between the nodes employ IPComp.
IPCompを設立するための方針は、ノードからノードへのIPCompがノードの間のあらゆるIPパケットに適用される方針かノードの間の選択されたセッションだけがIPCompを使うセッションベースの方針のどちらかであるかもしれません。
Two nodes may choose to negotiate IPComp in either or both directions, and they may choose to employ a different compression algorithm in each direction. The nodes MUST, however, negotiate a compression algorithm in each direction for which they establish an IPCA: there is no default compression algorithm.
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はダイナミックな交渉か手動の構成によって設立されます。 ダイナミックな交渉SHOULDはインターネット・キー・エクスチェンジプロトコル[IKE]を使用します。そこでは、IPsecが存在しています。 ダイナミックな交渉は異なったプロトコルを通して実装されるかもしれません。
4.1. Use of IKE
4.1. 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 Securityの文脈のIPCompのために、IKEはIPCAを設立するための必要なメカニズムとガイドラインを提供します。 IKEを使用して、スタンドアロンであるか他のIPsecプロトコルに関連してIPCompを交渉できます。
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 Associationは、Proposal有効搭載量、どれが1つを含んでいるか、そして、または、より多くのTransform有効搭載量を使用することで創始者によって交渉されます。 Proposal有効搭載量はプロトコルID分野でIP有効搭載量Compressionプロトコルを指定します、そして、それぞれのTransform有効搭載量は応答者に提供される特定の圧縮アルゴリズムを保管しています。
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.
提案のSPI分野でCPIを送って、SPIサイズで、分野は、合うようにセットしました。 16ビットの数としてCPI SHOULDを送って、SPIサイズで、分野は2にセットしました。 あるいはまた、32ビットの値としてSPIサイズ分野セットでCPIを4に送るかもしれません。 この場合、SPI分野の2つの最も重要でない八重奏に16ビットのCPI番号を置かなければなりません、2つの最も重要な八重奏をゼロに設定しなければならなくて、受信ノードで無視しなければなりませんが。 受信ノードはCPI提案の両方のフォームを処理できなければなりません。
Shacham, et al. Standards Track [Page 7] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[7ページ]。
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.
Interpretation(DOI)のインターネットIP Security Domainでは、IPCompはProtocol IDプロト_IPCOMPとして交渉されます。 圧縮アルゴリズムは定義されたIPCOMP Transform Identifiersの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.
非デフォルトEncapsulation Mode(トンネル・モードなどの)を提案するために、IPComp提案はEncapsulation Mode属性を含まなければなりません。 Encapsulation Modeが不特定であるなら、Transport Modeのデフォルト値は想定されます。
Lifetime
生涯
An IPComp proposal uses the Life Duration and Life Type
attributes to suggest life duration to the IPCA.
IPComp提案は、寿命をIPCAに示すのにLife DurationとLife Type属性を使用します。
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がProtection Suiteの一部として交渉されるとき、すべての論理的に関連する申し出が一貫しているに違いありません。 しかしながら、IPComp提案SHOULD NOTはIPCompに適切でない属性を含んでいます。 IPCompに関連していないProtection 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.
ノードはよく知られるアルゴリズムの1つを使用しているならCPIから圧縮アルゴリズムを決定するのに必要な計算を避けることができます。 これは減圧プロセスで時間を節約できます。 ノードは、値においてその圧縮アルゴリズムの事前に定義されたTransform識別子と等しいCPIを交渉することによって、これができます。 明確に: ノードは、あらかじめ定義された範囲でCPIと同じただ一つのTransform有効搭載量を含まなければならないProposal有効搭載量を送ることによって、CPIを提供するかもしれません。 より多くのTransform有効搭載量、事前に定義のCPIが複数のIPComp提案を使用することで及ぶノード5月の申し出--2かそれぞれただ一つのTransform有効搭載量を含まなければならないよう提案するとき。 はっきりさせるために: Proposal有効搭載量が2を含まなければならないか、または、より多くのTransform有効搭載量、CPIが含まなければならないなら、交渉された範囲にいてください。 受信ノードはそれぞれのこれらの提案フォームを処理できなければなりません。
Shacham, et al. Standards Track [Page 8] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[8ページ]。
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.
2つ以上のIPCompセッションが2つのノードの間で確立されて、同じよく知られるCPIが少なくとも2つのセッションのときに使用されるとき、IPCAsは非ユニークになります。 非ユニークなIPCAsは各IPCAに特定であるか、交渉されているか(例えば、生涯)、または内部に属性を維持する際に問題を引き起こします(例えば、取り扱いのための適応型のアルゴリズムのカウンタは以前に、ペイロードを圧縮しました)。 2IPCAsが同じ圧縮アルゴリズムを使用するときのCPIを2つのノードの間のIPCAsのユニークさに確実にするために、SHOULDは交渉された範囲のそうです。 しかしながら、例えば、属性が全くこれらのIPCAsに利用されていないとき、IPCAsが特有であることが必要でないときに、よく知られるCPIは使用されるかもしれません。 はっきりさせるために: 特定のよく知られるCPIを使用するただ一つのセッションだけが2つのノードの間で確立されるとき、このIPCAはユニークです。
4.2. Use of Non-IKE Protocol
4.2. 非IKEプロトコルの使用
The dynamic negotiations MAY be implemented through a protocol other than IKE. Such a protocol is beyond the scope of this document.
ダイナミックな交渉はIKE以外のプロトコルを通して実装されるかもしれません。 そのようなプロトコルはこのドキュメントの範囲を超えています。
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 Associationsを設立するかもしれません。 このメソッドにおいて、限られた数のCompression Parameters Indexes(CPI)が、特定の圧縮方法のリストを表すために指定されます。
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プロトコルから基本的なセキュリティの機能性への効果を供給しないとそれで信じられています。 基本的なセキュリティー体系かそれを実装するのに使用される暗号技術の本質を下がるか、またはすなわち、圧縮の使用が変更するのが知られません。
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
IPCompがIPsecなしで使用されるとき、IPペイロード圧縮は潜在的にインターネットのセキュリティを下げます、IPカプセル化[RFC2003]の効果と同様です。 例えば、IPCompは境界ルータがヘッダーフィールドに基づくデータグラムをフィルターにかけるのを難しくするかもしれません。 特に、IPヘッダーのプロトコル分野の元の値がデータグラムの中にノーマル位置に位置していなくて、データグラムの中のポートナンバーなどの少しのトランスポート層ヘッダーフィールドも、圧縮の後にデータグラムの中にそれらのノーマル位置に位置していなくて、またそれらの元の値で提示されません。 圧縮に使用されるIPComp Associationを共有する場合にだけ、フィルタリング境界ルータはデータグラムをフィルターにかけることができます。 すべてのパケットがフィルターにかけられる必要がある環境における、この種類の圧縮を許すために
Shacham, et al. Standards Track [Page 9] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[9ページ]。
(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 Associationを境界ルータに伝えるように、メカニズムは適所にあるに違いありません。 また、これは、よりめったに発信データグラムに使用されるIPComp Associationに適用されないかもしれません。
6. IANA Considerations
6. IANA問題
This document does not require any IANA actions. The well-known numbers used in this document are defined elsewhere; see [SECDOI].
このドキュメントは少しのIANA動作も必要としません。 本書では使用されるよく知られる数はほかの場所で定義されます。 [SECDOI]を見てください。
7. Changes made since RFC 2393
7. 変化は以来、RFCを2393にしました。
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.
このセクションは本書ではRFC2393のimplementerが意識しているべきであるRFC2393から変化をまとめます。 すべての変化が、IPsecの文脈でIKE[IKE]を使用することでIPComp Association(IPCA)の交渉をはっきりさせることになっています。
1) Added a clarification that IPComp can be negotiated stand-alone or
bundled with other protocols in a Protection Suite.
1) IPCompがそうすることができる明確化がスタンドアロンの状態で交渉されると言い足したか、またはProtection 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八重奏が5月です。 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) Transport ModeになるようにデフォルトEncapsulation Modeを定義するために言葉遣いを加えました。 トンネル・モードなどの非デフォルトカプセル化を示すとき、IPComp提案がEncapsulation Mode属性を含まなければならないのが必要でした。
4) Added the Lifetime attribute to the list of supported attributes
(along with Transport Mode).
4) サポートしている属性(Transport Modeに伴う)のリストに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) Protection Suiteの変換のIPCompに適切でない属性の取り扱いを指定します: これらの属性SHOULD NOTはIPComp提案に含まれていて、IPCAを設定するとき、無視されてIPCompの操作中であるに違いありません。 IPComp実装は他の変換の属性を含んでいないIPCOMP提案を決して拒絶してはいけません。
6) Added implementation notes on the negotiation and usage of CPIs in
the predefined (well-known) range.
6) 事前に定義のCPI(よく知られる)の交渉と用法に関する付記された実装注は及びます。
Shacham, et al. Standards Track [Page 10] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[10ページ]。
8. References
8. 参照
[RFC0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0791] ポステル、J.、エディタ、「インターネットプロトコル」、STD5、RFC791、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.ポステル、「規定番号」、STD2、RFC1700、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)仕様」、RFC2460、12月1998日
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
1962, June 1996.
D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962 1996年6月の[RFC1962]底ならし革。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2003] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[SECDOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[SECDOI]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、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)のためのエラー修正手順を用いるデータ圧縮手順」、Recommendation V.42、2回、1990年1月。
Shacham, et al. Standards Track [Page 11] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[11ページ]。
Authors' Addresses
作者のアドレス
Abraham Shacham Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, California 94089 United States of America
アブラハムShacham JuniperはInc.1194の北のマチルダ・Avenueカリフォルニア94089サニーベル(アメリカ合衆国)をネットワークでつなぎます。
EMail: shacham@shacham.net
メール: shacham@shacham.net
Bob Monsour 18 Stout Road Princeton, New Jersey 08540 United States of America
ボブMonsour18の逞しいRoadニュージャージー08540プリンストン(アメリカ合衆国)
EMail: bob@bobmonsour.com
メール: bob@bobmonsour.com
Roy Pereira Cisco Systems, Inc. 55 Metcalfe Street Ottawa, Ontario K1P 6L5 Canada
ロイペレイラシスコシステムズInc.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 メーリングリスト、そして/または、作者に記述されるべきです。
Shacham, et al. Standards Track [Page 12] RFC 3173 IP Payload Compression Protocol September 2001
Shacham、他 規格はIP有効搭載量圧縮プロトコル2001年9月にRFC3173を追跡します[12ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Shacham, et al. Standards Track [Page 13]
Shacham、他 標準化過程[13ページ]
一覧
スポンサーリンク
