フレッツ光ネクストの回線でプロバイダ切り替え作業のときにエラーが出てハマったので、ここに何が起きていたかをまとめる。
PPPoE接続ができない理由の1つにそのセッション数上限がある
自宅ではこれまでBB.exciteをNTT東日本のフレッツ光ネクスト経由で使っていた。ただ、BB.exciteには光コラボレーションとしてIPv6回線を提供するサービスがあっても、既存回線の追加としてIPv6に対応するサービスが存在しなかった。そのため、まずはプロバイダを「ぷらら光メイト」に切り替え、その後でIPv6回線の導入を行おうとした。ところが、NTTぷららとの契約が完了してもぷらら光メイトにPPPoEで接続することができず、これに関しNTT東日本とNTTぷらら両方に問い合わせても原因がわからなかった。紆余曲折を経てわかった原因はPPPoEセッション数の上限「2」に達していたことであった。上限の範囲内で同時接続を行うために、サービス情報サイトへのPPPoEセッションを切ることでBB.exciteとぷらら光メイトの両方の回線に接続することができた。
基礎知識:フレッツアクセスサービスは(大人の事情で)インターネット接続を提供していない
この話の詳細を理解するために、まずフレッツを用いたインターネット接続の仕組みを知る必要がある。
フレッツ光ネクストなどのフレッツ系のサービスは東西NTT(東日本電信電話株式会社、西日本電信電話株式会社)により提供され、フレッツの仕組みを理解する上でこの両社の成り立ちが重要になる。東西NTTとその持株会社である日本電信電話株式会社はその元をたどると日本電信電話公社、通称「電電公社」に行き着く。電電公社は電話網という公共インフラを運営するための法人として、日本電信電話公社法で設置された公営企業である。もはや歴史の1ページとなってしまったが、この電電公社は労働問題や財政問題など様々な要因により国鉄などとともに民営化されることとなった。
公営企業が民営化されるときに問題になるのが、その新しい企業が公正な競争を破壊してしまうことである。公営企業にはその事業の公共性を理由に税金が投入されており、単純に資産などを引き継いで民営化をすると普通の私企業に対して不当に有利な立場になることが多い。1980年代の電電公社民営化の際にも当然その問題は認識されていた。その時は純粋に民営化するのではなくその行動に行政の許可を必要とする特殊会社とし、5年以内に経営体制を見直す事となっていた。日本全国に広がる通信網を抱えるNTTは私企業から見ればあまりに強大すぎる寡占企業である。そのため、幾度となく再編、すなわち分社化が議論されてきた。
今回関係してくるのが1999年に行われた東西NTTが設立された再編成である。NTTは同名の持株会社である「日本電信電話株式会社」と地域通信を担う「東日本電信電話株式会社」「西日本電信電話株式会社」、そして長距離通信及び国際通信を担う「NTTコミュニケーションズ」の4社に分割された。当時の検討中の資料が[1]であり、現状も概ねこの延長となっている。
[1] http://www.soumu.go.jp/main_sosiki/joho_tsusin/pressrelease/japanese/denki/1206j601.html
1999年に行われたNTT再編成の概要
再編成の概要を上に図示した。東西NTTとNTTコミュニケーションズはNTTの完全子会社であるという点では共通である。ただし、東西NTTは特殊会社である一方NTTコミュニケーションズはほぼ純粋な民間企業であるという点で大きく異なる。特殊会社というのはその設立に際し一般的な登記による手続きではなく、法律に基づいているという点で特殊性があるものであり、何らかの形で法律の規制を受けている会社である。(実務面から見ると、規制をかけるために法律によって設立しているとも言える。)持株会社であるNTT株式会社も含め、今回出てくるこれらの特殊会社は日本電信電話株式会社等に関する法律(通称「NTT法」)に基づき設立されている。
なお余談ではあるが、NTTコミュニケーションズは特殊会社ではなくなったとはいえ、その親会社が国の出資によるため完全に民間企業と同一というわけではない。
さて、NTT法でフレッツを提供している東西NTTは「地域会社」とされており、第2条3項にその業務が規定されている。
３ 地域会社は、その目的を達成するため、次の業務を営むものとする。一 それぞれ次に掲げる都道府県の区域（電気通信役務の利用状況を勘案して特に必要があると認められるときは、総務省令で別に定める区域。以下同じ。）において行う地域電気通信業務（同一の都道府県の区域内における通信を他の電気通信事業者の設備を介することなく媒介することのできる電気通信設備を設置して行う電気通信業務をいう。以下同じ。）イ 東日本電信電話株式会社にあつては、北海道、青森県、岩手県、宮城県、秋田県、山形県、福島県、茨城県、栃木県、群馬県、埼玉県、千葉県、東京都、神奈川県、新潟県、山梨県及び長野県ロ 西日本電信電話株式会社にあつては、京都府及び大阪府並びにイに掲げる県以外の県二 前号の業務に附帯する業務
ざっくり言えば「地域会社は各都道府県内の通信を担う」ということである。そして、その目的の範囲において各種業務を総務大臣の監督の下で実施できる事になっている。なお、同5項で地域会社が持ってる各種資源(設備や技術など)を用いて他の業務も可能となっているが「電気通信事業の公正な競争の確保に支障のない範囲内」とある通り条件付きである。当然、電話も含めインターネット通信の多くが都道府県内だけで通信が完結するわけではない。この再編成の肝はNTTの事業から強い公共性を求めらない競合他社が存在しうる事業を切り出すことにある。離島を含む末端の通信回線を維持するという民間がやりにくい公共性の高い事業を行う会社(東西NTT)と、都道府県をまたいで電話をしたり海外と接続したりする民間企業も参入がしやすい長距離通信事業を担う会社(NTTコミュニケーションズ)とを分け、前者を特殊会社、後者を民間企業とする。これにより他社がNTTコミュニケーションズと競合できるようになる。
この様な規制を受けた東西NTTが提供するフレッツも、電話回線と同様に都道府県内での通信網として整備されてきた。ただ、これではいろいろ不便だということで、2003年に東西NTTが持つ設備の活用業務として県間通信を行うことによるフレッツサービス広域化が認可され、広域VPNのサービスなどが展開可能となった[2][3]。そして、現在はこれを新たな技術で置き換えた「NGN」がフレッツ光ネクスト等のベースとなっている。これによって理屈の上ではそれぞれの地域会社管内のフレッツサービスが均等になるはずだが、現実にはそうはなっていない。東西NTTのウェブサイトで県別の対応プロバイダ一覧を見てもらえば分かるが、県によって対応しているプロバイダの数が異なる。例えば東京都で利用できる「インターネット三重」は北海道では利用できない。ただ単純にケーブルを繋げば無条件に通信できるわけではないのと同様に県間通信を開始したからと言って接続した県内ネットワーク同士が完全に同化できるわけではない。帯域という設備の都合もある上に県間伝送路の設置には公正な競争を阻害しないようにいくつかの制限が課されている。現状でも原則として通信は各都道府県単位なのである。
[3] フレッツサービスの広域化の実施について – NTT東日本：NewsRelease
この様な法規制により、フレッツはそれ単体でインターネットサービスを提供できない。携帯電話回線とは異なりフレッツで東西NTTと別にプロバイダを選ぶ理由はこのNTT法の規制にある。東西NTTが都道府県内での通信しか提供できなくても、民間のプロバイダが県外、そして海外への通信を提供すれば顧客は様々なサービスが使えるわけである。現にフレッツに接続したプロバイダは多くいることを考えるとこの施策によって企業同士の競争の場を作ることには成功していると言えるだろう。
フレッツ網(NGN)から出るためのPPPoEとRADIUS
法的に回線とプロバイダ(ISP)を分離したという点は説明したが、法律を作ったら自動的にそれが実現されるわけではない。刑法や刑訴法を作ったのに肝心な警察官を育成しなければ、それらの法律はただの紙切れであるのと同様である。東西NTTが提供する地域電気通信(県内通信)を経由してインターネットに接続する仕組みが必要になる。それがPPPoEとRADIUSである。
フレッツ網の仕組みに関しては[4]や[5]でわかりやすく説明されている。ここでは必要となる部分だけ抜粋して図示する。なお、資料は東西NTT混在しているが、以下すべてNTT東日本 フレッツ光ネクストの場合を想定した情報である。
PPPoEによるインターネット接続を利用する際に用いるフレッツ関係の設備など
今回のPPPoEによるインターネット接続に関係あるフレッツの設備などを大まかに上に図示した。ユーザーはISPとインターネット接続サービスの契約を行うが、フレッツの場合はユーザーとISPは直接つながっているわけではない。法的に分離されたユーザーとISPを技術的手段によってつなげるのがフレッツアクセスサービスなのである。
ユーザーとフレッツ間は光ファイバーケーブルやそれに付随する様々な設備(マンション内の分配器だったりVDSLだったりも含む)を経由してEthernetレベルでつながっている。このEthernetのユーザー側は貸し出されたHGW(ホームゲートウェイ)もしくは自前のルーター、フレッツ側は収容局にあるB-RAS(Broadband Remote Access Server)である。なお、B-RASをフレッツの資料ではBAS(Broadband Access Server)と記述してあることもある。いわゆる光回線という商品はこのルーターとB-RAS間の全部もしくは一部を光ファイバーによる通信で提供するものである。ちなみに、接続先であるNTTの収容局は都市部なら徒歩か自転車で行ける距離にあるはずである。電柱をたどって探してみるのも面白いかもしれない。(途中で見失いそうだが…。)
一方、ISPとフレッツ間は媒体はいろいろあれど相互接続点(POI)に設置されているNTE(網終端装置 : Network Termination Equipment)を介して接続される。なお、このNTEはフレッツにおけるインターネットの速度低下の要因としてよくあげられる設備であるが、本記事で詳細には触れない。ISPから見るとこのNTEがフレッツとの接点でありユーザーとの接点でもある。そして、フレッツに接続しているISPは複数あり、フレッツはユーザーの通信を適切なISPにわたす必要がある。
では、どの様にユーザーが利用するISPを判別し、そして二者を結びつけているのだろうか？
ISPの判別に関してはユーザーがPPPoEで認証する際に用いるユーザー名を元に行っている。フレッツ光ネクストを利用している人は経験があるかと思うが、ユーザーはISPと契約するとPPPoEのユーザー名とパスワードを通知される。ユーザーはこれをルーターに設定することでフレッツ経由でインターネット接続サービスを利用できるようになる。このユーザーは「user@service」のような形式になっており、フレッツではこのPPPoEのユーザー名の@以降の部分を見ることでISPを判別している。この判別はB-RASとサービス制御部が連携して行う。
この判別の後に先のPPPoEのユーザー、パスワードを使ってISPと認証する。成功すればIPアドレス設定などを行ってフレッツ網越しのインターネット接続確率となる。
フレッツアクセスサービスにおけるPPPoEセッション確立の流れ
この流れの詳細を上図に示した。すでにユーザーはルーターなどの物理的な機材の接続は済ませているとする。この時点でルーターとB-RASの間にはEthenetによる接続が成立している。
PPPoEによる接続の最初のステップはPPPoE Discovery Stageと呼ばれ、ルーターとB-RAS間にPPPoEセッションを確立することである[6]。PPPoEはその名称”Point-to-Point Protocol over Ethernet“の名前が示すとおり、Ethernetによるリンク上でPPPを動作させるものである。ルーターはブロードキャスト宛(ff:ff:ff:ff:ff:ff)にPADI(PPPoE Active Discovery Initiation)パケットをEthetnet上に送出し接続相手を探す。フレッツではこれにB-RASが応じる仕組みになっている。
[6] RFC 2516 – A Method for Transmitting PPP Over Ethernet (PPPoE)
PPPoEセッションを確立したらPPPoE PPP Session Stageに移行し、PPPのフレームをEthernetフレームのペイロードに入れて、PPPセッションの確立をEthernet越しに行う。
PPP[7]はPPP LCPによる”Link Establishment Phase”、PPP CHAP[8]などによる”Authentication Phase”、PPP NCP(IPの場合はPPP IPCP[9])による”Network-Layer Protocol Phase”の3段で接続を確立する。先の説明の通り接続先ISPはPPPoEのユーザー名、すなわちPPP CHAPのResponseパケット(RFC1994のSection 4.1)のNameフィールドに入っているデータから判別することになる。B-RASからルーターへのCHAP Challengeパケットを送り、ルーターがそれにCHAP Responseで応答した後に初めてISPが登場することになる。
[7] RFC 1661 – The Point-to-Point Protocol (PPP)
[8] RFC 1994 – PPP Challenge Handshake Authentication Protocol (CHAP)
[9] RFC 1332 – The PPP Internet Protocol Control Protocol (IPCP)
フレッツがCHAP ResponseパケットからISPを判別したら、RADIUS[10]のAccess-RequestをISPのRADIUSに投げることになる。細かい実装は不明だが、ISPからNTEを見るとフレッツ網がRADIUSクライアントとして振る舞うようになっているようだ。ISPはその情報を元にユーザー認証を行い接続の可否を判断し、フレッツ網に結果を返す。ISP側で認証成功したらRADIUS Accounting[11]に進み、ISPからIPアドレスなどを付与することになる。
[10] RFC 2865 – Remote Authentication Dial In User Service (RADIUS)
[11] RFC 2866 – RADIUS Accounting
このRADIUS Accountingによる設定はルーターへPPP IPCPを用いて渡され、IP関連の設定が完了したらIPパケットをPPPでカプセル化し、さらにそれをEthernetフレームに入れてB-RASに投げるとISPにつながるNTEにPPPフレームが到着し、NTEがPPPによるカプセル化をほどくと晴れてIPパケットがISPに到達することになる。
この様にフレッツでは基本的には標準技術を用いているのだが、その実装に一工夫することで回線とISPの分離を達成している。フレッツの特徴的な仕組みもユーザーの設備からは一般的な機材を用いて利用できるインターフェースとなっている。
フレッツ光ネクストの細かい技術仕様はIP通信網サービスのインタフェース 第三分冊に記されている。また、同じ資料の後半にはフレッツ・VPNゲートの技術仕様も書かれている。VPNゲートはISPと同様にフレッツ光などのアクセスサービスを介してネットワーク同士を接続できるサービスであり、パケットレベルでの技術仕様はフレッツ-ISP間の通信とほぼ同様なのではと考えられる。参考にされたい。(なお、フレッツから送られるRADIUSのAccess-RequestにCHAP-Passwordが含まれるのにCHAP-Challengeが含まれないのは明らかにミスと思われる。)
複数ISPの利用と制限
このPPPoEによるユーザーとISPの接続は多重化することができる。Ethernetはパケット交換方式のデータリンクであるため、単にPPPoE Discovery Stageを開始すれば複数のISPを利用することができる。もちろんルーターが対応している必要がある。例えばYAMAHA RTX1210の場合PPPoEセッションの上限は40である。
ただ、忘れては行けないのは「フレッツ網」はインターネットのようなStupid Networkではないことである。先程のRADIUS関連の挙動を見ての通り、フレッツ網はそれ全体として1つの認証システムのコンポーネントとして振る舞うなど、Intelligent Networkとしての特性を持っている。フレッツ網でのPPPoEの挙動はフレッツ網がそのセッションを管理し仮想回線を開かなければ成立しない。IPルーターで構築されたネットワークと異なり中継役が状態を管理している。
管理しているということは制限をかけられることを意味し、そして制限が可能なものは大抵は制限されているのである。ご多分に漏れずフレッツ光ネクストなどでのPPPoEセッション数も制限されている。家庭向けアクセスサービスでは初期状態で”2″がその上限である[12]。(もちろんこれは不当に制限しているわけではなく、設備の能力に上限がある以上ベストエフォートでやるとまともに利用できない人が出てきてしまうという公平性の問題である。)
[12] サービス内容 | フレッツ・セッションプラス | インターネット／アクセス回線 | サービス | 法人のお客さま | NTT東日本
ここで注意が必要なのは「ISPの数」ではなく「PPPoEセッション数」である点である。1つのプロバイダでIPv4とIPv6の両方をPPPoEで設定したら上限の”2″セッションに達する。また、フレッツの「サービス情報サイト(IPv4)」への接続に用いるPPPoEセッションもカウントに入るため、サービス情報サイトへの接続を行いながらPPPoEによるIPv4接続を2つ利用することはできない。
この制限は[12]で説明されている「フレッツ・セッションプラス」を用いることで緩和することができる。これは追加料金を支払うことでこのPPPoEセッション数の上限を上げることができるサービスである。プロバイダを使い分けたり、フレッツVPNを利用する場合に必要になるサービスであるが、個人で使うのは相当マニアックである…。(当然私も契約していない。)
PPPoEセッション数の上限に達すると…何も返ってこない
PPPoEセッション数の上限に達すると何が起きるのか…？これが私を悩ませた原因とも言える。PADIを送っても何も起きなくなるのである。正常であればB-RASからPADO(PPPoE Active Discovery Offer)パケットが返ってくるところだが、セッション数の上限に達すると音沙汰がなくなる。前提知識がないとPADIがフレッツ網に吸い込まれるだけでトラブルシューティングの取っ掛かりになるエラー情報が得られずに困ってしまう。私が使用しているYAMAHA NVR500だと下の画像の様なエラーメッセージが出ることになる。
NVR500でセッション数の上限に達した様子
NVR500の851エラーの詳細
セッション数の上限に達した状態でさらにPPPoEの接続を試みると851というエラーが発生し、その内容は以下の通りである。
|
851 |
PPPoE: PADI TimeoutPPPoE接続でPADIタイムアウト。 接続先にサーバが存在しない。または、サーバまでの区間の回線状態が良くない可能性がある。 |
確かにルーターからパケット送っても何も返ってこないのだから、説明としては間違っていない。しかしながら、ここからいきなりPPPoEセッション数上限という答えにたどり着くのは難しい。実際、原因特定に3日間を要してしまった。3日目に2つのプロバイダを併用することを諦めて古い方を切断したらうまく言ったので気がついたという次第である。
セッション数の上限に達したらPADIに何も応答しない合理性
さて、この仕様を「そういうものである」と受け入れてしまえば話はおしまいだが、せっかくなのでここを掘り下げてみよう。まず、このフレッツのB-RASの挙動はきちんとRFCの内容を満たしているか確認する。PPPoE[6]のSection 5.2を見ると以下のような記述がある。
If the Access Concentrator can not serve the PADI it MUST NOT respond with a PADO.
Access Concentrator(AC)は今回で言うB-RASであり、セッション数の上限に達したということはPADIによる要求に答えられないことである。RFCに従えばPADOを返してはならないため、フレッツの挙動はこれを満たしている。
次に、RFCにおいて何らかのエラーメッセージを返すのではなく、なぜ何も返さないという仕様になっているのか。そこには合理的な理由があるのだろうか？答えを言えば簡単でPADIから始まるDiscovery Stageは名前通りEthernet上の1台以上ある目的のACを探し、その中から1台のACを選びそのEthernetアドレス得るステージであるためである。すなわち、とあるACがサービスを提供できなくても他のACが提供できるかもしれないので、提供できないACは大人しくしておいてくれということである。個々のACにエラーを返されても、クライアント側としてはそれをスルーして、正常なPADOを待つしかないのである。DHCPに似ているといえば似ているプロトコルとも言える。
PPPoEが想定している状況を示すと上図になる。この状況でAC-0が使えないなら、AC-0は黙っておくのが合理的であると言えるだろう。
フレッツのような最初から相手の候補が1つしか無い状況だとわかりにくいが、PPPoE DiscoveryはEthernet上にある複数の接続先から適したACを選ぶ手順なのである。そして、PPPという電話線などのシリアルケーブルで物理的に直接結ばれた2点間を結ぶ技術をEthernetを利用してネットワーク化しマルチポイントに対応させたのがPPPoEなのである。この様に捉えると、フレッツは本来はPPPoE DiscoveryでやりたかったPPPの接続先探索をPPP Session Stageでやっている、というなかなかにおかしな状況であることが見えてくる。
もちろん独自プロトコルを作れば無駄なく初手のパケットでISPを判別し、オーバーヘッドを削減できるだろう。でも、それをやったら接続するルーターはもちろん、各種中継機器もすべて独自開発しなければならないため、とても高コストになってしまう。今ある標準技術を駆使していかに良いサービスを安く提供できるかがネットワークビジネスを制する肝なのだろう。