原文：ftp://ftp.rfc-editor.org/in-notes/rfc1332.txt
この文書はインターネットコミュニティのための IAB 標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況は、 "IAB Official Protocol Standards" を参照して欲しい。この文書の配布は無制限である。
Point-to-Pint プロトコル(PPP)[1]は、 ポイントツーポイントリンク上でネットワーク層のプロトコル情報をカプセル化するための標準的手段を提供する。また PPP は拡張可能なリンクコントロールプロトコル(Link Control Protocol)も定義しており、様々なネットワーク層プロトコルの確立と設定とのためのネットワークコントロールプロトコル(Network Control Protocol:NCP)ファミリを提案してる。
この文書は、PPP 上でインターネットプロトコル(Internet Protocol)[2]の確立と設定とを行うための NCP と、PPP 上で Van Jacobson TCP/IP ヘッダ圧縮[3]をネゴシエートおよび利用する方法とを定義する。
この RFC は Internet Engineering Task Force (IETF) の Point-to-Point Protocol Working Group による成果物である。
PPP は３つの主要なコンポーネントを持つ：
ポイントツーポイントリンク上での通信を確立するために、まず最初に PPP リンクの両終端は、データリンクの設定とテストとを行うための LCP パケットを送信しなければならない。このリンクが確立し、LCP が必要としたオプション機能がネゴシエートされた後、PPP は１つ以上のネットワーク層プロトコルの選択と設定とを行うために、NCP パケットを送信しなければならない。選ばれた各ネットワーク層プロトコルが設定された時点で、各ネットワーク層プロトコルはそのリンク上でデータグラムを送信することが可能となる。
そのリンクは、LCP パケットまたは NCP パケットにより明示的にリンクが閉じられるか、何らかの外部イベント(不活性タイマーの期限切れや、ネットワーク管理者の介入)が発生するまで、通信のために設定された状態であり続けるだろう。
IP コントロールプロトコル (IPCP)は、ポイントツーポイントリンクの両終端において IP プロトコルモジュールの設定・有効化・無効化を行う責任を持つ。IPCP はリンクコントロールプロトコル(LCP)と同じパケット交換メカニズムを使用する。PPP がネットワーク層プロトコルのフェーズに達するまでは、IPCP パケットが交換されてはならない。そのフェーズに達する前に到達した IPCP パケットは、暗黙のうちに破棄されるべきである。
以下の例外を除き、IP コントロールプロトコルはリンクコントロールプロトコル[1] と正確に同じである。
IP パケットの通信が許可される前に、PPP はネットワーク層プロトコルのフェーズに達していなければならず、IP Control Protocol は Opened 状態に達していなければならない。
PPP データリンク層フレームの Information フィールド内に正確に１つの IPCP パケットがカプセル化される。そのフレームの Protocol フィールドは 16 進数の 8021(IP Control Protocol)である。
PPP リンク上を送信される IP パケットの最大長は、PPP データリンク層フレームの Information フィールドの最大長と同じである。それ以上の長さの IP データグラムは必要に応じて分割されなければならない。分割と再構築を避けたい場合、システムは TCP Maximum Segment Size オプション[4]と MTU discovery[5] とを使用するべきである。
IPCP Configuration Option は、Internet Protocol パラメータのネゴシエートを可能にする。IPCP は LCP[1] のために定義されているのと同じ構成オプションのフォーマットを、別のオプションセットと共に使用する。
IPCP Option Type フィールドの最新の値は、最新の "Assigned Numbers" RFC [6] で規定されている。現在、以下の値が割り当て済みである：
1 IP-Addresses
2 IP-Compression-Protocol
3 IP-Address
IP-Compression-Protocol のフォーマットの概要は以下の通りである。フィールドは左から右へ送信される。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
| 値(16進) | Protocol プロトコル |
| 002d | Van Jacobson Compressed TCP/IP |
IP-Address のフォーマットの概要は以下の通りである。フィールドは左から右へ送信される。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Van Jacobson TCP/IP ヘッダ圧縮は、TCP/IP ヘッダを最低３バイトにまで削減する。これは低速シリアル回線上の、特に対話的なトラフィックにおいては著しい改善である。
IP-Compression-Protocol は圧縮パケットを受け取る能力を表すために使用される。双方向圧縮を望む場合、リンク上の両終端はそれぞれにこの構成オプションを要求しなければならない。
IP パケットが送信される場合、PPP プロトコルフィールドには以下の値がセットされる：
|
|
|
| 0021 | Type IP。その IP プロトコルはTCP ではないか、パケットが分割されているか、圧縮できない。 |
| 002d | 圧縮 TCP。TCP/IP ヘッダは圧縮ヘッダに置き換えられる。 |
| 002f | 非圧縮 TCP。IP プロトコルフィールドはスロット識別子に置き換えられる。 |
Van Jacobson TCP/IP ヘッダ圧縮のネゴシエートに使用される IP-Compression-Protocol のフォーマットの概要は以下の通り。フィールドは左から右へ送信される。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-Slot-Id | Comp-Slot-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | スロット識別子は圧縮されてはならない。全ての圧縮 TCP パケットは全ての変更マスクの C ビットをセットしなければならず、またスロット識別子も含まなければならない。 |
| 1 | スロット識別子は圧縮されても良い。 |
以下の構成オプションが推奨されている：
IP-Compression-Protocol -- 最低でも 4 スロット、通常は 16 スロット。
IP-Address -- ダイアルアップ回線上でのみ。
この文書でセキュリティ問題は議論されていない。
[1] Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.
[2] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981.
[3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January 1990.
[4] Postel, J., "The TCP Maximum Segment Size Option and Related Topics", RFC 879, USC/Information Sciences Institute, November 1983.
[5] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[6] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990.
[7] Perkins, D., and R. Hobby, "Point-to-Point Protocol (PPP) initial configuration options", RFC 1172, August 1990.
この文書内の文章の一部は、Carnegie Mellon University の Drew Perkins と、Davis にある University of California の Russ Hobby とによる RFC 1171 および RFC 1172 に由来している。
拡張された IP-Compression へと誘導する情報は、SIGCOMM '90 において Van Jacobson により提供された。
Bill Simpson はこの文書の書式化を手助けしてくれた。
このワーキンググループには、以下の現代表者を通して連絡可能である：
Brian Lloyd
Lloyd & Associates
3420 Sudbury Road
Cameron Park, California 95682
Phone: (916) 676-1147
EMail: brian@ray.lloyd.com
この文書に関する質問は、以下のアドレスへ送って欲しい：
Glenn McGregor
Merit Network, Inc.
1071 Beal Avenue
Ann Arbor, MI 48109-2103
Phone: (313) 763-1203
EMail: Glenn.McGregor@Merit.edu