PPP WAN接続の定番を理解する
第一部 役割
レイヤー３を正確に運ぶ用途も回線も選ばない
NTT東西のフレッツ・ADSLと契約すると，「フレッツ接続ツール」と呼ぶパソコン向けのソフトが配られる。これがないと，フレッツ・ADSLでインターネットに接続できない。なぜなら，インターネット接続事業者（プロバイダ）のユーザー認証を受けることや，プロバイダからIPアドレスを通知してもらうことができないからだ。
このフレッツ接続ツール，その実体はPPPoE（PPP over Ethernet）というプロトコルのクライアント・ソフトである。ユーザー認証もIPアドレス取得も，このPPPoEが実行する。
PPPoEはADSLとセットで使われることが多いものの，ADSL専用のプロトコルではない。実際，2001年8月から始まったNTT東西のFTTH（fiber to the home）サービス「Bフレッツ」もプロバイダ接続の方法としてPPPoEを採用する。今後のブロードバンド・インターネットの標準プロトコルと目されており，パソコンOSやブロードバンド・ルータこもPPPoEの採用を始めている。まさに旬のプロトコルといえる。
紹介したように，PPPoEクライアントの代表的な機能はユーザー認証とIPアドレスの取得である。具体的には，プロバイダが用意するアクセス・サーバーとデータをやりとりし，自分がそのプロバイダの正規ユーザーであることを承認してもらったり，プロバイダからIPアドレスを割り当ててもらったりする。
ただし，これらの機能は，PPPoEならではの機能ではない。パソコンOSやISDNルーターもダイヤルアップ接続するために標準的に備えている。こちらはPPP（point-to-point protocol）と呼ぶプロトコルが実行する。
では，PPPoEとPPPはどのような関係にあるのだろうか。実はPPPoEは，LAN環境でPPPを使うためのルールを規定しただけのプロトコルである。ユーザー認証などの規定はない。つまりPPPoEクライアントとは，LAN環境でPPPを実行するためのソフトなのである。本来の役割は正確なデータ伝送ISDNからFTTHまで，プロバイダ接続における必須プロトコルとして広まりつつあるPPPだが，PPP本来の役割はユーザー認証やIPアドレスの取得機能ではない。
PPP本来の役割は，電話回線やISDNといったWAN回線で直接結ばれた機器の間で，伝え合いたいデータを正確に，かつ効率よく届けることである。このような隣り合う機器だけでやりとりされるプロトコルは，データリンク層プロトコルあるいはレイヤー2プロトコルと呼ばれる。
データリンク層プロトコルは，自分が運ぶデータをいくつかの塊に分け，その塊を単位に送信する。塊はフレームと呼ばれる。フレームを送り始めるときは，「これからデータを送るよ」という意味の同期信号を何回か送信する。受信側にデータが届くことを前もって伝えるためである。PPPでは，「01111110」というビット列が同期信号として使われる。
データリンク層プロトコルは，すべての通信の場面で必ず使われる。なぜなら，これがないとエンドエンドでの通信ができないからだ。例えばIPパケットを相手のサーバーヘ送ることがきなくなる。
身近なデータリンク層プロトコルとしては，PPPのほかにLANで使われるMAC（media access control。LANにおけるデータリンク層プロトコル。イーサーネットの場合，MACフレームはイーサーネット・フレームである。）がある。では，LANとWANを経由してデータが運ばれるときMACとPPPはどのような関係になるのだろうか。LAN上のパソコンがISDN経由でオフィスのサーバーにアクセスする例で考えてみよう（図１−１）。
図１−１ PPPの基本的な役割
パソコンが作ったIPパケットはMACフレームの中に納められてからルーターに送られる。MACフレームを受け取ったルーターは，MACフレームの中からIPパケットを取り出し，今度はPPPフレームの中に入れてオフィスのルーターヘ送り出す。オフィスのルーターは再びIPパケットをMACフレームに載せ替えてサーバーヘ送る。
このように回線が変わるたびにデータリンク層プロトコルは変わる。しかし，そこで運ばれるIPパケットは基本的にそのままだ。IPがエンドエンドでデータを運ぶことを目的としているのに対し，PPP（データリンク層プロトコル）は回線で結ばれた隣り合う機器間だけで完結する。いくつものデータリンク層プロトコルが連係することで，IPパケットは最終日的地に届けられているのである。
PPPはもともと，モデムやISDN，専用線のような通信回線での利用を前提に設計された。しかし，今では新しく開発されたWAN環境でも使えるようになっている。それは，新しいWAN技術が生まれるたびに，そこでPPPを使うためのルールも整備されたからである。
たとえば，通信事業者は自らの高速基幹網を光ファイバで作っているが，そこではSONET（synchronous optical network。国際的に採用された光伝送方式）と呼ばれる独特の高速伝送技術を使っている。ここでPPPを動かすために，POS（PPP over SONET/SDH。PPPをSONETやSDHで使うため仕様。SDHはSONETに似た光伝送方式である。）と呼ばれるプロトコルが開発された。
また，PHSでデータ通信するときもPPPを使う。PHS向けのデータ伝送プロトコル「PIAFS（PPP internet access forum standard。）」を開発するときに，PPPを使うように設計したからである（図１−２）。
図１−２ PPPはいろんなこと使われている
図１−２を見るとわかるように，実際のネットワークでもPPPはいろいろな回線で使われており，それぞれの回線で結び付けられた機器の間ごとにPPPが動いている。
また，最近では，隣接する機器だけでなく，IP網を経由した先の機器との間でPPPでやりとりできるようになっている。PPPoEのほか，PPTPもそうした技術である。
PPPがこれほど拡張性に富んでいる穣密は，PPPの基本設計にある。PPPは，いくつかの機能単位に動作を独立させ，それを多数組み合わせて全体を構成するモジュール構造になっている。
PPPのモジュール群をぎっと見てみよう（図１−３）。
図１−３ PPPは二つの機能を中心とした集合体
いくつもの機能が階層別に用意されている様子がわかるだろう。構成要素は大きくこつある。一つは，基本となる通信機能を担当する部分。LCP（1ink control protocol）と呼ぶ。たとえばユーザー認証はこのLCPのオプション機能の一つである。
もう一つは，LCPの上位で動く機能モジュール。一般にNCP（network control protocol）と呼ばれる。NCPは，レイヤー3プロトコルごとに決められており，それぞれ仕様が決まっている。NCPの代表例としては，IP用のIPCP（internet protocol contorol protocol）がある。
このようにPPPは，LCPを中核に，専門機能ごとに用意された多くのモジュール群を連係させることで，全体としてさまぎまな機能を提供する構造になっている。PPPは，単一プロトコルではなく，多数のプロトコルの集合体なのである。（PPPのプロトコル階層構造（主なプロトコル））
現在のPPPは多彩なモジュールで構成されているが，もちろん最初からそうだったわけではない。
ただし LCPとNCPで機能を分担するという基本構造ははじめからあった。当初から拡張性を考慮した設計になっていたわけだ。10年以上に及ぶPPPの歴史は，仕様追加の歴史と言える。簡単に発展経緯を振り返ってみよう。
開発が始まった80年代末から92年初頭までは，PPPの基本機能を整備した時期である。ここでは，本来の目的であるWAN回線で結びつけられた2地点間でデータ誤りのない通信を実行することに主限が置かれた。運べるレイヤー3プロトコルはIPだけだった。
92年後半から94年にかけて，PPPは拡張期に入る。IP以外のレイヤー3プロトコルを利用するための仕様と，LCPのセキュリティ機能が整備された。こうして94年7月にPPPの基本仕様は一通り完成した。
98年以降になると，PPPが持つユーザー認証やIPアドレス取得の機能を，隣り合う機器間以外でも使えるようにするための技術提案が始まる。その代表例がPPPoEである。PPPに求められる役割も変わりつつあるようだ。
PPPのおおまかな特徴，構造，そして歴史を見てきた。ここまでで，PPPの全体像はある程度つかめたと思う。PPPoEとPPPの基本的な関係もわかったことだろう。
ただ，まだPPPがWAN環境で多用されている理由が今ひとつはっきりしないかもしれない。どこでも使え，何でも運べるという利点はわかるが，もっと決定的な「好かれる理由」があるはずだ。
結論から先に言おう。PPPが好かれる理由は，データを誤りなく届けるという本来の役割に加え，データ通信を円滑に進める効果のある4つの基本機能が，ユーザーの使いやすい形で備わっていることにある（図１−４）。
図１−４ PPP４大機能
4つの機能とは交渉，認証，通知，監視のこと。しかもこの4つの機能は，パラメータを追加することで実現機能を増やすことができる。
実際，長年に渡るPPPの拡張作業により，PPPはデータリンク層プロトコルに求められるほとんどの機能を実現できるようになっている。この汎用性と柔軟性，そして使い勝手の良さが，プロバイダや企業ユーザーに好まれているのである。
PPPの4つの基本機能のうち，もっとも重要かつ効果的な機能は交渉機能である。
見てきたように，PPPには多彩なオプション機能が用意されている。しかし実際のルーター製品やPPPクライアント・ソフトがそれらすべての機能をサポートしているわけではない。はっきりいえば，PPPのオプション機能すべてをサポートしている製品は存在しないといっていい。というのは，製品にPPPを組み込む際，一般にはその製品が使われる場面や用途を想定し，不要なオプションは実装しないようにしているからだ。
通常，相手の通信機能がはっきりしないと効率的な通信は難しい。だが，PPPは優れた交渉能力を持っている。この交渉能力があるため，すぐさまお互いの最善の通信条件を見つけ，その条件で通信を始められる。
細かな交渉方法は第二部で説明するが，PPPは通信を始める前にお互いが持っている機能を照らし合わせ，双方が備えている機能の範囲でベストの条件を見つけるようにする。
逆に言えば，それだけ効率的な交渉手段を備えているから，ちょっとしたオプション機能も気軽に追加できるともいえる。
残りの3つの基本機能についても，その概要を簡単に紹介しておこう。
認証はLCPのオプション機能の一つ。冒頭で紹介したように，ユーザーIDとパスワードを相手に届けるなどして，アクセス先に自分が正規ユーザーであることを承認してもらう機能である。プロバイダにダイヤルアップ接続するケースだけでなく，企業ネットワークにリモート・アクセスする場面で額繁に使われている。ユーザーの目に見える数少ないPPP機能である。
通知はIPCPのオプション機能である。プロバイダにダイヤルアップ接続したとき，自分のIPアドレスだけでなく，デフォルト・ゲートウェイやDNSサーバーのIPアドレスを入力しなくてもすぐにインターネット接続できることを不思議に思ったことはないだろうか。これらのインターネット接続に必要なアドレス情報をユーザーが手入力しなくてすむのは，このアドレス通知機能を使って，パソコンのTCP/IPソフトが自動的にアドレス設定しているからだ。
最後の監視はLCPが備えている機能。制御データを相互にやりとりすることで，PPPデ一夕が正しくやりとりできているかを監視する。
PPPの4大機能を見てきた。どれも，普段はあまり表に出ないWAN接続の機能である。第二部では，4大機能のそれぞれに着目し，その舞台裏をのぞくことにする。WAN通信の基盤技術の振る舞いをじっくり見ていこう。
第二部 機能
交渉，認証，通知，監視 目的に応じて手順を追加
第一部で述べたようにPPPは交渉，認証，通知，監視の4大横能を備える。それぞれの実行フェーズでは，豊富に用意されたオプションから必要となる機能を選び，最適な条件を探り出して通信する。（PPPリンク処理）
PPPはレイヤー2プロトコルなので，レイヤー3プロトコルをデータと見なし，その先頭部分にヘッダーを付けた構造となっている。PPPのヘッダーはとてもシンプルでたった2バイト（16ビット）しかない。（PPPのデータリンク・フレームの構造）。
ここに書き込まれるのはプロトコルIDと呼ばれる識別子（識別子の数値はRFC1700で規定されている。IPなら0021h，AppleTalkなら0029hになる。制御用のメッセージには「c」で始まるIDが振られる。LCPはc021h，CHAPはc223hとなる。）。（PPPフレームの主なプロトコル値）。
ヘッダーに続くデータ部分の内容を示す。運んでいるプロトコルの種頸や，LCPやNCPで使われる制御メッセージを示す。PPP対応機器は，受け取ったPPPのヘッダーを見るだけで，次にするべき処理を判断できる。
ヘッダーをここまでシンプルにできるのは，PPPが一対一の通信用に設計されているから。相手は常に決まっているから，あて先や送り元を識別するアドレス情報が不要（実際のPPPフレームは，同期信号，アドレス・フィールド，制御フィールド，PPPヘッダー，データ部分，誤り訂正用データで構成される。ただし，アドレス・フィールドと制御フィールドには固定値を埋め込み，使わないようにしている。）なのである。
次に，PPP通信の全体の流れを確認しておこう。
PPP通信は4大横能を傾を追って実行する（図２−１）。
図２−１ 典型的なPPPの接続手順
まず通信の条件を決める交渉と相手を確認する認証は，最初のリンク確立フェーズでやりとりする。これが終わると，NCPの処理が始まる。ここではレイヤー3プロトコルに関連した設定が交渉され，必要に応じて通知機能が使われる。IPの場合は，IPアドレスが通知される。
NCPの設定が終わると，実際のデータ通信が始まる。ただしデータ通信の間は，リンクの監視機能がいつでも使えるしくみになっている。
１ PPPは交渉する パケット・サイズやオプションの利用を決める
PPPの通信が始まるとまず行われるのが交渉（ネゴシエーション）のプロセスである。ネゴシエーションはLCPメッセージ・パケットを使う。紹介してきたように，通信の条件を交渉で細かく決められることがPPPのメリットの一つ。その意味でLCPはPPPのキモと言ってよい。「ネゴシエーション機能があるから，どんな相手とでも通信ができる」。
LCPネゴシエーションでは，基本的な通信条件と，どのLCPオプションを使うかを決める。交渉で決める通信条件の中で最重要なのはパケット・サイズである。
パケット・サイズはMRU（maximum receive unit，最大受信単位）値の設定という形で行われる。MRUは自分が受け取り可能なペイロード・サイズ（データ部分の長妄）の最大値である。
MRUを通知するのは，相手に対し，自分が意図したサイズ以下のパケットで送信するように伝えるため。MRUは受信側が要求するものなので，双方が相手に希望を伝えて交渉する。交渉が成立したら，相手が指定した最大長以下の大きさでパケットを送る。IP通信では，双方でなるべく大きなパケットを送ろうとするので，事実上，交換するパケットサイズはMRUで決まることになる。
MRU値のデフォルトは1500バイトである。もちろん交渉次第で自由な値を選べる。実際のPPPソフトは，回線の種頚によって値を変えるようにプログラムされている。電話回線やISDNなどの低速回線では576バイト前後，ADSLなどの高速回線では1500バイト弱，光ファイバなどの超高速回線では4000バイト前後という設定が多い。
それではLCPネゴシエーションのプロセスを実際に見てみよう（図２−２）。ここではあるADSLサービスを利用したときにクライアント・ソフトとサーバーが行ったプロセスを例にしてみた。
図２−２ LCPのネゴシエーション
LCPネゴシエーションの特徴は双方が対等の立場で交渉することである。図２−２では便宜上，クライアントとサーバーと書いたが，PPPにおいて通信する双方は対等の関係にある。互いに条件を出し合い，それぞれ譲歩しながら最適な値を探し出す。クライアントからサーバーヘの交渉と，サーバーからクライアントヘの交渉は別々に独立に動く。また，それぞれの交渉は並行して進められる。
交渉の流れはおおむね次の通りだ。まず要求する側から要求パケットが届く。ここにはMRU値など使いたいLCPオプションとその設定パラメータ（条件）が全部リストアップされている。この中にサポートしていないオプションが含まれていたら，それを拒否パケットで返す。すると要求側はサポートできるオプションだけにして再び要求パケットを送ってくる。これが受け入れ可能なら確認パケットを送って交渉成立だ。このときの確認パケットには，受け入れたオプションと設定パラメータが入っている。
オプションの利用はOKだが，条件を変えたいときは否認パケットを送る。このとき否認パケットに，受け入れ可能なパラメータを入れておく。すると要求側はこのパラメータを見て，その条件で使うかどうかを判断する。納得した場合は，再び受け入れたパラメータを格納した確認パケットを送り，合意したことを相手側に伝える。
図では比較的，順調に交渉が進んだ例を描いているが，確認に至るまで何度もパケットをやり取りするケースもある。逆に双方がほとんどオプションを使わない設定だと，各1往復のやり取りで確認に至ることもある。このあたりは条件の設定や製品の実装によって異なる部分だ。もし通信条件が合わなければ交渉が決裂し，接続に失敗する。このようなしくみなので，ユーザーが余計なオプションを設定することで，PPP接続に失敗することもある。
LCPメッセージの内部では，オプションを番号で識別する。たとえぼ��RU設定は1番，認証プロトコルの利用は3番といったぐあいに何種頸もオプションがある。
もっとも，よく使われるLCPオプションは決まっており，それ以外はあまり使われていないようだ。「よく使われるのは，MRU設定，認証，マルチリンクなど。その一方で，リンク品質モニタリング機能などはほとんどのルーター製品がサポートしていない」）。
実はLCPオプションの多くはPPPの黎（れい）明期に定義されたもの。当時の回線は，低速で低品質であることが多かったので，その問題をクリアするためのオプションが多かった。
しかし最近の高速かつ高品質な回線では，そうしたオプションを取り入れてもあまり効果がない。こうした事情から，いくつかのオプションは使われない傾向にある。たとえばPPPoEの規格書（RFC2516）ではいくつかのLCPオプションの利用を堆奨していない。
同じことはNCPのオプション機能にも言える。たとえば，CCP（compression control protocol）と呼ばれる圧縮制御プロトコルがそれ。多くのルーターがサポートしているが，実際はほとんど使われていない。「CCPはルーターの負荷を増やしパフォーマンスを落とす弊害の方が目立つので，とくに高速な回線や大規模なネットワークでは使わない傾向になっている」。
実際，アナログ回線を使ったダイヤルアップ接続でも，プロバイダ側のルーターでCCPの利用を受け付けるケースはほぼ皆無であるという。
２ PPPは認証する 手順は２種類，CHAPの方が安全
PPPがプロバイダ接続やリモート・アクセス利用時に使われるのは，その認証機能を使うためである。
認証機能は，アクセスしてきたユーザーが正規のユーザーかどうか確かめる機能。セキュリテイ面だけでなく，プロバイダの場合は課金情報にも関係するので，ぜひとも活用したい機能となっている。
PPPの認証機能はLCPオプションの一つとして位置づけられている。認証機能は，LCPネゴシエーション時に認証機能を利用するかどうかを決め，使う場合はどの方式にするかを交渉する。そして，LCPネゴシエーションが終了したあとに認証プロセスが始まる。
PPPでよく使われる認証方式はPAP（password authentication protocol）とCHAP（challenge handshake authentication protocol）の2種頸である（図２−３）。どちらもたいていのPPP機器が備えている。
図２−３ PAPとCHAPのしくみ
PAPはPPPの開発当初からサポートされていた方式で，UNIXの標準的なログイン・プロセスを流用している。PAPのプロセスはクライアント（認証される方）がユーザーIDとパスワードを送り，サーバー（認証する方）があらかじめ登録しておいたユーザーIDとパスワードと照合するという単純な方式である。
PAPの問題点はユーザーIDとパスワードが一緒に，しかもテキスト・データとして送られる点にある。途中でパケットを法聴すればユーザーIDとパスワードを取り出せる。セキュリテイ上，あまり推奨できない方式である。
CHAPは，PAPの問題を解決するために開発され，あとからPPPに追加された方式である。CHAPは生のパスワードがネットワーク上を流れないように工夫されている。
CHAPのプロセスはまずサーバー側から「チャレンジ値」と呼ばれる文字列が送られるところから始まる。チャレンジ値を受け取ったクライアントは，自分のパスワードとチャレンジ値からハッシュ関数を使って演算し，その答えをユーザーIDと共に送り返す。サーバー側でもユーザーIDに対応するパスワードに対して同じ演算を行い，結果が合致すれば，確認メッセージを送る。
CHAPのポイントは，パスワードを導き出せるデータをネットワーク上に流さないことにある。ネットワークでやりとりするデータは，チャレンジ値とハッシュ関数による演算結果である。ハッシュ関数は計算結果から元の数値が導き出せない性質を持っており，同じ計算結果が出るパスワードとチャレンジ値の組み合わせはいくつも存在する。
このようなしくみなので，たとえチャレンジ値と演算結果の両方を盗聴されても，そこからパスワードを解析するのは極めて難しい。
３ PPPは通知する DNSサーバーのIPアドレスも通知してもらう
認証が柊了すると次はNCPネゴシエーションの段階に入る。第一部で説明したように，NCPはレイヤー3プロトコルごとに定義されている。それぞれのNCPは，レイヤー3プロトコルに応じた通信条件をネゴシエーションすることになる。
ここではIP用のNCPであるIPCPを例に説明する
IPCPの最も重要な役割は，IPアドレス関連の設定情報を通知することである。ダイヤルアップ接続環境を例に取ると，クライアント側は自分が使えるIPアドレスと，相手のIPアドレス，そしてDNSサーバーのIPアドレスを通知してもらう。
実はIPCPの仕様そのものの中には，DNSサーバーのIPアドレスを通知する規定がない。DNSサーバーのIPアドレスを通知する機能は，マイクロソフトによって独自に拡張されたものである。これは，95年12月に公開されたRFC1877で定義されている。このRFCは単なる情報提供（Informational）の扱いであり，インターネット標準ではない。だが，WindowsのPPPがこの機能を搭載していることもあり，ルーターやアクセス・サーバーの多くがDNSサーバーのIPアドレスを通知できるようになっている。
IPCPネゴシエーションのプロセスはLCPと似ている（図２−４）。基本的には双方が条件を提示し，譲歩しながら設定を詰めていくスタイルだ。
図２−４ IPアドレスを配布するプロセス
ただLCPと異なり，IPCPの動作はサーバーとクライアントで別々の振る舞いをする。これは，お互いが必要とするアドレス情報が違うからである。
サーバーは自分のIPアドレスを伝えるだけだが，クライアントは自分のIPアドレス，デフォルト・ゲートウェイのIPアドレス，そしてDNSサーバーのIPアドレスが欲しい。
サーバーが通知するIPアドレスは，クライアントから見るとデフォルト・ゲートウェイのIPアドレスになるので，残りは自分とDNSサーバーのIPアドレスとなる。
実はPPPには，通知を依頼するためのメッセージが用意されていない。そこでこの場合，通知して欲しい項目のパラメータにダミー・アドレス（0.0.0.0）を入れて要求パケットを送る。するとサーバーはそのアドレスが不適切であると判断し，正しい値を否認パケットに入れて伝えてくれる。条件変更のプロセスをうまく活用しているのである。
NCPネゴシエーションが終了するといよいよPPPの通信が始まる。PPPヘッダーのプロトコルIDで運ぶデータの中身を知らせ合う。あとは，レイヤー3プロトコルの通信を仲介し，正確なデータ伝送という本来の仕事を始めることになる。
４ PPPは監視する 品質の優れた回線ほど監視は難しい
通信が始まると，PPPソフトウェアは，上位プロトコル層から受け取ったデータに適切なプロトコルIDのヘッダーを付けて回線上に送り出す。具体的には，同期信号を最初に送ってからPPPヘッダーを先頭に付けてIPパケットを送り出す。IPパケットの後ろには，誤り訂正用データも付け加える。
一方の受信側は，PPPフレームを受け取るとデータ誤りが生じていないかを，誤り訂正用データを使って調べる。わずかな誤りならその場で修正してから，上位プロトコルに渡す。
データ通信中にPPPが実行する機能はもう一つある。データがきちんとやりとりできる状態にあるかどうかを，監視することである。
PPPが備えているリンクの監視機能は次のように動作する。まずリンクが生きているかどうか監視したい側が，エコー要求というパケットを送りだす。もう一方がエコー要求を受け取ったら，すぐにエコー応答パケットを送り返す。基本的にはこれだけである（図２−５）。エコー要求／応答パケットはLCPパケットである。
図２−５ リンク監視機能の使われ方
なお，RFCでは「LCPエコー要求を受け取ったら必ず返す」と定義されているだけで，エコー要求をどう使うかは機器の実装に任されている。
一般的には一定間隔でエコー要求を投げ，失敗した場合はリトライを何度か繰り返す実装が多い。つまり，監視したい側がエコー要求を送り，応答がない場合も何度か繰り返し，それでも応答がないときはリンクが切れていると判断する。
ノードのどちらが監視するかとか，通常時の監視間隔やリトライ回数は，その機器がどのような回線で使われるのかによって異なる。
一般的な傾向は，高速で信頼性が要求される回線ほどエコー要求の送信間隔が短い。きめ細かく監視したいということである。一方，低速回線では監視機能をまったく使わないケースが多い。電話やISDNの場合は，回線が切れるとすぐにわかるので，PPPレベルで監視する必要性がないからだ。また，ただでも狭い帯域を，監視パケットでさらに狭くすることも避けたい。
高い信頼性が求められる基幹回線を除けば，監視プロセスはどちらか片方のみで動かすことが多い。たとえばダイヤルアップ接続のような状況では，クライアント側でリンクを監視してもあまり意味がないので，プロバイダ側だけで監視するケースが多い。プロバイダ側のアクセス・サーバーの能力を，エコー応答に使うのはもったいないと考えるからである。
実際，NTT東西が配布しているPPPoEクライアント・ソフト「フレッツ接続ツール」は監視機能を使わない設定（PPPoEクライアント機能を内蔵したルーターの多くは，１分間隔程度でリンク監視を実行する設定がデフォルトとなっている。このため，ルーターを使うと両側でリンクを監視することになる。）で配布されている。アクセス・サーバーは1分に1回の間隔で監視している。
第三部 応用
PPPoEとは一体何か 使う場所で便利さが違う
PPPoE（PPP over Ethernet）は，パソコンやルーターがイーサネットでPPPを動かすために開発された。その用途は大変広い。第一部で紹介したように，NTTはADSLサービスだけでなく，FTTHサービス「Bフレッツ」でもPPPoEを使う。今後のブロードバンド・インターネットの標準プロトコルとなる可能性は極めて大きい。
もう一つ重要なことは，PPPoEをうまく使うには，PPPoEのしくみを知っておく必要があること。正しく理解していないと，複数ユーザーで利用できなかったり，通信そのものができなくなったりする。
そこで第三部では，PPPoEのしくみと，実際に活用する際に知っておきたい実践情報を紹介することにしよう。
まず最初に，PPPoEがどのように使われるのか確認しよう（図３−１）。ここでは，PPPoE対応のブロードバンド・ルーターを使うケースを示した。
図３−１ PPPoEの基本的な役割
まずパソコンがIPパケットをMACフレームでルーターに送信する。ルーターはMACフレームからIPパケットを一度取り出すと，IPパケットの先頭にPPPヘッダーとPPPoEヘッダーをくっつけて，これを再びMACフレームの中に入れる。ここでPPPoEフレームができるわけだ。
ルーターがADSLモデムに送り出したPPPoEフレームは，最終的にプロバイダのアクセス・サーバーヘ届けられる。こうして，ブロードバンド・ルーターとアクセス・サーバーは PPPをやりとりできるようになる。
PPPoEといっても，そこで運ばれるPPPは通常のPPPと何ら違いはない。ただし一つだけ使用条件が加わる。それは，PPPのデータ部分（ペイロード）の最大長が1492バイトとなることである。これは，イーサネット・フレームが運べるパケットの最大値が1500バイトであることと，PPPoEヘッダーとPPPヘッダー（両方で8バイト）が加わるためである。
では，PPPoEのセッション確立手順を見ていこう。
動作は，PPPoEクライアントが開始メッセージを流すことから始まる。これはクライアントがPPPoEの通信を引き受けてくれるPPPoEサーバーを探すメッセージである（図３−２）。
図３−２ PPPoEの通信
開始メッセージを受け取ったPPPoEサーバーは，クライアントにオファー・メッセージを返す。これはクライアントの要請に応える用意があるというメッセージである。オファーを受け取ったクライアントはセッションの開始を要求するメッセージを送り返す。このあと，サーバーがセッションIDを指定した確認メッセージを送り返して，PPPoEセッションが確立される。この直後からPPPのLCPネゴシエーションが始まる。
ここでちょっと疑問が沸くかもしれない。もし，PPPoEが動いているイーサネット上に複数のPPPoEサーバーがあったらどうなるのだろうか。複数のサーバーが同じクライアントにオファーを返信する可能性があるはずである。
現在の実装では，複数のオファーがクライアントに返信された場合，クライアントは一番最初に返信したサーバーを選んでPPPoEセッションを始めることになっている。
PPPoEの規格書を見ると，サーバーを選ぶための材料として，「Service-Name」（サービスの名前）や「AC-Name」（サーバーの名前）を指定できるようになっている。確かにPPPoEクライアント・ソフトの設定項目を見ていくと，Service-NameやAC-Nameを指定できる画面がある。
ただし，現状のADSLインターネットは名前を指定する機能を使っていない。このため，ここを空欄にしておかないと，そこに書き込んだ名前のサービスやサーバーを探してしまい，本来のサーバーと接続できなくなることがある。
もちろん将来的にはService-NameとAC-Nameを使うサービスが登場する可能性はある。こうしたことからPPPoEを利用するときは，名前を指定するべきかどうか確認する必要がある。
ここでPPPoE登場の背景を簡単に説明しておこう。この事情がわかると，ADSLインターネットでPPPoEが採用される理由が見えてくる。
ADSLでPPPを使おうと考えたのは，プロバイダである。プロバイダはどこも，電話やISDNでダイセルアップ接続サービスを提供するためにPPPサーバーを用意してある。ユーザー認証やIPアドレスの通知を実行するためだ。
そこでプロバイダは，ADSLインターネットにもこのしくみをそのまま持ち込みたいと考えた。新たな設備を入れることなくサービス・メニューを増やすことができるからである。
こうしたプロバイダのニーズに答えるため，ADSL機器ベンダーはまず最初にPPPoA（PPP over ATM）と呼ぶプロトコルを開発した。これは，ATM上でPPPを実行する仕様。ADSLはATM技術で通信するので，ATM上でPPPを動かすことを考えたのだ。
ただし，PPPoAには問題があった。パソコンでPPPoAを起動させるケースを考えると，パソコンとADSLモデムをATMで接続しなければならないことだ。ATMは高価であるうえに，パソコン向けの通信技術としてはほとんど利用されていない。一般ユーザーが気軽に使える方法とはいえなかった。
そこでプロバイダとADSL機器ベンダーが協力し，PPPoAの問題を解決する技術を開発した。これがPPPoEである。PPPoEの開発目的は，ユーザーにATMを見せないようにすることと，パソコンとADSLモデムをイーサネットで接続できるようにすること。この技術があれば，一般的なダイヤルアップ接続と同等の手順でADSLインターネットを提供できる。プロバイダはPPPoEを歓迎し，ADSLインターネットに採用したのである。
PPPoEによるADSLインターネットの構成例は大きくこつある（図３−３）。
図３−３ PPPoEを使うときの接続形態
一つは，パソコン上でPPPoEクライアント・ソフトを動かすもの。パソコンはLANでADSLモデムとつながっているものの，使い勝手はモデムやISDN用ターミナル・アダプタでダイヤルアップ接続するときと同じである。
この構成では，パソコンとプロバイダが直接PPPをやりとりするので，ユーザー認証はパソコンごとに実行する。このため，LAN上に複数のパソコンがあっても，同時利用はできない。それぞれ別のアカウントが必要になる。
もう一つの方法は，ADSLモデムとパソコンの間にブロードバンド・ルーターをおくもの。PPPoEはブロードバンド・ルーターが実行する。これはISDNルーターでダイヤルアップ接続するときと同等の構成である。
こうしておけば，ブロードバンド・ルーターのNAT機能を使うことで，複数のパソコンが同時にインターネットを利用できるようになる。
なおどちらの場合も，ADSLモデムからADSL回線に送り出されるデータはPPPoEフレームである。
通常のPPPoEは，PPPパケットをイーサネットで包み，それを通信する両側の間で運ぶ格好になる。ADSLインターネットの場合は，ユーザー側と プロバイダ側との間でPPPパケットがやりとりされる。
ところが，日本最大のPPPoE環境であるフレッツ・ADSLは，通常のADSLインターネットとは構造が違うため，PPPが働く場所も少し違った格好になる。
フレッツ・ADSLでは，PPPoEクライアントのユーザーIDを「ユーザー名＠プロバイダ名」という形式で運用している（図３−４）。これは，フレッツ・ADSLにおいて，複数のプロバイダを選べるようにするため。＠以降の文字列でプロバイダ名を識別する。
図３−４ フレッツ・ADSLの認証方法
一見，何の不思議もないように見えるかもしれないが，PPPのふるまいを考えると，ちょっとおかしいことに気づく。ユーザーは自分が正式なユーザーであることをプロバイダに伝えるためにユーザーIDを送る（＠の前の部分）。ユーザーIDを受け取るのはプロバイダとなるはずだ。
だが，フレッツ・ADSLのユーザーIDは，NTT東西がどのプロバイダと接続するのかを決める材料としても使われている（＠のうしろの部分）。ユーザーIDは誰に届いているのだろう。
フレッツ・ADSLにおいてユーザーIDを受け取るのはNTT東西のアクセス・サーバーである。PPPのネゴシエーションは，すべてユーザーとNTT東西のアクセス・サーバーとの間で実施されている。具体的には次のような流れとなる。ユーザーからのPPPoEの起動を受け付けたNTT側のアクセス・サーバーは，PPPoEのセッションを確立し，LCPネゴシエーションを始める。LCPの交渉が終了すると，続いて認証プロセスが始まる。このときPPPoEクライアントは，ユーザーIDと認証用データをNTTのアクセス・サーバーに送る。
これを受け取ったNTTのアクセス・サーバーは，＠のうしろの文字列から契約しているプロバイダを判断する。そして，そのプロバイダの認証サーバーに，ユーザーIDと認証用データを送るのである。
ユーザーIDと認証用データを受け取ったプロバイダ側の認証サーバーは，自分の持つユーザー情報と照合して正規ユーザーかどうかを判断する。そしてその結果をNTTのアクセス・サーバーに返信する。
さて，認証に成功したPPPoEクライアントは，こんどはIPCPを起動し，IPアドレスの通知を求める。クライアント側が求める各種のIPアドレスは，プロバイダごとに異なる値だ。つまり，NTT東西が勝手に割り当てることはできない。
そこで再びNTTのアクセス・サーバーは，プロバイダの認証サーバーに問い合わせを送る。認証サーバーは求められたIPアドレス情報をNTTのアクセス・サーバーに返信する。
このように，フレッツ・ADSLでは，PPP（PPPoE）をユーザー側のPPPoE、クライアントとやりとりするのはNTTのアクセス・サーバーであるが ユーザー認証とアドレスの割り当てはプロバイダの認証サーバーに任せている。
ここで紹介したアクセス・サーバーとプロバイダの認証サーバーの連携方法は，フレッツ・ADSLだけでなく，フレッツ・ISDNやBフレッツにおいても採用されてる。
なお，このときアクセス・サーバーと認証サーバーは，RADIUSと呼ばれる認証プロトコルで通信する。RADIUSは，認証サーバーをアクセス・サーバーとは別のマシンにするときに広く使われている。
最後にPPPoE対応のブロードバンド・ルーターが備えている独特の機能を紹介しておこう。
この機能は フレッツ・ADSLが始まってまもなく報告された不具合を解決するためのもの。不具合とは，フレッツ接続ツールを使っていると問題なく見えるいくつかのホームページが，ブロードバンド・ルーターを経由すると見えなくなったり，極端に表示が遅くなるというものだ（図３−５）。
図３−５ ブロードバンド・ルーターはTCP/IPのパケットサイズ設定を書き換える
ADSLをフレッツ接続ツールで使うとき，PPPの最大パケット・サイズ（MRU）は1454バイトに設定される。
WebブラウザがWebサイトにアクセスするとき，Webブラウザは相手のWebサーバーに自分が受け取れる最大のデータ・サイズ値を通知する。これをMSS（maximum segment size）と呼ぶ。MSSは通常，MRUからIPとTCPのヘッダー（両方で40バイトある）を取り除いた長さとなるため，フレッツ・ADSLの場合は1454−40＝＝1414バイトとなる。つまりWebブラウザがMSS値を1414バイトとしていれば問題は起こらない。
ところがブロードバンド・ルーター経由で接続すると，WebブラウザはMRUの制限を知らないのでMSSの値が変わってくる。MRUをイーサネット・フレームの最大値である1500バイトだと考えるので，MSSが1500−40＝1460バイトになってしまう。こうなるとPPPoEのパケットサイズは，NTT東西が想定する値を超えてしまう。これが正しく通信できなくなる原因だった。
最近のPPPoE対応ブロードバンド・ルーターは，Webアクセスのデータを監視し，MSSが1414バイトより大きく設定してあると，それを1414以下の値に変更する。こうすることでトラブルを未然に防いでtlるのである。
トップページへ
