山本和彦
IIJ 技術研究所
BSD Magazine No. 18 (2003/12)
今回は、IPv6 の標準化に関して報告します。
カーネルとユーザプロセスの API(Application Program Interface) は、ソケットです。 IPv6 では、このソケットに関する仕様が 2 つの RFC で規定されています。
一つは、よく利用されるソケットの使用方法を定めた Basic API で、 RFC 2133、2553 を経て、現在は RFC3493 となっています。
もう一つは、raw ソケットや拡張ヘッダに関する仕様を定めた Advanced API です。 この仕様を利用する代表的なコマンドには、"ping6" や "traceroute6" があります。
Advanced API の初版は RFC 2292 であり、 これを改訂するための Internet Draft (以下、ドラフトと略記)は長い間 2292bis という名前で知られていました。
両方の API に対して、 仕様を分りやすくすることに多大な貢献をしたのは、 著者の一人である W. Richard Stevens 氏でしょう。 そう、TCP/IP Illustrated など簡明で詳細な解説で著名なあの方です。
残念ながら Stevens 氏は他界されました。 これは、UNIX やインターネット業界にとっての大きな損失だと思います。
RFC 2292 の改訂作業は東芝の神明さんらに引き継がれ、 今年 5 月に RFC 3542 となって公開されました。
KAME プロジェクトには、RFC になっていない仕様に基づいた実装は、 BSD 本家のソースツリーにマージしないというポリシーを持っています。 なぜなら、ドラフトの内容は頻繁に変るので、 それに基づいたコードをマージすると、ユーザを混乱させるからです。
2292bis がようやく RFC 3542 となったので、KAME プロジェクトでは、 新 Advanced API の実装を本家にマージする作業を開始しました。
RFC 2292 には存在せず、 RFC 3542 で新たに定義された機能を利用しているアプリケーションとしては、 BIND が挙げられます。 BIND は、コンパイルする環境に「送信する IP パケットの大きさを最小にする機能」があれば、 利用するように実装されています。 将来、IPv6 やDNSSEC の普及によって DNS パケットのサイズが大きくなると、 これは重要な意味を持ちます。
KAME プロジェクトの実装が本家にマージされ、 新Advanced API をサポートしたカーネルが普及すれば、 こういった機能が使われていくことになるでしょう。
家庭ネットワークを ADSL などを使ってインターネット につなげることを考えてみて下さい。
IPv4 では、ホームルータは PPP などを利用し、 ISP から IPv4 グローバル・アドレスを 1 つ割り当ててもらいます。 またホームルータは、ホームネットワークに対し DHCP を使ってプライベート・アドレスを割り当てるのが一般的です。
IPv6 では、ホームルータが ISP から IPv6 のグローバル・アドレス「空間」を割り当ててもらいます。 そして、その一部を家庭ネットワークに再割り当てします。
IPv6 アドレス空間は IPv6 アドレスの先頭(prefix)によって指定されるので、 ISP とホームルータ間のプロトコルは「Prefix Delegation(PD)」と呼ばれています。
PD としては、ルータ通知(RA)や PPP を使う方法も考えられますが、 現在有力視されているのは DHCPv6 に基づく方法です。
対向ネットワーク上で DHCPv6 を使うのは、 少しおかしな感じを受けるかもしれません。 実は DHCPv6 は、状態遷移がしっかりと規定されていること、 そしてオプションを規定するだけで容易に拡張できることといった特徴を備えています。
DHCPv6 の策定には長い時間がかかりましたが、 ようやくRFC 3315 として公開されました。 また、PD 用のDHCPv6 のオプションを定めた仕様は、 すべての作業が終わり、RFC として発行されるのを待つばかりとなっています。
DHCPv6 に基づいた PD は、多くのベンダーで実装され、 相互接続性が検証されています。 前回このコーナーでは、 IPv6 ShowCase のアクセス・ゾーンでこれらの実装を展示したことをお伝えしました。
残念ながら、NTT 東に代表される大手 ADSL キャリアは、 運用している機器に IPv6 対応のファームをインストールすることに対し及び腰であるため、 多くのユーザが PD を利用できない状況にあります。
このような環境では、 ユーザは ISP から IPv6 アドレス空間を紙面で割り当ててもらい、 自分で IPv6 over IPv4 トンネルを設定するしかありません。 これでは、IPv6 のウリの一つであるプラグ＆プレイ機能が台無しで す。
現在のところ、 PD が利用できる商用サービスは、ACCA + OCN の組合わせのみです。 OCN で利用されている PD は、 古いドラフトに基づいており、もうすぐ発行されるであろう RFC の仕様とは異なっています。
OCN によれば、最終的には新しい仕様に移行することを目指すが、 当面はユーザに迷惑がかからないように、 古い仕様と新しい仕様を同時にサポートすることを検討しているそうです。
IPv4 のプライベート・アドレスに相当する IPv6 のサイトローカル・アドレスが、 「deprecated」(仕様上規定されているが、利用しない)になりました。 事実上、廃止されたと思って頂いて構いません。
サイトローカル・アドレスの本来の目的は、以下の 2 つ です。
(1) を実現するためには、何もサイトローカル・アドレスを使う必要はありません。 たとえば、グローバル・アドレスの一部を「自由に使えるアドレス」と定義しておく方法も考えられます。
(2) に関しては、そもそも ISP の乗り換えがどれくらいの頻度で起るかによって重要性は変ります。 一般的には、頻度は低いと言えるので、深刻な問題とはなりにくいでしょう。 また、ISP を乗り換える際は、一定期間、 古いISP と新しい ISP に「二股をかける」はずです。 この場合、古いアドレスが利用されなくなるのを確認してから、 古い ISP との接続を切れば、サイト内での通信は安定していると言えます。
廃止されたことから分るようにサイトローカル・アドレスは、 いくつかの問題を抱えていますが、それらを大まかに分類すると以下の 2 つになります。
まず、(a) についてですが、IPv6 は NAT のない世界を目指しています。 ですから、NAT の出現は食い止めなければればなりません。
IPv4 では、グローバル・アドレスが足りないためにプライベート・アドレスを利用し、 プライベート・アドレスを使ったネットワークは直接インターネットに接続できないので、NAT が必要でした。
しかしながら、IPv6 では十分なグローバル・アドレスが割り当てられるので、 その意味では NAT は不要です。
(b) は、さまざまな問題を含んでいます。 まず、サイトの定義が曖昧です。サイトとはどう定義されるのでしょうか？ ルータやホストは、複数のサイトに属すことはできるのでしょうか？ できるとしたら、その振る舞いはどう定義されるべきでしょうか？
運用の問題もあります。 サイト内に閉じ込めておかなければならない情報、 たとえば DNS や経路情報が誤って流出すると、 インターネットが不安定にしてしまいます。
また、Mobile IPv6 とサイトローカル・アドレスの組み合わせも頭の痛い問題です。 移動元も移動先もサイトローカル・アドレスを利用しているとすると、 移動ホストから見るとサイトが混ざってしまったように見え、 正常に通信することは困難です。
以上のような理由からサイトローカル・アドレスは、 なくせるなら廃止する方がよいことは分って頂けたと思います。 しかしながら、サイトローカル・アドレス、あるいは NAT がなくなると、 実現できなくなることがあるという不安もあるでしょう。 その代表がセキュリティに関する懸念です。
サイトローカル・アドレスに関する議論は、 広範囲で深いため限られた紙面では、 すべてを網羅することはできません。
しかしながらご理解頂きたいのは、 サイトローカル・アドレスはとても長い議論の末に廃止され、 復活はありえないことです。 議論を蒸し返すのは、時間の無駄ですのでお止め下さい。 それよりも、サイトローカル・アドレスはないという前提条件での実装や運用について議論していきましょう。