このメモの状態

このドキュメントは、インターネット社会の為のインターネット標準トラックプロトコルを規定しており、改善の為の議論と提案を求めている。このプロトコルの標準化の状態と状況については、"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;

    /* 出力に追加 */
    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