RFC1661 - The Point-to-Point Protocol (PPP)

このドキュメントは、インターネット社会の為のインターネット標準トラックプロトコルを規定しており、改善のための議論と提案を求めている。このプロトコルの標準化の状態と状況については、"Internet Official Protocol Standards" (STD 1) の現在の版を参照されたい。このメモの配布は制限されない。

Abstract

Point-to-Point Protocol (PPP) は、ポイントツーポイントリンク上で複数のプロトコルのデータグラムを転送する標準の方法を提供する。PPP は、3 つの主要コンポーネントを含む。

このドキュメントは、各種豊富な通信設定パラメタが折衝可能であり、付加的な管理機能を提供する拡張性のあるオプション折衝メカニズムと共に、PPP 構成と方法論と PPP カプセル化を定義する。PPP リンク制御プロトコル (LCP) は、このメカニズムで規定される。

1. 導入

ポイントツーポイントプロトコルは、二者間でパケットを送信する単純なリンクとして設計されている。これらのリンクは全二重同時両方向処理を提供し、パケットを順序通りに配送すると想定される。PPP は、広範囲に渡る多様なホスト、ブリッジ、ルータの容易なコネクションに対し、共通の解決方法を提供することを意図している。

カプセル化

PPP カプセル化は異なるネットワーク層プロトコルの、同一リンク上での多重化を提供する。PPP カプセル化は、最も一般的に使用されているサポートハードウェアと互換性を保つために、注意深く設計されている。

デフォルトの HDLC リンクフレーム内で使用される時、カプセルを形成するために必要な追加オクテットは 8 個だけである。帯域幅が高価な環境では、カプセル化やフレーム化を 2 か 4 オクテットに短くしてもよい。

高速な実装をサポートするために、デフォルトのカプセル化は単純なフィールドしか使用しない。多重分離のためにチェックする必要があるのは、その内の 1 つだけである。デフォルトヘッダと情報フィールドは 32 ビッド境界に入れられ、トレイラを任意の境界に詰めてもよい。

リンク制御プロトコル

広く多様な環境に移植可能なよう十分な融通性を持たせるために、PPP はリンク制御プロトコル (LCP: Link Control Protocol) を提供する。LCP は、カプセル化形式オプションを自動的に合意したり、パケットサイズに関する様々な制限を取り扱ったり、ループバックリンクやその他一般的な設定誤りを検出したり、リンクを終了させるために使用される。他のオプションで提供される機能は、リンク上の相手のアイデンティティの認証と、リンクがいつ機能的に適切化でありいつ不適切であるかの決定である。

ネットワーク制御プロトコル

ポイントツーポイントリンクは、ネットワークプロトコルの現在のファミリーが持つ多くの問題を悪化させる傾向にある。例えば、LAN 環境内でさえも問題になっている IP アドレスの割り当てや管理は、回線交換のポイントツーポイントリンク (例えばダイアルアップモデムサーバ) 上では特に困難である。これらの問題は、ネットワーク制御プロトコル (NCPs) のファミリーによって扱われる。それは各々、それぞれのネットワーク層プロトコルに要求される特定の必要性を管理する。これらの NCPs は、付随ドキュメントで定義される。

通信設定

PPP リンクは、通信設定が容易であるよう意図されている。設計により、標準のデフォルトは全ての共通的な通信設定を扱う。実装者はデフォルト設定の改善を指定でき、オペレータの介入なしで自動的に相手と通信できる。最終的には、別な方法では不可能な環境でリンクの操作を可能にするために、オペレータが明示的にリンクのオプションを設定してもよい。

この自己設定は拡張可能なオプション折衝メカニズムを通じて実装され、その中でリンクの各終端が他方に自分の機能や要求を示す。このドキュメントで規定されているオプション折衝メカニズムは、リンク制御プロトコル (LCP) で規定されるが、同じ機能は他の制御プロトコル、特に NCPs のファミリーで使用するために設計されている。

1.1. 要件の規定

このドキュメントでは、幾つかの単語が規約の要件を識別するために使用される。これらの単語は大抵大文字である。

MUST
この単語、あるいは形容詞 "required" は、その定義が規約の絶対的な要件であることを意味する。

MUST NOT
このフレーズは、その定義が規約の絶対的な禁止であることを意味する。

SHOULD
この単語、あるいは形容詞 "recommended" は、ある特定の環境でこの項目を無視する正当な理由があるかもしれないが、完全な実装はこれを理解し、別の方法を選択する前に慎重に熟慮しなければならないことを意味する。

MAY
この単語、あるいは形容詞 "optional" は、この項目は許容された代替セットの 1 つであることを意味する。このオプションを含まない実装体は、このオプションを含む別の実装体と相互動作するための用意をしていなければならない (MUST)。

1.2. 用語

データグラム (datagram)
ネットワーク層 (例えば IP) での転送単位。データグラムは、データリンク層に渡される 1 つ以上のパケットにカプセル化してもよい。

フレーム (frame)
データリンク層での転送単位。フレームは数個のデータ単位に加えて、ヘッダやトレイラを含んでもよい。

パケット (packet)
ネットワーク層とデータリンク層間のインターフェースを通じて渡される、カプセル化の基本単位。パケットは通常、フレームにマッピングされる。ただし、データリンク層の分割が実行される時や、複数のパケットが単一のフレームに組み込まれている時は例外である。

相手 (peer)
ポイントツーポイントリンクの他方の終端

黙って破棄 (silently discard)
実装体は、パケットを更なる処理を行わずに破棄する。実装体は、黙って破棄されたパケットの内容含めて、エラーをログにとる機能を提供すべきである (SHOULD)。そして、統計カウンタにイベントを記録すべきである (SHOULD)。

2. PPP カプセル化

PPP カプセル化は、複数プロトコルのデータグラムを明確にするために使用される。このカプセル化は、カプセルの開始と終了を示すためにフレーム化を必要とする。フレーム化を提供する方法は、付随ドキュメントで規定される。

PPP カプセル化の要約は、以下の通り。フィールドは左から右へ転送される。

+----------+-------------+---------+
| Protocol | Information | Padding |
| 8/16 bits|      *      |    *    |
+----------+-------------+---------+

Protocolフィールド

Protocol フィールドは 1, 2 個のオクテットであり、その値はパケットの Information フィールド中のカプセル化されたデータグラムを識別する。フィールドは、最上位オクテットが一番最初に送信、または受信される。

このフィールドの構造は、アドレスフィールドに関する ISO 3309 拡張メカニズムと一致している。全ての Protocol は奇数でなければならない (MUST)。すなわち、最下位オクテットの最下位ビットは、"1" でなければならない (MUST)。また、全ての Protocol は、最上位オクテットの最下位ビットが "0" であるように割り当てなければならない (MUST)。これらの規則に従わずに受信されたフレームは、認識されない Protocol を持つとして扱わなければならない (MUST)。

"0***" から "3***" の範囲の Protocol フィールドの値は、特定のパケットのネットワーク層プロトコルを識別する。"8***" から "b***" の範囲の値は、もしあれば、関連するネットワーク制御プロトコル (NCP: Network Control Protocol) に属しているパケットを識別する。

"4***" から "7***" の範囲の Protocol フィールドの値は、NCP に割り付けられていない低量トラフィックを持つプロトコルのために使用される。"c***" から "f***" の範囲の Protocol フィールドの値は、バケットをリンク層制御プロトコル (例えば LCP) として識別する。

プロトコルフィールドの最新の値は、最も最近の "Assigned Numbers" (RFC [2]) 中で規定される。この規約は以下の値を予約している。

新しいプロトコルの開発者は、IANA@isi.edu にある Internet 番号割り当てオーソリティ (IANA: Internet Assigned Numbers Authority) から番号を取得しなければならない (MUST)。

Information フィールド

Information フィールドは 0 個以上のオクテットである。Information フィールドは、Protocol フィールドで指定されたプロトコルのデータグラムを含む。

Padding を含み Protocol フィールドを含まない Information フィールドの最大長は、最大受信単位 (MRU: Maximum Receive Unit) という名称を持ち、そのデフォルトの値は 1500 オクテットである。折衝によって同意した PPP 実装は、MRU として別の値を使用してもよい。

Padding

転送する際、Information フィールドは MRU 以内の任意の個数のオクテットでパディングしてもよい (MAY)。パディングオクテットを実際の情報と区別することは、各プロトコルの責任である。

3. PPP リンク操作

3.1. 概要

ポイントツーポイントリンク上で通信路を確立するために、PPP リンクの各終端は、データリンクを通信設定し試験するために、最初に LCP パケットを送信しなければならない (MUST)。リンクが確立された後に、相手を認証してもよい (MAY)。

その後 PPP は、1 個以上のネットワーク層プロトコルを選択し、設定するために NCP パケットを送信しなければならない (MUST)。一旦、選択されたネットワーク層プロトコルの各々が設定されたら、各ネットワーク層プロトコルからデータグラムをそのリンク上に送信することができる。

リンクは、明示的な LCP か NCP パケットがリンクをクローズするか、ある外部事象が発生する (内部操作タイマが切れるか、ネットワーク管理者が介入する) まで、通信路は設定されたままである。

3.2. フェーズ図

ポイントツーポイントリンクを設定し保持し完了する処理において、PPP リンクは、以下の単純化された状態図で示されている幾つかの異なるフェーズを遷移する。

+------+        +-----------+           +--------------+        
|      | UP     |           | OPENED    |              | SUCCESS
| Dead |------->| Establish |---------->| Authenticate |--+/NONE
|      |        |           |           |              |  |     
+------+        +-----------+           +--------------+  |     
   ^               |                        |             |     
   |          FAIL |                   FAIL |             |     
   +<--------------+             +----------+             |     
   |                             |                        |     
   |            +-----------+    |           +---------+  |     
   |       DOWN |           |    |   CLOSING |         |  |     
   +------------| Terminate |<---+<----------| Network |<-+     
                |           |                |         |        
                +-----------+                +---------+

全ての遷移がこの図に示されているわけではない。以下のセマンティクスに従わなければならない (MUST)。

3.3. リンクデッド (物理層が準備されていない)

リンクは、必要に応じてこのフェーズを開始し終了する。外部イベント (例えば、キャリア検出やネットワーク管理者の通信設定等) が、物理層を使用する準備ができたことを示す時、PPP はリンク確立フェーズの手続きを行うだろう。

このフェーズの間に、LCP オートマトン (後述) は初期または開始状態になる。LCP オートマトンに Up イベントを信号で通知することにより、リンク確立フェーズへ遷移する。

実装注:
通常、リンクはモデムの切断の後、自動的にこのフェーズに戻る。ハード回線リンクの場合、このフェーズは極端に短いかもしれない。単にデバイスの存在を検出する時間でしかない。

3.4. リンク確立フェーズ

リンク制御プロトコル (LCP) は、通信設定パケットの交換を通じてコネクションを確立するために使用される。一旦、通信設定肯定パケット (後述) の送受信両方が行われると、この交換が完了し、LCP Open 状態に入る。

全ての通信設定オプションは、もし通信設定の交換による変更がなければ、デフォルト値が想定される。さらなる議論は、LCP 通信設定オプションのチャプタを参照されたい。

特定のネットワーク層プロトコルに依存しない通信設定オプションのみが、LCP によって設定されることを注意することは重要である。個々のネットワーク層プロトコルの通信設定情報は、ネットワーク層プロトコルフェーズの間に別々のネットワーク制御プロトコル (NCP) によって取り扱われる。

このフェーズの間に受信した非 LCP パケットは全て、黙って破棄しなければならない。

LCP 通信設定要求の受信によって、ネットワーク層プロトコルフェーズや認証フェーズからリンク確立フェーズへ戻される。

3.5. 認証フェーズ

あるリンクでは、ネットワーク層プロトコルパケットを交換する前に、自身の認証を相手に要求することが望ましいかもしれない。

デフォルトでは、認証は必須ではない。もし実装体がある特定の認証プロトコルで相手の認証を望むならば、リンク確立フェーズの間に認証プロトコルの使用を要求しなければならない (MUST)。

認証は、リンクを確立した後可能な限り早く実行すべきである (SHOULD)。しかし、リンク品質の決定が同時に発生しても良い (MAY)。実装体は認証を無期限に遅らせるようなリンク品質決定パケットの交換を許してはならない (MUST NOT)。

認証フェーズからネットワーク層プロトコルフェーズへは、認証が完了するまで移行してはならない。もし認証が失敗したら、認証者はリンク終了フェーズに代わりに移行すべきである (SHOULD)。

リンク制御プロトコルと認証プロトコルとリンク品質監視のパケットのみが、このフェーズでは許される。このフェーズの間に受信した他の全てのパケットは、黙って破棄しなければならない (MUST)。

実装注:
実装体は、単にタイムアウトや応答の欠落によって認証を失敗すべきではない (SHOULD NOT)。認証は、何回かの再送の方法を許し、認証の試みの回数がある回数を超えた後にのみ、リンク終了フェーズに移行すべきである (SHOULD)。

リンク終了フェーズの開始に責任のある実装体は、相手の認証を拒否した実装体である。

3.6. ネットワーク層プロトコルフェーズ

一旦 PPP が直前のフェーズを終了したら、各々のネットワーク層プロトコル (例えば IP, IPX, AppleTalk) は、適切なネットワーク制御プロトコル (NCP) によって別々に設定しなければならない (MUST)。

各 NCP はいかなる時もオープン／クローズされてよい (MAY)。

実装注:
実装体はリンク品質決定のために、大きな時間を使用するかもしれないので、実装体は相手が NCP を通信設定するのを待つ時、固定時間でのタイムアウトを避けるべきである (SHOULD)。

NCP が Opened 状態に達した後、PPP は対応するネットワーク層プロトコルのパケットを運ぶであろう。対応する NCP が Opened 状態でない時に受信した、サポートされたネットワーク層プロトコルパケットは、黙って破棄しなければならない (MUST)。

実装注:
LCP が Opened 状態である間、実装体によってサポートされていない如何なるプロトコルパケットもプロトコル拒否で返却しなければならない (後述)。サポートされているプロトコルのみが黙って破棄される。

このフェーズの間、リンクのトラフィックは LCP, NCP, ネットワーク層プロトコルのパケットのあり得る組み合わせから成る。

3.7. リンク終了フェーズ

PPP はいかなる時でもリンクを終了することができる。これは、キャリアの消失や、認証失敗、リンク品質失敗、アイドル期間タイマの満了、リンクの管理上の閉塞といった理由で行われるかもしれない。

終了パケットの交換を通じて、リンクをクローズするために LCP が使用される。リンクがクローズされる時、PPP はネットワーク層プロトコルに通知して、適切な動作を実行させる。

終了パケットの交換の後、実装体はリンクを強制終了するために、特に認証が失敗した場合、物理層に切断の合図を送るべきである (SHOULD)。終了要求の送信側は、終了確認を受信した後か、再開カウンタが満了した後に切断すべきである (SHOULD)。終了要求の受信側は、相手が切断するのを待つべきであり (SHOULD)、終了確認を送信後、少なくとも一回の再開時間が過ぎるまでは切断してはならない (MUST)。PPP はリンクデッドフェーズに移行すべきである (SHOULD)。

このフェーズで受信した全ての非 LCP パケットは、黙って破棄しなければならない。(MUST)

実装注:
LCP によるリンクのクローズで十分である。各 NCP が終了パケットを慌てて送信する必要性はない。逆に、一つの NCP がクローズしたという事実は PPP リンクを終了させるのに十分な理由とはならない。たとえ、その NCP が現在オープン状態である唯一の NCP であってもである。

4. オプション折衝オートマトン

有限状態のオートマトンは、イベント、アクション、状態遷移によって定義される。イベントは、オープンやクローズ等の外部コマンドの受信、再開タイマの満了、相手からのパケット受信を含む。アクションは、再開タイマの開始や相手へのパケット再送を含む。

幾つかのパケット (通信設定否定応答や通信設定拒否、コード拒否やプロトコル拒否、エコー要求、エコー応答、破棄要求)は、オートマトン記述の中では区別されない。後述するが、これらのパケットは、実際には異なる機能を実行させる。しかし、これらは常に同じ遷移を引き起こす。

4.1 状態遷移図

完全な状態遷移表は以下の通りである。状態は行で示され、イベントは列で読める。

状態遷移とアクションは、アクション/新状態の形式で表される。複数のアクションはカンマによって区切られ、空白を必要として継続行に続くかもしれない。複数のアクションは、いかなる便利な順序で実装されてもよい。状態には、解説の脚注を示す文字が後続するかもしれない。ダッシュ('-')は、無効な遷移を示す。

再開タイマが作動している状態は、TO イベントの存在によって識別可能である。通信設定要求送信、終了要求送信、再開始数零クリアのアクションのみが開始されるか、再開タイマを再起動する。再開タイマは、タイマが作動している状態から、タイマが作動していない状態に遷移するときに停止する。

イベントとアクションは、アーキテクチャへの信号通知アーキテクチャではなく、メッセージ渡しアーキテクチャによって定義される。もしあるアクションが特殊な信号 (例えば DTR) の制御を望むならば、アクションの追加が必要になるだろう。

[p] オプションを渡す。停止状態の議論参照。
[r] 再開オプション。オープンイベントの議論参照。
[x] コネクション衝突。RCA イベントの議論参照。

4.2. 状態

初期状態 (Initial)

初期状態では、下位層は利用できず (停止)、オープンは発生していない。初期状態では、再開タイマは作動していない。

開始中状態 (Starting)

開始中状態は、初期状態とオープンの対である。管理上オープンが起動されたが、下位層はまだ利用できない (停止)。再開タイマは、開始中状態では作動していない。

下位層が利用可能になったとき (起動)、通信設定要求が送信される。

クローズ状態 (Closed)

クローズ状態では、リンクは利用可能である (起動中) が、オープンは発生していない。再開タイマは、クローズ状態では作動していない。

通信設定要求パケットを受信すると終了肯定応答を送信する。終了肯定応答は、ループを避けるために黙って破棄される。

停止状態 (Stopped)

停止状態はクローズ状態とオープンの対である。この層の終了アクションか終了肯定応答を送信した後で、オートマトンが停止イベントを待っている時にこの状態に入る。停止状態では、再開タイマは作動していない。

通信設定要求パケットを受信すると、適切な応答が送信される。他のパケットを受信すると、終了肯定応答が送信される。終了肯定応答は、ループを避けるために黙って破棄される。

原理的説明:
停止状態は、リンク終了、リンク通信設定失敗、他のオートマトンの失敗モードで合流する状態である。これらの潜在的に別々の状態は、結合される。

停止イベント応答 (この層の終了アクションからの) と通信設定要求受信イベントとの競争状態が存在する。通信設定要求が停止イベントの前に到達した時、停止イベントはオートマトンが開始状態に戻ることによって置き換わる。これは繰り返しによる攻撃を防ぐ。

実装オプション:
相手が通信設定要求への応答に失敗した後、実装体は相手が通信設定要求を送信するのを消極的に待ってもよい (MAY)。この場合、Req-Sent, Ack-Rcvd, Ack-Sent 状態での TO- イベントでは、この層の終了動作が使用されない。

このオプションは専用回線か、利用可能な状態信号を持たない回線で有効であるが、交換回線では使用すべきでない。

クローズ中 (Closing)

クローズ中状態では、コネクションを終了する試みがなされる。終了要求が送信され、再開タイマが作動しているが、終了肯定応答をまだ受信していない。

終了肯定応答を受信するとクローズ状態に入る。再開タイマが満了すると新たな終了要求が送信され、再開タイマが再度開始される。再開タイマが最大終了回数に達した後、クローズ状態に入る。

停止中 (Stopping)

停止中状態はクローズ中状態とオープンの対である。終了要求が送信され再開タイマが作動しているが、終了肯定応答はまだ受信していない。

原理的説明: 停止中状態は、新しいトラフィックを許す前にリンクを終了するために、明確な機会を提供する。リンクが終了した後、新しい通信設定が停止状態か開始中状態を経て発生してもよい。

要求送信 (Request-Sent)

要求送信状態では、コネクションを設定する試みがなされる。通信設定要求が送信され再開タイマは作動しているが、通信設定肯定応答をまだ受信していないか、まだ送信していない。

肯定応答受信 (Ack-Received)

肯定応答受信状態では通信設定要求を送信し、通信設定肯定応答を受信した。通信設定肯定応答をまだ送信していないので、再開タイマはまだ作動している。

肯定応答送信 (Ack-Sent)

肯定応答送信状態では、通信設定要求と通信設定肯定応答の両方を送信したが、通信設定肯定応答をまだ受信していない。通信設定肯定応答をまだ送信していないので、再開タイマはまだ作動している。

オープン (Opened)

オープン状態では、通信設定肯定応答を送信と受信の両方を行った。再開タイマは作動していない。

オープン状態に入ったとき、実装体は上位層に今アップしたことを通知すべきである (SHOULD)。逆にオープン状態から抜けるとき、実装体は上位層に今ダウンしたことを通知すべきである (SHOULD)。

4.3. イベント

オートマトンの遷移とアクションは、イベントによって引き起こされる。

アップ (Up)

このイベントは、下位層がパケットを運ぶ準備がなされていることを示す時使用される。

通常このイベントは、モデム操作や発呼処理、あるいは物理媒体への PPP リンクの連結によって、リンクがリンク確立フェーズに入ったことを LCP に通知するために使用される。

また、LCP が各々の NCP に、リンクがネットワーク層プロトコルフェーズに入ったことを通知することにも使用できる。

ダウン (Down)

このイベントは、下位層がもはやパケットを運ぶ準備がされていないことを通知する時発生する。

通常このイベントは、モデム操作や発呼処理、あるいは物理媒体への PPP リンクの連結によって、リンクがリンク終了フェーズに入ったことを LCP に通知するために使用される。

また、LCP が各々の NCP に、リンクがネットワーク層プロトコルフェーズから抜けることを通知することにも使用できる。すなわち、LCP からのこの層の停止アクションが、NCP におけるダウンイベントのトリガとなる。

オープン (Open)

このイベントは、リンクがトラフィックのために管理上利用可能であること、すなわち、ネットワーク管理者 (人間かプログラム) がリンクをオープンするのを許可したことを示す。このイベントが発生したとき、リンクはオープン状態ではなく、オートマトンは相手に通信設定パケットの送信を試みる。

もしオートマトンが通信設定を開始することが出来ないならば (下位層が停止しているか、以前のクローズイベントが完了していない)、リンクの確立は自動的に遅らされる。

終了要求を受信した時、あるいはリンクを利用不可にする他のイベントが発生した時、オートマトンはリンクの再オープンが準備された状態に遷移するだろう。さらに管理上で介在することは不要である。

実装オプション:

経験則では、ユーザはリンクを再折衝したい時に追加のオープンコマンドを実行する。これは、新しい値の折衝を示すかもしれない。

これはオープンイベントの手段ではないので、オープンのユーザイベントがオープン、クローズ中、停止中、停止状態で実行される時、実装体がダウンイベントを発行し、直後にアップイベントを発行することが提案されている。間に入るダウンイベントは、別の送信元から発生できないことに注意しなければならない。

アップに続くダウンイベントは、開始中状態を経由して要求送信状態へ遷移することによって順序的にリンクの再折衝を引き起こすだろう。これにより、有害な副作用無しにリンクの再折衝が行われる。

クローズ (Close)

このイベントは、リンクがトラフィックで利用できないこと、すなわち、ネットワーク管理者 (人間かプログラム) がリンクのオープン不可を指示したことを示す。このイベントが発生した時、リンクはクローズ状態ではなく、オートマトンはコネクションの終了を試みる。さらに、新しいオープンイベントが発生するまで、リンクの再設定要求を拒否する。

実装注:
認証が失敗した時、繰り返しによる攻撃や他のユーザへのサービス拒否を防ぐためにリンクを終了すべきである (SHOULD)。リンクは管理上利用可能なので (定義により)、これは LCP へのクローズイベントと直後のオープンイベントを擬似することによって実現できる。間に入るクローズイベントは、別の送信元から発生できないことに注意しなければならない。

オープンに続くクローズイベントは、クローズ中状態を経由して停止中状態へ遷移することによって順序的にリンクの終了を引き起こすだろう。そして、この層の終了動作がリンクを切断出来る。オートマトンは、停止状態か開始中状態で次のコネクションの試みを待つ。

タイムアウト (TO+,TO-)

このイベントは再開始タイマの満了を示す。再開始タイマは、通信設定要求と終了要求パケットの応答時間に使用される。

TO+ イベントは、再開始カウンタが 0 より大きく、継続することを示し、通信設定要求と終了要求パケットの再送のトリガになる。

TO- イベントは、再開カウンタが 0 以下であることを示し、もはや何のパケットも再送されない。

通信設定要求受信 (RCR+,RCR-)

このイベントは、通信相手から通信設定要求パケットを受信した時発生する。通信設定要求パケットは、コネクションをオープンしたいことと、通信設定オプションを特定することを示す。通信設定要求パケットの詳細については、後続のセクションで説明されている。

RCR+ イベントは、通信設定要求が受諾されたことを示し、通信設定肯定応答の送信のトリガとなる。

RCR- イベントは通信設定要求が受諾されず、通信設定否定応答か通信設定拒否の送信のトリガとなる。

実装注:
これらのイベントは、既にオーブン状態のコネクション上で発生するかもしれない。実装体は、その通信設定オプションを即座に再折衝する準備がなされていなければならない。(MUST)

通信設定肯定応答受信 (RCA)

このイベントは、通信相手から正しい通信設定肯定応答パケットを受信した時発生する。通信設定肯定応答パケットは、通信設定要求パケットに対する肯定的な応答である。シーケンス外での受信や他の不正なパケットは黙って破棄される。

実装注:
肯定応答受信状態やオープン状態では正しいパケットを既に受信しているので、別のそうしたパケットが到達することは、極めて希である。規定されているように、あらゆる不正な肯定応答/否定応答/拒否パケットは黙って破棄され、オートマトンには何の影響も及ぼさない。

しかし、正しい形式のパケットが一致したクロスコネクションを通じて到達することは有り得ない。実装誤りの結果として引き起こされる可能性の方が高い。少なくとも、この発生はログに採取すべきである (SHOULD)。

通信設定否定応答/拒否受信 (RCN)

このイベントは、通信相手から正しい通信設定否定応答パケットか通信設定拒否パケットを受信した時発生する。通信設定否定応答パケットは、通信設定要求パケットに対する否定的な応答である。シーケンス外での受信や他の不正なパケットは黙って破棄される。

実装注:
通信設定否定応答と通信設定拒否は、オートマトンにおいて同じ状態遷移を引き起こすが、これらのパケットは通信設定要求パケットの結果として送信された通信設定オプション上に、意味が異なる効果を及ぼす。

終了要求受信 (RTR)

このイベントは、終了要求を受信したとき発生する。終了要求パケットは通信相手がコネクションをクローズしたいことを示す。

実装注:
このイベントはクローズイベント (上記参照) と同じではなく、自側ネットワーク管理者オープンコマンドを上書きしない。実装体はネットワーク管理者が介在することなく、新しい通信設定要求の受信が準備されていなければならない (MUST)。

終了肯定応答受信 (RTA)

このイベントは、終了肯定応答を通信相手から受信したとき発生する。終了肯定応答パケットは通常、終了要求パケットの応答である。終了肯定応答パケットは通信相手がクローズか停止状態で、リンク再設定の再同期を受けることを示してもよい。

未知コード受信 (RUC)

このイベントは、通信相手から解釈できないパケットを受信したとき発生する。コード拒否パケットが応答で送信される。

コード拒否受信、プロトコル拒否受信 (RXJ+,RXJ-)

このイベントは、コード拒否かプロトコル拒否パケットを通信相手から受信したとき発生する。

RXJ+ イベントは、例えば拡張コードのコード拒否や NCP のプロトコル拒否のように、拒否された値が許容可能である場合に発生する。これらは通常処理の範囲内である。実装体は、拒否されたパケットタイプの送信を止めなければならない (MUST)。

RXJ- イベントは、例えば通信設定要求のコード拒否や LCP のプロトコル拒否のように、拒否された値が致命的である場合に発生する。このイベントはコネクションを終了する回復不能なエラーを通知する。

エコー要求受信、エコー応答受信、破棄要求受信 (RXR)

このイベントは、エコー要求、エコー応答、破棄要求パケットを通信相手から受信したとき発生する。エコー応答パケットはエコー要求パケットの応答である。エコー応答と破棄要求パケットの応答はない。

4.4. アクション

オートマトン中のアクションはイベントによって引き起こされ、通常、パケットの送信や再開始タイマの開始か停止を示す。

不正イベント (-)

これは、正しく実装されたオートマトンでは発生し得ないイベントを示す。実装体は通知やログ採取すべき内部エラーを持つ。何の遷移も行われず、実装体はリセットやフリーズすべきではない (SHOULD NOT)。

この層の起動 (tlu)

このアクションは、オートマトンがオープン状態に入ったことを上位層に示す。

通常、このアクションはアップイベントを NCP や認証プロトコル、リンク品質プロトコルに通知するために、LCP によって使用される。あるいは、リンクがネットワーク層のトラフィックで利用可能であることを示すために、NCP が使用してもよい (MAY)。

この層の停止 (tld)

このアクションは、オートマトンがオープン状態から抜けたことを上位層に示す。

通常、このアクションはダウンイベントを NCP や認証プロトコル、リンク品質プロトコルに通知するために、LCP によって使用される。あるいは、リンクがネットワーク層のトラフィックでもう利用不可であることを示すために、NCP が使用してもよい (MAY)。

この層の開始 (tls)

このアクションは、オートマトンが開始状態に入ったことを下位層に示し、下位層がリンクで必要とされる。下位層は下位層が利用可能であるとき、アップイベントで応答すべきである (SHOULD)。

この層の終了 (tlf)

このアクションは、オートマトンが初期、クローズ、停止状態に入ったことを下位層に示し、下位層はもはやリンクで必要とされない。下位層は下位層が終了したとき、ダウンイベントで応答すべきである (SHOULD)。

通常、このアクションは、リンク終了フェーズに移行するために LCP が使用してもよい (MAY) し、他の NCP がオープンしていないときに、リンクを終了してもよいことを NCP が LCP に示すのに使用してもよい (MAY)。

再開始数の初期化 (irc)

このアクションは、再開始カウンタを適切な値 (最大終了回数か最大通信設定数) に設定する。このカウンタは、最初の送信を含む各々の送信毎に 1 ずつ減らされる。

実装注:
再開始カウンタの設定に加え、再開始タイマバックオフが使用されるとき、実装体はタイムアウト間隔に初期値を設定しなければならない (MUST)。

再開始数を零クリア (zrc)

このアクションは、再開始数を 0 に設定する。

実装注:
このアクションは、FSA が望ましい最終状態に進む前に停止することを可能にし、トラフィックが通信相手によって処理されることを可能にする。再開始数を 0 にすることに加え、実装体はタイムアウト間隔に適切な値を設定しなければならない (MUST)。

通信設定要求の送信 (scr)

通信設定要求パケットを送信する。これは、指定されたセットの通信設定オプションでコネクションをオープンしたいことを示す。通信設定要求パケットが送信されたら、パケット損失をカバーするために再開始タイマを開始する。再開始カウンタは、通信設定要求を送信する毎に 1 ずつ減らされる。

通信設定肯定応答の送信 (sca)

通信設定肯定応答パケットを送信する。これは、受諾可能な通信設定オプションのセットを持った通信設定要求パケットの受信を確認する。

通信設定否定応答送信 (scn)

通信設定否定応答か通信設定拒否を適宜送信する。この否定応答は、受諾できない通信設定オプションのセットを持った通信設定要求パケットの受信を通知する。

通信設定否定応答パケットは通信設定オプションを拒否し、新たに受諾可能な値を提案するのに使用する。通信設定拒否パケットは、一般的には認識不可か未実装のために、通信設定オプションに関する全ての折衝を拒否するのに使用される。通信設定否定応答と通信設定拒否の使用については、LCP パケット形式のチャプタで詳細に説明されている。

終了要求送信 (str)

終了要求パケットを送信する。これはコネクションのクローズを望んでいることを示す。パケット損失をカバーするために、終了要求パケットを送信するとき、再開始タイマを開始する。再開始カウンタは、終了要求を送信する毎に 1 ずつ減らされる。

終了肯定応答送信 (sta)

終了肯定応答パケットを送信する。これは終了要求パケットの受信を確認するか、それ以外はオートマトンの同期をとる。

コード拒否送信 (scj)

コード拒否パケットを送信する。これは未知のタイプのパケットを受信したことを示す。

エコー応答送信 (ser)

エコー応答パケットを送信する。これはエコー要求パケットの受信を確認する。

4.5. ループ回避

プロトコルは、通信設定オプションの折衝ループを避ける効率的な試みを行う。しかし、プロトコルはループが起こらないことを保証してはいない。ある折衝において、二つの PPP 実装体が決して収束することの無い相反するポリシーを持って通信設定を行う可能性はある。通信設定ポリシーは収束はするが、それまでに大きな時間がかかる可能性もある。実装者はこのことに注意し、ループ検出メカニズムか上位レベルでのタイムアウトを実装すべきである (SHOULD)。

4.6. カウンタとタイマ

再開始タイマ

オートマトンによって使用される一つの特別なタイマが存在する。通信設定要求と終了要求パケットを転送する時を指定するために、再開始タイマが使用される。再開始タイマが満了するとタイムアウトイベントが引き起こされ、該当する通信設定要求か終了要求パケットが再送される。再開始タイマは設定可能でなければならないが (MUST)、デフォルト値は三秒にすべきである (SHOULD)。

実装注:
再開始タイマは、リンクの速度に基づくべきである (SHOULD)。デフォルト値は低速度 (2,400～9,600bps) で、大きな切り替え待ち時間のあるリンク (一般的に電話回線) のために設計されている。より高速のリンク、あるいは小さな切り替え待ち時間のリンクでは、それに応じてより早い再送時間にすべきである (SHOULD)。

固定値の代わりに、再開始タイマは小さい初期値から開始して、設定された最終値まで値を増加させても良い (MAY)。最終値より小さい各々の継続値は、少なくとも前の値の二倍にすべきである (SHOULD)。初期値はパケットのサイズを考慮して、リンク速度の転送におけるラウンドトリップ時間の二倍に、通信相手が応答を返す前に処理できるよう少なくとも 100ミリ秒追加した大きさにすべきである (SHOULD)。ある回線では衛星遅延の 200ミリ秒を更に追加する。14,400 bpsを扱うモデムのラウンドトリップ時間は、160～600ミリ秒の範囲で計測されている。

最大終了要求数

終了要求で必要な再開始カウンタが存在する。最大終了要求数は、通信相手が応答できないと仮定する前に、終了肯定応答未受信の送信済み終了要求の数を示す。最大終了要求数は設定可能でなければならず (MUST)、デフォルト値は 2 回の送信にすべきである (SHOULD)。

最大通信設定要求数

同様なカウンタが通信設定要求でも推奨される。最大通信設定要求数は、通信相手が応答できないと想定する前に、正しい通信設定肯定応答、通信設定否定応答、通信設定拒否を受信せずに送信する通信設定要求の数を示す。最大通信設定要求数は設定可能でなければならない (MUST) が、デフォルトは 10 回の送信にすべきである (SHOULD)。

最大失敗数

関連するカウンタが通信設定否定応答で推奨される。最大失敗数は通信設定が収束しないと想定する前に、通信設定肯定応答を送信せずに送信する通信設定要求の数を示す。オプションを要求する通信相手に向けての以降の通信設定否定応答パケットは、通信設定拒否に変更され、ローカルに望むオプションはもう付加されない。最大失敗数は設定可能でなければならず (MUST)、デフォルトは 5 回の送信にすべきである (SHOULD)。

5. LCP パケット形式

単純化するため、LCP パケットにはバージョンフィールドが存在しない。正しい機能を持つ LCP 実装体は、未知のプロトコルやコードに対して、簡単に認識できる LCP パケットで常に応答する。従って、他のバージョンの実装体のために決定論的な代替機構を提供する。

どの通信設定オプションが利用可能かに関わらず、全ての LCP リンク設定、リンク終了、コード拒否パケット (コード 1～7) は常に、あたかも何の通信設定オプションも折衝されないかのように送信される。特に、各々の通信設定オプションはデフォルト値を示す。これは、一方の終端が誤ってリンクがオープンされると信じているときでさえ、そのような LCP パケットが常に認識可能であることを保証する。

正確に一つの LCP パケットは PPP 情報フィールドでカプセル化され、PPP プロトコルフィールドは 16進の c021 (リンク制御プロトコル) のタイプを示す。

リンク制御プロトコルパケット形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...                                                    
+-+-+-+-+

Code

コードフィールドは 1 オクテットで、LCP パケットの種類を識別する。未知のコードフィールドを持つパケットを受信したとき、コード拒否パケットが送信される。

最新の LCP コードフィールドは最新の "番号割当て" [2]で規定される。このドキュメントは以下の値を考慮している。

Identifier

識別子フィールドは 1 オクテットであり、要求と応答の照合を助ける。不正な識別子フィールドを持つパケットを受信したとき、オートマトンに何の影響も及ぼさず黙って破棄する。

Length

長さフィールドは 2 オクテットで、Code, Identifier, Length, Data フィールドを含む LCP パケットの長さを示す。長さはリンクの MRU を超えてはならない (MUST NOT)。

長さフィールドの範囲外のオクテットはパディングとして扱われ、受信時に無視される。不正な長さフィールドを持つパケットを受信したとき、オートマトンに何の影響も及ぼさず黙って破棄する。

Data

データフィールドは、長さフィールドによって示される 0 個以上のオクテットである。データフィールドの形式は、コードフィールドによって決まる。

5.1. 通信設定要求

説明

コネクションをオープンしたい実装体は、通信設定要求を送信しなければならない (MUST)。オプションフィールドには、リンクのデフォルトに望む変更を指定する。通信設定オプションは、デフォルト値を含むべきではない (SHOULD NOT)。

通信設定要求の受信時に、適切な応答を送信しなければならない (MUST)。

通信設定要求パケット形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...                                                    
+-+-+-+-+

Identifier

識別子フィールドは、オプションフィールドの内容が変わる場合や、前の要求に対して正しい応答を受信したときには必ず変更しなければならない (MUST)。再送の場合は、識別子は変えなくてもよい (MAY)。

Options

オプションフィールドは長さが可変で、送信側が折衝したいと望む 0 個以上の通信設定オプションを含む。全ての通信設定オプションは、必ず同時に折衝される。通信設定オプションの形式の詳細は、後のチャプタで説明される。

5.2. 通信設定肯定応答

説明

もし、受信した通信設定要求内の全ての通信設定オプションが認識可能で、受諾できるならば、実装体は通信設定肯定応答を送信しなければならない (MUST)。肯定した通信設定オプションは、順番を変えたり何らかの修正を施してはならない (MUST NOT)。

通信設定肯定応答の受信時に、識別子フィールドを最後に送信した通信設定要求の識別子と照合しなければならない (MUST)。加えて、通信設定肯定応答内の通信設定オプションを、最後に送信した通信設定要求のオプションと正確に照合しなければならない (MUST)。不正なパケットは、黙って破棄される。

通信設定肯定応答パケット形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...                                                    
+-+-+-+-+

Identifier

識別子フィールドは、この通信設定肯定応答の契機となった通信設定要求の識別子フィールドのコピーである。

Options

オプションフィールドは長さが可変で、送信側が確認した 0 個以上の通信設定オプションを含む。全ての通信設定オプションは、必ず同時に肯定される。

5.3. 通信設定否定応答

説明

もし受信した通信設定オプションの全てのインスタンスが認識可能だが、いくつかの値が受諾できないならば、実装体は通信設定否定応答を送信しなければならない (MUST)。オプションフィールドには、通信設定要求の中で受諾できない通信設定オプションのみを指定する。受諾できる全ての通信設定オプションは、通信設定否定応答からは除外するが、それ以外は通信設定要求の通信設定オプションの順番を変えてはならない (MUST NOT)。

値フィールドを持たないオプション (論理型オプション) は、通信設定拒否を使用しなければならない (MUST)。

単一のインスタンスのみ許される各々の通信設定オプションは、通信設定否定応答の送信者で受諾できる値に修正しなければならない (MUST)。要求された値がデフォルト値と異なる場合、デフォルト値を使用してもよい (MAY)。

最後に、実装体は特定のオプションの折衝を要求するために設定してもよい。もしそのオプションがリスト化されていなければ、そのオプションを次の通信設定要求パケットに含めることを通信相手に促すために、否定応答のリストに追加してもよい (MAY)。オプションのいかなる値フィールドも、通信設定否定応答の送信者が受諾できる値を指定しなければならない (MUST)。

最後に、実装体は特殊なオプションの折衝を要求するために設定するかもしれない。もしそのオプションがリスト化されていないならば、そのオプションを次の通信設定要求パケットに含めることを通信相手に促すために、否定応答のリストに追加してもよい(MAY)。オプションのいかなる値フィールドも、通信設定否定応答の送信者が受諾できる値を示す。

通信設定否定応答の受信時に、識別子フィールドは最後に送信した通信設定要求の識別子と一致しなければならない (MUST)。不正なパケットは、黙って破棄する。

正しい通信設定否定応答の受信は、新たに通信設定要求を送信する時に、通信設定否定応答に指定された通りに通信設定オプションを修正してもよい (MAY) ことを示す。通信設定オプションの複数のインスタンスが提供されている場合、通信相手は次の通信設定要求パケットで一つの値を選択するべきである (SHOULD)。

いくつかの通信設定オプションは可変の長さを持つ。否定応答のオプションは通信相手によって変更されるので、実装体は元の通信設定要求とは異なるオプション長を扱えなければならない (MUST)。

通信設定否定応答パケット形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...                                                    
+-+-+-+-+

Identifier

識別子フィールドは、この通信設定否定応答の契機となった通信設定要求の識別子フィールドのコピーである。

Options

オプションフィールドは長さが可変で、送信側が否定する 0 個以上の通信設定オプションのリストを含む。全ての通信設定オプションは、必ず同時に否定される。

5.4. 通信設定拒否

説明

もし受信した通信設定オプションの幾つかのインスタンスが認識できないか、折衝において受諾できないならば (ネットワーク管理者によって設定される)、実装体は通信設定拒否を送信しなければならない (MUST)。オプションフィールドには、通信設定要求の中で受諾できない通信設定オプションのみを指定する。認識でき受諾できる全ての通信設定オプションは、通信設定否定応答からは除外するが、それ以外は通信設定要求の通信設定オプションの順番を変えてはならない (MUST NOT)。

通信設定拒否の受信時に、識別子フィールドは最後に送信した通信設定要求の識別子と一致しなければならない (MUST)。加えて、通信設定拒否の通信設定オプションは、最後に送信された通信設定要求の適切なサブセットでなければならない (MUST)。不正なパケットは、黙って破棄する。

正しい通信設定拒否の受信は、新たに通信設定要求を送信する時に、通信設定拒否にリスト化された通信設定オプションを含めてはならない (MUST NOT) ことを示す。

通信設定拒否パケット形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...                                                    
+-+-+-+-+

Identifier

識別子フィールドは、この通信設定拒否の契機となった通信設定要求の識別子フィールドのコピーである。

Options

オプションフィールドは長さが可変で、送信側が拒否する 0 個以上の通信設定オプションのリストを含む。全ての通信設定オプションは、必ず同時に拒否される。

5.5. 終了要求と終了肯定応答

説明

LCPはコネクションをクローズするメカニズムを提供するために、終了要求と終了肯定応答を含む。

コネクションをクローズしたい実装体は、終了要求を送信すべきである (SHOULD)。終了肯定応答を受信するか、下位層がダウンしたことを示すか、通信相手が効率的な確実性を以ってダウンしたと判断できる程十分な回数送信するまで、終了要求パケットを送信し続けるべきである (SHOULD)。

終了要求の受信時に、終了肯定応答を送信しなければならない (MUST)。

意図的でない終了肯定応答は、通信相手がクローズ状態か停止状態にいるか、さもなくば再折衝を必要としていることを示す。

終了要求と終了肯定応答パケット形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...                                                    
+-+-+-+-+

Identifier

送信する際、データフィールドの内容が変わる場合や、前の送信に対して正しい応答を受信した場合は、必ず識別子フィールドを変更しなければならない (MUST)。再送の場合は、識別子フィールドを変更しなくてもよい (MAY)。

受信時、終了要求の識別子フィールドは、終了肯定応答パケットの識別子フィールドにコピーされる。

Data

データフィールドは 0 個以上のオクテットであり、送信者が使用する解釈されないデータを含む。データはいかなるバイナリ値で構成されてもよい。フィールドの最終は、長さによって示しされる。

5.6. コード拒否

説明

未知のコードを持つ LCPパケットの受信は、通信相手が異なるバージョンで処理していることを示す。これは、コード拒否を送信することによって未知のコードの送信者に報告しなければならない (MUST)。

コードがプロトコルのこのバージョンにとって主要なものであるコード拒否の受信時は、状況が自動的に改正されなさそうなので、実装体は問題を報告し、コネクションを落とすべきである (SHOULD)。

コード拒否パケット形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected-Packet ...                                            
+-+-+-+-+-+-+-+-+

Identifier

識別子フィールドは、コード拒否の送信毎に変更しなければならない (MUST) 。

Rejected-Packet

拒否パケットフィールドは、拒否しようとしている LCP パケットのコピーを含む。それは情報フィールドから始まり、いかなるデータリンクヘッダも FCS も含まない。拒否パケットは、通信相手の確立した MRU に応じて切りつめなければならない (MUST) 。

5.7. プロトコル拒否

説明

未知のプロトコルフィールドを持つ PPP パケットの受信は、通信相手が未サポートのプロトコルの使用を試みていることを示す。これは通常、通信相手が新しいプロトコルの通信設定要求を試みる時に発生する。もし LCP オートマトンがオープン状態であるならば、プロトコル拒否を送信することによって通信相手に報告しなければならない (MUST)。

プロトコル拒否の受信時は、実装体は最も早い機会に指定されたプロトコルのパケットの送信を停止しなければならない (MUST)。

プロトコル拒否パケットは、LCP オープン状態でのみ送信できる。LCP オープン状態以外で受信したプロトコル拒否パケットは、黙って破棄すべきである (SHOULD)。

プロトコル拒否パケット形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Rejected-Protocol       |      Rejected-Information ...  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Identifier

識別子フィールドは、プロトコル拒否の送信毎に変更しなければならない (MUST)。

Rejected-Protocol

拒否プロトコルフィールドは 2 オクテットであり、拒否しようとしているパケットのPPPプロトコルフィールドを含む。

Rejected-Information

拒否情報フィールドは、拒否しようとしているパケットのコピーを含む。それは情報フィールドから始まり、いかなるデータリンクヘッダも FCS も含まない。拒否情報は、通信相手の確立した MRU に応じて切りつめなければならない (MUST)。

5.8. エコー要求、エコー応答

説明

LCP はリンクの両方向を動作させる際に使用する、データリンク層のループバックメカニズムを提供するために、エコー要求とエコー応答を含む。これは、デバッグやリンク品質の決定、パフォーマンスのテストや他の数多くの機能の補助とし有用である。

LCP オープン状態でエコー要求を受信したら、エコー応答を送信しなければならない (MUST)。

エコー要求とエコー応答パケットは、LCP オープン状態でのみ送信できる。LCP オープン状態以外で受信したエコー要求とエコー応答パケットは、黙って破棄すべきである (SHOULD)。

エコー要求とエコー応答パケット形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Magic-Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...                                                    
+-+-+-+-+

Identifier

送信時、識別子フィールドはデータフィールドの内容が変わる時、及び前の送信に対する正しい応答を受信した時は常に、変更しなければならない (MUST)。再送時は、識別子フィールドを変更しなくてもよい (MAY)。

受信時、エコー要求の識別子フィールドは、エコー応答パケットの識別子フィールドにコピーされる。

Magic-Number

マジックナンバーフィールドは 4 オクテットであり、ループバック状態にあるリンクを検出する際の補助になる。マジックナンバーの通信設定オプションが正常に折衝されるまで、マジックナンバーは 0 で送信しなければならない (MUST)。マジックナンバーの通信設定オプションについては、後続の説明を参照されたい。

Data

データフィールドは 0 個以上のオクテットで、送信者によって使用される解析されないデータを含む。このデータはいかなるバイナリ値で構成されてもよい。フィールドの最終は長さフィールドによって識別される。

5.9. 破棄要求

説明

LCP は、ローカルからリモートへのリンクの方向を動作させる際に使用する、データリンク層のシンクメカニズムを提供するために破棄要求コードを含む。これは、デバッグやパフォーマンスのテスト、その他の数多くの機能の補助として有用である。

破棄要求パケットは、LCPオープン状態でのみ送信できる。受信時、受信者は受信した如何なる破棄要求も黙って破棄しなければならない (MUST)。

破棄要求パケット形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Magic-Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...                                                    
+-+-+-+-+

Identifier

識別子フィールドは、破棄要求の送信毎に変更しなければならない (MUST)。

6. LCP 通信設定オプション

LCP 通信設定オプションは、ポイントツーポイントリンクのデォルト機能に対する変更の折衝を可能にする。もし通信設定要求パケットに通信設定オプションが含まれていなければ、通信設定オプションのデフォルト値が想定される。

幾つかの通信設定オプションは、一回以上リスト化してもよい (MAY)。この効果は、通信設定オプションに固有であり、各々のそうした通信設定オプションの説明で規定される。(この規約に無い通信設定オプションは、一回以上リスト化できない)。

通信設定オプションのリストの終端は、LCP パケットの長さフィールドで指定される。

他に規定されていなければ、全ての通信設定オプションは、半二重方式、一般に通信設定要求の送信側から見てリンクの受信方向に適用する。

設計指針

オプションは、オプションを要求している実装体の追加機能や追加実装要件を示す。いかなるオプションも解釈できない実装体は、全てのオプションを実装している実装体と相互接続可能であるべきである (SHOULD)。

恐らく最適なパフォーマンスより劣るだろうが、オプションの折衝なしで正しくリンクが機能できるよう、デフォルト値が各々のオプションに規定される。

明示的に指定されているものを除き、オプションの肯定応答はデフォルト以外の追加動作の実行を相手に要求しない。

通信設定要求でオプションのデフォルト値を送信する必要ない。

通信設定オプション形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 0                   1                       
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    
|     Type      |    Length     |    Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

タイプフィールドは 1 オクテットであり、通信設定オプションのタイプを示す。LCP オプションタイプの最新の値は、最も最近の "番号割当て" RFC [2] で規定されている。このドキュメントは、以下の値に関係している。

Length

長さフィールドは 1 オクテットで、タイプとデータフィールドを含む通信設定オプションの長さを示す。

もし折衝可能な通信設定要求を受信したが、長さが不正/未知であるならば、適切な長さとデータを持った望ましい通信設定オプションを含む通信設定否定応答を送信すべきである (SHOULD)。

Data

データフィールドは 0 個以上のオクテットであり、通信設定オプションに固有な情報を含む。データフィールドの長さと形式は、タイプと長さフィールドによって決定される。

長さフィールドによって、データフィールドが情報フィールドの終端を超えることを示された時、そのパケット全体をオートマトンに何の影響もなく黙って破棄する。

6.1. 最大受信単位 (MRU)

説明

この通信設定オプションは、実装体がより大きいパケットを受信できることを相手に通知するか、又は相手がより小さいパケットを送信することを要求するのに送信してもよい。

デフォルト値は 1500 オクテットである。より小さいパケットが要求されても、実装体はリンクの同期が失われた場合に 1500 オクテットの情報フィールド全体を受信できなければならない (MUST)。

実装注:
このオプションは、実装体の能力を示すために使用される。相手は、受信能力の使用を最大化する必要はない。例えば、MRU が 2048 オクテットを示していても、相手は全パケットを 2048 オクテットで送信する必要はない。相手は、より小さいパケットしか送信しないことを示すために通信設定否定応答を送る必要はない。というのも、実装体は少なくとも 1500 オクテットをサポートする必要があるからである。

最大受信単位オプション形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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     |      Maximum-Receive-Unit     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Maximum-Receive-Unit

最大受信単位フィールドは 2 オクテットであり、情報フィールドとパディングフィールドの最大オクテット数を指定する。フレーム、プロトコルフィールド、FCS、透過ビットまたはバイトは含まない。

6.2. 認証プロトコル

説明

あるリンクでは、ネットワーク層プロトコルパケットの交換が許可される前に、相手に自身の認証を要求することが望ましいかもしれない。

この通信設定オプションは、認証のための特定のプロトコルの使用を折衝する方法を提供する。デフォルトでは認証は要求されない。

実装体は、複数の認証プロトコルの設定オプションを、一つの通信設定要求パケットに含めてはならない (MUST NOT)。代わりに、まず最も望ましいプロトコルを設定して試みるべきである (SHOULD)。もしそのプロトコルが否定応答されたら、実装体は次の最も望ましいプロトコルを通信設定要求で試みるべきである (SHOULD)。

この通信設定要求を送信した実装体は、相手からの認証を期待していることを示す。もし実装体が通信設定肯定応答を送信したら、指定されたプロトコルで認証することに同意したということである。通信設定肯定応答を受信した実装体は、肯定されたプロトコルで認証することを相手に期待すべきである (SHOULD)。

認証は全二重であるとか、両方向で同じプロトコルを使用するといった要件は無い。各方向で異なるプロトコルを使用することは、完全に受諾される。これは無論、折衝された固有のプロトコルによる。

認証プロトコル設定オプション形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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     |     Authentication-Protocol   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...                                                    
+-+-+-+-+

Authentication-Protocol

認証プロトコルフィールドは 2 オクテットであり、望ましい認証プロトコルを指定する。このフィールドの値は、PPP プロトコルフィールドにおける同じ認証プロトコルの値と常に同じである。

認証プロトコルフィールドの最新の値は、最も最近の "番号割当て" RFC [2]で規定される。現在の値は、以下の通りである。

Data

データフィールドは 0 個以上のオクテットであり、特定のプロトコルによって決定される追加データを含む。

6.3. 品質プロトコル

説明

あるリンクでは、いつ、どの程度リンクがデータを落とすかを決めることが望ましい。この処理は、リンク品質監視と呼ばれる。

この通信設定オプションは、リンク品質監視のための特定のプロトコルの使用を折衝するための方法を提供する。デフォルトでは、リンク品質管理は使用しない。

この通信設定要求を送信する実装体は、相手からの監視情報の受信を期待することを示している。もし実装体が通信設定肯定応答を送信するならば、指定されたプロトコルの送信に同意したことになる。通信設定肯定応答を受信した実装体は、相手が肯定されたプロトコルを送信することを期待すべきである (SHOULD)。

品質監視は全二重であるとか、両方向で同じプロトコルを使用するという要件は無い。各方向で異なるプロトコルを使用することは、完全に受諾される。これは無論、折衝された固有のプロトコルによる。

品質プロトコル設定オプション形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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     |        Quality-Protocol       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...                                                    
+-+-+-+-+

Quality-Protocol

品質プロトコルフィールドは 2 オクテットであり、望ましいリンク品質監視プロトコルを指定する。このフィールドの値は、PPP プロトコルフィールドにおける同じ品質監視プロトコルの値と常に同じである。

品質監視プロトコルフィールドの最新の値は、最も最近の "番号割当て" RFC [2]で規定される。現在の値は、以下の通りである。

Data

データフィールドは 0 個以上のオクテットであり、特定のプロトコルによって決定される追加データを含む。

6.4. マジックナンバー

説明

この通信設定オプションは、ループバックリンクや他のデータリンク層例外を検出するための方法を提供する。この通信設定オプションは、品質プロトコル通信設定オプションのような他の通信設定オプションによって要求されてもよい(MAY)。デフォルトでは、マジックナンバーは折衝されず、マジックナンバーが他に使用される場合、0が挿入される。

この通信設定オプションが要求される前に、実装体は自分のマジックナンバーを選択しなければならない(MUST)。実装体がユニークな番号で到着する可能性を極めて高くすることを保証するために、マジックナンバーを可能な最もランダムな方法で選択することが推奨される。ユニークなランダム番号を選択する適切な方法は、ユニークな種で開始することである。提案されるユニークさの元は、マシンのシリアル番号やネットワークハードウェアアドレス、時計の日時を含むことである。特に優れたランダム数の種は、例えば他の接続されたネットワーク上でのパケット受信や、サーバ応答時間、人間のユーザのキー入力レート等の物理イベントの内部到達時間を正確に計測することである。可能な限り多くの元を同時に使用することが推奨される。

マジックナンバー通信設定オプションを持つ通信設定要求を受信したとき、受信したマジックナンバーを最後に相手に送信した通信設定要求のマジックナンバーと照合する。もし二つのマジックナンバーが異なっていたら、リンクはループバックではなく、そのマジックナンバーを肯定すべきである(SHOULD)。もし二つのマジックナンバーが一致していたら、リンクがループバックあるかもしれないし、この通信設定要求は実際には最後に送信されたものかもしれないが、確かではない。これを決定するために、異なるマジックナンバーを指定して、通信設定否定応答を送信しなければならない(MUST)。通常の処理で送信するまで(すなわち、通信設定否定応答を受信するか、再開始タイマが満了するまで)、相手に新しい通信設定要求を送信すべきではない(SHOULD NOT)。

最後に相手に送信した通信設定否定応答の番号と異なるマジックナンバーを持つ通信設定否定応答を受信したら、それは回線がループバックではないことを証明し、ユニークなマジックナンバーを示す。もし、マジックナンバーが最後に送信した通信設定否定応答の番号と等しいならば、ループバックリンクである可能性がますます高まり、新しいマジックナンバーを選択しなければならない(MUST)。いずれかの場合、新しいマジックナンバーを持つ新しい通信設定要求を送信すべきである(SHOULD)。

もしリンクが本当にループバックならば、このシーケンス(通信設定要求を送信し、通信設定要求を受信し、通信設定否定応答を受信し、通信設定否定応答を受信する)は繰り返し行われる。もしリンクがループバックでなければ、このシーケンスが何回か発生しても、繰り返し発生する可能性は極めて低い。より有り得るのは、一方の終端で選択したマジックナンバーは即刻分かれ、このシーケンスは完了するだろう。以下のテーブルは、リンクの両端が完全に一様に配分してマジックナンバーを選択することを想定した、衝突の可能性を示している。

ユニークさやランダムさの適切な元は、この分岐を発生させるために必要とされる。もし適切なユニークさの元が見つけられないならば、この通信設定オプションを利用しないことが推奨され、このオプションを持つ通信設定要求を送信すべきでなく(SHOULD NOT)、相手が送信したマジクナンバーの通信設定オプションを肯定するか、拒否すべきである(SHOULD)。この場合、相手によって検出されるかもしれないが、実装体は信頼高くループバックリンクを検出することはできない。

もし実装体がマジックナンバー通信設定オプションを持つ通信設定要求を送信したら、マジックナンバー通信設定オプションを持つ通信設定要求を受信したときに、通信設定拒否で応答してはならない(MUST NOT)。すなわち、もし実装体がマジックナンバーを使用したいならば、相手が使用することも許さなければならない(MUST)。もし実装体が、通信設定要求の応答として通信設定拒否を受信したら、それはリンクがループバックではなく、その相手がマジックナンバーを使用していないことを意味するだけである。この場合、実装体はあたかも折衝が成功したかのように動作すべきである(SHOULD)。(あたかも通信設定肯定応答を受信したかのように)。

マジックナンバーは、通信設定オプションの折衝だけでなく、通常の操作の間のループバックリンクの検出にも使用してよい。LCPエコー要求やエコー応答、破棄要求パケットは皆、マジックナンバーフィールドを持っている。もしマジックナンバーが正常に折衝されたら、実装体は折衝されたマジックナンバーを設定したマジックナンバーフィールドを持つこれらのパケットを送信しなければならない(MUST)。

これらのパケットのマジックナンバーは、受信側で検査すべきである(SHOULD)。全ての受信したマジックナンバーフィールドは、相手がマジックナンバーを折衝したか否かに従って、0か相手のユニークなマジックナンバーのいずれかと等しくなければならない(MUST)。

折衝された自側のマジックナンバーと等しいマジックナンバーフィールドの受信は、ループバックリンクを示す。折衝された自側のマジックナンバー以外のマジックナンバーの受信は、相手の折衝されたマジックナンバーか、もし相手が折衝していなかったら0であり、異なる相手との通信のために(誤って)設定されたリンクを示す。

いずれかのケースからの回復手続きは規定されず、実装体によって異なるかもしれない。幾分悲観的な手続きは、LCP停止イベントを想定することである。続くオープンイベントが、リンクの再確立の処理を開始するだろう。それは、ループバック状態が完了するまで完了しない。そして、マジックナンバーが正常に折衝される。より楽天的な手続き(ループバックリンクの場合)は、ループバック状態が完了したことを示す適切なエコー応答を受信するまで、LCPエコーパケットの送信を開始することである。

マジックナンバー通信設定オプション形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 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     |          Magic-Number          
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Magic-Number (cont)       |                                
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Magic-Number

マジックナンバーフィールドは4オクテットであり、リンクの一方の終端に非常にユニークになりそうな番号を指定する。0のマジックナンバーは不正であり、もし即座に拒否なしいならば、必ず否定応答しなければならない(MUST)

6.5. プロトコルフィールド圧縮 (PFC)

説明

この通信設定オプションは、PPPプロトコルフィールドの圧縮を折衝するための方法を提供する。デフォルトでは、全ての実装体は、PPPプロトコルフィールドを2オクテットで送信しなければならない。

PPPプロトコルフィールド番号は、幾つかの値を2オクテット形式と明確に区別される1オクテット形式に圧縮してもよいように選択される。この通信設定オプションは、実装体がそのような1オクテットのプロトコルフィールドを受信できることを相手に通知するために送信される。

前に述べたように、プロトコルフィールドメカニズムは、ISO 3309 アドレスフィールド拡張メカニズムと一致する拡張メカニズムを使用する。各オクテットの最下位ビット (LSB: Least Significant Bit) は、プロトコルフィールドの拡張を示すために使用される。LSB の 2 進値 "0" は、プロトコルフィールドが次のオクテットに継続することを示すために使用される。LSB に 2 進値 "1" が存在したら、プロトコルフィールドの最終オクテットを示す。如何なる個数の "0" オクテットもフィールドの前に存在してもよく、それは同じ値を示す (3 の二つの 2 進表現を考えると、00000011 と 00000000 00000011) ことに注意されたい。

低速回線を使用するとき、可能な限り冗長なデータを小さくすることによって帯域幅を保持することが望ましい。プロトコルフィールド圧縮通信設定オプションは、実装の簡素化と帯域幅の効率とのトレードオフを可能にする。もし正常に折衝されたら、プロトコルフィールドを2オクテットではなく1オクテットに圧縮するために、ISO 3309拡張メカニズムを使用してもよい。パケットの大多数は圧縮可能である。なぜなら、データプロトコルはプロトコルフィールドに、通常256以下の値が割り当てられるからである。

この通信設定オプションが折衝されなければ、圧縮したプロトコルフィールドを送信してはならない(MUST NOT)。折衝されたら、PPP実装体は2オクテットか1オクテットのプロトコルフィールドを持つPPPパケットを受信できなければならず(MUST)、これらを区別してはならない。

LCPパケットを送信する時は、プロトコルフィールドを圧縮してはならない(MUST NOT)。この規則は、LCPパケットの明確な再折衝を保証する。

プロトコルフィールドが圧縮される時、データリンク層FCSフィールドは、元の圧縮されていないフレームではなく、圧縮されたフレームに対して算出される。

プロトコルフィールド圧縮通信設定オプション形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 0                   1           
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.6. アドレス-制御フィールド圧縮 (ACFC)

説明

この通信設定オプションは、データリンク層アドレスと制御フィールドの圧縮を折衝する方法を提供する。デフォルトでは、全ての実装体は、リンクのフレーム化に適切なアドレスと制御フィールドを持つフレームを送信しなければならない(MUST)。

これらのフィールドは通常、ポイントツーポイントリンクに対して定数値を持つので、簡単に圧縮できる。この通信設定オプションは、実装体が圧縮されたアドレスと制御フィールドを受信できることを相手に通知するために送信される。

もしアドレス-制御フィールド圧縮がまだ折衝されていない時に圧縮されたフレームを受信したら、実装体はそのフレームを黙って破棄してもよい(MAY)。

LCPパケットを送信する時は、アドレス-制御フィールドを圧縮してはならない(MUST NOT)。この規則は、LCPパケットの明確な再折衝を保証する。

アドレス-制御フィールドが圧縮される時、データリンク層FCSフィールドは、元の圧縮されていないフレームではなく、圧縮されたフレームに対して算出される。

アドレス-制御フィールド圧縮通信設定オプション形式の詳細は、以下の通りである。フィールドは左から右へ送信される。

 0                   1           
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

セキュリティの考慮

セキュリティの問題は、認証フェーズ、クローズイベント、認証プロトコル通信設定オプションに関するセクションで手短に論じられている。

参照

[1] Perkins, D., "Requirements for an Internet Standard Point-to-Point Protocol", RFC 1547, Carnegie Mellon University, December 1993.

[2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC1340, USC/Information Sciences Institute, July 1992.

謝辞

このドキュメントは、インターネット技術作業団体(IETF: Internet Engineering Task Force)のポイントツーポイントプロトコルのワーキンググループの生産物である。コメントは、ietf-ppp@merit.eduのメーリングリストに投稿しなければならない。

このドキュメントの大半のテキストは、カーネギーメロン大学のドュリューパーキンスとデービスのカリフォルニア大学のロスホビーにより、ワーキンググループの要件[1]と、RFC1171/1172から取っている。

ウィリアムシンプソンは、主に一貫した用語や思想やフェーズと折衝の状態マシンの再設計に責任があった。

多くの人々は、ポイントツーポイントプロトコルの開発を補助するために多大な時間を費やした。人々の完全なリストはあまりにも膨大なリストになるが、次の人々には特別な感謝に値する。Rick Adams, Ken Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross, Kory Hamzeh, former WG chair Russ Hobby, David Kaufman, former WG chair Steve Knowles, Mark Lewis, former WG chair Brian Lloyd, John LoVerso, Bill Melohn, Mike Patton, former WG chair Drew Perkins, Greg Satz, John Shriver, Vernon Schryver, Asher Waldfogel。

この規約を作成するにあたり、コンピュータ資源とネットワークアクセスサポートを提供してくれたモーニングスターテクノロジーに大変感謝する。

議長のアドレス

ワーキンググループは、以下の現在の議長を通じてコンタクトをとれる。

Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117

作者のアドレス

このメモについての質問は、直接下記へ。

William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071

値 (16進)	プロトコル名
0001 0003 to 001f 007d 00cf 00ff	Padding Protocol 予約 (transparency inefficient) 予約 (Control Escape) 予約 (PPP NLPI 予約 (compression inefficient)D)
8001 to 801f 807d 80cf 80ff	未使用未使用未使用未使用
c021 c023 c025 c223	リンク制御プロトコルパスワード認証プロトコルリンク品質報告チャレンジハンドシェイク認証プロトコル

The Point-to-Point Protocol (PPP)

Status of this Memo

Abstract