ネットワークワーキンググループ
Request for Comments: 3173
廃止: 2393
分類: スタンダードトラック
A. Shacham
Juniper
B. Monsour
Consultant
R. Pereira
Cisco
M. Thomas
Consultant
2001年9月

IP ペイロード圧縮プロトコル(IPComp)
(IP Payload Compression Protocol (IPComp))

このメモの位置付け 
この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。
このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。
このメモの配布に制限はない。
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
要旨 
この文書では、インターネット環境における IP データグラムに対して、無損失圧縮を提供するプロトコルについて記述する。
1. はじめに 
IP ペイロード圧縮は、IP データグラムのサイズを小さくするプロトコルである。
このプロトコルは、ホストまたはゲートウェイ(ノード)が、十分な CPU または圧縮用コプロセッサによる計算能力を持っていて、通信が遅いまたは混雑しているリンクで行われている場合に、データグラムを圧縮することによって、通信するノード間の全体の通信性能を向上させる。

IP ペイロード圧縮は、特に IP データグラムが暗号化されている場合に有効である。
IP データグラムを暗号化すると、その性質上データが乱数となり、低プロトコル層での圧縮(PPP 圧縮制御プロトコル [RFC1962] など)は有効でなくなる。
もし、圧縮と暗号化の両方が必要な場合は、暗号化の前に圧縮が行われなければならない。

この文書では、IP ペイロード圧縮プロトコル(IPComp)について定義し、IPComp のパケット構造や IPComp アソシエーション(IPCA)、そして、IPCA を折衝するためのいくつかの方法について定義する。

IP ペイロード圧縮プロトコルで使用される個々の圧縮アルゴリズムの使用方法については、他の文書で定義されるものとする。
このようなアルゴリズムに関する記述は、この文書の範囲外である。

1.1. 要求仕様 
この文書において、しなければならない (MUST)、してはならない (MUST NOT)、要求される (REQUIRED)、することになる (SHALL)、することはない (SHALL NOT)、する必要がある (SHOULD)、しないほうがよい (SHOULD NOT)、推奨される (RECOMMENDED)、してもよい (MAY)、選択できる (OPTIONAL) のキーワードが使用された場合は、RFC 2119 [RFC2119] における定義に沿って解釈されるものとする。
2. 圧縮処理 
IP データグラムの圧縮処理は、出力される IP データグラムの処理(圧縮)と入力されるデータグラムの処理(復元)の 2 つのフェーズから成る。
圧縮処理は、圧縮してから復元した後の IP データグラムが、オリジナルの IP データグラムと同一であることを保証するように、無損失でなければならない (MUST)

IP データグラムが順序通りに到着しない場合や全く到着しない場合を考慮して、各 IP データグラムは他のデータグラムとは無関係に圧縮および復元される。
圧縮された各 IP データグラムには、一つの IP ペイロードがカプセル化される。

入力される IP データグラムの処理は、2.2 節において定義される拡大防止ポリシーに従うように、圧縮された IP データグラムと圧縮されていない IP データグラムの両方に対応しなければならない (MUST)

出力される IP データグラムの圧縮は、暗号化や認証などの IP セキュリティ処理や、IP データグラムのフラグメント処理の前に行わなければならない (MUST)
加えて、IP バージョン 6 [RFC2460] では、出力される IP データグラムの圧縮は、パケットの配送経路上のすべてのノードによって調査され、処理されなければならない可能性のある情報を運ぶ中継点オプションヘッダや経路制御ヘッダが加えられる前に行わなければならず (MUST)、それらのヘッダはオリジナルの形で送られなければならない (MUST)

同様に、入力される IP データグラムの復元は、IP データグラムの再構築や、認証や復号化などのすべての IP セキュリティ処理が完了した後に行われなければならない (MUST)

2.1. 圧縮されたペイロード 
圧縮は、IP データグラム中で隣接して連なる単一オクテット列に対して適用される。
このオクテット列は、必ず IP パケットペイロードの最後のオクテットで終了する。
注意:IP データグラム中で隣接して連なるオクテット列は、物理メモリ上で隣接していなくても良い。

IP バージョン 4 [RFC0791] では、圧縮は IP データグラムのペイロードに対して適用され、IP ヘッダに続く最初のオクテットから始まり、データグラムの最後のオクテットまで続く。
IP ヘッダや IP ヘッダオプションのどの部分も圧縮されない。
注意:カプセル化された IP ヘッダの場合(IPsec のトンネルモードなど)は、データグラムペイロードは、外側 IP ヘッダのすぐ後から始まるため、内側 IP ヘッダはペイロードの一部分と見なされ、圧縮される。

IPv6 では、IPComp は終点間ペイロードと見なされ、中継点、経路制御、フラグメンテーションの各拡張ヘッダには適用してはならない (MUST NOT)
もし、このような IP ヘッダオプションフィールドが存在する場合は、圧縮は、パケットの配送経路上のノードによって調査され、処理されなければならない情報を運ばない最初の IP ヘッダオプションフィールドから始まり、IP データグラムの ULP ペイロードまで適用される。

圧縮アルゴリズムによって生成された圧縮済ペイロードのサイズは、完全なオクテット単位でなければならない (MUST)

3 章で定義されるように、IPComp ヘッダは圧縮されたペイロードの直前に挿入される。
オリジナルの IP ヘッダは、IPComp プロトコルの使用と、減少した IP データグラムのサイズを示すために修正される。
次ヘッダフィールド(IPv6)またはプロトコルフィールド(IPv4)のオリジナルの内容は、IPComp ヘッダ中に保存される。

復元は、IP データグラム中の隣接して連なる単一オクテット列に対して適用される。
オクテット列は、IPComp ヘッダの直後から始まり、IP ペイロードの最後のオクテットで終わる。
復元処理が問題なく完了すれば、IP ヘッダは復元された IP データグラムのサイズと、IPComp ヘッダ中に保存されたオリジナルの次ヘッダを示すように修正される。
IPComp ヘッダは IP データグラムから削除され、復元された IP ペイロードが IP ヘッダの直後に続く。

2.2. 拡大防止ポリシー 
もし、3 章で記述されるように、圧縮されたペイロードと IPComp ヘッダの合計サイズが、オリジナルのペイロードのサイズよりも小さくならない場合は、IP データグラムは圧縮されていないオリジナルの形式で送信されなければならない (MUST)
ここで明確にしておくと、もし、IP データグラムが圧縮されずに送信された場合は、IPComp ヘッダはデータグラムに追加されない。
このポリシーによって、復元処理のサイクルが節約され、拡大したデータグラムが MTU より大きくなった場合における、IP データグラムのフラグメンテーションの発生を避けることが保証される。

小さい IP データグラムは、圧縮を行うと拡大しやすい傾向にある。
このため、スレッショルド値より小さいサイズの IP データグラムは、圧縮を試みずにオリジナルの形式で送信するという、ある数値のスレッショルドを圧縮の前に適用するべきである。 このスレッショルドの値は、実装依存である。

既に圧縮されたペイロードを持つ IP データグラムは、それ以上圧縮されない傾向にある。
既に圧縮されたペイロードは、通信スタックの上位層やオフラインの圧縮ユーティリティによる圧縮などの外部処理の結果生じたものであるかもしれない。
性能に打撃を与えることを避けるためのアルゴリズムが実装されるべきである。
例えば、ある IPCA における i 個の連続した IP データグラムの圧縮に失敗した場合は、次のいくつかの IP データグラム(k 個とする)を、圧縮を試みずに送信する。
もし、それから次の j 個のデータグラムも圧縮に失敗した場合は、さらに多い数のデータグラム(k+n 個とする)を圧縮を試みずに送信する。
一度、あるデータグラムの圧縮に成功すると、IPComp の通常の処理が再び始まる。
このようなアルゴリズムは、それに関連するスレッショルドもすべて含めて、実装依存である。

ペイロードの処理の間、圧縮アルゴリズムは、[V42BIS] の要求条件と同様の、処理データの圧縮性を調べるためのテストを定期的に適用しても良い (MAY)
このテストの性質は、アルゴリズム依存である。
データを圧縮できないことが圧縮アルゴリズムによって検知された場合は、そのアルゴリズムはデータの処理を停止する必要があり (SHOULD)、ペイロードは、圧縮されていないオリジナルの形式で送信される。

3. 圧縮された IP データグラムのヘッダ構造 
圧縮された IP データグラムは、IP ヘッダを修正し、IPComp ヘッダを圧縮されたペイロードの直前に挿入することでカプセル化される。
この章では、IPv4 と IPv6 の両方の場合における IP ヘッダの修正と、IPComp ヘッダの構造について定義する。
3.1. IPv4 ヘッダの修正 
以下の IPv4 ヘッダフィールドは、圧縮された IP データグラムを送信する前にセットされる。
パケット全体長(Total Length)
IP ヘッダ、IPComp ヘッダ、圧縮されたペイロードを含む、カプセル化された IP データグラムの全体の長さ。
プロトコル(Protocol)
プロトコルフィールドは、108(IPComp データグラム)にセットされる [RFC1700]。
ヘッダチェックサム(Header Checksum)
IP ヘッダのインターネットヘッダチェックサム [RFC0791]。
ヘッダオプションを含む、この他のすべての IPv4 ヘッダフィールドは、変更されずに保たれる。
3.2. IPv6 ヘッダの修正 
以下の IPv6 ヘッダフィールドは、圧縮された IP データグラムを送信する前にセットされる。
ペイロード長(Payload Length)
圧縮された IP ペイロードの長さ。
次ヘッダ(Next Header)
次ヘッダフィールドは、108(IPComp データグラム)にセットされる [RFC1700]。
圧縮されていないヘッダオプションを含む、この他のすべての IPv6 ヘッダフィールドは、変更されずに保たれる。

IPComp ヘッダは、IPv6 フラグメントヘッダと同様の規則を使用して IPv6 パケット中に置かれる。
しかしながら、もし、IPv6 パケットが IPv6 フラグメントヘッダと IPComp ヘッダの両方を含む場合は、IPv6 フラグメントヘッダが、パケット中で IPComp ヘッダより前になければならない (MUST)
注意:この他の IPv6 ヘッダは、IPv6 フラグメントヘッダと IPComp ヘッダの間に存在するかもしれない。

3.3. IPComp ヘッダの構造 
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 ビットのセレクタ。
オリジナルのIP ヘッダの IPv4 プロトコルフィールド、または IPv6 次ヘッダフィールドを保持する。
フラグ(Flags)
8 ビットのフィールド。
ゼロにセットしなければならない (MUST)
受信側のノードでは、無視されなければならない (MUST)
圧縮パラメータインデックス(CPI)(Compression Parameter Index)
16 ビットのインデックス。
CPI は、ネットワーク順序で保持される。
0-63 の値は、追加の情報を必要としないウェルノウンの圧縮アルゴリズムを指定し、手動でのセットアップ用に使用される。
この値自体は、[SECDOI] において定義されている IPCOMP トランスフォーム ID と同一である。
定義されている値の初期設定や、新しい値の割り当ての方法に関しては、[SECDOI] を参照のこと。
64-255 の値は、将来の使用のために予約されている。
256-61439 の値は、4 章で定義される IPComp アソシエーションの定義により、2 つのノード間で折衝される。
注意:ウェルノウンのアルゴリズムを折衝する場合は、ノードは、事前に定義された 0-63 の範囲の CPI を選択しても良い (MAY)
61440-65535 の値は、既に同意しているパーティの間でプライベート用に使用される。
参加する両ノードは、それぞれ独立して CPI 値を選択でき、この独立して選択された 2 つの CPI の間には何の関係もない。
出力用 IPComp ヘッダは、復元側のノードによって選択された CPI 値を使用しなければならない (MUST)
CPI は、宛先 IP アドレスと組み合わされて、データグラムに対する圧縮アルゴリズム特性を一意に識別する。
4. IPComp アソシエーション(IPCA)の折衝 
IPComp プロトコルを使用するためには、最初に 2 つのノードは、それらの間で IPComp アソシエーション(IPCA)を確立しなければならない (MUST)。 IPCA は、圧縮パラメータインデックス(CPI)、動作モード、使用される圧縮アルゴリズム、選択された圧縮アルゴリズムに必要なあらゆるパラメータを含む、IPComp の動作に必要な情報をすべて含む。

IPComp を確立するためのポリシーは、ノード間のすべての IP パケットに対して IPComp を適用するノード間ポリシーか、ノード間の選択されたセッションのみが IPComp を使用するセッションベースポリシーのどちらかとなるだろう。

2 つのノードは、どちらか一方向または両方向の IPComp を折衝することを選択しても良いし、それぞれの方向に対して、異なる圧縮アルゴリズムを使用することを選択しても良い。
しかしながら、ノードは、IPCA を確立するそれぞれの方向において、圧縮アルゴリズムを折衝しなければならない (MUST) (デフォルトの圧縮アルゴリズムは存在しない)。

IPComp の実装において必須の圧縮アルゴリズムは存在しない。

IPCA は、動的折衝または手動設定によって確立される。
動的折衝では、IPsec が存在する場合は、インターネット鍵交換プロトコル [IKE] を使用する必要がある (SHOULD)
動的折衝は、別のプロトコルによって実装されても良い (MAY)

4.1. IKE の使用 
IP セキュリティにおいて IPComp が使用される場合、IKE は IPCA を確立するために必要な仕組みであり、ガイドラインである。
IKE を使用することにより、IPComp を単独で、または他の IPsec プロトコルと組み合わせて折衝することが可能となる。

IPComp アソシエーションは、一つ以上のトランスフォームペイロードを含むプロポーザルペイロードを使用して始動者によって折衝される。
プロポーザルペイロードでは、プロトコル ID フィールドで IP ペイロード圧縮プロトコルを指定し、それぞれのトランスフォームペイロードには、応答者に提案される(一つまたは複数の)圧縮アルゴリズムの指定が含まれる。

CPI は、プロポーザルの SPI フィールドにおいて送信され、SPI 長フィールドが調整される。
CPI は、16 ビットの数で送信される必要があり (SHOULD)、この場合は、SPI 長フィールドが 2 にセットされる。
代わりに、CPI は 32 ビットの値で送信されても良く (MAY)、この場合は、SPI 長フィールドが 4 にセットされる。
この場合、16 ビットの CPI 値は、SPI フィールドの最初の 2 バイトに置かれ、残りの 2 バイトはゼロにセットされなければならず (MUST)、これは受信側ノードによって無視されなければならない (MUST)
受信側ノードは、CPI の提案の両方の形式を処理できなければならない (MUST)

インターネット IP セキュリティ翻訳ドメイン(DOI)では、IPComp はプロトコル ID "PROTO_IPCOMP" として折衝される。
圧縮アルゴリズムは、定義されている IPCOMP トランスフォーム ID の一つとして折衝される。

次の属性が IPComp のプロポーザルに適用される。

カプセル化モード(Encapsulation Mode)
デフォルトでないカプセル化モード(トンネルモードなど)を提案する場合は、IPComp のプロポーザルに、カプセル化モード属性を含まなければならない (MUST)
カプセル化モードが指定されない場合は、デフォルトでトランスポートモードが想定される。
有効期間(Lifetime)
IPComp プロポーザルでは、IPCA の有効期間を提案するために、有効期間(Life Duration)属性と有効期間タイプ(Life Type)属性を使用する。
IPComp が保護スイート(Protection Suite)の一部として折衝される場合は、論理的に関連するすべての提案は矛盾していてはならない。
しかしながら、IPComp プロポーザルには、IPComp に適用されない属性を含むべきではない (SHOULD NOT)
保護スイートに IPComp とは関係のない他のプロトコルの属性を含んでいるという理由で、IPComp プロポーザルを拒否してはならない (MUST NOT)
IPComp プロポーザルにこのような属性が含まれている場合は、IPCA を設定する際にそれらの属性を無視しなければならず (MUST)、そのため、IPComp の動作中も無視しなければならない。

実装上の注意:

ウェルノウンのアルゴリズムの一つを使用した場合は、ノードは、CPI から圧縮アルゴリズムを決定するために必要な計算を避けることが可能となり、復元処理にかかる時間の短縮につなげることができる。
ノードは、その圧縮アルゴリズムに該当する事前に定義されたトランスフォーム ID と同じ値を CPI として折衝することで、これを実現することが可能となる。
特に、ノードは、事前に定義された範囲の CPI を、その CPI と同じ一つのトランスフォームペイロードを含む (MUST) プロポーザルペイロードを送信することによって提案しても良い (MAY)
2 つ以上のトランスフォームペイロードを提案する場合は、ノードは、事前に定義された範囲の複数の CPI を、それぞれ一つのトランスフォームペイロードを含む (MUST) 複数の IPComp プロポーザルを使用して提案しても良い (MAY)
ここで明確にしておくと、プロポーザルペイロードが 2 つ以上のトランスフォームペイロードを含んでいる場合は、CPI は折衝範囲のものでなければならない (MUST)
受信側ノードは、これらのプロポーザル形式のそれぞれを処理できなければならない (MUST)
実装上の注意:
2 つのノード間で 2 つ以上の IPComp セッションが確立される場合は、IPCA は一意ではなくなり、少なくとも 2 つのセッションで同じウェルノウン CPI が使用される。
IPCA が一意でない場合、折衝されたもの(有効期間など)であっても、内部的なもの(以前に圧縮されたペイロードを処理するアルゴリズムのカウンタなど)であっても、それぞれの IPCA に特有の属性を管理する上で問題が発生する。
2 つ以上の IPCA が同じ圧縮アルゴリズムを使用する場合に、2 つのノード間の IPCA の一意性を保証するためには、CPI は折衝範囲のものである必要がある (SHOULD)。 しかしながら、IPCA が一意である必要がない場合は(例えば、これらの IPCA で使用される属性が存在しない場合)、ウェルノウンの CPI を使用しても良い (MAY)
ここで明確にしておくと、2 つのノード間で、ある特定のウェルノウンの CPI を使用する一つのセッションのみが確立される場合は、この IPCA は一意となる。
4.2. IKE 以外のプロトコルの使用 
動的折衝は、IKE 以外のプロトコルを使用して実装されても良い (MAY)
このようなプロトコルについては、この文書の範囲外である。
4.3. 手動設定 
ノードは、IPComp アソシエーションを手動設定により確立しても良い。
この方法のために、ある限られた数の圧縮パラメータインデックス(CPI)が特定の圧縮方式のリストを表すために指定されている。
5. セキュリティに関する考慮事項 
IPComp が IPsec と共に使用される場合、IPsec プロトコルによって提供される基本的なセキュリティ機能に影響を与えることはないと信じられている。
つまり、圧縮を使用することによって、基本的なセキュリティアーキテクチャまたはそれを実装するために使用される暗号化技術の性質を下げたり、変更したりすることは知られていない。

IPComp が IPsec なしで使用される場合、IP ペイロード圧縮は、IP カプセル化 [RFC2003] の効果と同様に、インターネットのセキュリティを潜在的に下げる。
例えば、IPComp は、境界ルータにおけるヘッダフィールドを基にしたデータグラムのフィルタリングを難しくするかもしれない。
特に、圧縮後は、IP ヘッダのプロトコルフィールドのオリジナルの値は、データグラム内の通常の場所には置かれず、また、ポート番号のような、データグラム内のどのトランスポート層ヘッダフィールドもデータグラム内の通常の場所には置かれず、オリジナルの値でも存在しない。
フィルタリングを行う境界ルータは、圧縮に使用される IPComp アソシエーションを共有している場合のみデータグラムのフィルタリングを行うことが可能となる。
すべてのパケットをフィルタリングする(または少なくともアカウンティングを行う)必要があるような環境でこのような圧縮を許可するためには、受信側ノードが境界ルータと安全に IPComp アソシエーションをやり取りする仕組みが存在しなければならない。
この仕組みは、さらにまれに、出力されるデータグラムに対して使用される IPComp アソシエーションに対しても適用される可能性がある。

6. IANA に関する考慮事項 
この文書では、IANA のアクションを全く必要としない。
この文書において使用されているウェルノウン値は、至る所で定義されている([SECDOI] を参照)。
7. RFC 2393 からの変更点 
この章では、この文書における、RFC 2393 の実装者が注意すべき RFC 2393 からの変更点についてまとめる。
変更点のすべてが、IPsec と共に使用した場合の、IKE [IKE] を使用した IPComp アソシエーション(IPCA)の折衝について明確にするものである。

  1. IPComp を単独または保護スイート内で他のプロトコルと組み合わせて折衝することが可能であることを明確にした。

  2. IKE プロポーザルの SPI フィールドでの CPI を、2 オクテットフィールドを SHOULD、4 オクテットを MAY と定義した。
    4 オクテットフィールドでの 16 ビット CPI の置き方について定義した。
    受信者は両方のフィールド長を処理しなければならない (MUST) ことを指定した。

  3. デフォルトのカプセル化モードをトランスポートモードとして定義する文を追加した。
    トンネルモードのようにデフォルトでないカプセル化を提案する場合は、IPComp プロポーザルにカプセル化モード属性を含まなければならない (MUST) ことを要求した。

  4. サポートする属性のリストに、有効期間(Lifetime)属性を(トランスポートモードとともに)追加した。

  5. 保護スイートのトランスフォームにおける、IPComp に適用されない属性の処理方法を指定した。
    これらの属性は IPComp プロポーザルに含まれるべきではなく (SHOULD NOT)、IPCA のセッティング時や、IPComp の動作時には無視されなければならない (MUST)
    IPComp の実装は、他のトランスフォームの属性を含まない IPCOMP プロポーザルを決して拒否してはならない (MUST)

  6. 事前に定義された(ウェルノウン)範囲の CPI の折衝と使用についての、実装上の注意を追加した。
8. 参考文献 
[RFC0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. Or see: http://www.iana.org/numbers.html

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.

[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, 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.

著者の連絡先 
Abraham Shacham
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
United States of America
 
EMail: shacham@shacham.net
 
 
Bob Monsour
18 Stout Road
Princeton, New Jersey 08540
United States of America
 
EMail: bob@bobmonsour.com
 
 
Roy Pereira
Cisco Systems, Inc.
55 Metcalfe Street
Ottawa, Ontario K1P 6L5
Canada
 
EMail: royp@cisco.com
 
 
Matt Thomas
3am Software Foundry
8053 Park Villa Circle
Cupertino, California 95014
United States of America
 
EMail: matt@3am-software.com
 
 

翻訳者

東京都中央区新川1-21-2 茅場町タワー
株式会社 NTTデータ
技術開発本部
馬場 達也

EMail: babatt@nttdata.co.jp

コメント 
コメントは、ippcp@external.cisco.com メーリングリストまたは著者らに宛てられるべきである。
著作権表示全文 
Copyright (C) The Internet Society (2001). All Rights Reserved.

本文書とその翻訳は、複製および他に提供することができる。
また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。
ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。
インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合はそのかぎりでない。

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。

本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわない。
その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。

謝辞 
現在、RFC エディタの機能に対する資金は、インターネットソサエティによって提供されている。