PR

 今日は,IPv6ルーターの開発フェーズ2について見ていきます。

■UIをコマンドライン型に統一

 フェーズ2はフェーズ1のベータ版を正式に製品化するためのフェーズです。機能的にはフェーズ1とフェーズ2では大きな違いはありませんが,製品化に当たっては二つの課題がありました。

 一つはユーザー・インタフェースをIPv4と同じコマンドライン・ベースのものにすることです。フェーズ1では,「IPv6に関するあらゆる機能を実装して試したい」ということから,可能な限りIPv6のフルスペックの機能を入れ込むことを優先しました。そのため,IPv6関連の機能とは直接関係がない「ユーザー・インタフェース」(UI)は後回しとしました。

 ルーターやスイッチなどのネットワーク製品では,UIとしてコマンドライン・インタフェースを提供するのが一般的です。GR2000のIPv4機能でもそれに則っています。しかしながら,フェーズ1のIPv6機能では,より伝統的なBSDの手法を採用しました。つまり,KAMEと同じく,テキスト・エディタで書いた設定ファイルをあらかじめ用意しておいて,それをGR2000に読み込ませるという方法です。

 ただし,機能によって設定方法が異なるという統一性のない方法では,製品としてユーザーに提供できません。そこで,IPv6機能の設定もコマンドラインから実現できるように,UIを作り込みました。この作業は単純に手間だけの問題で作業そのものは難しくありませんでした。

■対応する物理インタフェースを決める

 もう一つのより悩ましい課題は,フェーズ1の結果を元に製品の実装方針を決定しなければならないということです。

 ここでいう実装方針というのは,どの機能をどこまで,どの部分に実装するかということです。また,実装にあたってはフル・スクラッチで自分たちで作るのか,KAMEソフトウエアのものを流用するのかというのも決める必要があります。製品になってしまうと,一度決められた実装方針を変更するのは難しいので,以降のフェーズを見据えた長期的な視野での判断が必要です。

 実装方針を決めるにあたっては,いくつかの前提条件を決めておく必要がありました。

 まずは,物理ポートのインタフェース種別をどこまでサポートするかという点です。最近は広域イーサネット・サービスやイーサネット・インタフェースで提供される各種ブロードバンド・サービスが普及したことで,イーサネット・ポートさえ装備しておけばほとんどの場合は問題がなくなりました。しかし,1999年当時はまだ,WAN回線用のインタフェースをサポートする必要がありました。そこで,ATM,ISDN,V.35やX.21といったシリアル・インタフェース,POSをサポートすることにしました。

 インタフェースの種類によって,サポートにかかる手間には差があります。ATMの場合は,IPv6のパケットを48バイト単位に細かく分割してセルに収容するだけなので手間がかかりません。しかし,それ以外のWANインタフェースは,相手側とIPアドレスを交換するプロトコルである「PPPv6」のプロトコル・スタックを必要とします(図4)。

図4●ルーターが処理するプロトコルの階層構造
図4●ルーターが処理するプロトコルの階層構造

 この頃,KAMEプロジェクトでもPPPv6の実装が始まっていましたが,残念ながらこのコードは利用できませんでした。PPPは仕様としてIPv4とIPv6の処理が密接に結びついていて,プロトコル・スタックとしての独立性が低いため,仮にKAMEのPPPを実装しようとすると,すでにGR2000に搭載されていたIPv4用PPPもKAMEをベースに書き換えなければならなくなるからです。こうした理由により,GR2000のPPPv6は,既存のGR2000 PPPv4のコードを拡張して対応することになりました。

■NDPをどこに実装するのがよいのか

 次に,「NDP」をどこに実装するのかが議論になりました。NDPとは,IPv6アドレスとイーサネットのMACアドレスを対応付るためのプロトコルです。IPv4の「ARP」に相当する重要なプロトコルです。

 フェーズ1ではKAMEのソフトウエアをそのままコントロール・エンジンに移植していたので,NDPもコントロール・エンジン上で稼働していました。しかし,本格的な製品化に向けて,NDPの実装部分について改めて議論になったのです。というのも,GR2000の場合,IPv4でNDPと同等の働きをするARPのソフトウエアは転送エンジン側のCPUに実装されているからです。

 ルーターの場合,インタフェースごとに異なるIPアドレスが設定されます。そのため,実際にあて先を指定するMACアドレスとIPアドレスの対応表である「ARPテーブル」は転送エンジンごとに持てばよく,他の転送エンジンとデータを共有する必要はありません。分散処理やデータ量の観点からも,ARPテーブルは各転送エンジンに分散して管理する方が望ましいのです。

 IPv4の手法をIPv6でも踏襲するならば,NDPも同じく転送エンジン側のCPUに実装するのが筋です。しかしながら,NDPはIPv6の基本スペックの中でも仕様通りにプログラミングするのが難しい機能の一つなのです(例えば,規格を決めたRFCのサイズで比較すると,NDPのRFC文書のサイズはARPのRFCに比べて約10倍になります)。

 ARPは問い合わせパケットに返事するだけの単純なプロトコルですが,NDPは状態(ステート)を管理し,ステートによって送信するパケットが変わるなど複雑な動きをします。

 こうした特徴を持つNDPを転送エンジン側のCPUで実現することには,二つのデメリットがあります。それは,(1) 実装が困難でバグの温床になりやすい,(2) KAMEソフトウエアで実現されてるものを再実装するので,いわゆる「車輪の再発見」である――という点です。

 こうしたメリットとデメリットをめぐって議論は紛糾したのですが,最終的に,フェーズ1と同じくKAMEソフトウエアをそのまま使って,コントロール・エンジン側でNDPを処理することにしました。

 本コラムを執筆しながら当時の決定を改めて振り返ってみたのですが,長期的な視点で見てもこれは正しい選択だったと思います。後に,ルーターに続いてIPv6対応のレイヤー3スイッチを製品化したときに,この構成をそのまま活用できたからです。レイヤー3スイッチでもルーターと同様の分散アーキテクチャを採用しました。レイヤー3スイッチがルーターと異なる点は,VLANの概念があることです。VLANでは,異なる転送エンジンに搭載されているインタフェースで一つのサブネットを構築することになります。このため,ARPテーブルもNDPテーブルも,すべての転送エンジンで共有しなければなりません(図5)。つまり,レイヤー3スイッチでは,転送エンジンごとにテーブルを分けることによるメリットがまったくないのです。

図5●NDP機能に関するルーターとレイヤー3スイッチの差
図5●NDP機能に関するルーターとレイヤー3スイッチの差

■IPv6用ルーティング・ソフトはIPv4と別に実装

 話をGR2000のフェーズ2の時点に戻しましょう。フェーズ2でIPv6を実装する際の最後の議論ポイントは,OSPFやBGPといったルーティング・プロトコルを扱うルーティング・ソフトをどのように実装するかという点でした。ルーティング・ソフトはルーターの心臓部とも言えるソフトで,フェーズ1ではIPv4用とIPv6用で独立に実装していました。フェーズ2では,これを統合するかどうかが議論になったのです。

 前述のPPPと異なり,ルーティング・プロトコルは,IPv4およびIPv6と密接に関係しているものではないので,IPv4とIPv6で別々に実装しても,統合して実装しても,問題はありません。

 ルーティング・プロトコルをIPv4とIPv6で別々に実装することのメリットは,相互の影響を最小に抑えられることです。バグのないソフトウエアはないとよく言われますが,ルーティング・ソフトはその最たるものです。実装を始めてから安定して動くようになるまでには,長い時間がかかります。当時,すでにIPv4のルーティング・ソフトは安定期に入っていました。このソフトに,IPv6のルーティング・ソフトを統合するということは,非常にリスキーです。

 IPv6を利用するユーザーは,顧客全体から見れば少数です。大半はIPv4だけを使うユーザーです。IPv6対応のGR2000を導入してIPv4しか使っていないユーザーが,使ってもいないIPv6のルーティング・ソフトのバグで被害を被るのは避けなければいけません。直接のトラブルもさることながら,このトラブルによってIPv4ユーザーがIPv6に悪印象を持ってしまうのは,今後のためにもなりません。

 運用面から見ても別々に実装することのメリットがあります。IPv6のルーティング・ソフトが誤動作しても,IPv4のルーティング・ソフトは正常に動いているので,例えばIPv4ネットワークを介してリモートからログインしてトラブル・シューティングできるといった点です。

 逆に,別々に実装することのデメリットは二つあります。それは,(1) 二つのルーティング・ソフトが動作するため,オーバーヘッドが大きくなるという問題と,(2) IPv4とIPv6が密接に結びつくプロトコルが実装できない――という点です。ただし,前者はフェーズ1の成果として,性能を落とすことなく実装できる見通しができたので,問題ないレベルであることがわかっていました。後者は,例えば,IPv4のBGPでIPv6の経路情報を流すといった機能が実装できないことになります。

 こうしたメリットとデメリットを比較検討した結果,統合しなければ実現できない機能があることは懸念事項として残っていましたが,私たちが出した結論は「統合を見送る」というものでした。現状ではまだこうした機能のニーズが顕著に見られていません。結果論になりますが,IPv4とIPv6でルータリング・ソフトを統合しなかったことは大きな問題にはなりませんでした。

 こうして製品版のIPv6対応GR2000が誕生しました。製品の出荷は,2001年2月にスタートしました。

 後日談ですが,最終的に二つのルーティング・ソフトが統合されたのは2003年になってからでした。これは,欧州の通信事業者で使われている「IS-IS」というルーティング・プロトコルへの対応と同じタイミングです。IS-ISは,トポロジの情報をIPv4とIPv6で共有するので,両者の関係が密になります。IS-ISに対応するには,両者を統合する必要があったのです。また,IPv6のルーティング・ソフトが安定してきたのも統合に踏み切った理由でした。

林 剛久(はやし たけひさ) アラクサラネットワークスCTO

角川 宗近(すみかわ むねちか) アラクサラネットワークス 先端技術企画部

>>【1】を読む 

>>【3】を読む