Network Working Group W. Simpson, Editor Request for Comments: 1662 Daydreamer STD: 51 July 1994 Obsoletes: 1549 Category: Standards Track PPP in HDLC-like Framing このメモの状態 このドキュメントは、インターネット社会の為のインターネット標準トラッ クプロトコルを規定しており、改善の為の議論と提案を求めている。この プロトコルの標準化の状態と状況については、"Internet Official Protocol Standards" (STD 1) の現在の版を参照されたい。このメモの配 布は制限されない。 Abstract ポイントツーポイントプロトコル (PPP) [1] は、複数のプロトコルデータ をポイントツーポイント回線上で送信するための標準的な方法を提供する。 このドキュメントは、PPP のカプセル化されたパケットのために、擬似 HDLC フレーム化の使用について規定する。 Table of Contents 1. 導入 1.1. 要件の規定 1.2. 用語 2. 物理層要件 3. データリンク層 3.1. フレーム形式 3.2. 基本フレームの修正 4. オクテット詰めフレーム化 4.1. フラグシーケンス 4.2. 透過性 4.3. 不正フレーム 4.4. タイムフィル 4.4.1. オクテット同期 4.4.2 非同期 4.5. 送信の考慮 4.5.1. オクテット同期 4.5.2. 非同期 5. ビット詰めフレーム化 5.1. フラグシーケンス 5.2. 透過性 5.3. 不正フレーム 5.4. タイムフィル 5.5. 送信の考慮 6. 非同期から同期への変換 7. 追加の LCP 設定オプション 7.1. 同期制御文字マップ (ACCM) 付録 A. 推奨 LCP オプション B. PPP フレームの自動認識 C. 高速フレームチェック (FCS) 実装 C.1. FCS テーブル生成器 C.2. 16 ビット FCS 計算方法 C.3. 32 ビット FCS 計算方法 セキュリティの考慮 参照 謝辞 議長のアドレス 作者のアドレス 1. 導入 この規約は、ビット型とオクテット型の同期回線上と、8 ビットのデータ でパリティ無しの非同期回線上の両方におけるフレーム化を提供する。こ れらの回線は全二重でなければならない (MUST) が、専用線か回線交換の いずれであってもよい (MAY)。 エスケープメカニズムは、、XON/XOFF などの制御データを回線上に透過的 に転送したり、介入するハードウェアやソフトウェアによって挿入される かもしれない不正な制御データを除去することを可能にするために規定さ れる。 幾つかのプロトコルは、エラーフリー転送や、条件付き基礎にのみ基づく エラー検出を提供するか、全く提供しないことを望む。PPP は、エラー検 出のための HDLC フレームチェックシーケンスを使用する。これはハード ウェア実装で共通的に使用でき、ソフトウェア実装が提供される。 1.1. 要件の規定 このドキュメントでは、幾つかの単語が規約の要件を識別する為に使用さ れる。これらの単語は大抵大文字である。 MUST この単語、形容詞 "required" は、その定義がこの規約の絶対 的な要件であることを意味する。 MUST NOT このフレーズは、その定義はこの規約の絶対的な禁止であるこ とを意味する。 SHOULD この単語、形容詞 "recommended" は、ある特定の環境でこの項 目を無視する正当な理由があるかもしれないが、完全実装はこ れが理解され、異なる道を選択する前に注意深く重視されなけ ればならないことを意味する。 MAY この単語、形容詞 "recommended" は、この項目は可能な代替セッ トの 1 つであることを意味する。このオプションを含まない実 装体は、このオプションを含む別の実装体と相互動作する為の 準備をしていなければならない (MUST)。 1.2. 用語 このトキュメントは、しばしば以下の単語を使用する。 データグラム(datagram) ネットワーク層 (例えば IP) での転送単位。データグラムは、 データリンク層に渡される 1 つ以上のパケットにカプセル化さ れてもよい。 フレーム (frame) データリンク層での転送単位。フレームは、数個のデータ単位 に付加されたヘッダやトレイラを含むかもしれない。 パケット (packet) ネットワーク層とデータリンク層間のインターフェースを通じ て渡されるカプセル化の基本単位。パケットは通常、フレーム にマッピングされる。ただし、データリンク層のフラグメント 化が実行される時や、複数のパケットが単一のフレームに混合 されている時は例外である。 相手 (peer) point-to-point リンクの他方の終端 黙って破棄 (silently discard) 実装体は、パケットを更なる処理を行わずに破棄する。実装体 は、黙って破棄されたパケットの内容含めて、エラーをログに とる機能を提供すべきである (SHOULD)。そして、静的カウンタ にイベントを記録すべきである (SHOULD)。 2. 物理層要件 PPP は、大半の DTE/DCE インタフェース (例えば EIA RS-232-E, EIA RS-422, CCITT V.35) に渡って操作することができる。PPP によって課せ られる唯一の絶対的な要件は、全二重回線で、専用線か回線交換のいずれ か、非同期 (開始/終了)、ビット同期、オクテット同期モードのいずれか、 PPP データリンク層フレームへの透過性を用意することである。 インタフェース形式 PPP は物理層にオクテットインタフェースを提供する。サブオクテット の供給や受信のための用意はない。 転送レート ある特定の DTE/DCE インタフェースのレートを除き、PPP は転送レー トに関して如何なる制限も課さない。 制御信号 PPP は、例えば送信要求 (RTS: Request To Send) や送信クリア (CTS: Crear To Send)、データキャリア検出 (DCD: Data Carrier Detect)、 データ端末レディ (DTR: Data Terminal Ready) などの制御信号を使用 する必要はない。 使用可能な時は、そうした信号を使うことにより、大きな機能性とパフォ ーマンスを可能にできる。特にそのような信号は、LCP オプション折衝 オートマトン [1] で、Up と Down イベントを通知するために使用すべ きである (SHOULD)。このような信号を使用できない時には、実装体は 初期化時に Up イベントを LCP に通知しなければならず (MUST)、Down イベントを通知すべきではない (SHOULD NOT)。 信号化は必須ではないので、物理層はデータリンク層から分離し、物理 的な転送の一時的な詳細を隠蔽してもよい (MAY)。これは、携帯ラジオ ネットワークにおけるモバイル性や、他の高速交換回線向けといった暗 黙的な意味を持つ。 同じゾーンの中でセルからセルへ移動する時、たとえ転送が複数の周波 数に切り替わるとしても、実装体はゾーン全体を単一の回線として扱う 選択をしてもよい (MAY)。その回線は個々のセル受信機ではなく、ゾー ンの中央制御単位と見なされる。しかし、回線は異なる管理に回線が切 り替わる場合は常に、その設定を再確立すべきである (SHOULD)。 データトラフィックの突発的流入特性により、ある実装体は、データリ ンク層に通知せずに、無活動期間の間物理層を切断し、トラフィックが 再開したら再接続することを選択した。セットアップ潜在期間が減るこ との価値が安全性を減らすことなので、頑強な実装体はむやみにこのト リックを使用することを避けるべきである。実装体はリンクが切断され てから「意味ある時間」が経過した後、Down イベントを通知すべきで ある (SHOULD)。「意味ある時間」の値は考慮すべき議論の主題であり、 トラフィックや発呼設定時間、インストールに関する安全性に基づく。 3. データリンク層 PPP は、非同期環境で HDLC の使用を可能にするための修正を規定した ISO 3309-1979 HDLC フレーム構造 (最新は 3309 第 4 版 1991 [2]) で規 定された原理を使用する。 PPP 制御手続きは、ISO 4335-1979 HDLC 手続き要素 (最新は 4335 第 4 版 1991 [4]) で規定された制御フィールドの符号化を使用する。 これは、上記の推奨の全ての特徴が PPP に含まれることを示すと解釈 すべきではない。含まれる各特徴は、以下のセクションで明示的に説明 される。 インターネット標準との一貫性を保ち、RFC を読み慣れている読者の混乱 を避けるために、以下の説明中の全ての 2 進数字は、最上位ビットから最 下位ビットへの順番である。もし別に指示されていなければ、左から右に 読む。これは、転送する順番 (ネットワークビットオーダ) で表記する ISO や CCITT 標準とは対照的である。このドキュメントと国際標準ドキュ メントを比較する場合、このことを留意されたい。 3.1. フレーム形式 PPP HDLC ライクなフレーム構造の要約を以下に示す。この図は、同期をと るために挿入されたビット (例えば、非同期回線での開始と終了ビット) も、透過性のために挿入されたビットやオクテットも含んでいない。フィ ールドは、左から右へ送信される。 +----------+----------+----------+ | フラグ | アドレス | 制御 | | 01111110 | 11111111 | 00000011 | +----------+----------+----------+ +----------+-------------+----------+ |プロトコル| 情報 |パディング| | 8/16 bits| * | * | +----------+-------------+----------+ +----------+----------+----------------- | FCS | フラグ | フレーム間タイムフィル |16/32 bits| 01111110 | 次アドレス +----------+----------+----------------- プロトコル、情報、パディングフィールドは、ポイントツーポイントプロ トコルのカプセル化 [1] で規定されている。 フラグシーケンス 各フレームはフラグシーケンスから始まり、フラグシーケンスで終わる。 フラグシーケンスは 2 進シーケンスの 01111110 (16 進で 0x7e) であ る。全ての実装体は、フレームの同期をとるのに使用するために、この フラグを継続的にチェックする。 2 つのフレーム間で 1 つのフラグシーケンスのみが必要とされる。2 つの連続したフラグシーケンスは空フレームを形成し、そのフレームは 黙って破棄され、FCS エラーにはカウントされない。 アドレスフィールド アドレスフィールドは単一のオクテットであり、2 進シーケンスの 11111111 (16 進で 0xff)、全ステーションアドレスを含む。全ステー ションアドレスは、必ず認識して受信しなければならない (MUST)。 後で、あるいは前の同意によって、他のアドレス長と値の使用が定義さ れるかもしれない。認識できないアドレスを持つフレームは、黙って破 棄すべきである (SHOULD)。 制御フィールド 制御フィールドは単一のオクテットであり、2 進シーケンスの 00000011 (16 進で 0x03)、ポール/ファイルナルビットが 0 に設定さ れた非番号制情報 (UI) コマンドを含む。 後で、あるいは前の同意によって、他の制御フィールドの値の使用が定 義されるかもしれない。認識できない制御フィールドを持つフレームは、 黙って破棄すべきである (SHOULD)。 フレームチェックシーケンス (FCS) フィールド フレームチェックシーケンスフィールドは、デフォルトで 16 ビット (2 オクテット) である。FCS は最下位オクテットが一番最初に送信さ れ、最大項の係数を含む。 32 ビット (4 オクテット) FCS もまた定義される。その使用は "PPP LCP 拡張" [5] で規定されているように折衝してもよい。 後で、あるいは前の同意によって、他の FCS 長の使用が定義されるか もしれない。 FCS フィールドはアドレス、制御、プロトコル、情報、パディングフィ ールドの全てのビットから算出され、開始と終了ビット (非同期) と透 過性のために挿入されるビット (同期) やオクテット (非同期又は同 期) を含まない。これはまた、フラグシーケンスと FCS フィールド自 体も含まない。 Async-Control-Character-Map のフラグを持つオクテットを受信し た場合、FCS を算出する前に破棄する。 FCS に関する詳細な情報については、付録を参照されたい。 情報フィールドとパディングフィールドの終端は、閉じるフラグシーケ ンスの所在を探すことにより見つかり、フレムチェックシーケンスは削 除する。 3.2. 基本フレームの修正 リンク制御プロトコルは、標準的な擬似 HDLC フレーム構造への変更を折 衝することができる。しかし、修正されたフレームは、必ず標準フレーム とは明確に区別できる。 アドレスと制御フィールド圧縮 標準的な HDLC-like フレーム化を使用する時、アドレスと制御フィー ルドはそれぞれ、16進値の 0xff と 0x03 である。他のアドレスと制御 フィールド値が使用する場合、アドレスと制御フィールド圧縮を折衝し てはならない (MUST NOT)。 送信時は、圧縮されたアドレスと制御フィールドは単に省略する。 受信時は、アドレスと制御フィールドは最初の 2 オクテットを検査す ることによって伸長する。もし 0xff と 0x03 の値ならば、それらはア ドレスと制御フィールドであると想定される。もし 0xff と 0x03 の値 ではないならば、そのフィールドは圧縮され、送信されなかったと想定 する。 定義により、 2 オクテットのProtocol フィールドの最初のオクテッ トは決して 0xff にはならないだろう (相当するものがないので)。 プロトコルフィールド値 0xff は、プロトコルフィールド圧縮が可 能であり、最初の情報フィールドオクテットが 0x03 である時の曖 昧さを避けるために許されない。 4. オクテット詰めフレーム化 このチャプタは、8 ビット非同期やオクテット同期回線での擬似 HDLC フ レーム化の使用方法を要約する。 4.1. フラグシーケンス フラグシーケンスはフレームの開始、又は終了を示す。オクテットストリ ームは、値 01111110 (16 進で 0x7e) をオクテット単位でチェックする。 4.2. 透過性 オクテット詰め手続きを使用する。制御エスケープオクテットは 2 進の 01111101 (16進 0x7d) として定義され、最上位ビットが一番最初である。 最低限、送信側実装体は、フラグシーケンスと制御エスケープオクテット をエスケープしなければならない (MUST)。 FCS の計算後、送信者は 2 つのフラグシーケンス間のフレーム全体をチェッ クする。各々のフラグシーケンス、制御エスケープオクテット、非同期制 御キャラクタマップ (ACCM: Async-Control-Character-Map) の送信時にフ ラグを付けられたオクテットは、制御エスケープオクテットと、その後ろ に元のオクテットと 16 進の 0x20 と排他的論理和をとったオクテットが 付けられ、2 オクテットシーケンスに置き換えられる。 これは、ビット位置が 76543210 の番号を付けられたビット 5 補完で ある (ISO の番号付けの 87654321 で使用されている 6 番目のビット -- ドキュメントを比較する時注意されたい)。 受信側実装体は、正しく全ての制御エスケープシーケンスを処理しなけれ ばならない (MUST)。 受信時、FCS の算出前に 16進で 0x20 以下の値を持つ各オクテットをチェッ クする。受信した ACCM にフラグが指定されているならば、それは単に除 去する (それは介在するデータ通新装置によって挿入されたかもしれない)。 各制御エスケープオクテットも除去され、もしフラグシーケンス (フレー ムをアボートする) でなければ、後続するオクテットは 16進の 0x20 と排 他的論理和をとられる。 幾つかの例を示せば、より明確になるだろう。エスケープされるデータは、 以下のように回線上に送信される。 0x7e は 0x7d, 0x5e に符号化される (フラグシーケンス) 0x7d は 0x7d, 0x5d に符号化される (制御エスケープ) 0x03 は 0x7d, 0x23.に符号化される (ETX) ソフトウェアフロー制御を持つモデムは、8 番目のビット (バイナリ) を 無視する出力 DC1 と DC3 を妨げてもよい。このデータは以下のように回 線上に送信されるだろう。 0x11 は 0x7d, 0x31 に符号化される (XON) 0x13 は 0x7d, 0x33 に符号化される (XOFF) 0x91 は 0x7d, 0xb1 に符号化される (パリティあり XON) 0x93 は 0x7d, 0xb3 に符号化される (パリティあり XOFF) 4.3. 不正フレーム 短すぎるフレーム (16 ビット FCS を使用して 4 オクテット以下) や、制 御エスケープオクテットの直後に閉じるフラグシーケンスで終了するフレ ーム、オクテットのフレーム化に違反するフレーム (ストップビットとし て "1" のビットを期待しているが、"0" が送信さけている) は黙って破棄 され、FCS エラーにはカウントされない。 4.4. タイムフィル 4.4.1. オクテット同期 オクテット間タイムフィルについては規定しない。 フラグシーケンスは、フレーム間タイムフィルの間に送信しなければなら ない (MUST)。 4.4.2. 非同期 オクテット間タイムフィルは、"1" のビットを続けて送信する (mark-hold 状態) ことによって果たさなければならない (MUST)。 フレーム間タイムフィルは、オクテット間タイムフィルの拡張として見る ことができる。それを行うことにより、全てのフレームに 1 オクテットを セーブすることができ、遅延を減らし、帯域を増やす。これは、フラグシ ーケンスがフレームの終了と開始の両方に使えるから可能である。如何な るフレームを受信した後も、アイドルの受信側は常にフレーム開始状態に いる。頑強な実装体はむやみにこのトリックの使うことを避けるべきであ る。なぜなら、遅延を減らす対価が信頼性の低下であるからである。ノイ ズの多い回線の場合、受信側がゴミの文字を受信して、入力フレームの一 部としてそれを解釈するかもしれない。もし送信側が次のフレームを送信 する前に新たな開始フラグシーケンスを送信しないならば、フレームは不 正フレームを引き起こすノイズ文字に付加されるだろう (高信頼性を持っ て)。 実装体は、もし新しいフレームが最後に続いて来なければ、常に開始フラ グシーケンスを送信することによって最善の結果を果たすことが提案され る。送信者は、前の終了フラグシーケンス後、"感知可能な時間" が経過し たら、開始フラグシーケンスを送信すべきである (SHOULD)。"感知可能な 時間" の最大値は、遅いタイピストのタイビング率程度であり、約 1 秒で ある。 4.5. 送信の考慮 4.5.1. オクテット同期 様々な符号化と周波数変更の定義は使用する DTE/DCE 装置の責任であり、 この規約の範囲外である。 4.5.2. 非同期 全てのオクテットは、1 つの開始ビットとデータの 8 ビットと 1 つの停 止ビットを持って、最下位ビットが一番最初に送信される。7 ビット非同 期回線についての規定はない。 5. ビット詰めフレーム化 このチャプタは、ビット同期回線での擬似 HDLC フレーム化の使用方法を 要約する。 5.1. フラグシーケンス フラグシーケンスはフレームの開始か終了を示し、フレーム同期のために 使用される。ビットストリームは、2 進数のシーケンスで 01111110 (16 進で 0x7e) をビット単位でチェックされる。 "共有 0 モード" フラグシーケンス "011111101111110" は使用すべきでな い (SHOULD NOT)。避けられない場合、そうした実装体は検出された最初の フラグシーケンス (フレームの終了) が、即座にリンク層に通信されるこ とを保証しなければならない (MUST)。共有 0 モードの使用は、ビット同 期から非同期への変換器や、ビット同期からオクテット同期への変換器と の相互接続性を妨げる。 5.2. 透過性 FCS を算出した後、送信者は二つのフラグシーケンス間のフレーム全体を チェックする。5 つの連続した "1" ビットのシーケンス全て (FCS の最後 の 5 ビットも含む) に対し、フラグシーケンスに見られないことを保証す るために、後ろに "0" ビットを挿入する。 受信時は、FCS を算出する前に、直後に 5 つの連続した "1" ビットが続 く "0" ビットを全て破棄する。 5.3. 不正フレーム 短すぎるフレーム (16 ビット FCS を使用して 4 オクテット以下) や、6 個以上の "1" ビットシーケンスで終わるフレームは黙って破棄され、FCS エラーにはカウントされない。 5.4. タイムフィル オクテット間タイムフィルについては規定しない。 フラグシーケンスは、フレーム間タイムフィルの間に送信すべきである (SHOULD)。しかし、ある種の回線交換回線、特にビット活性時間に基づい て料金を計算する回線は、マークアイドル (連続した 1) を使用する必要 がある。ビット同期回線でマークアイドルを使用する場合、実装体はアイ ドル時間中、フラグ間に少なくとも 15 個連続した "1" ビットを保証し、 アイドル時間の後、フラグシーケンスがフレームの開始で常に生成される ことを保証しなければならない (MUST)。 これは、7 〜 14 ビットのマークアイドルを許している ISO 3309 とは 異なる。 5.5. 送信の考慮 全てのオクテットは最下位ビットが一番最初に送信される。 様々な符号化と周波数変更の定義は使用する DTE/DCE 装置の責任であり、 この規約の範囲外である。 PPP は下位層のビットストリームの表現とは無関係に処理するが、送信の ための標準が無いことはデータリンク標準が無いのと同程度に、高い相互 接続性を妨げる。56 Kbps から 2.0 Mbps の速度では NRZ は現在最も広く 利用可能であり、基本的にデフォルトとして推奨されている。 符号化の設定が可能な場合、逆転設定エラーを通知するための相対的な免 疫になり、高価な DSU/CSU 無しでインスタンスが接続可能となるかもしれ ない (MAY) ので、代わりに NRZI が推奨される。不幸にも、NRZI 符号化 は 16 ビット FCS の X1 係数の誤りを悪化させる。よって 2**15 で 1 つ の (2**16 で 1 つではない) エラーが検出できず、三重エラーも検出でき ない。従って NRZI を使用する場合は、x1 係数を含む 32 ビット FCS を 折衝することが推奨される。 最大 45 Mbps までの高速時、ある実装者は ANSI 高速同期インタフェース [HSSI] を選択した。この経験は現在制限されているが、実装者は送信符号 化の選択で協調することを奨励している。 6. 非同期から同期への変換 回線の一方の終端は非同期 PPP の実装で、もう一方が同期実装である結果、 非同期-同期変換器を使用する (あるものはモデムやセルラーに組み込まれ ている) ケースがあるかもしれない。処理中に全ての詰めを行うことは変 換器の責任である。 この機能を可能にするために、同期 PPP 実装は必ず、LCP 設定肯定応答に 同期制御文字マップ設定オプションを付けて応答しなければならない (MUST)。しかし、設定オプションを受諾することは、同期実装が全ての ACCM マッピングを行うことを意味していない。代わりに、そのようなオク テットマッピングは、非同期-同期変換器によって実行されるだろう。 7. 追加の LCP 設定オプション 設定オプション形式と基本オプションは既に LCP [1] で定義されている。 LCP オプションタイプフィールドの最新の値は、最新の "番号割り当て" RFC [10] で規定される。このドキュメントは、以下の値に関係する。 2 同期制御文字マップ 7.1. 同期制御文字マップ (ACCM) 説明 この設定オプションは、同期回線上での制御文字の透過性を折衝する方 法を提供する。 非同期回線の各終端は二つの同期制御文字マップを維持する。受信側 ACCM は 32 ビットであるが、送信側 ACCM は最大 256 ビットまで可能 である。これにより、4 つの異なる ACCM、回線の各方向で 2 つがあり える。 非同期回線では、デフォルトの受信側 ACCM は 0xffffffff である。デ フォルトの送信側 ACCM は 0xffffffff であり、加えて制御エスケープ とフラグシーケンス文字自身と、妨害されるかもしれないフラグ化され る他の出力文字 (事前設定による) である。 他のタイプの回線では、マッピングする必要が無いのでデフォルト値は 0 である。 16 進で 0x20 以下の全てのオクテットをデフォルトで含めることは、 DEL (削除) を除く全ての ASCII 制御文字 [6] を、全ての既知のデ ータ通信装置を通じて透過的に通信することを可能にする。 送信者は、0x40 から 0xff (0x5e を除く)までの範囲の値も、制御エス ケープ形式で送信してよい (MAY)。これらのオクテット値は折衝可能で はないので、全ての非制御文字を扱うことができないという受信側の問 題を解決しない。さらに、このテクニックは 8 番目のビットに効果が ないので、7 ビット文字だけしか送信できない通信回線の問題を解決し ない。 この規定は、例えば 3309:1991/Amendment 2 [3] 等の最近の改訂版 とは詳細には異なることに注意されたい。しかし、そうした "透過 性拡張" は、"事前の合意" によってのみ適用可能である。この規定 における透過性方法の使用は、PPP に関する事前合意に相当する。 3309:1991/Amendment 2 との互換性のために、送信側は DEL と 8 番目の (最上位) ビットが設定された ACCM 相当をエスケープして もよい (MAY)。受信側アルゴリズムには、何ら変更は不要である。 ACCM 折衝の後、送信側は DEL のエスケープを中止すべきである (SHOULD)。 しかし、全ての制御文字をマッピングすることはほとんど必要ではなく、 制御文字をマッピングすることは大抵不要である。設定オプションは、 通信相手が送信する時にどの制御文字をマッピングしておかなければな らない (MUST) かを通信相手に通知するために使用される 通信相手が認識している制約のために必要ならば、通信相手は他の如何 なるオクテットもマッピングされた形式で依然として送信してよい (MAY)。通信相手は、マッピングされたオクテットのセットの論理結合 を持つ通信設定否定応答を返すべきである (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 | ACCM +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACCM (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length 6 ACCM ACCM フィールドは 4 オクテットであり、マッビングする制御文字のセッ トを示す。そのマップは最上位ビットが一番最初に送信される。 各々の数字付きのビットは、同じ値のオクテットに対応する。もしビッ トが 0 にクリアされたら、そのビットはマッピングする必要が無い。 もそビットが 1 に設定されていれば、そのオクテットはマッピングし たままでなければならない (MUST)。例えば、もしビット 19 が 0 に設 定されていれば、ASCII 制御文字 19 (DC3, Control-S) をそのまま送 信してもよい (MAY)。 注記: 最下位オクテット (一番最後に送信される) の最下位ビット が、ビット番号 0 であり、ASCII 制御文字 NUL にマッピングされ る。 A. 推奨 LCP オプション 以下の通信設定オプションが推奨される。 高速回線 マジックナンバー有り リンク品質監視有り アドレスと制御フィールド圧縮無し プロトコルフィールド圧縮無し 低速か非同期回線 非同期制御文字マップ有り マジックナンバー有り アドレスと制御フィールド圧縮有り プロトコルフィールド圧縮有り B. PPP フレームの自動認識 例えば、ログインシーケンスの間に PPP フレームを検出することは時々望 ましい。以下のオクテットシーケンスは全て、正しい PPP LCP フレームで 始まっている。 7e ff 03 c0 21 7e ff 7d 23 c0 21 7e 7d df 7d 23 c0 21 最初の 2 オクテットは Unix における正しいユーザ名ではないことに注意 されたい。しかし 3 つ目の形式に限っては、パリティ (それらはパリティ 回線でさえ正しい) と破棄に関係なく 03 と ff が制御文字 ETX と DEL として取られる時は必ず、正しいチェックサムが付いた PPP フレームを生 成する。 多くの実装体は、上記のユーザ名のパターンの一つがログインの間に検出 される時、初期 PPP チェックサムをチェックせずに、インタフェースをパ ケットモードに置くことによって、これを扱っている。最初の入力 PPP フ レームは破棄されるが、通信設定要求は即座に送信される。 C. 高速フレームチェック (FCS) 実装 FCS は元々、ハードウェア実装を念頭に設計された。シリアルビットスト リームは配線上に送信される。FCS はシリアルデータが出て行く時に計算 され、結果的に生成された FCS の補数がシリアルストリームに追加され、 その後にフラグシーケンスが続く。 受信側はフラグシーケンスを検出するまで、受信した FCS の計算が完了し たことを決定する方法が無い。従って、FCS は FCS 処理が補数化された FCS を通過する時に、特定のパターンが結果として生成されるよう設計さ れる。正しいフレームは、この "正常 FCS" の値によって示される。 C.1. FCS テーブル生成器 以下のコードは、FCS-16 を計算するのに使用される検索テーブルを生成す る。 /* * FCS-16 テーブルを生成する * * Drew D. Perkins、カーネギーメロン大学 * * Mohsen Banan と D. Hugh Redelmeier よりコードライブラリを拝借した */ /* * FCS-16 生成多項式: x**0 + x**5 + x**12 + x**16 */ #define P 0x8408 main() { register unsigned int b, v; register int i; printf("typedef unsigned short u16;\n"); printf("static u16 fcstab[256] = {"); for (b = 0; ; ) { if (b % 8 == 0) printf("\n"); v = b; for (i = 8; i--; ) v = v & 1 ? (v >> 1) ^ P : v >> 1; printf("\t0x%04x", v & 0xFFFF); if (++b == 256) break; printf(","); } printf("\n};\n"); } C.2. 16 ビット FCS 計算方法 以下のコードは、インタフェースにデータが到着した時にフレームチェッ クシーケンスを計算するテーブル検索計算を提供する。この実装は、 [7],[8],[9] に基づいている。 /* * u16 は unsigned の 16 ビットの数を表す。自分のハードウェアに * 合わせて typedef を調整すること。 */ typedef unsigned short u16; /* * テーブル生成器によって計算される時の FCS 検索テーブル */ static u16 fcstab[256] = { 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 }; #define PPPINITFCS16 0xffff /* 初期 FCS 値 */ #define PPPGOODFCS16 0xf0b8 /* 正しい最終 FCS 値 */ /* * 現 FCS と新たなデータを与えて新しい FCS を計算する */ u16 pppfcs16(fcs, cp, len) register u16 fcs; register unsigned char *cp; register int len; { ASSERT(sizeof (u16) == 2); ASSERT(((u16) -1) > 0); while (len--) fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff]; return (fcs); } /* * FCS の使い方 */ tryfcs16(cp, len) register unsigned char *cp; register int len; { u16 trialfcs; /* add on output */ trialfcs = pppfcs16( PPPINITFCS16, cp, len ); trialfcs ^= 0xffff; /* 補数 */ cp[len] = (trialfcs & 0x00ff); /* 最下位バイトが一番目 */ cp[len+1] = ((trialfcs >> 8) & 0x00ff); /* 入力をチェック */ trialfcs = pppfcs16( PPPINITFCS16, cp, len + 2 ); if ( trialfcs == PPPGOODFCS16 ) printf("Good FCS\n"); } C.3. 32 ビット FCS 計算方法 以下のコードは、インタフェースにデータが到着した時に 32 ビットフレ ームチェックシーケンスを計算するテーブル検索計算を提供する。 /* * The FCS-32 生成多項式: x**0 + x**1 + x**2 + x**4 + x**5 * + x**7 + x**8 + x**10 + x**11 + x**12 + x**16 * + x**22 + x**23 + x**26 + x**32. */ /* * u32 は unsigned の 32 ビットの数を表す。自分のハードウェアに * 合わせて typedef を調整すること。 */ typedef unsigned long u32; static u32 fcstab_32[256] = { 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de, 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59, 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433, 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01, 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65, 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0, 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f, 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a, 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8, 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, 0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7, 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc, 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b, 0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236, 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d, 0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713, 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777, 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2, 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, 0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9, 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf, 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94, 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d }; #define PPPINITFCS32 0xffffffff /* 初期 FCS 値 */ #define PPPGOODFCS32 0xdebb20e3 /* 正しい最終 FCS 値 */ /* * 現 FCS と新しいデータから新しい FCS を算出する */ u32 pppfcs32(fcs, cp, len) register u32 fcs; register unsigned char *cp; register int len; { ASSERT(sizeof (u32) == 4); ASSERT(((u32) -1) > 0); while (len--) fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]); return (fcs); } /* * fcs の使い方 */ tryfcs32(cp, len) register unsigned char *cp; register int len; { u32 trialfcs; /* 出力に追加 */ trialfcs = pppfcs32( PPPINITFCS32, cp, len ); trialfcs ^= 0xffffffff; /* 補数 */ cp[len] = (trialfcs & 0x00ff); /* 最下位バイトが一番目 */ cp[len+1] = ((trialfcs >>= 8) & 0x00ff); cp[len+2] = ((trialfcs >>= 8) & 0x00ff); cp[len+3] = ((trialfcs >> 8) & 0x00ff); /* 入力チェック */ trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 ); if ( trialfcs == PPPGOODFCS32 ) printf("Good FCS\n"); } セキュリティの考慮 物理層要件のセクションでも注記したように、リンク層は物理層の接続状 態が変更された時に通知されないかもしれない。結果的に、完全性や、交 換システムや管理のセキュリティへの過信によりセキュリティ喪失が起こ り得る。挿入攻撃は検出されないかもしれない。同じ発呼側識別子を偽っ て送信できる攻撃者は、リンク認証を回避することができるかもしれない。 参照 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 50, RFC 1661, Daydreamer, July 1994. [2] ISO/IEC 3309:1991(E), "Information Technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - Frame structure", International Organization For Standardization, Fourth edition 1991-06-01. [3] ISO/IEC 3309:1991/Amd.2:1992(E), "Information Technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - Frame structure - Amendment 2: Extended transparency options for start/stop transmission", International Organization For Standardization, 1992-01-15. [4] ISO/IEC 4335:1991(E), "Information Technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - Elements of procedures", International Organization For Standardization, Fourth edition 1991-09-15. [5] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer, January 1994. [6] ANSI X3.4-1977, "American National Standard Code for Information Interchange", American National Standards Institute, 1977. [7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983. [8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte, September 1986. [9] LeVan, J., "A Fast CRC", Byte, November 1987. [10] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. 謝辞 このドキュメントは、インターネット技術作業団体(IETF: Internet Engineering Task Force)のポイントツーポイントプロトコルのワーキング グループの生産物である。コメントは、ietf-ppp@merit.edu のメーリング リストに投稿しなければならない。 この規約は前の RFC に基づいており、多くの貢献に対し感謝したい。 32 ビット FCS のサンプロコードは Karl Fox (Morning Star Technologies) によって提供された。 この規約を作成するにあたり、コンピュータ資源とネットワークアクセス をサポートしてくれた Morning Star Technologies に、特別感謝したい。 議長のアドレス ワーキンググループは、以下の現議長を経由してコンタクトできる。 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