KAME プロジェクト便り
山本和彦
IIJ 技術研究所
BSD Magazine No. 16 (2003/6)
第16回 第三期前半の自己評価
KAME プロジェクトは、活動の単位を 2 年で一期としており、
今年度は第三期の後半となります。
昨年度、第三期が始まるにあたり、
KAME プロジェクトでは第三期のロードマップを定めました。
すなわち、前半の昨年度はこれまでと同様の開発を進める。
後半の今年度は、それぞれの BSD が IPv6 などの実装を独自に保守できる体制を作るという内容です。
一年前にここで説明した昨年度の実装項目は、ほぼ達成できました。
この成果を踏まえて、
KAME プロジェクトは 4 月に今年度の具体的なロードマップを以下のように定めました。
マージする項目:
- Advanced API (RFC 2292 を改訂する RFC の発行待ち)
- 始点、終点アドレスの選択 (RFC 3484)
- ip6_mroute.c のコードの洗練化
- Mobile IPv6 の固定ノード機能 (以下を参照)
- IGMPv3 (以下の SSM を参照)
以下、昨年度の実装項目が現在どういう状況にあるかを説明します。
- SSM (Source Specific Multicast)
- IPv4 用の SSM を実現する IGMPv3 を定めた仕様は RFC3376 として発行されている。
しかしながら、IGMPv3 の API はドラフト段階であり、RFC になるのを待つ必要がある。
IPv6 用の SSM を実現する MLDv2 はドラフト段階であり、まだマージできる状況ではない。
- mDNS
- libc に組み込むか、
デーモンとして実現するかといった実装の枠組みを再考する必要がある。
また、仕様が RFC として発行されるのを待つ必要がある。
- ICMPv6 名前解決
- RFC の発行待ち。mDNS と同様に、実装の枠組みを再考する必要がある。
- スコープを考慮した経路制御
- 残された作業は、経路表にスコープ対応コードを導入することである。
しかし、サイトローカルが削除はされないものの利用されなくなりそうな現在、
この大がかりな作業に見合う結果が得られるか疑わしい。
またこの変更は、いくつかのコマンドに対し互換性の問題を発生させる。
よって、各 BSD のコミュニティと話し合う必要がある。
作業は継続し、成果はスナップショット
として公開する。
- X Window System
- 我々は、XFree86 を IPv6 に対応させるパッチを作成した。
しかし、X.org は、独自に IPv6 対応のコードを実装し、
すでに公開されている。そこで、我々のパッチは参考程度に公開されているが、
X.org へマージすることはない。
- VRRP(Virtual Router Redundancy Protocol)
- IPv6 用の VRRP は実装済であるが、需要が低いようなので、
マージする予定はない。
- Mobile IPv6
- Mobile IPv6 の固定ノードの機能(経路の最適化)は、
各 BSD へマージするべきである。RFC の発行を待つ必要がある。
移動ノードとホーム・エージェントのマージは、コードの洗練化のために保留。
- IPsec
- 暗号ペイロード(v3)と認証ヘッダの改訂版は、
現在ドラフト段階。RFC が発行された際には、追従する必要がある。
- KMP (Key Management Protocol)
- 単純明快な鍵交換プロトコルになると予想されていた KMP を実装し、
マージする予定を立てていた。
その一つである IKEv2 は RFC になる最終段階であるが、
我々の期待とは違って、複雑である。我々は、IKEv2 を実装し、
スナップショットして提供する予定であるが、マージすることはない。
- ルータ選択
- 我々としては、ドラフトが定める機能のうち、
「ルータの優先順位」をマージしたいと考えている。
しかし、ドラフトには「経路情報オプション」や「ルータのロードバランス」といった他の機能も含まれており、標準化の難航が予想される。
- ISATAP
- 標準化が混乱しているために、マージは保留。
- DNS サーバ探索
- RFC の発行待ち。
- DHCPv6
- 実装は枯れており、相互接続性の検証も十分である。
RFC が発行されれば、マージする予定。
- SCTP(Stream Control Transmission Protocol)
- 新しいトランスポート・プロトコルである SCTP のコードが提供された。
マージのためには、試験が必要。