Ethernet_Tutorial

2002年6月

セミナー資料

ネットワークの基礎講座

株式会社　クレス

光岡輝義

内容

1. イーサネット

2. ポイント対ポイント・プロトコル(PPP)

3. インターネット・プロトコル（IP）

4. トランスミッション制御プロトコル（TCP）

5. DSLによるインターネット接続

© Cresc Corporation, June 2002

目次

1ネットワークの基礎講座

2目次

5イーサネット

51.はじめに

82.イーサネット・パケットの構成

113.イーサネットのアクセス制御

134.イーサネットの論理制御(LLC)

155.イーサネットの物理層

186.ネットワーク・トポロジ

207.参考となるドキュメント

21ポイント対ポイント・プロトコル(PPP)

211.はじめに

252.PPPの仕様

25RFC 1661 (PPP: The Point-to-Point Protocol)

261.1　概要(Abstract)

291.2　PPPカプセル化(PPP Encapsulation)

311.3　PPPリンク動作(PPP Link Operation)

351.4　オプション・ネゴシエーション・オートマトン(The Option Negotiation Automaton)

471.5 LCP パケット形式(LPC Packet Formats)

581.6 LPC設定オプション(LPC Configuration Options)

681.7 セキュリティへの考察(Security Considerations)

681.8　参照(References)

69インターネット・プロトコル

691.はじめに

702.インターネットの歴史

723.アーキテクチャ・モデル

744.インターネットのアーキテクチャ

775.ブリッジ、ルータ、ゲートウエイ

796.IPの経路設定

827.インターネットのアドレス

838.IPアドレス

869.サブネット

8810.静的サブネット化の例

9011.ユニキャスト、ブロードキャスト、マルチキャスト

9212.プライベート・アドレス

9313.クラスレスのドメイン間ルーティング(CIDR)

9414.ドメイン名とIPアドレスのマッピング

9615.IPデータグラム

10216.ICMP(Internet Control Message Protocol)

11017.アドレス解決プロトコル(ARP: Address Resolution Protocol)

11318.経路設定（ルーティング）の基本

11619.ベクター・ディスタンス

11820.リンク・ステート、最短パス最初(Link-State, Shortest Path First)

12021.Border Gateway Protocol(BGP)の概要

122トランスミッション制御プロトコル(TCP)

1221.はじめに

1232.TCPのコンセプト

123信頼性あるメッセージの到着の保証

124誤りの検査

124フロー制御

124コネクション・モードとポートの概念

1273.TCPセグメントのヘッダ

1304.コネクションの状態遷移

131コネクションの開設

132コネクションの開放

132コネクションのリセット

1345.データ転送

1366.緊急データ送信

1377.ウィンドウ（フロー）制御

1398.参考URL

140DSLによるインターネット接続

1401.DSLにはいろんな方式がある

1422.DSLはインターネットとどう接続されるのか

1443.PPPoAとPPPoE

1464.ルータの機能

1525.企業の場合

152ファイアウオール

155VPN

2001年2月（初版）

ネットワークの基礎講座(1)

イーサネット(Ethernet)

株式会社　クレス

イーサネット

1. はじめに

皆さんがネットワークについて関心を持つとしたら、一番手元にあるイーサネットからではないだろうか。あなたの使っているPCからの情報はまずこのイーサネット・ケーブルを通って他のPCやインターネットに流れていく。イーサネットは長い歴史を持ち、ネットワークの基本的な要素ではあるが、今も発展を続け、単にLANの高速化だけでなく、ブロードバンド社会にむけた光アクセス（皆さんのオフィスや家庭から局までの光ネットワーク）の手段（EPON: Ethernet Passive Optical Network）として注目されているのである。

イーサネットはもともとXerox社の研究所が開発したものであり、”Ethernet”という名前はXerox社の商標登録だった。その後IEEE（電気・電子学会）がLANの標準化を担当することになり1980年2月に発足した802委員会が作業した。イーサネットは802.3が物理層を、802.2がデータ・リンク層をまとめている。ただ802.3規格が出来る前に存在した所謂イーサネット(Ethernet 2あるいは単にEthernet規格とも呼ぶ)規格もあり、両者は微妙に異なるのでデバイスやドライバを開発する人は注意が必要だが、我々のようにこれを利用する立場の人たちはそこまで詳細に知る必要は通常無い。

このように「イーサネット」と我々が言うときは、それには物理層とデータ・リンク層が含まれている。とたんに「層」という言葉が出てきたので、まずコンピュータ間のデータ転送における階層について説明しなければならない。一般にこれの説明の為に良く参照されるのがOSI参照モデルである。OSIは国際的に標準化しようとしたプロトコルであるが、残念ながら米国を中心としたデファクト・スタンダードのTCP/IPに駆逐され、いまはOSIといえばこの階層モデルが引き合いにだされるだけである。

7層からなるOSI参照モデルは、上からつぎのようになっている。

7:　アプリケーション(Applications)層

この層はアプリケーション・ソフトウエアが乗る。ファイル・アクセスと転送、仮想マシン・エミュレーション、プロセス間通信などの処理がここで取扱われる。

6:　プレゼンテーション(Presentation)層

データ表現の相違がこの層で処理される。例えば、UNIXスタイルの行終端（CRのみ）をMS-DOSスタイル（CRLF）に変換したり、EBCIDIC符号をASCII文字セットに変換したりする処理がこれに該当する。

5:　セッション(Session)層

ネットワークを介したアプリケーション間の通信の制御がこの層で実施される。パケットのシーケンスの検査や、双方向通信の処理などがこの層で処理される。

4:　トランスポート(Transport)層

この層の下位3層が正しく実行しており、透過的（トランスペアラント）で論理的なデータの流れがエンド・ユーザとネットワーク・サービス間でとれていることを確たるものとする。もっと柔らかい表現をすれば、等価的で正しいデータ・ストリームが得られるように、下位3層で処理できなかった問題を解決する。具体的にはパケットの順序制御などが相当する。更にはひとつのネットワーク接続に対し複数のトランスポート接続を行う効率的な転送機能もここで持たせる。

３：　ネットワーク(Network)層

この層では、ある端末から別の端末へのパケットが所定の時間内に到達するようにする。ルーティング（日本語では適切な言葉が無いので、経路設定とか、転送と中継とでもしようか）やフロー制御がここで行われる。物理的な網の部分を無視すればこの層がOSIモデルの最下位層である。具体的な機能としてはネットワーク・アドレス制御、サービス品質制御、データ転送制御などがこれに含まれる。

2:　データ・リンク(Data Link)層

この層では、回線にデータを乗せたり、逆に回線からデータを取り出し、誤りの検出と訂正及び再送を行う。この層は通常2つのサブ・レイヤに分割され、上半分の誤りの検出を行う論理リンク制御(LLC: Logical Link Control)と、下半分の回線とのデータの受け渡しをするメディア・アクセス制御(MAC: Medium Access Control)とからなる。

1:　物理(Physical)層

これは金物の層である。ここではケーブル、コネクタ、信号などの規格が相互接続のため規定される。

イーサネットの規格には、データ・リンク層に係わる部分と物理層に係わる部分が記載されている。ここではデータ・リンク層に係わる部分から説明することにする。

2. イーサネット・パケットの構成

まずイーサネットに乗るパケットはどのようになっているのだろうか。パケットは頭から次のような構成となっている。ただしネットワーク上はビット列で伝送されるから、実際は各バイトの左のビットから送信される。ここで「左」といったのは、IEEEとIETF（インターネットの技術グループでInternet Engineering Task Forceの略）とでバイトの表現が異なり、混乱を招くからである。同じことを言っているのにIEEEでは下のビット(LSB: Least Significant Bit)から、IETFでは上のビット(MSB: Most Significant Bit)から送信されるということになるからである。

プリアンブル

7バイト

1と0の交番ビット列信号で、イーサネット・レシーバがビット同期をとるのに使う（これはチップが生成するので、ソフトウエアは関与しない）

フレーム開始識別

1バイト

10101011なるビット列でフレームの頭を知るのに使われる。（これはチップが生成するので、ソフトウエアは関与しない）

宛先イーサネット・アドレス

6バイト

相手とするレシーバの唯一無二のイーサネット・MACアドレスである。イーサネット上の全端末に送出するブロードキャストのパケットの場合、宛先アドレスはオール1(Ethernet)か、第2バイト目が奇数か(802.3)である

送信元イーサネット・アドレス

6バイト

送信端末の唯一無二のイーサネット・MACアドレスである。

データの長さ（802.3）またはタイプ（Ethernet）

2バイト

フレーム（プリアンブルとSFDを除く）のバイト長がはいる。1518以上の場合は上位層のタイプを意味する。例えば0x800はIPパケットであることを示す

データ

46～1,500バイト

転送すべきデータがこの部分にはいる。最小46バイトとなるよう46バイト長以下のデータにはパッディングする。後述のように802.3ではこの部分の頭が更に追加ヘッダ情報が入る。

フレーム・チェック・シーケンス

4バイト

32ビットの巡回誤りチェックデータで、通常この部分はチップが生成する

プリアンブル(preamble)は７オクテット（バイト）で、1と0の繰り返し信号である。これをもとに、受信回路の位相同期系(PLS)がこの信号に同期して、到来パケットのビット列をきちんと受信できるようにする。

開始フレーム識別子(SFD: Start Frame Delimiter)は、'10101011'なる8ビットからなるビット列でプリアンブルの直後にあり、フレームの開始を示す（フレーム同期）ものである。

ところでMACアドレスとは何であろうか？

これは唯一無二の16進のシリアル番号で、ネットワーク上のイーサネット・デバイス（アダプタ、ブリッジ、ルータなど）を識別する為に附されるものである。イーサネット・デバイスにはこのアドレスは通常ソフトウエアで設定できるが、恒久的に製造メーカが設定するもので、ユーザが変更を加えてはならない。

MACアドレスがどうして唯一無二でなければならないかというと、ネットワーク上の自分宛のパケットを排他的にそのイーサネット・デバイスが取り出さねばならないからである。でないと2つのデバイス間の区別がつかなくなるからである。ネットワーク上のデバイスはそのネットワーク上のトラフィック（パケットの流れ）を監視し、各パケットから自分宛で受理すべきパケットを探す。総てのデバイスが同時に受理しなければならないブロードキャスト（放送）という特別な状態も存在する。

MACアドレスは6バイト（48ビット）長で通常12:34:56:78:90:ABなどのようにコロンで区切った16進で表現する。コロンは省略しても良いが、読みやすさと間違いを防ぐ為に通常区切りとして使用される。イーサネット・デバイスの各メーカは、自分が使えるMACアドレスの範囲を申請する。アドレスの最初の3バイトはメーカの識別に使われる。RFC-1700にはメーカ宛に割り当てられたアドレスの一覧の一部がリストアップされている。最新のリストはftp.lcs.mit.edu in pub/map/Ethernet-codesから取得できる。皆さんのコンピュータのOSがWindowsで、かつLANに接続されていれば、以下の手順で皆さんのコンピュータのEthernetポートのMACアドレスを知ることができる。スタート／ファイル名を指定して実行(R)／”winipcfg”を入力してOKボタンをクリック。Ethernetアダプタ情報が表示される。アダプタアドレスが知りたいMACアドレスである。表示されるそれ以外の情報は、今回の解説には関係ないので説明はしない。

ブロードキャスト・アドレスは総ての受信デバイスあてのアドレスで、802.3では2バイト目が奇数(1,3, ... FF)のものはすべてブロードキャスト・アドレスである。

データが46バイト以下のときはパッディングされるとか、最大1500バイトというけれど、それでは上位層が困るのではと心配されるかもしれない。これはMAC層にわたすデータグラムの長さの管理は上位層の責任となっており、IPの場合は下位層の最大伝送単位長（これをMTU: Maximum Transmission Unitという）に従ってIPパケットを分割してデータ・リンク層に渡す。

3. イーサネットのアクセス制御

イーサネットのアクセスと再送制御は「キャリア検知多重アクセス／衝突検出」方式といい、英語ではCSMA/CD(Carrier Sense Multiple Access / Collision Detection)と書く。コンピュータがイーサネット上にメッセージを送信したいときは、まずネットワークが他のノード（端末、ブリッジ、ルータなど）によって使われていないか、つまり誰かがキャリアを送出していないかどうかを調べる（これがキャリア検知）。イーサネットに送り出された信号はケーブル上を上り下り双方向に伝播する。したがってネットワーク上の総てのノードに伝わる（これが多重アクセス）。総てのノードがこのメッセージを読むことが出来るけれども、自分宛のものでなければこれを無視するので、当該の宛先（MACアドレス）のノードだけが読み出すことになる。

「衝突」は、たまたま2つのノードが同時に送信を開始したら生じ得る。これは最初のノードが送信を開始したが、それが第2のノードに「使用中」として検出されない短い期間に第2のノードが送信を開始する場合である。どうしてそのような事態が発生するのかと思われる人がいるかも知れない。実際はデバイス毎にキャリアの検知能力が異なるであろうし、またネットワーク・トポロジの話をしなければならないが、100m離れたデバイスに相手からの10Mbpsのパケットが届き始めるのは相手が第3ビット目を送り終わった時点となる時間差があるからである。衝突が発生すると2つのパケットが重なり合って読出し不能の状態になる。更には衝突を検出した送信もとノードは「ジャム」といって32ビット長の特殊の妨害信号（同軸系では通常より高い信号電圧）を送信して該パケットを確実に読出し不能にする。衝突が発生したら、そのノードはランダムな時間待機する（2つが同じ時間をおいて再送信したらまた衝突が発生する確率が大である）。この待機／再送信のサイクル（待機時間はその度2倍される）を16回繰り返しそれでも駄目ならこれを上位層や管理面に報告する。

どうしてこのように徹底的に衝突検出を確たる物にしなければならないかは、歴史的な経過がある。当初のLANは10Base5（別名イエロー・ケーブルとも云った）というごつい同軸ケーブルが使用されていた。このケーブル一本が工場や研究所を這いまわり、長さが不足すればレピータという中継器を介して継ぎ足されていた。レピータは電気信号をそのまま増幅伝送するので、一番端同士（遠端）の端末に信号が届くには相当の遅延が生じる。送信元が衝突を知るのはその往復分（ラウンド・トリップ）である。この時間を50マイクロ秒（約1.5kmに相当）と定めたのである。この時間は10Mbpsでいえば500ビット（64バイト）である。このことからデータ部分が46バイトに満たなければパッディングしなければならないとされているのである。転送スピードが速くなってもこの規約は守らなければならない。

したがって、このメカニズムは、極端にトラフィックが大きくなって容量の限度に近くなると衝突により効率が低下する傾向がある。通常の場合は衝突による遅れやスループットの低下は問題になることはなかろう。

4. イーサネットの論理制御(LLC)

実はイーサネットとよく呼ばれるが、フレーム・フォーマットには二つの標準が存在する。ひとつは1978年にXerox、Intel、DEC社が作成した標準で通常イーサネット(Ethernet)あるいは3社の頭をとってDIXイーサネットと呼ばれるものである。これはイーサネット・パケットの構成のところで紹介したフォーマットであり、データの長さ（またはタイプ）のフィールドがタイプとして使われるものである。もうひとつの標準はIEEE802.3がその後に標準化したもので、データの長さ（またはタイプ）のフィールドはデータの長さとして使用し、その後に以下の拡張がされているものである。二つの標準はここのフィールドが1500以上か否かで処理をすれば良いので物理層は互換性を持たせることはできるが、データ・リンク層は互換性を持たせられないので注意が必要である。

IEEE 802.2は802.3物理層パケット・フォーマットにリンク・サービス・アクセス・ポイント(LSAP: Link Service Access Point)の概念をとりいれ、次のようなリンク制御の為のフィールドを追加している。これらのフィールドは、46~1500バイトのデータ部分に入るものである。

8ビット

8ビット

8または16ビット

宛先サービス・アクセス・ポイント(DSAP Address)

送信元サービス・アクセス・ポイント(SSAP Address)

制御(Control)

情報

サービス・アクセス・ポイントは、両端でのデータ交換の相違を識別する為に使用される。DSAPとSSAPはDestination Service Access PointとSource Service Access Pointの略である。SSAPはLLCデータを送信し、DSAPはこれを受信する。ところがイーサネットの普及拡大に伴いこれでは不十分となり、802.2は更にSNAP(Sub-Network Access Protocol)という5バイトの拡張も採用した。これは上表のヘッダ部分のあとに更にプロトコルIDまたは組織コード用に3バイト、イーサネット・タイプに2バイトを追加するものである。拡張した書式を使っているか否かはDSAPとSSAPフィールドが共に170（16進でAA）が入っているかどうかで識別する。

これらの詳細は、別途PPPプロトコルのチュートリアルで説明することとしたい。

ただしSNA Pヘッダの最後の2バイトのフィールドには次の値が設定されている。これらはIPの説明で重要な意味を持つ。

0 組織コードを示す

1 2048(0x0800)IPデータグラム

2 2054(0x0806)ARPデータグラム

3 32821(0x8035)RARPデータグラム

5. イーサネットの物理層

次に物理層について簡単に説明する。

物理層のなかで一番皆さんが目にするのはイーサネット・ケーブルであろう。またその使い方も良く理解しておくべきであろう。ケーブルには10Base5, 10BaseT, 10Base2, 10Broad36などという名前が付けられている。一番お馴染なのは100BaseTX（カテゴリ5）と呼ばれるツイスト・ペア・ケーブルであろう。このケーブルはまた「ファスト・イーサネット」(Fast Ethernet)とも呼ばれる。”10”は信号速度10MHzを意味し、”Base”はベースバンド、Broadはブロードバンドを意味する。そして最後の部分がレピータ（中継器）を介さないで使える最大長を100m単位で示している。10BaseTの場合はこの規則に追加してツイスト・ペア・ケーブル、Fx（xは更に文字が追加される場合がある）やは光ファイバ・ケーブルを意味する。

実際には各ケーブルは以下のようになっている：

10Base2:50オームのベースバンドの細い同軸ケーブルで10MHzで動作する。このケーブルは良くシン（細い）ケーブルとかチーパ（安い）ケーブルとか呼ばれた。最大185mまで伸ばせる。

10Base5:50オームのベースバンドの標準の（太い）同軸ケーブルで、10MHzで動作する。最大500mまで伸ばせる。

10BaseFL:光ファイバ・ケーブルで10MHzで動作するケーブル。通常2km程度まで使える。

10BaseT:シールドなしのツイスト・ペア線(UTP: Unshielded Twisted Pair)による10MHzで動作するケーブル。通常100m~150mまで伸ばせるが、そのような用途はあまり無いであろう。

100BaseTX:10BaseTと同じくシールドなしのツイスト・ペアケーブルだが100MHzまで使用可能.カテゴリ5という名前は、ケーブルの伝送特性（何処までの周波数に使えるか）を示し、カテゴリ3は10MHz、カテゴリ4は16MHzのトークンリング、カテゴリ5は100MHz用である。通常100mまで伸ばせる。コリジョン・ドメイン長は最大500mである。

10Broad36:ブロードバンド・ケーブルで、10MHzで動作。3.6kmが最大長。

100BaseTXケーブルを良く見ると8本（4対）が使われているが、実際は送信と受信の2対（ピン１，２，３，６）だけに信号がながれる。PC側ではピン1,2（EIA/TIA標準の568Aではペア3）が送信データ、ピン3,6（568Aではペア2）が受信データで、偶数番号ピン（単色の線）がマイナス端子である。

ピン番号

TIA/EIA-568-A

TIA/EIA-568-B

注

1

白／緑

白／橙

2

緑

橙

3

白／橙

白／緑

4

青

青

5

白／青

白／青

6

橙

緑

7

白／茶

白／茶

8

茶

茶

良く使われる配線のRJ-45コネクタ接続は通常この2つのどれかになっている。オレンジの縦パタンで表示してあるのは白にオレンジが印刷されているという意味である。ケーブルには方向性がない（ストレート）のでどちら側をPCにあるいはハブにつなぐかは自由である。

PC同士をひとつのイーサネット・ケーブルで接続する場合は、「クロスオーバ・ケーブル」（通常「クロス」と呼ばれているが、これは”cross”の略と間違われる危険性がある）が必要になる。このケーブルは、ピン1,2のペアとピン3,6のペアが両端で交差する（つまり片方のピン1,2が他方のコネクタのピン3,6に、片方のピン3,6が他方のコネクタのピン1,2に対応する）。このケーブルは特殊で、一般に入手しづらいので、自分で組み立てなければならない場合がある。

100BaseTXファスト・イーサネット・ケーブルでLANを構成する場合に良く遭遇する問題に、ルータ、スイッチやインテリジェント・ハブとPC端末間に最大幾つまでの非インテリジェント・ハブ（所謂バカハブ）が入っても良いのかということであろう。スタッカブル・ハブは多くの端末に展開できるように、ハブを従属接続することができる。答えは2である。また、従来10BaseTで構成されていたLANを100BaseTXに拡張しようとする場合には、単にケーブルを置き換えただけでは問題が生ずる場合がある。つまりケーブル長に注意が必要で、マニュアルを良く見る必要がある。LAN機器のメーカによってはその接続の誤り率を監視して、転送速度を10Mに落とすようなものも存在する。

6. ネットワーク・トポロジ

イーサネットの初期の時代は、前にも書いたように1本の太い同軸に多くの端末がぶら下がるバスライン形式であった。

このような構成は、端末やワークステーションが貴重で分散していた時代は良かったが、ひとつの部屋に数10台のコンピュータが存在する時代になると、工事が大変だし、システムの信頼性にも問題が出てくる。

10Base5ケーブルに端末を接続するときは、太い同軸ケーブルの芯線に針を突き当てるやり方がとられた。しかしながら振動や移動が多い端末の場合は、これが接続の信頼性を損ねた。加えて、1台の故障がネットワーク上の総てのデバイスに影響を与えてしまう危険性もある。

そのような理由から、現在はスター型に構成するのが一般的である。

Host

A

cresc

.co.

jp

Name Server

co.

jp

Name Server

jp

Name Server

home

Name Server

root

Name Server

Host

www.

cresc

.co.

jp

q

r

Host

A

cresc

.co.

jp

Name Server

co.

jp

Name Server

jp

Name Server

home

Name Server

root

Name Server

Host

www.

cresc

.co.

jp

q

r

ここでネットワークの構成要素について簡単に説明することにする。

· レピータ(Repeater)：　ルーティングやパケット・フィルタリングなどいわゆるデータ・リンク層やネットワーク層の機能を有さないで、単純に物理層内で2つのケーブルをつなぐ物である。したがって衝突などの事象も通過する。物理層のデバイスで、専門的に云えば衝突ドメイン(Collision Domain)内のデバイスとなる。

· ハブ(Hub)：　ハブはまた集線装置(Concentrator)ともいい、スター型にネットワークを展開するものである。ハブのなかには、配下のデバイスの障害を自動的に検出し、これを切り離す機能を持ついわゆるインテリジェントなものもある。高度なハブは速度が10MHzか100MHzを判断し自動的に選択するものもある。ハブは本来物理層のデバイスである。しかしスイッチング・ハブと称するものは、宛先アドレスを見てこれをどこに転送するかの機能を持ち、データ・リンク層とネットワーク層の一部の機能を持つ高度なデバイスである。通常のハブ（ばかハブとかレピータ・ハブとかいうことがある）のパネルを見ていただきたい。衝突（通常”Col”などと印刷されている）表示ランプがひとつだけである。つまり物理層のデバイスだから衝突はその配下のデバイスに伝播され、このデバイスは衝突ドメインに含まれるのである。衝突ドメインを切り分けるデバイスは、ブリッジ、スイッチング・ハブ、ルータなど上位層のデバイスである。

· スイッチング・ハブ(Switching Hub)あるいはレイヤ2スイッチ(Layer 2 Switch)とも云う：　スイッチング・ハブはイーサネット・パケットを受信し、その宛先を見て該当するポートに送出するので、衝突は伝播しない。このデバイスには衝突表示のランプは存在しない。従ってポート毎のトラフィック量が少なくなりまた衝突も少なくなるのでスループットの低下の問題が少なくなる。

· ブリッジ(Bridge)：　2つ以上の物理的なネットワークを接続するもの。ブリッジは通常パケットのフィルタリングを行い、正しいパケットのみを伝送する。このデバイスはデータ・リンク層のデバイスであり、ネットワーク層の機能は有さない。

· ルータ(Router)：　外国人と話すときは「ラウタ」と発音してください。ルータは、ネットワークあるいはインターネットの、どのパスにトラフィックを流すかを決定する機能を有するネットワーク層のデバイスである。ルータはその為の情報をルーティング・プロトコルにより取得する。詳細はIPのチュートリアルで説明する。

· ゲートウエイ(Gateway)：　トランスポートより上の層の機能を持ってネットワークをつなぐ装置をいう。たとえば公衆電話回線のファクシミリのトラフィックをインターネットのメール形式に変換してインターネットに流したりする機能である。

7. 参考となるドキュメント

イーサネットに関するドキュメントは豊富に存在する。各自インターネットから好みのドキュメントを検索していただきたい。以下は、その一部である。

http://netman.cit.buffalo.edu/FAQs/ethernet.faq

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ethernet.htm

http://www.networkmagazine.com/article/NMG20000727S0012

2001年2月（初版）

ネットワークの基礎講座(2)

PPP(Point to Point Protocol)

株式会社　クレス

ポイント対ポイント・プロトコル(PPP)

8. はじめに

ポイント対ポイント・プロトコル(PPP: Point-to-Point Protocol)は、通信回線をはさんで2つのコンピュータがデータ通信する場合に標準的に使われるデータ・リンク層（またはMAC層）プロトコルである。PPPは、皆さんがアナログ・モデムを介してインターネットをアクセスする場合などで動作しているが、通常はこれを意識する必要はない。いまさらここで少し詳細に説明しようとする目的は、これがデータ通信における基本的なプロトコルであり、きちんと理解しておくべきものであることと、加えて最近はFTTHやDSLサービスでPPPoE（イーサネット上でのPPP接続）やPPPoA（ATM網上でのPPP接続）などが活用されているからである。

PPPの第1の目的は上位層からの各種データグラム（IPパケットなど）をカプセル化して相手に届けることである。それだけの目的であればSLIP(Serial Line IP)と呼ばれるプロトコルがある。SLIP(RFC 1055)は極めて簡単なプロトコルで、回線上のフレームはENDコード(0xC0)で終端されるというものである。データの中にこのコードが含まれ得るので、データ中の0xC0は(0xDB,0xDC)なる文字列に変換し、かつ0xDBを(0xDB,0xDD)なる文字列に変換して送信し、受信側でこれをもとに戻す。しかしながらSLIPは、リンク層での誤りの検出と処置が出来ない、各種上位プロトコルの区別が出来ない、リンクの制御ができない、ネットワークの制御が出来ないなどの問題があって現在利用されることはない。

PPPはこれらの問題を解決したもので、アナログ・モデムから高速光ファイバー回線まで現在幅広く使われている。

PPPはRFC1134から発展して幾つかのRFCを経由して現在はRFC1661(std51)とRFC1662(std51)が中心となった大きなグループとなっている。RFC1661はカプセル化、リンク制御について規定しており、RFC1662は代表的なHDLCベースのフレーミングに就いて規定している。またネットワーク制御は、ネットワーク・プロトコルごとに別途規定されている。RFC 1662で規定されているPPPフレームはもともとIBMのSDLC(Synchronous Data Link Protocol)から発展したHDLC(High-Level Data Link Control)のひとつのバリエーションでもある。HDLCから引き継いだ部分は、フレームの定義、それによる非同期、バイト同期、ビット同期などのデータ・ストリーム対応である。

PPPに関するRFCsは極めて多く、これらを全部マスターするのは大変である。私がひととおり最近のものから順に整理したものを以下に示す。対応するネットワークやプロトコルが増えればその分関連するRFC（Obsoleteされたものは除く）も多くなり、設計・検証が複雑となる。当社でPPPをインプリメントされる方はあまりいないとは思うが、システム・インテグレーションで一番問題の生じやすい（特に相互接続）ところでもあり、各ドキュメントの基礎だけは各技術者が理解されていることが好ましい。

PPP関連RFC一覧

2000年12月現在

番号

著者

タイトル

日付と注記

2684

D. Grossman;

J. Heimanen

Multiprotocol Encapsulation over ATM Adaptation Layer 5

September 1999

(Obsoletes 1483)

2516

L. Mamakos; K. Lidl;

J. Evarts; D. Simone;

R. Wheeler

A Method for Transmitting PPP Over Ethernet (PPPoE)

February 1999 (Working)

2364

G. Gross; M. Kaycee;

A. Malis; J. Stephens

PPP Over AAL5(PPPoATM)

July 1998

2153

W. Simpson

PPP Vendor Extensions

May 1997 (Updates: RFCs 1661, 1962)

1994

W. Simpson

PPP Challenge Handshake Authentication Protocol (CHAP)

August 1996

1990

Sklower, K.; Lloyd, B.; McGregor, G.; Carr, D.; Coradetti, T.

The PPP Multilink Protocol (MP)

1996 August 16;

24 p. (Obsoletes RFC 1717)

1973

W. Simpson

PPP in Frame Relay

June 1996

1717

K. Sklower, B. Lloyd,

G. McGregor & D. Carr.

PPP Multilink Protocol

November 1994. (Obsoleted by RFC1990)

1663

Rand, D

PPP Reliable Transmission

1994 July; 8 p.

1662

Simpson, W.,editor

PPP in HDLC-like Framing

1994 July; 25 p. (Obsoletes RFC 1549)

1661

Simpson, W.,editor

The Point-to-Point Protocol (PPP)

1994 July; 52 p. (Obsoletes RFC 1171, 1172, 1548 and 1331)

1638

Baker, F.; Bowen, R.,eds

PPP Bridging Control Protocol (BCP)

1994 June; 28 p. (Obsoletes RFC1220)

1619

Simpson, W

PPP over SONET/SDH

1994 May; 4 p.

1618

Simpson, W

PPP over ISDN

1994 May; 6 p.

1598

Simpson, W

PPP in X.25

1994 March; 7 p.

1570

Simpson, W., editor

PPP LCP Extensions

1994 January; 18 p. (Updates RFC 1548)

1553

Mathur, S.; Lewis, M.

Compressing IPX Headers Over WAN Media (CIPX)

1993 December; 23 p.

1552

Simpson, W.

The PPP Internetwork Packet Exchange Control Protocol (IPXCP)

1993 December; 14 p.

1551

Allen, M.

Novell IPX Over Various WAN Media (IPXWAN)

1993 December; 22 p. (Format: TXT=54210 bytes)

1549

Simpson, W.,ed.

PPP in HDLC Framing

1993 December; 18 p. (Obsoleted by RFC 1662)

1548

Simpson, W.

The Point-to-Point Protocol (PPP)

1993 December; 53 p. (Obsoletes RFC 1331; Obsoleted by RFC 1661; Updated by RFC 1570)

1547

Perkins, D.

Requirements for an Internet Standard Point-to-Point Protocol

1993 December; 21 p.

1483

Juha Heimanen

Multiprotocol Encapsulation over ATM Adaptation Layer 5

July 1993

(Obsoleted by 2684)

1474

F. Kastenholz,

Managed Objects for the BCP of the PPP

June 1993

1473

F. Kastenholz

Managed Objects for the IPCP of the PPP

June 1993

1472

F. Kastenholz

Managed Objects for the Security Protocols of the PPP

June 1993

1471

F. Kastenholz

Managed Objects for the LCP of the PPP

June 1993

1378

Parker, B.

PP AppleTalk Control Protocol (ATCP)

1992 November;

16 p. (Format: TXT=28496 bytes)

1377

Katz, D.

PPP OSI Network Layer Control Protocol (OSINLCP)

1992 November; 10 p.

1376

Senum, S.J.

PPP DECnet Phase IV Control Protocol (DNCP)

1992 November; 6 p.

1362

Allen, M.

Novell IPX Over Various WAN Media (IPXWAN)

1992 September; 18 p.

1334

Lloyd, B.;

Simpson, W.A.

PPP authentication protocols (PAP and CHAP)

1992 October; 16 p.

1333

Simpson, W.A.

PPP link quality monitoring

1992 May; 15 p.

1332

McGregor, G.

PPP Internet Protocol Control Protocol (IPCP)

1992 May; 12 p. (Obsoletes RFC1172)

1331

Simpson, W.A.

Point-to-Point Protocol (PPP) for the transmission of multi-protocol datagrams over point-to-point links

1992 May; 66 p. (Obsoletes RFC1171, RFC1172; obsoleted by RFC 1548)

1220

Baker, F.,ed.

Point-to-Point Protocol extensions for bridging

1991 April; 18 p. (Obsoleted by RFC1638)

1172

Perkins, D.; Hobby, R.

Point-to-Point Protocol (PPP) initial configuration options

1990 July; 38 p. (Obsoleted by RFC1331, RFC1332)

1171

Perkins, D.

Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links

1990 July; 48 p. (Obsoletes RFC1134; Obsoleted by RFC1331)

1134

Perkins, D.

Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links

1989 November; 38 p. (Obsoleted by RFC1171)

1144

Jacobson, V.

Compressing TCP/IP headers for low-speed serial links

1990 February; 43 p.

9. PPPの仕様

RFC 1661 (PPP: The Point-to-Point Protocol)

RFC 1661は、前述のようにフレーミングや誤り検出などは規定していない。これはRFC 1662などのドキュメントによるものとしている。RFC 1661で重要なのはマルチプロトコルの上位層からの伝送単位（これをデータグラムという）のカプセル化とリンクの制御であろう。この章はRFC 1661の翻訳と一部判りにくいところは多少手をいれたものである（つまり対訳ではない）。RFC 1661の日本語訳されたものは入手可能であり、わざわざ翻訳するまでもないのだが、自分の理解を高める為に、また他の翻訳で判らないところはこれを参考してもらえばとも思って翻訳したものである。ただし最終的には原文で確認して頂きたい。

ここであらかじめ幾つかの用語の定義を紹介する。

· データグラム(datagram)：　ネットワーク層（例えばIP層）の伝送単位。データグラムはデータリンク層に渡されるときは一つ以上のパケットにカプセル化されることもある。

· フレーム(frame)：　データリンク層における伝送単位。フレームにはある種のデータを含むヘッダ、及び／あるいはトレーラが付加される。

· パケット(packet)：　カプセル化の基本単位で、ネットワーク層とデータリンク層のインターフェイスで受け渡される。一つのパケットは通常一つのフレームにマッピングされる。例外としては、データリンク層でフラグメンテーション（分割）なされる場合や、複数のパケットが一つのフレームにまとめられる場合などがある。

· ピア(peer)：　ポイント対ポイントのリンクの他方の端点をいう。

· 無通知放棄(silently discard)：　更なる処理なしで該パケットを放棄することをいう。この場合、廃棄されたパケット内容を含めてログを採らなければならないし[SHOULD]、統計カウンタにこのイベントを記録しなければならない[SHOULD]。

また、訳文には[MUST]、[MUST NOT]、[SHOULD]、[MAY]が入っているところは、RFCで標準的につかわれている定義(RFC 2116)による。実装時のチェック・ポイントとなる。

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

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

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

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

1.1　概要(Abstract)

PPPは、以下の3要素からなる。

1. マルチプロトコルのデータグラムのカプセル化

2. データリンク接続の確立、設定、検査といったリンク制御(LCP: Link Control Protocol)

3. 複種ネットワーク層プロトコルの接続の確立や設定といったネットワーク制御(NCPs: Network Control Protocols　例えばIPではIPCP)

カプセル化は、同じリンク上で、異なったネットワーク層プロトコルを多重化して伝送出来るようにするものである。このカプセル化を決めるにあたっては、一番一般的に使われているハードウエアとの両立性が配慮された。デフォルトであるHDLC類似のフレーミング(RFC 1662)を使った場合には、カプセル化の為に必要な情報はたったの8オクテットである。帯域が貴重であるような環境では、カプセル化とフレーミングに必要なオクテット数を2または4に圧縮することも可能である。高速のリンクに使われる場合は、このデフォルトのカプセル化では、単純化されたフィールドだけが使われ、そのフィールドの一つだけで多重を戻すことができる。このデフォルトのヘッダと情報のフィールドは32ビットのバウンダリを持ち、トレイラはこのバウンダリになるようパッディングされる。

リンク制御プロトコル(LCP)は、多様な環境に充分対応できるようするものである。LCPは、カプセル化のためのフォーマットのオプションの自動的な選択、パケット・サイズの上限の変動への対応、折り返しリンクの検出やその他の一般的な設定誤りの検出、リンクの開放などを行う。その他のオプショナルな機能としては、該リンクのピアの識別の認証、リンクが正常に機能しているあるいはそうでない時間の監視などがある。

ネットワーク制御プロトコル(NCP)は、ポイント対ポイントのリンクが、現在のネットワーク・プロトコルのファミリで生じる多くの問題を悪化させないようにするものである。問題の例として例えば、LANの環境でも問題であるIPアドレスの割当と管理の問題は、回線交換型のポイント対ポイント・リンク（例えばダイヤルアップ・モデム・サーバ）上では特に困難である。かかる問題は複数のNCPで処理され、各NCPは対応するネットワーク層プロトコルの固有のニーズを処理する。したがってこれらのNCPsは個別のドキュメントで定義される。

この仕様は、PPPリンクが容易に設定できることを意図している。設計によっては、標準として用意されているデフォルトで総ての通常の設定がまかなえる。設計者は、このデフォルトの設定を改良のため手を加えることが出来、その変更点はオペレータの介在なしで自動的に相手側に送られる。それ以外には出来ないような環境にあっては、最後の手段としてオペレータが該リンクを機能させるために明示的に設定することも可能である。自動的な設定は、詳細なオプションのネゴシエーションの機構により達成されている。このネゴシエーションの段階でリンクの各端は、自分の持っている機能や要求事項を相手に通知する。このドキュメントに記されているオプション・ネゴシエーションのメカニズムはLCPとして規定されているが、同じ機能は他の制御プロトコル、特にNCPのファミリにも採用されている。

次ページに典型的なPPPのシーケンスを示す。個々の詳細はのちほど記述されているので、PPPの機能・役割をざっと理解していただければ良い。最初にLCPでリンクの接続を行い、必要ならログオンなどの認証を行う。リンクが張られたら次に上位層であるNCP（この図はIPベースなのでIPCP）での接続を行い、しかる後ネットワーク層プロトコルでのデータ交換がなされる。終了にあたってはネットワーク層での終了手続きを必ずしも経由することなく、LCPで終了手続きがなされている。

PPPシーケンスの事例

　端末側

　　ルータ側

この条件で回線を利用したいが良いか？(Send LCP Configure Request ID=XX)

この条件で回線を利用したいが良いか？(Receive LCP Configure Request ID=YY)

その条件で良い　(Send LCP Configure Ack ID=YY)

その条件で良い　(Receive LCP Configure Ack ID=XX)

RAPやCHAPによる認証手順

この条件でIP通信したいが良いか？(Send IPCP Configure Request ID=AA)

この条件でIP通信したいが良いか？(Receive IPCP Configure Request ID=BB)

その条件で良い　(Send IPCP Configure Ack ID=BB)

一部条件を変更して欲しい　(Receive IPCP Configure Nak ID=AA)

この条件でIP通信したいが良いか？(Send IPCP Configure Request ID=AB)

その条件で良い　(Receive IPCP Configure Ack ID=AB)

IPデータグラム通信

通信を終了したい　(Send/Receive LCP Terminate Request)

了承　(Send/Receive LCP Terminate Ack)

終了（回線切断）

注：点線で囲った部分は条件によっては存在しない。

1.2　PPPカプセル化(PPP Encapsulation)

CLOSED

LISTEN

ESTAB

SYN SENT

SYN RCVD

TCB

削除

TCB

削除

TCB

生成と

SYN

送信

能動的

OPEN

CLOSE

CLOSE

TCB

生成

受動的

OPEN

ACK

送信

SYN

受信

SYN,ACK

送信

SYN

送信

SYN

受信

SEND

ACK

送信

SYN,ACK

受信

SYN

の

ACK

受信

FIN WAIT

-

1

CLOSE WAIT

FIN

送信

FIN

送信

ACK

送信

CLOSE

CLOSE

FIN

受信

CLOSING

LAST

-

ACK

FIN WAIT

-

2

TIME WAIT

CLOSED

FIN

の

ACK

受信

FIN

受信

CLOSE

FIN

送信

ACK

送信

TCB

削除

FIN

受信

FIN

の

ACK

受信

Timeout=2MSL

FIN

の

ACK

受信

ACK

送信

CLOSED

LISTEN

ESTAB

SYN SENT

SYN RCVD

TCB

削除

TCB

削除

TCB

生成と

SYN

送信

能動的

OPEN

CLOSE

CLOSE

TCB

生成

受動的

OPEN

ACK

送信

SYN

受信

SYN,ACK

送信

SYN

送信

SYN

受信

SEND

ACK

送信

SYN,ACK

受信

SYN

の

ACK

受信

FIN WAIT

-

1

CLOSE WAIT

FIN

送信

FIN

送信

ACK

送信

CLOSE

CLOSE

FIN

受信

CLOSING

LAST

-

ACK

FIN WAIT

-

2

TIME WAIT

CLOSED

FIN

の

ACK

受信

FIN

受信

CLOSE

FIN

送信

ACK

送信

TCB

削除

FIN

受信

FIN

の

ACK

受信

Timeout=2MSL

FIN

の

ACK

受信

ACK

送信

PPPのカプセル化は、プロトコルの混ざったデータグラムを区別するのに使われる。カプセル化においては、カプセルの始まりと終わりを示すフレーミングが必要である。フレーミングのための方法は対応するドキュメントに規定されている。フレーミングの一例（HDLCタイプ）を下図に示す。

カプセル化は上図のプロトコルとデータの部分にて行われる。データ部分は、情報部分とパッディング部分とからなる。したがってここでは、プロトコルのフィールドと情報のフィールドに関してまず説明する。

プロトコル

Protocol

8/16 bits

情報

Information

＊

パッディング

Padding

＊

プロトコル・フィールドは、1ないし2オクテット長である。この値はパケットの情報フィールドにカプセル化されたデータグラムを識別する。総てのプロトコル値は奇数[MUST]、即ち最後のオクテットのLSBが”1”でなければならない[MUST]。また、２オクテット長の場合は、最初のオクテットのLSBは”0”でなければならない[MUST]。この規則に従わないフレームを受信したときは、認識できないプロトコル(unrecognized Protocol)として処理しなければならない[MUST]。”0***”から”3***”までの値はネットワーク層のプロトコルの識別であり、”8***”から”b***”までの値は、もしあれば、それに関連するネットワーク制御プロトコル(NCPs)である。”c***”から”f***”の範囲はリンク制御プロトコル(LCPs)である。

以下に現在の割り当て状況を示す。これらの値は、RFC 1340 “Assigned Numbers”に記されているので、その都度確認することが好ましい。

Value (in hex)

Protocol Name

0001

Padding Protocol

0003 to 001f

Reserved (transparency inefficient)

0021

Internet Protocol

0023

OSI Network Layer

0025

Xerox NS IDP

0027

DECnet Phase IV

0029

002b

Novell IPX

002d

Van Jacobson Compressed TCP/IP

002f

Van Jacobson Uncompressed TCP/IP

0031

Bridging PDU

0033

Stream Protocol (ST-II)

0035

Banyan Vines

0037

Reserved (until 1993)

007d

Reserved (Control Escape)

00cf

Reserved (PPP NLPID)

00ff

Reserved (compression inefficient)

0201

802.1d Hello Packets

0231

Luxcom

0233

Sigma Network Systems

8021

Internet Protocol Control Protocol

8023

OSI Network Layer Control Protocol

8025

Xerox NS IDP Control Protocol

8027

DECnet Phase IV Control Protocol

8029

Appletalk Control Protocol

802b

Novell IPX Control Protocol

802d

Reserved

802f

Reserved

8031

Bridging NCP

8033

Stream Protocol Control Protocol

8035

Banyan Vines Control Protocol

8037

Reserved till 1993

80ff

Reserved (compression inefficient)

c021

Link Control Protocol

c023

Password Authentication Protocol

c025

Link Quality Report

c223

Challenge Handshake Authentication Protocol

情報フィールドは、ゼロまたはそれ以上のオクテット長である。情報のフィールドはプロトコル・フィールドで規定されたプロトコルのデータグラムが入る。この情報フィールドの最大長は、（パッディングを含め、プロトコル・フィールドを含めない）最大受信ユニット(MRU: Maximum Receive Unit)と呼び、デフォルト値は1,500オクテットである。ネゴシエーションにより、同意がなされれば、MRUとしてこの値以外の値を採用してもかまわない。

伝送に際しては、この情報フィールドにはMRU内であれば任意のオクテット数のパッディングを含めても構わない[MAY]。パッディングオクテットと真の情報との識別を行うのは、各プロトコルの責任である。

1.3　PPPリンク動作(PPP Link Operation)

1.3.1 概要(Overview)

ポイント対ポイント・リンクの確立のため、該PPPリンクの各端は、最初にLCPパケットを交信してデータ・リンクの設定とテストを行わなければならない[MUST]。リンクが確立されたもち、該ピアは必要なら認証を得る[MAY]。

次にPPPはNCPパケットを交信して一つまたはそれ以上のネットワーク層プロトコルの選択と設定を行わなければならない[MUST]。選択されたネットワーク層プロトコルげ設定されれば、各ネットワーク層プロトコルからのデータグラムが該リンクを介して送信される。

明示的なLCPまたはNCPパケットがリンクを閉じるか、何らかの外部的イベントが発生（タイムアウト発生やネットワーク管理者の介入）するまでは、このリンクの設定は維持される。

1.3.2 リンクの状態遷移図(Phase Diagram)

ポイント対ポイントのリンクの設定、継続、終端の過程で、PPPは幾つかのフェーズを通過する。これを単純化したものが下図である。したがって総ての状態遷移を記述したものではないことに注意しなければならない。本図の各フェーズはこのあと説明する定義に従わねばならない[MUST]。

クライアント

サーバ

SYN

ACK,SYN

ACK

SEQ=1234(ISN)

SEQ=4567(ISN)

,

ACK=1235

SEQ=1234, ACK=4568

(

CLOSED)

(

ESTAB)

(

SYN SENT)

(

LISTEN)

(

SYN RCVD)

(

ESTAB)

クライアント

サーバ

SYN

ACK,SYN

ACK

SEQ=1234(ISN)

SEQ=4567(ISN)

,

ACK=1235

SEQ=1234, ACK=4568

(

CLOSED)

(

ESTAB)

(

SYN SENT)

(

LISTEN)

(

SYN RCVD)

(

ESTAB)

1.3.3　リンク停止（Link Dead: 物理層非レディ）

リンクは必然的にこのフェーズから始まりまたこのフェーズで終わる。外部イベント（キャリア検出やネットワーク管理者の設定など）によりこの物理層がレディであることを通知したときに、PPPはリンク確立のフェーズに移行する。

インプリメンテーションに際しての注意：

通常、モデムを接続を外すとリンクは自動的にこのフェーズに戻る。ハード・ワイヤードのリンクの場合はこのフェーズは極めて短く、単にこのデバイスの存在を検出するだけである。

1.3.4 リンク確立のフェーズ(Link Establishment Phase)

設定(Configure)パケットを交換することで接続を確立するためにLCP（リンク制御プロトコル）が使われる。ひとたび設定応答(Configure-Ack)パケットを双方が送信し且つ受信すれば、この交換手順は完了となり、LCP接続済み(LCP Opened)状態に入る。

設定交換で変更されない限り、総ての設定オプションはデフォルト状態であるとみなされる。詳細は別途1.6章を参照されたい。特定のネットワーク層プロトコルに依存しない（独立した）設定オプションのみがLCPで設定されることに注意することが大事である。個々のネットワーク層の設定は別途ネットワーク層プロトコル・フェーズ(Network-Layer Protocol phase)にてNCP（ネットワーク制御プロトコル）により処理される。

このフェーズで受信された非LCPパケットは無通知放棄されねばならない[MUST]。

ネットワーク層プロトコル・フェーズまたは認証フェーズ(Authentication phase)でLCP設定要求(LCP Configure-Request)が受信されると、リンク確立フェーズに戻る。

1.3.5　認証フェーズ(Authentication Phase)

リンクによっては、ネットワーク層プロトコルが交換される前にピアを認証することが好ましいこともある。

デフォルトとしては認証は必須ではない。適用システムでそのための認証プロトコルを使ったピアの認証が必要な場合は、リンク確立フェーズで該認証プロトコルの使用を要求しなければならない[MUST]。

リンクが確立次第、認証は可及的速やかに開始されねばならない[SHOULD]。しかしながら、リンク品質の計測(link quality determination)は平行してなされても良い[MAY]。認証を無期限に遅らせてしまうようなリンク品質計測パケットの交換は許すようなシステム設計はしてはならない[MUST NOT]。

認証のプロセスが終了するまではこの認証のフェーズからネットワーク・プロトコルのフェーズへの移行は生じてはならない[MUST NOT]。認証に失敗した場合は、ネットワーク・プロトコルのフェーズではなく、リンク終了フェーズ(Link Termination phase)に進む[SHOULD]。

リンク制御プロトコル、認証プロトコル、及びリンク品質監視パケットのみがこのフェーズでは許される。受信したその他の総てのパケットは非通知廃棄としなければならない[MUST]。

実装にあたっての注意：

インプリメンテーションにあたっては、単にタイムアウトや無応答などに起因して認証失敗扱いとしてはならない[SHOULD NOT]。認証にあたっては何らかの再送の手段とを持たせ、それが所定回数の認証の試みがなされた場合にのみリンク終了フェーズに移行すること[SHOULD]。リンク終了フェーズへの移行の要因とすべきものは、そのピアに対して認証を拒絶したことである。

1.3.6 ネットワーク層プロトコル・フェーズ(Network-Layer Protocol Phase)

PPPがその前のフェーズを終了したら、各ネットワーク層プロトコル（IP、IPX、AppleTalkなど）は、それに対応したネットワーク制御プロトコル(NCP: Network Control Protocol)により各々が設定されねばならない[MUST]。

各NCPは何時でも開き(Opened)また閉じ(Closed)ても良い[MAY]。

実装にあたっての注意：

インプリメンテーションによっては最初にリンク品質計測の為にかなりの時間を要することがあるので、ピアのNCP設定を待つのに固定したタイムアウト値を使うのを避けること[SHOULD]。

NCPが開いた(Opened)状態に達したら、PPPはそれに対応したネットワーク層プロトコル・パケットを伝送する。サポートされているネットワーク層プロトコルであっても、対応するNCPがまだ開かれていない状態で、受信された如何なる該ネットワーク層プロトコル・パケットも無通知廃棄としなければならない[MUST]。

実装にあたっての注意：

LCPが開かれた（Openedの）状態で該インプリメンテーションがサポートしていないプロトコル・パケットは、プロトコル拒絶(Protocol-Reject)で戻さねばならない（あとで廃棄される）[MUST]。サポートされているプロトコルのみが非通知廃棄される。

このフェーズの期間は、リンクのトラフィックはLCP、NCP、そしてネットワーク層プロトコル・パケットの任意の組み合わせからなる。

1.3.7　リンク終了フェーズ(Link Termination Phase)

PPPは何時でも終了可能である。このことはキャリア信号の断、認証の失敗、リンク品質の失敗、アイドル期間のタイムアウト、あるいは管理者によるリンクの切断などに起因して生ずる。

終了(Termination)パケットの交換により該リンクを終了する為にLCPが使用される。リンクが終了中は、PPPはネットワーク層プロトコルにこれを通知し、しかるべき処置がとれるようにする。

終了パケットの交換が終了すると、インプリメンテーションは物理層に対してリンクの終了をおこすよう切断を指示しなければならない[SHOULD]。とくに認証失敗の場合はそうである。終了要求(Terminate-Request)送信元は終了応答(Terminate-Ack)受信後、あるいは再送カウンタのカウントアウト後はただちに切断を行わねばならない[SHOULD]。終了要求の受信側は、相手が切断するのを待たねばならない[SHOULD]。また終了応答を送信してから少なくとも1回は再送タイマがカウントしない限り切断を行っては行けない[MUST NOT]。PPPはデータ・リンク停止(Link Dear)のフェーズに移行しなければならない[SHOULD]。

このフェーズに受信したLCP以外のパケットは非通知廃棄されねばならない[MUST]。

実装にあたっての注意：

LCPによるリンクの終了で充分である。NCPがばたばた終了パケットを送る必要はない。逆に、NCPが終了させたということは、たとえ該NCPが現在開いた状態の唯ひとつのNCPであったとしても、PPPリンクの終了の充分条件にならない。

1.4　オプション・ネゴシエーション・オートマトン(The Option Negotiation Automaton)

有限状態システムはイベント、アクション、及び状態遷移で定義される。イベントには、開く、閉じるといった外部コマンドの受信や、再スタート・タイマのタイムアウト、及びピアからのパケットの受信などがある。アクションには、再スタート・タイマの開始やピアへのパケットの送信などがある。このオートマトンは、汎用性（リンク層にもネットワーク層にも使える）を考えレイヤに依存しない記述がなされているので、戸惑うかもしれないが、当面はThis-Layerをリンク層に、Lower-Layerを物理層におきかえて考えれば良い。

あるタイプのパケット、即ち設定否定応答(Configure-Naks)、またはコード拒絶(Code-Rejects)やプロトコル拒絶(Protocol-Rejects)、あるいはエコー要求(Echo-Requests)、エコー応答(Echo-Replies)、および廃棄要求(Discards-Requests)などはこのオートマトン記述では区別されていない。あとで述べるように、これらのパケットは異なった機能をはたす。しかしながらいつも同じ状態遷移を引き起こす。

イベント

アクション

Up = lower layer is Up

tlu = This-Layer-Up

Down = lower layer is Down

tld = This-Layer-Down

Open = administrative Open

tls = This-Layer-Started

Close = administrative Close

tlf = This-Layer-Finished

TO+ = Timeout with counter > 0

irc = Initialize-Restart-Count

TO- = Timeout with counter expired

zrc = Zero-Restart-Count

RCR+ = Receive-Configure-Request (Good)

scr = Send-Configure-Request

RCR- = Receive-Configure-Request (Bad)

RCA = Receive-Configure-Ack

sca = Send-Configure-Ack

RCN = Receive-Configure-Nak/Rej

scn = Send-Configure-Nak/Rej

RTR = Receive-Terminate-Request

str = Send-Terminate-Request

RTA = Receive-Terminate-Ack

sta = Send-Terminate-Ack

RUC = Receive-Unknown-Code

scj = Send-Code-Reject

RXJ+ = Receive-Code-Reject (permitted)

or Receive-Protocol-Reject

RXJ- = Receive-Code-Reject (catastrophic)

or Receive-Protocol-Reject

RXR = Receive-Echo-Request

or Receive-Echo-Reply

or Receive-Discard-Request

ser = Send-Echo-Reply

1.4.1 状態遷移表(State Transition Table)

リンクの初期状態から確立にわたる完全な状態遷移表を以下に示す。状態を横軸に、イベントを縦軸に示す。状態遷移とアクションはアクション／新状態の形式で記述してある。複数のアクションを引き起こす場合は、コンマで区切り、必要なら次の行に亘って書いてある。複数のアクションが生じるときは都合の良いものから先にインプリメンとすればよい。状態に文字が付加されている場合は注記があることを示す。ダッシュ(“-“)はイリーガル（無効）な遷移であることを示す。

イベント

0

Initial

1

Starting

2

Closed

3

Stopped

4

Closing

5

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

イベント

6

Req-Sent

7

Ack-Rcvd

8

Ack-Sent

9

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+

src/6

src/6

src/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

注：

[p] 受動的オプション(Passive option); Stopped状態の項参照

[q] 再スタートオプション;　Openイベントの項参照

[x]　接続閉(Closed connection); RCAイベントの項参照

再スタート・タイマが走っている状態はTOイベントが存在していることで識別できる。Send-Configure-Request、Send-Terminate-Request、及びZero-Restart-Countアクションだけが再スタート・タイマを再スタートさせる。再スタート・タイマは、タイマが走っている任意の状態からタイマが走行しない状態に遷移したときは再スタート・タイマは停止する。

ここでは、イベントとアクションをシグナリングのアーキテクチャよりは、メッセージ転送のアーキテクチャに基づいて定義してある。もし特定の信号（例えばDTRなど）を制御することが必要になれば、追加のアクション（たとえばDTR送信など）が必要になるかも知れない。

1.4.2 各状態(States)

以下は、各オートマトン状態の詳細な記述である。

Initial（初期）

この状態では、下位層が使えなく(Down)、またOpenイベントが発生していない。この状態では再スタート・タイマは動作していない。この状態から抜けるのは管理者の介在(Open)と下位層が自分が起動したことを通知(Up)したときだけであり、またこの状態に戻るのは管理者操作(Close)かClosedの状態から下位層が自分が停止したことを通知(Down)したときだけである。

Starting（開始）

この状態は上記Initialに相対する開いた(Open)状態である。管理者のオープン操作がなされた状態であるが、下位層は引き続き使える状態ではない(Down)。この状態では再スタート・タイマは動作していない。下位層が使える状態になったら(Up)、設定要求(Configure-Request)が送信される。

Closed（終了）

この状態では、該リンクは使用可能(Up)であるがOpenイベントが発生していない状態である。この状態では再スタート・タイマは動作していない。設定要求(Configure-Request)パケットを受信すると、終了応答(Terminate-Ack)を送信する。相手からの終了応答(Terminate-Acks)はループ回避のために無通知廃棄する。

Stopped（停止）

この状態は、上記Closed状態に相対する開いた(Open)状態である。Closedとの差は設定要求(Configure-Request)が受け付けられることである。この状態は、本レイヤ終了(This-Layer-Finished)動作をしたあと、あるいは終了応答(Terminete-Ack)送信したあとDownイベントを待っている状態である。この状態では再スタート・タイマは動作していない。設定要求(Configure-Request)パケットを受信したらしかるべき処置（Ack/NakまたはConfigure-Request送信）を行う。その他のパケットに対しては、終了応答(Terminate-Ack)を返す。終了応答(Terminate-Acks)が受信されたときはループ回避の為に無通知廃棄する。

検討：　この状態はリンク終了(link termination)、リンク設定失敗(link configuration failure)及びその他のオートマトンの失敗モードへの分岐の状態である。下位層停止(Down)イベントの応答（This-Layer-Finishedアクションから) と設定要求受信(Receive-Configure-Request)イベントとの間で競合状態が発生する。設定要求が回送停止イベントより先に到来したときは、このオートマトンは停止イベントを優先させStartingの状態に戻る。これで繰り返しを防止する。

実装上のオプション：　相手が設定要求に応答するのに失敗した場合は、相手が設定要求を送信するのを受動的に待つという方法でも良い[MAY]。この場合は、Req-Sent、Ack-Rcvd、及びAck-Sent状態でのTO-イベントにはThis-Layer-Finishedアクションは使用しない。このオプションは専用線、あるいはステータス信号が得られない回線の場合に有用であるが、回線交換型回線には使用してはいけない[SHOULD NOT]。

Closing（終了中）

この終了中の状態では、接続の終了の試みがなされる。終了要求(Terminate-Request)が送信されて再スタート・タイマが動作中であるが、終了応答(Terminate-Ack)がまだ受信されていない状態である。終了応答が受信されると、終了(Closed)状態になる。再スタート・タイマがタイムアウトになると、新しく終了要求を送信し、再スタート・タイマが再スタートする。最大終了(Max-Terminate)回数を超えたら、終了状態に移る。

Stopping（停止中）

終了中に対比される状態である。終了要求(Terminate-Request)が送信されて再スタートタイマが動作中であるが、終了応答(Terminate-Ack)がまだ受信されていない状態である。

検討：　このStoppingの状態は新しいトラフィックを受け付ける前にリンクを終了させる機会を持たせるものである。リンクが終了したら、停止または開始中の状態経由で新しい設定をさせても良い。

Request-Sent（要求送信済み）

これは接続の設定の試みがなされている状態である。設定要求(Configure-Request)が送信され、再スタート・タイマが動作中であるが、設定応答(Configure-Ack)がまだ受信されていないか送信していない状態である。

Ack-Received（応答受信）

これは設定要求を送信し、設定応答が受信された状態である。設定応答をまだ送信していないので、再スタート・タイマは走行中である。

Ack-Sent（応答送信済み）

この状態は、設定要求及び設定応答の双方が送信済みだが、設定応答がまだ受信されていない状態である。設定応答がまだ受信されていないので再スタート・タイマは動作中である。

Opened（リンクオープン状態）

この状態では、設定応答の送信と受信双方が終了した状態である。再スタート・タイマは動作していない。この状態に入るときは、実装は上位レイヤにこのレイヤが立ち上がったことを通知しなければならない。逆に、この状態を離れるときは、実装は上位レイヤに終了中であることを通知しなければならない。

1.4.3 イベント(Events)

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

Up（下位層レディ）

下位層がパケットを伝送するのにレディであることを通知したときに生ずる。一般的に、このイベントはモデム処理または呼処理、あるいはその他のPPPリンクと物理層との結合が、LCPに対して該リンクがリンク確立フェーズに入ったことを通知するのに使われる。これはまた、LCPが各NCPに対して該リンクがネットワーク層プロトコル(Network-Layer Protocol)フェーズにはいったことを通知するのにも使われる。即ち、LCPからの本レイヤ・レディ(This-Layer-Up)アクションがNCPのUpイベントを引き起こす。

Down（下位層非レディ）

このイベントは下位層がもはやパケットを伝送するのにレディではないことを通知したときに生ずる。一般的に、このイベントはモデム処理または呼処理、あるいはその他のPPPリンクと物理層との結合が、LCPに対して該リンクがリンク終了フェーズに入ったことを通知するのに使われる。これはまた、LCPが各NCPに対して該リンクがネットワーク層プロトコル(Network-Layer Protocol)フェーズから離れることを通知するのにも使われる。即ち、LCPからの本レイヤ・レディ(This-Layer-Up)アクションがNCPのDownイベントを引き起こす。

Open（管理者のオープン）

このイベントは、管理者によってこのリンクが利用可能になったことを示す。即ち、ネットワーク管理者（人間またはプログラム）が、リンクがオープン可能になったことを示す。このイベントが発生し、且つリンクがまだOpenedでないときは、オートマトンは設定の為のパケットを相手に送信しようとする。このオートマトンが設定作業を開始できないとき（下位層が非レディ状態、あるいは前のCloseイベントが完了していないとき）は、リンクの確立は自動的に延期される。終了要求(Terminate-Request)を受信したときは、あるいはリンクが使用不能となるそれ以外のイベントが発生したときは、オートマトンは再オープン可能の状態に遷移する。更なる管理側の介入は必要としない。

実装上のオプション：　経験に依れば、ユーザはリンクを再びネゴシエートしようとするときは更なるOpenコマンドを実行してしまう。これは新しい値がネゴシエートされることを示す。このことはOpenイベントを意味しないので、Opened、Closing、Stopping、Stoppedの状態からユーザからのOpenコマンドを実行するときは、インプリメンテーションはDownイベントを発生させ、その後すぐUpイベントを発生することが好ましい。Downイベントの介入は、他の要因源からは生じ得ないことに注意が必要である。UpがついたDownイベントは、リンクの順序正しい、つまりStartingからRequest-Sent状態に遷移する再ネゴシエーションを起こす。これによりリンクの再ネゴシエーションが、有害な副次効果をきたすことなく実施される。

Close（管理者の終了）

このイベントはリンクがトラフィックの為に使用可能でない、即ち、ネットワーク管理者（人間またはプログラム）が、リンクがオープン利用不可になったことを通知したことを意味する。該リンクがClosed状態でないときにこのイベントが発生したときは、オートマトンは接続を終了しようと試みる。該リンクの再設定のための試みは、新しいOpenイベントが発生するまでは拒絶される。

実装上のオプション：　認証に失敗したときは、繰り返しや他のユーザへのサービス拒絶を防止するために、リンクは終了しなければならない。リンクは管理者が（定義により）利用可能なため、LCPにCloseイベントを送り、ただちにOpenイベントを送ってやることで達成できる。Closeイベントの介入は、他の要因源からは生じ得ないことに注意が必要である。OpenがついたCloseイベントは、リンクの順序正しい、つまりClosingからStopping状態に遷移する終了を起こし、This-Layer-Finishedアクションがリンクを切断できる。オートマトンはStoppedまたはStarting状態で次なる接続が開始されるのを待つ。

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

このイベントは再スタート・タイマのタイムアウトを意味する。再スタートタイマは、設定要求(Configure-Request)及び終了要求（Terminate-Request）パケットの応答時間をみるのに使われる。TO+イベントは再スタート・カウンタがゼロ以上の状態でカウントしており、対応する設定要求または終了要求を再送する契機となる。TO-イベントは再スタートカウンタがゼロまたはマイナスであることを示し、もはやパケット再送の必要がないことを示す。

Receive-Configure-Request(RCR+,RCR-)（設定要求受信）

このイベントは、ピアからの設定要求パケットが受信されたとき生ずる。設定要求パケットは接続のオープンの意思を示し、それに設定オプションを指定しても良い。設定要求パケットは別途詳細に記述する。RCR+イベントは該設定要求が受理可能なもので,対応する設定応答(Configure-Ack)の送信をひきおこす。RCR-はこの設定要求は受理できないもので、対応する設定否定応答(Configure-Nak)あるいは設定拒絶(Configure-Reject)の送信を引き起こす。

実装上の注意：　これらのイベントはすでにオープンの状態の接続においても生じ得る。インプリメンテーションはただちに設定オプションのネゴシエーションが開始できるようにしておかねばならない[MUST]。

Receive-Configure-Ack(RCA)（設定応答受信）

このイベントは有効なConfigure-Ackパケットが受信されたときに発生する。このConfigure-Ackパケットは設定要求に対するポジティブ（肯定）な応答である。シーケンス外あるいは無効なパケットは無通知廃棄される。

実装用の注意：　Ack-RcvdあるいはOpenedの状態に至る前にすでに正しくパケットが受信されているので、他のそのようなパケットが到達することは殆どあり得ない。規定されているようにAck/Nak/Rejの総ての無効なパケットは無通知廃棄とし、オートマトンの遷移には影響しない。しかしながら、同時発生クロス接続で、正しくフォーマットされたパケットが到達することはあり得ないことではない。実装のミスの結果として生じる可能性のほうが高い。少なくともこの発生はログに記録されるべきである[SHOULD]。

Receive-Configure-Nak/Rej(RCN)（否定または拒絶応答受信）

このイベントはピアからの有効なConfigure-NakまたはConfigure-Rejが受信されたときに発生する。Configure-NakまたはConfigure-Rejは設定要求に対するネガティブな応答である。シーケンス外あるいは無効なパケットは無通知廃棄される。

実装用の注意：　Configure-NakまたはConfigure-Rejはオートマトン上では同じ状態遷移を引き起こすものの、これらのパケットは結果としての設定要求パケットの設定オプションへは全く異なった効果をもたらす。

Receive-Terminate-Request(RTR)（終了要求受信）

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

実装上の注意：　このイベントはCloseイベント (上記参照) と同じではなく、自側ネットワーク管理者のオープン・コマンドに優先しない。実装はネットワーク管理者が介在することなく、新規設定要求の受信にそなえていなければならない[MUST]。

Receive-Terminate-Ack(RTA)（終了応答受信）

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

Receive-Unknoun-Code (RUC) （未知コード受信）

このイベントは、ピアから解釈できないパケットを受信したとき発生する。コード拒絶(Code-Reject)パケットが応答で送信される。

Receive-Code-Reject,　Receive-Protocol-Reject(RXJ+,RXJ-)（コード拒絶受信、プロトコル拒絶受信 ）

このイベントは、ピアからのコード拒絶かプロトコル拒絶パケットを受信したとき発生する。 RXJ+ イベントは、例えば拡張コードのコード拒絶や NCP のプロトコル拒絶のように、拒絶された値が受理可能である場合に発生する。これらは通常処理の範囲内である。実装では、拒絶されたパケット・タイプの送信を停止しなければならない[MUST]。RXJ- イベントは、例えば設定要求のコード拒絶や LCP のプロトコル拒絶の如く、拒絶された値が致命的である場合に発生する。このイベントはコネクションを終了すべき回復不能なエラーを通知する。

Receive-Echo-Request,　Receive-Echo-Reply,　Receive-Discard-Request(RXR)（エコー要求受信、エコー応答受信、破棄要求受信 ）

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

1.4.4 アクション(Actions)

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

Illegal-Event(-)（不正イベント）

これは、正しく実装されたオートマトンでは発生し得ないイベントを示す。実装では通知やログ採取すべき内部エラーがあることになる。何の遷移も行われず、実装はリセットやフリーズしてはなら