KAMEプロジェクトの歴史と成果

山本和彦、IIJ 技術研究所
2005年11月

KAME プロジェクトは、その目的を達成し、2006年3月をもって8年間の活動を完了する。我々が実装した IPv6 などのコードは、それぞれの BSD コミュニティに引き継がれ、発展していくだろう。今回は、ipv6style.jp の紙面をお借りして、KAME プロジェクトの設立の趣旨、活動内容、成果などについてまとめる。

KAME プロジェクト以前

KAME プロジェクトの設立は1998年だが、物語は1992年から始めるのがよいだろう。

1992年6月に神戸で開催された INET ’92 で、IPv4 のクラス B アドレスが枯渇すると報告され、次世代の IP である IPng の模索が始まった。さまざまな方式が提案され、2 年間の競合の後、1994年7月にトロントで開催された第30回IETF で、最終的に SIPP が IPng に選ばれた。バージョンには 6 が与えられ、以降 IPv6 の名で知られることになる。

案が一本化された IPv6 は、それまで競争関係にあったエンジニアも協力し、標準化作業が進められ、1995年12月に基本仕様を定めた RFC 1883 が発行された。

その4ヶ月前、WIDE プロジェクトのボードメンバーは、福岡で勉強会を開いた。テーマは、IETF で話題となっている IPv6。当時、村井さんの学生であった慶應義塾大学(以降、慶応)の南さんは、すでに IPv6 の実装を進めていた。また、WIDE プロジェクトに参加している NEC、日立、富士通などの企業も実装に取り組んでいた。

そのころの IPv6 にとって最も大切なのは、仕様に誤りがないか検証することだった。これには、複数の独立した実装を用い、互いに通信できるかという相互接続性を検証する必要がある。

単純に相互接続性の検査をするなら、南さんの実装と企業の実装でも十分だっただろう。しかしながら、企業の実装はソースコードを公開していない。IPv6の研究を進める上では、複数の実装方式を比較検討するために、ソースコードを気兼ねなく参照できる実装がもう一つ必要だと判断された。そこで当時、奈良先端科学技術大学院大学(以下、奈良先端大)の助手をしていた私が、勉強会の宿題として、もう一つの実装を請け負うことになった。

奈良先端大で実装を担当したのは、当時私の学生だった島さんである。この実装は、奈良にある通称「あじさい寺」にちなんで、「Hydrangea」と名付けられた。慶応の実装も奈良先端大の実装も、共に BSD/OS で開発されていた。当時から FreeBSD や NetBSD も存在していたが、BSD/OS が一番よくノート PC をサポートしていたからである。

WIDE プロジェクトは、9月に IPv6 に関する分科会を作り、IPv6 について議論することで理解や経験を深めていった。そして、12月には相互接続実験のため、慶応の湘南藤沢キャンパスに集った。実際に異なる実装とつないでみると、新たなバグが発見されることが多く、また仕様に対する間違った解釈に気づくこともある。

このように同じグループ内で複数の実装を持っていることは、何よりの強みであった。以降、WIDE プロジェクトの IPv6 分科会は、定期的に相互接続実験を開催することになる。

翌年2月には、ニューハンプシャー大学に、慶応、奈良先端大、日立のメンバーで乗り込み、仕様適合試験を受けた。摂氏-18度と極めて寒かったこと、そして旬のメインロブスターが美味しかったことをよく覚えている。

6月には、WIDE プロジェクトのバックボーンに多重化装置を入れ、T1 の回線から 64 Kbps を切り出して、IPv6 用の専用線とし、IPv6 のバックボーンを構築した。これは、単一ネットワークでの相互接続実験から、複数ネットワーク間での経路制御の検証へと段階が進んだことを意味する。Hydrangea 上の RIPngによる経路制御ソフトウェアは、東京大学の加藤さんがあっという間に実装した。

同年6月、トンネルを用いてカリフォルニアの Cisco と結び、世界的な 6boneの初期メンバーとなった。これには、島さんの後を引き継いでいた角川さんが大きな役割を果たした。

当時のよきライバルは、NetBSD/FreeBSD を対象にしていた INRIA、そして 4つのBSDを対象にしていた NRL である。INRIA はいち早くコードを公開していた。

一方で、我々は Hydrangea の公開には慎重だった。よい品質になるまでリリースしたくないという思いも理由の一つではあるが、一番の問題は対象が商用のBSD/OS だったことだ。単純にリリースしたのでは、BSD/OS のライセンスに抵触するかもしれない。そこで、開発元の BSDI と交渉を続けていた。

1997年3月には、萩野さんが Hydrangea を FreeBSD へ移植した。同年、9月には BSDI が NRL のコードを採用したことが発覚。我々は、FreeBSD への乗り換えを余儀なくされた。

結局、Hydrangea は一般にリリースされることなく、WIDE プロジェクト内の公開にとどまった。これは、後ろ向きなことではなく、大きな飛躍への一歩であったことがすぐに分かるだろう。

第40回のIETFは、1997年12月にワシントン DC で開催された。IETF の朝食は、ホテルのホワイエにビュフェスタイルで用意される。私がモーニングコーヒーを飲んでいると、日立の新さん(現在はアラクサラネットワークス)や東芝の江崎さん(現在は東京大学)らが集まってきた。

WIDE プロジェクト内に複数の実装を持つことは、昔は強みであったが、その時点では足枷になっていると感じていた。IPv6 に仕様に致命的な欠点がないと確信できる今、同じことをバラバラにやっているのは非効率である。そのことを率直に切り出すと、その場にいた人は同意し、実装の努力を一本化できないか模索することになった。

同日、この件を相談するため、同じホテルに泊まっていた村井さんの部屋のドアを叩いた。そのドアの向こうには、新しい世界が待っている、そんな気がした。

KAME プロジェクトの設立

村井さんの賛成の下、今では「兄」と呼ばれる人たちが、力の結集に向けて急ピッチで動き出した。

本来競合関係にある東芝、日立、NEC、富士通などの企業が共同で IPv6 を実装するのである。しかも、成果物はフリーで公開される。これまでの日本では実現しそうにない大胆な目標が掲げられたのだ。

斬新なプロジェクトに企業を巻き込む以上、このプロジェクトは成功させなければならない。成功のためには各社のエースを派遣して頂くことが不可欠である。そこで、参加して頂くプログラマの条件は、IPv6 分科会で活躍していることになった。「まず人ありき」なのである。

エースの選定は私に任された。それは、私がテクニカルリーダに選ばれたからである。このころ私は腹をくくり、奈良先端大から東京のインターネットイニシアティブへ転職することを決めていた。

エースの選定後は、その人が所属している会社に賛同して頂き、派遣して頂く必要がある。「フリーな参照コードの作成による世界への貢献と IPv6 の普及」という大きな夢を鞄につめこんで、村井さんは各社をまわった。

各社から派遣され実際にコードを書く人を 「core」、その上司を「パパ」、そして中間に立ってあれこれと労して頂く人を「兄」と呼ぶことが、いつの間にか定着していた。

core が実装に専念するためには、会社の雑用に束縛されない時間を確約する必要がある。そこで、3 日ルールが定められた。オフィスは刈込に村井さんが借りている建物で、都心から離れた慶応湘南藤沢キャンパス近くに位置する。一週間の内、3日間はこのオフィスへ来て実装に専念するのだ。

KAME プロジェクトの発足は、1998年4月である。当然、正式な契約が各企業とWIDE プロジェクトの間で締結された。今振り返ると、このような準備がたったの4ヶ月間で実行されたのは驚異と言う他ない。

創設時の参加企業の一覧を以下に示す。

すでに語り尽くされた感があるが、名前の由来にも触れておこう。準備期間中のコードネームは、「かめプロジェクト」だった。

その小さな事件が起こったのは、1997年10月のことだ。WIDE IPv6 分科会の相互接続実験が北陸先端科学技術大学院大学で開催されていた。Hydrangea のバグ取りをしていた萩野さんは、原因が分からず、とうとう傍にあったカメのぬいぐるみに抱きつき、「ああ、かめさん助けて」と叫んだのだ。これ以降、「かめ」という言葉が仲間内で流行となっていた。

1998年3月の準備ミーティングで、正式な名前を決めることになった。私は外国の方が発音できない「KAME」には反対し、Hydrangea を短縮した「Hydra」を提案していた。しかしながら、最終的には「KAME」と決まった。

すなわち、文字通り動物のカメに由来しているのである。海ガメ(turtle)なのか、陸ガメ(tortoise)なのか、公式な見解はない。

活動の歩み

KAME プロジェクトの目標は、「IPv6、IPsec および高度なネットワークプロトコルに対する参照コードの提供」である。

インターネットの歴史を紐解けば、BSD の貢献が光り輝いている。カリフォルニア州立大学バークレー校の CSRG が提供した BSD は、IPv4 の参照コードとなった。このコードを見て学び、製品のコードを書いたエンジニアも多いだろう。W. Richard Stevens 氏が執筆した BSD コードの解説本「TCP/IPIllustrated Vol.II」は、エンジニアのバイブルとなっている。

KAME プロジェクトは、BSD が IPv4 の普及に果たしたのと同じ役割を IPv6 に対して果たしたいと志したのだ。

1998年当時、4.4BSD から派生した BSD は 4 つあった。すなわち、商用のBSD/OS、フリーの FreeBSD、NetBSD、および OpenBSD である。大変ではあるが、KAME プロジェクトは、すべての BSD に対しコードを提供することにした。

我々が提供するコードには、次の3つの形態があった。

snap
その時点での実装のスナップショット。最新の実装であるが故、不安定であるかもしれない。毎週、月曜日にリリース。
stable
不安定なコードを削除し、安定性を確かめたコード。できるかぎり奇数月にリリース。
release
KAME プロジェクトの区切りにリリースする stable をこう呼んだ。利用者にとっては stable と変わりない。

不安定かもしれない snap を提供する理由は、Hydrangea の反省に基づいている。Hydrangea ではコードの品質にこだわったがために、結局一般にリリースされることなく、世界的な認知度は低いままに終わった。

そこで、コードの品質に改善の余地がある時点でも、恥ずかしがらずに公開すると決めたのだ。もちろん悪印象を与える可能性もあるが、よい効果をもたらす方が大きい。まず、我々の積極的な活動が、外から見えると言うこと。そして、恥ずかしさを消すために、急いでコードを改良するという動機を与えることである。

コードの一本化の作業は、Hydrangea をベースに、各社の優れた部分をマージする形で進められた。共同作業のツールとしては、CVS を使う。最初にコードのスタイルを定めた。あとは自分の実装した部分を各自の判断でマージしていく。マージの段階で衝突が起こった場合は、後から衝突を起こした人の責任で直す。つまり、マージ作業は早いもの勝ちだった。

core が刈込オフィスに泊まり込むことは日常茶飯事であり、5月には最初のsnap、6月には最初の stable をリリースすることができた。snap を毎週リリースすることは、これまで絶え間なく続けられている。マージの作業が完了した後も、同様の開発スタイルで、最新の仕様が実装されていった。

我々は仕様適合試験や相互接続試験があるたびに参加していた。また、KAME プロジェクトが提供するコードの質を客観的に示すために、横河電機の岡部さんや横河ディジタルコンピュータ宮田さん(現在は横河電機)らが中心となって、TAHI プロジェクトを発足させた。TAHI プロジェクトは、その地道な活動が認められ、今では提供している検証ツールが世界標準となった感がある。

我々の願いは 4 つの BSD に、同じ品質のコードを提供することだった。同じ4.4 BSD から派生したにも関わらず、各 BSD のネットワークコードの実装は大幅に異なる。我々が実装する IPv6 やその他のコードは、新しく書くのであるから、大枠としては共通化できる。ただ、各 OS の差を吸収するために、複雑な場合分けがコードの中にたくさん埋め込まれることになった。

さらに、各 BSD がバージョンアップすれば、古いバージョンと新しいバージョンの両方をサポートしなければならない。一時は、4 OS、10 バージョンを管理していることもあった。

こういった努力の甲斐あって、KAME プロジェクトは次第に認められるようになり、1999 年の夏頃までには、すべての BSD で採用されることが決まっていた。これには、NRL や INRIA では資金や人手の問題から、開発の継続が困難になったことも影響している。

BSD/OS からは NRL の IPv6 コードが削除され、KAME のコードで置き換えられた。フリーの BSD は、KAME のコードをそのまま採用した。ただし、OpenBSDは IPsec のコードだけは独自に実装している。BSD の制覇が成ったのは、2000年末のこだ。

表: 各 BSD に KAME のコードがマージされた日時とそのときの BSD のバージョン

OS名 マージの日付
BSD/OS 4.2 2000年11月29日
FreeBSD 4.0 2000年3月14日
NetBSD 1.5 2000年12月6日
OpenBSD 2.8 2000年12月1日

KAME の成果は、日立のルータ/スイッチ GR/GSシリーズ、富士通のルータ GeoStream R900シリーズ/GeoStream Si-Rシリーズ、IIJ のルータ SEIL、Juniper のルータ、Extreme のスイッチ、アラクサラネットワークスのルータ/スイッチ、CEC カメラサーバ、リコーのプリンタなどに採用された。また MacOS X は、KAME をマージした FreeBSD を基にしている。読者の皆さんが KAME のコードに触りたいなら、MacOS X を利用してみるとよいだろう。

KAME プロジェクトは IETF でも認められ、発言力が増していった。萩野さんが、IETF v6ops の議長と IAB メンバーに選出されたことは、それを象徴している。

また、我々の活動は日本政府にも認知され、2002年10月には平成14年情報化促進貢献企業等表彰 (総務大臣表彰)を受賞した。表彰理由は以下の通りである。

次世代インターネットプロトコル IPv6 の研究開発及び成果の公開を 通じて、IPv6 の研究開発、標準化及び実用化を国際的に先導し、 IPv6 の普及に多大な貢献をした。

さらに、村井さんは IPv6 の開発と普及に対する貢献が認められ Postel Award を受賞した。2005年8月の第63回 IETF パリでのことだ。

このように KAME プロジェクトは、参照コードの提供という目的を十二分に果たした。手前みその感があるが、その集大成として、我々のコードに対する解説本

(詳細は成果一覧参照)が、core メンバである神明さんと島さんらの執筆により、近日出版される。この本が IPv6 について学びたいと思うエンジニアの道しるべとなることを願う。

それぞれのコンポーネント

IPv6

Hydrangea を基に各社のコードをマージ。拡張ヘッダのコードは、東芝からの貢献が大きい。マージ完了後は、RFC や Internet-Draft を積極的に実装した。実装の範囲は、基本仕様、自動設定機能、トンネル機能、経路制御機能、スコープ付きアドレス、API、DHCPv6など多岐に渡る。これらを活発に実装したのは、萩野さんと神明さんである。

BSD に組み込まれた後は、新しい悩みが生まれた。それは、Internet-Draft の改訂で仕様が大幅に変化すると、BSD ユーザを混乱させてしまうことだ。そこで、原則として、Internet-Draft の段階の仕様を実装したものは snap で公開し、RFC に対する実装のみを BSD へ還元する方針をとった。

IPsec

IPsec コードは、カーネル空間での IPsec そのものの実装とユーザ空間での鍵交換ソフトウェアに大別できる。我々の IPv4 および IPv6 用の IPsec は、FreeBSD や NetBSD にマージされている。残念ながら将来我々のコードは、暗号ハードウェアとの相性がよい OpenBSD 由来のコードで置き換えられるだろう。しかしながら、仕様をいち早く実装し、誰でも自由に使え、安定して動作するIPsecスタックを提供できたことの意義は大きいと言える。

鍵交換ソフトウェアの名前は racoon である。racoon バージョン 1 は、BSD のみならず Linux でも採用された。現在、racoon バージョン 1 は、作者である坂根さんの手を離れ、IPsec-Tools として sourceforge.net で保守されている。

一方、坂根さんは、現在 racoon バージョン 2 の実装に専念している。racoon バージョン 2 は複数のメンバーが協力して開発している。ポリシーを管理する部分がユーザ空間で実装されていることと、IKE バージョン 2 とKINK の両方をサポートしていることが大きな特徴である。IKE バージョン 2は、相互接続実験で良好な結果をだした。KINK は誰でも自由に使える実装としては世界初である。Linux を最初からサポートしていることもバージョン 1 との違いである。現在、より仕様に忠実となるように、また Mobile IPv6 でも利用可能となるように開発を進めている。

Mobile IPv6

最初は、Ericsson がローダブルモジュールとして開発した Mobile IPv6 のコードを snap にマージしていた。島さんが core となってからは、独自のコードをカーネル空間で開発し始めた。Mobile IPv6 の大きな仕様変更が発生した頃に、第三期から百瀬さんが core に参加し、島さんとともに Mobile IPv6 のコードの開発、維持に従事した。残念ながら、仕様が RFC となるまでに長い時間がかかったため、snap で提供されたのみだった。

現在、慶応大学で独自に Mobile IPv6 の実装を進めていた植原さん、湧川さん、および三屋さんと力を結集して、SHISA というコードを実装している。これは、古いコードを置き換えるかたちで snap として公開されている。

SHISA では、移動に関する情報をやりとりする処理をカーネル空間からユーザ空間へ追い出した。この処理は仕様でしばしば変更されてきたが、さらなる変更があったとしても SHISA の方式ではユーザ空間のプログラムを変更するだけでよい。このため、BSD カーネルへのマージに大きく影響することがなくなった。SHISA は、Mobile IPv6に加え、後述の特許問題を解決した NEMO の実装も含む形で snap として提供されている。現在、SHISA を BSD へマージすることが検討されている。

マルチキャスト

IPv4 ではマルチキャスト中継機能が、OS 毎に独立に実装されていた。そのため OS によってサポート状況が異なったり、マルチキャスト対応 OS 間でもAPI が異なったりしていた。こうした統一性のなさが、IPv4 マルチキャスト普及の足枷の一因になっていた。

KAME プロジェクトでは神明さんが中心となり、IPv6マルチキャスト中継機能および経路制御ソフトウェアをすべての BSD に共通な形で実装し、すべてのBSDへマージした。このため、どのBSD でも同じ IPv6 マルチキャスト経路制御ソフトウェアを使用できる。これは IPv6 マルチキャスト普及にとって、大きな前進であった。

なお KAME プロジェクトの開発したIPv6 マルチキャスト経路制御ソフトウェアは、現在 SSM 機能や Linux のサポートも含めた形で、sourceforge.net のmcast-tools プロジェクトにて保守されている。

さらに KAME プロジェクトでは、INRIA の朝枝氏(現在は慶応)の NetBSD 向けIGMPv3 ホスト実装を基に、すべての BSD 向けの IGMPv3/MLDv2 ホスト機能を鈴木さんが実装した。今後この機能を BSD へマージする予定である。

特許問題

IETF のポリシーとしては、 プロトコルのある部分が特許に触れていても、 特許権保持者がその技術を誰にでも公平にライセンスするのであれば、そのプロトコルは Proposed Standard になれる。利用料や契約を要求していても構わない。

KAME プロジェクトでは、 特許問題のないプロトコルはもちろんのこと、特許が取得されていても契約なしに無料で利用できるのであれば実装してきた。しかしながら、契約が必要であったり、使用料を払わなければならない場合は、実装しない方針をとっていた。

理由は次の通り。まず、KAME プロジェクトの成果物は無償だから、使用料がかかるのは困る。次に契約についてだが、対象が実装者と利用者の 2 つの場合がある。実装者である KAME プロジェクトに契約が求められる場合、KAME プロジェクトには契約を結ぶ枠組みがない。

また、利用者に契約が求められる場合、KAME プロジェクトでは面倒をみれないし、KAME プロジェクトの成果物に契約を結ぶといった制約が加わることは、我々の望むところではない。そもそも、誰に対して契約を求めているのか明確でない特許もあった。

KAME プロジェクトを悩ました特許問題があるプロトコルは以下の通り。

この方針に対し、ある会社が利益を得るためでなく、訴えられないようにするために取得した特許に対して、あまり過剰に反応するべきでないという意見が内部から出された。また、特許の問題があることを知らずに作成したコードをこのまま捨ててしまうのは、もったいないという意見もあった。

そこで、特許を持つ会社ときちんと交渉し、KAME の実装を提供できるかたちにすることになった。法律に強い慶応の村上さんの協力もあって、NEMO やISATAP の問題が解決され、実装を公開できた。

期ごとの目標と評価

期ごとの目標と自己評価を示す。

第一期

目的は、WIDE プロジェクト内にある複数の IPv6 コード、およびIPsec コードのマージ、および最新仕様への追従であった。

この目標は完全に達成できた。具体的な項目としては、IPv6 (基本仕様、API など)、IPsec、鍵交換ソフトウェア、トランスレータ、各種アプリケーションを IPv6 へ対応させることなど、多岐にわたる。

4つすべての BSD へ採用が決まったことからも分かるように大成功だった。

第二期

第一期と同様に活発な開発活動を継続し、KAME の成果を BSD コミュニティなどにフィードバックすることが目標であった。

4つすべての BSD に KAME の安定しているコードがマージされ、この目標は達成できた。活発な開発活動の成果としては、Mobile IPv6 の実装が開始されたこと、マルチキャストに関するコードの開発などが挙げられる。KAME のコードを製品に組み込む企業も出現した。このような面は大成功だった。

一方で、KAME プロジェクトが名声を得るにつれ、講演、チュートリアル、イベントなどへ駆り出されることが多くなり、3日ルールが機能しなくなっていたことは反省点の一つである。

第三期

2002年度の目標は、新たなプロトコルの実装やプロトコルの更新への追随。2003年度のそれは、第3期の終了後、各 BSD がそれぞれ独自にIPv6、IPsec、Mobile IPv6 を保守できるよう技術移転すること。また引き続き新たなプロトコルの実装し、プロトコルの更新へ追随することであった。

core が忙しくなったため、藤沢の刈込オフィスに集まるのは難しくなり、第二期末にはオフィスを都心に近い慶応新川崎タウンキャンパスに移していた。

新たなプロトコルの実装やプロトコルの更新への追随は満足がいく形で達成できた。しかし、BSDあるいは他のアプリケーション開発者が、まったく独自に保守を続けられるという理想の状態を作り出せたとは言いがたい。実際、主要な技術項目のうち、一部はまだBSDへのマージを完了していなかったし、BSD側における新しい活動においても、しばしば core からの助言を求められていた。

この原因となった主な問題点は、IETF において仕様の策定が遅れRFC とならなかった機能、プロトコルが多いこと、そして SSM、ISATAP、VRRP に関しては特許やライセンスの問題が浮上しマージできなかったことである。

第四期

BSD コミュニティが独自にコードを保守できる体制作りと、KAME プロジェクトの完了に向けて、第四期は開始された。ただし、2004年度は新たな機能の実装も継続する。

特許問題に向き合って、いくつかのプロトコルに対する問題を解決し、BSD コミュニティへ公開できた。また、現在は snap に残されている機能を各 BSD へマージする作業に注力している。

今後の展開

今後 core は、それぞれの興味がある分野で活動していく。IPv6をさらに発展させる応用プロトコルの実装に注力する人もいれば、IPv6活用の場を広げるようなアプリケーション分野に軸足を移す人もいる。もちろん、BSD コミュニティにも深く関わっているので、各 BSD コミュニティの一員として、IPv6 やその他のコードを発展させていくだろう。

成果一覧

KAME プロジェクトに関係するメンバーが、IETF で議論した成果として、発行 された RFC は以下の通り。

KAME プロジェクトに関係するメンバーが、執筆した書籍は以下の通り。

KAME に関する論文は以下の通り。

リンク集

・KAME プロジェクト: http://www.kame.net/

・KAME プロジェクト便り: http://www.mew.org/~kazu/kame/

・WIDE v6 WG の歴史: http://www.v6.wide.ad.jp/Events/

年表

※ 月が不正確かもしれないことを表す