Network Working Group W. Simpson, Editor Request for Comments: 1661 Daydreamer STD: 51 July 1994 Obsoletes: 1548 Category: Standards Track The Point-to-Point Protocol (PPP) Status of this Memo このドキュメントは、インターネット社会の為のインターネット標準トラッ クプロトコルを規定しており、改善のための議論と提案を求めている。こ のプロトコルの標準化の状態と状況については、"Internet Official Protocol Standards" (STD 1) の現在の版を参照されたい。このメモの配 布は制限されない。 Abstract Point-to-Point Protocol (PPP) は、ポイントツーポイントリンク上で複 数のプロトコルのデータグラムを転送する標準の方法を提供する。PPP は、 3 つの主要コンポーネントを含む。 1. 複数プロトコルのデータグラムをカプセル化する方法。 2. データリンクコネクションを確立し、設定し、テストするリンク制 御プロトコル (LCP: Link Control Protocol)。 3. 異なるネットワーク層プロトコルを確立し、設定するネットワーク 制御プロトコル (NCP: Network Control Protocol) のファミリー。 このドキュメントは、各種豊富な通信設定パラメタが折衝可能であり、付 加的な管理機能を提供する拡張性のあるオプション折衝メカニズムと共に、 PPP 構成と方法論と PPP カプセル化を定義する。PPP リンク制御プロトコ ル (LCP) は、このメカニズムで規定される。 Table of Contents 1. 導入 1.1. 要件の規定 1.2. 用語 2. PPP カプセル化 3. PPP リンク操作 3.1. 概要 3.2. フェーズ図 3.3. リンクデッド (物理層が準備されていない) 3.4. リンク確立フェーズ 3.5. 認証フェーズ 3.6. ネットワーク層プロトコルフェーズ 3.7. リンク終了フェーズ 4. オプション折衝オートマトン 4.1 状態遷移図 4.2. 状態 4.3. イベント 4.4 アクション 4.5 ループ回避 4.6 カウンタとタイマ 5. LCP パケット形式 5.1 通信設定要求 5.2 通信設定肯定応答 5.3 通信設定否定応答 5.4 通信設定拒否 5.5 終了要求と終了肯定応答 5.6 コード拒否 5.7 プロトコル拒否 5.8 エコー要求、エコー応答 5.9 破棄要求 6. LCP 通信設定オプション 6.1 最大受信単位(MRU) 6.2 認証プロトコル 6.3 品質プロトコル 6.4 マジックナンバー 6.5 プロトコルフィールド圧縮 (PFC) 6.6 アドレス-制御フィールド圧縮(ACFC) セキュリティの考慮 参照 謝辞 議長のアドレス 作者のアドレス 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]) 中で規定される。この規約は以下の値を予約している。 値 (16進) プロトコル名 0001 Padding Protocol 0003 to 001f 予約 (transparency inefficient) 007d 予約 (Control Escape) 00cf 予約 (PPP NLPID) 00ff 予約 (compression inefficient) 8001 to 801f 未使用 807d 未使用 80cf 未使用 80ff 未使用 c021 リンク制御プロトコル c023 パスワード認証プロトコル c025 リンク品質報告 c223 チャレンジハンドシェイク認証プロトコル 新しいプロトコルの開発者は、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/NONE | Dead |------->| Establish |---------->| Authenticate |--+ | | | | | | | +------+ +-----------+ +--------------+ | ^ | | | | FAIL | FAIL | | +<--------------+ +----------+ | | | | | +-----------+ | +---------+ | | DOWN | | | CLOSING | | | +------------| Terminate |<---+<----------| Network |<-+ | | | | +-----------+ +---------+ 全ての遷移がこの図に示されているわけではない。以下のセマンティクス に従わなければならない (MUST)。 3.3. リンクデッド (物理層が準備されていない) リンクは、必要に応じてこのフェーズを開始し終了する。外部イベント (例えば、キャリア検出やネットワーク管理者の通信設定等) が、物理層を 使用する準備ができたことを示す時、PPP はリンク確立フェーズの手続き を行うだろう。 このフェーズの間に、LCP オートマトン (後述) は初期または開始状態に なる。LCP オートマトンに Up イベントを信号で通知することにより、リ ンク確立フェーズへ遷移する。 実装注: 通常、リンクはモデムの切断の後、自動的にこのフェーズに戻る。ハー ド回線リンクの場合、このフェーズは極端に短いかもしれない。単にデ バイスの存在を検出する時間でしかない。 3.4. リンク確立フェーズ リンク制御プロトコル (LCP) は、通信設定パケットの交換を通じてコネク ションを確立するために使用される。一旦、通信設定肯定パケット (後述) の送受信両方が行われると、この交換が完了し、LCP Open 状態に入る。 全ての通信設定オプションは、もし通信設定の交換による変更がなければ、 デフォルト値が想定される。さらなる議論は、LCP 通信設定オプションの チャプタを参照されたい。 特定のネットワーク層プロトコルに依存しない通信設定オプションのみが、 LCP によって設定されることを注意することは重要である。個々のネット ワーク層プロトコルの通信設定情報は、ネットワーク層プロトコルフェー ズの間に別々のネットワーク制御プロトコル (NCP) によって取り扱われる。 このフェーズの間に受信した非 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. オプション折衝オートマトン 有限状態のオートマトンは、イベント、アクション、状態遷移によって定 義される。イベントは、オープンやクローズ等の外部コマンドの受信、再 開タイマの満了、相手からのパケット受信を含む。アクションは、再開タ イマの開始や相手へのパケット再送を含む。 幾つかのパケット (通信設定否定応答や通信設定拒否、コード拒否やプロ トコル拒否、エコー要求、エコー応答、破棄要求)は、オートマトン記述の 中では区別されない。後述するが、これらのパケットは、実際には異なる 機能を実行させる。しかし、これらは常に同じ遷移を引き起こす。 イベント アクション Up = 下位層が起動 tlu = この層の起動 Down = 下位層が停止 tld = この層の停止 Open = 管理上オープン tls = この層の開始 Close= 管理上クローズ tlf = この層の終了 TO+ = カウンタ > 0 でタイムアウト irc = 再開始数を初期化 TO- = カウンタ満了でタイムアウト zrc = 再開始数を零クリア RCR+ = 通信設定要求受信 (Good) scr = 通信設定要求送信 RCR- = 通信設定要求受信 (Bad) RCA = 通信設定肯定応答受信 sca = 通信設定肯定応答送信 RCN = 通信設定否定応答/拒否受信 scn = 通信設定否定応答/拒否送信 RTR = 終了要求受信 str = 終了要求送信 RTA = 終了肯定応答受信 sta = 終了肯定応答送信 RUC = 未知コード受信 scj = コード拒否送信 RXJ+ = コード拒否受信 (許可) 又は プロトコル拒否受信 RXJ- = コード拒否受信 (致命的) 又は プロトコル拒否受信 RXR = エコー要求受信 又は ser = エコー応答送信 エコー応答受信 破棄要求受信 4.1 状態遷移図 完全な状態遷移表は以下の通りである。状態は横に示され、イベントは縦 に読む。状態遷移とアクションは、アクション/新状態の形式で表される。 複数のアクションはカンマによって区切られ、空白を必要として継続行に 続くかもしれない。複数のアクションは、いかなる便利な順序で実装され てもよい。状態には、解説の脚注を示す文字が後続するかもしれない。ダッ シュ('-')は、無効な遷移を示す。 | State | 0 1 2 3 4 5 Events| Initial Starting Closed Stopped Closing Stopping ------+----------------------------------------------------------- Up | 2 irc,scr/6 - - - - Down | - - 0 tls/1 0 1 Open | tls/1 1 irc,scr/6 3r 5r 5r Close| 0 tlf/0 2 2 4 4 | TO+ | - - - - str/4 str/5 TO- | - - - - tlf/2 tlf/3 | RCR+ | - - sta/2 irc,scr,sca/8 4 5 RCR- | - - sta/2 irc,scr,scn/6 4 5 RCA | - - sta/2 sta/3 4 5 RCN | - - sta/2 sta/3 4 5 | RTR | - - sta/2 sta/3 sta/4 sta/5 RTA | - - 2 3 tlf/2 tlf/3 | RUC | - - scj/2 scj/3 scj/4 scj/5 RXJ+ | - - 2 3 4 5 RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3 | RXR | - - 2 3 4 5 | State | 6 7 8 9 Events| Req-Sent Ack-Rcvd Ack-Sent Opened ------+----------------------------------------- Up | - - - - Down | 1 1 1 tld/1 Open | 6 7 8 9r Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4 | TO+ | scr/6 scr/6 scr/8 - TO- | tlf/3p tlf/3p tlf/3p - | RCR+ | sca/8 sca,tlu/9 sca/8 tld,scr,sca/8 RCR- | scn/6 scn/7 scn/6 tld,scr,scn/6 RCA | irc/7 scr/6x irc,tlu/9 tld,scr/6x RCN |irc,scr/6 scr/6x irc,scr/8 tld,scr/6x | RTR | sta/6 sta/6 sta/6 tld,zrc,sta/5 RTA | 6 6 8 tld,scr/6 | RUC | scj/6 scj/7 scj/8 scj/9 RXJ+ | 6 6 8 9 RXJ- | tlf/3 tlf/3 tlf/3 tld,irc,str/5 | RXR | 6 7 8 ser/9 再開タイマが作動している状態は、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 パケットには三つのクラスが存在する。 1. リンクを確立し設定するために使用されるリンク設定パケット。 (通信設定要求、通信設定肯定応答、通信設定否定応答、通信設定拒 否) 2. リンクを終了するために使用されるリンク終了パケット。(終了要求 と終了肯定応答) 3. リンクを管理しデバッグするために使用されるリンク保守パケット。 (コード拒否、プロトコル拒否、エコー要求、エコー応答、破棄要求) 単純化するため、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]で規定される。 このドキュメントは以下の値を考慮している。 1 通信設定要求 2 通信設定肯定応答 3 通信設定否定応答 4 通信設定拒否 5 終了要求 6 終了肯定応答 7 コード拒否 8 プロトコル拒否 9 エコー要求 10 エコー応答 11 破棄要求 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 ... +-+-+-+-+ Code 通信設定要求は 1 である。 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 ... +-+-+-+-+ Code 通信設定肯定応答は 2 である。 Identifier 識別子フィールドは、この通信設定肯定応答の契機となった通信設定要 求の識別子フィールドのコピーである。 Options オプションフィールドは長さが可変で、送信側が確認した 0 個以上の 通信設定オプションを含む。全ての通信設定オプションは、必ず同時に 肯定される。 5.3. 通信設定否定応答 説明 もし受信した通信設定オプションの全てのインスタンスが認識可能だが、 いくつかの値が受諾できないならば、実装体は通信設定否定応答を送信 しなければならない (MUST)。オプションフィールドには、通信設定要 求の中で受諾できない通信設定オプションのみを指定する。受諾できる 全ての通信設定オプションは、通信設定否定応答からは除外するが、そ れ以外は通信設定要求の通信設定オプションの順番を変えてはならない (MUST NOT)。 値フィールドを持たないオプション (論理型オプション) は、通信設定 拒否を使用しなければならない (MUST)。 単一のインスタンスのみ許される各々の通信設定オプションは、通信設 定否定応答の送信者で受諾できる値に修正しなければならない (MUST)。 要求された値がデフォルト値と異なる場合、デフォルト値を使用しても よい (MAY)。 通信設定オプションの特定のタイプが異なる値で一回以上リスト化でき る場合、通信設定否定応答は、通信設定否定応答の送信者が受諾できる オプションの全ての値のリストを含まなければならない (MUST)。 最後に、実装体は特定のオプションの折衝を要求するために設定しても よい。もしそのオプションがリスト化されていなければ、そのオプショ ンを次の通信設定要求パケットに含めることを通信相手に促すために、 否定応答のリストに追加してもよい (MAY)。オプションのいかなる値フィ ールドも、通信設定否定応答の送信者が受諾できる値を指定しなければ ならない (MUST)。 通信設定否定応答の受信時に、識別子フィールドは最後に送信した通信 設定要求の識別子と一致しなければならない (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 ... +-+-+-+-+ Code 通信設定否定応答は 3 である。 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 ... +-+-+-+-+ Code 通信設定拒否は 4 である。 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 ... +-+-+-+-+ Code 終了要求は 5 である。 終了肯定応答は 6 である。 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 ... +-+-+-+-+-+-+-+-+ Code コード拒否は 7 である。 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code プロトコル拒否は 8 である。 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 ... +-+-+-+-+ Code エコー要求は 9 である。 エコー応答は 10 である。 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 ... +-+-+-+-+ Code 破棄要求は 11 である。 Identifier 識別子フィールドは、破棄要求の送信毎に変更しなければならない (MUST)。 Magic-Number マジックナンバーフィールドは 4 オクテットであり、ループバック状 態にあるリンクを検出する際の補助になる。マジックナンバーの通信設 定オプションが正常に折衝されるまで、マジックナンバーは 0 で送信 しなければならない (MUST)。マジックナンバーの通信設定オプション については、後続の説明を参照されたい。 Data データフィールドは 0 個以上のオクテットで、送信者によって使用さ れる解析されないデータを含む。このデータはいかなるバイナリ値で構 成されてもよい。フィールドの最終は長さフィールドによって識別され る。 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] で規定されている。このドキュメントは、以下の値に関係 している。 0 予約 1 最大受信単位 3 認証プロトコル 4 品質プロトコル 5 マジックナンバー 7 プロトコルフィールド圧縮 8 アドレスと制御フィールド圧縮 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 4 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 ... +-+-+-+-+ Type 3 Length 4 以上 Authentication-Protocol 認証プロトコルフィールドは 2 オクテットであり、望ましい認証プロ トコルを指定する。このフィールドの値は、PPP プロトコルフィールド における同じ認証プロトコルの値と常に同じである。 認証プロトコルフィールドの最新の値は、最も最近の "番号割当て" RFC [2] で規定される。現在の値は、以下の通りである。 値(16進) プロトコル c023 パスワード認証プロトコル c223 チャレンジハンドシェイク認証プロトコル 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 ... +-+-+-+-+ Type 4 Length 4 以上 Quality-Protocol 品質プロトコルフィールドは 2 オクテットであり、望ましいリンク品 質監視プロトコルを指定する。このフィールドの値は、PPP プロトコル フィールドにおける同じ品質監視プロトコルの値と常に同じである。 品質監視プロトコルフィールドの最新の値は、最も最近の "番号割当て" RFC [2]で規定される。現在の値は、以下の通りである。 値(16進) プロトコル c025 リンク品質報告 Data データフィールドは 0 個以上のオクテットであり、特定のプロトコル によって決定される追加データを含む。 6.4. マジックナンバー 説明 この通信設定オプションは、ループバックリンクや他のデータリンク層 例外を検出するための方法を提供する。この通信設定オプションは、品 質プロトコル通信設定オプションのような他の通信設定オプションによっ て要求されてもよい (MAY)。デフォルトでは、マジックナンバーは折衝 されず、マジックナンバーが他に使用される場合、0 が挿入される。 この通信設定オプションが要求される前に、実装体は自分のマジックナ ンバーを選択しなければならない (MUST)。実装体がユニークな番号で 到着する可能性を極めて高くすることを保証するために、マジックナン バーを可能な最もランダムな方法で選択することが推奨される。ユニー クなランダム番号を選択する適切な方法は、ユニークな種で開始するこ とである。提案されるユニークさの元は、マシンのシリアル番号やネッ トワークハードウェアアドレス、時計の日時を含むことである。特に優 れたランダム数の種は、例えば他の接続されたネットワーク上でのパケッ ト受信や、サーバ応答時間、人間のユーザのキー入力レート等の物理イ ベントの内部到達時間を正確に計測することである。可能な限り多くの 元を同時に使用することが推奨される。 マジックナンバー通信設定オプションを持つ通信設定要求を受信したと き、受信したマジックナンバーを最後に相手に送信した通信設定要求の マジックナンバーと照合する。もし二つのマジックナンバーが異なって いたら、リンクはループバックではなく、そのマジックナンバーを肯定 すべきである (SHOULD)。もし二つのマジックナンバーが一致していた ら、リンクがループバックあるかもしれないし、この通信設定要求は実 際には最後に送信されたものかもしれないが、確かではない。これを決 定するために、異なるマジックナンバーを指定して、通信設定否定応答 を送信しなければならない (MUST)。通常の処理で送信するまで (すな わち、通信設定否定応答を受信するか、再開始タイマが満了するまで)、 相手に新しい通信設定要求を送信すべきではない (SHOULD NOT)。 最後に相手に送信した通信設定否定応答の番号と異なるマジックナンバ ーを持つ通信設定否定応答を受信したら、それは回線がループバックで はないことを証明し、ユニークなマジックナンバーを示す。もし、マジッ クナンバーが最後に送信した通信設定否定応答の番号と等しいならば、 ループバックリンクである可能性がますます高まり、新しいマジックナ ンバーを選択しなければならない (MUST)。いずれかの場合、新しいマ ジックナンバーを持つ新しい通信設定要求を送信すべきである (SHOULD)。 もしリンクが本当にループバックならば、このシーケンス (通信設定要 求を送信し、通信設定要求を受信し、通信設定否定応答を受信し、通信 設定否定応答を受信する) は繰り返し行われる。もしリンクがループバッ クでなければ、このシーケンスが何回か発生しても、繰り返し発生する 可能性は極めて低い。より有り得るのは、一方の終端で選択したマジッ クナンバーは即刻分かれ、このシーケンスは完了するだろう。以下のテ ーブルは、リンクの両端が完全に一様に配分してマジックナンバーを選 択することを想定した、衝突の可能性を示している。 衝突回数 可能性 -------------------- --------------------- 1 1/2**32 = 2.3 E-10 2 1/2**32**2 = 5.4 E-20 3 1/2**32**3 = 1.3 E-29 ユニークさやランダムさの適切な元は、この分岐を発生させるために必 要とされる。もし適切なユニークさの元が見つけられないならば、この 通信設定オプションを利用しないことが推奨され、このオプションを持 つ通信設定要求を送信すべきでなく (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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 Length 6 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 パケットを送信する時は、プロトコルフィールドを圧縮してはなら ない。この規則は、LCP パケットの明確な再折衝を保証する。 プロトコルフィールドが圧縮される時、データリンク層 FCS フィール ドは、元の圧縮されていないフレームではなく、圧縮されたフレームに 対して算出される。 プロトコルフィールド圧縮通信設定オプション形式の詳細は、以下の通り である。フィールドは左から右へ送信される。 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 Length 2 6.6. アドレス-制御フィールド圧縮 (ACFC) 説明 この通信設定オプションは、データリンク層アドレスと制御フィールド の圧縮を折衝する方法を提供する。デフォルトでは、全ての実装体は、 リンクのフレーム化に適切なアドレスと制御フィールドを持つフレーム を送信しなければならない (MUST)。 これらのフィールドは通常、ポイントツーポイントリンクに対して定数 値を持つので、簡単に圧縮できる。この通信設定オプションは、実装体 が圧縮されたアドレスと制御フィールドを受信できることを相手に通知 するために送信される。 もしアドレス-制御フィールド圧縮がまだ折衝されていない時に圧縮さ れたフレームを受信したら、実装体はそのフレームを黙って破棄しても よい (MAY)。 LCP パケットを送信する時は、アドレス-制御フィールドを圧縮しては ならない。この規則は、LCP パケットの明確な再折衝を保証する。 アドレス-制御フィールドが圧縮される時、データリンク層 FCS フィー ルドは、元の圧縮されていないフレームではなく、圧縮されたフレーム に対して算出される。 アドレス-制御フィールド圧縮通信設定オプション形式の詳細は、以下の通 りである。フィールドは左から右へ送信される。 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 Length 2 セキュリティの考慮 セキュリティの問題は、認証フェーズ、クローズイベント、認証プロトコ ル通信設定オプションに関するセクションで手短に論じられている。 参照 [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, RFC 1340, 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 fbaker@acc.com 作者のアドレス このメモについての質問は、直接下記へ。 William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com