旧 v4 シングルスタックサーバ。 インターネット 旧 v4 ボリュームゾーン サービス資源の ボリュームゾーン インターネット利用者の クライアント 旧 v4 シングルスタック テュアルスタック サーバ クライアント デュアルスタック 6 とは何なのか ! ? 炉 v6 シングルスタックサーバ インターネット 旧 v6 サービス資源 新たに出現する インターネット利用者 新たに出現する クライアント 旧 v6 シングルスタック 図 8 インターネットに接続されるさまざまなサーバとクライアント がら IPv4 アドレスが枯渇した際に、現在の 他の技術と比べれば、 IPv6 がそのネットワー クに取って代わることができるネットワーク であると、コンセンサスを得ているというだ けなのです。 この IPv6 ネットワークはすでに利用され 始め、筆者も一部のネットワークで IPv6 を 利用しています。 IPv4 から IPv6 への移行が、突然起こると いうことは考えられません。また IPv4 アド レスが枯渇しても、 IPv4 を用いたネットワー クが突然なくなるものでもありません。移行 は、現在の IPv4 ネットワークが利用されて いるなかで IPv6 ネットワークが次第に広が りをみせ、そして徐々に IPv4 ネットワーク が縮退していくというような傾向をみせるこ とでしよう。 移行においては、「枯渇点」が大きなター ニングボイントになることはいうまでもあり ません。ですが、枯渇点を中心にその前後で、 IPv4 と IPv6 が混在した混在型インターネッ トが台頭すると考えられます。 ただしこの混在型インターネットは、いく っかの問題を生むと考えられます。 IPv4 と IPv6 は、同じ IP 技術という基本 技術に則って開発されたという意味において は、同様の特性を持ちます。しかしバケット ヘッタか起っように、 IPv4 と IPv6 は基本的 にまったく異なるネットワークとなり、その 間には原則として互換性は存在しません。つ まり混在型インターネットにおいては、その 両者間で通信しようとした場合にその通信を 取り持つ「なにか」が必要になります。そし てこれがいくつかの問題を引き起こすだろう と考えられるわけです。 報告書には、この混在型インターネットの 問題と、必要と思われる対策について細かく こでは混在型ネッ 書かれています。そこで、 トワークの典型的な間題とその対策の考え方 について示しておきます。 まず、混在型インターネットの概念につい て図 8 に示します。混在型ネットワークに おいても、 IPv4 と IPv6 の互換性はありませ んから、概念的に IPv4 と IPv6 の 2 つのイ ンターネットが存在します。インターネット に接続している機器やサーバなどは、 IPv4 のみサポートしているもの、 IPv6 のみサポー トしているもの、そして両者をサポートして いるものの 3 つに分かれます。 IPv4 のみをサポートしているホスト・ネッ UNIX magazine 2006 Summer
6 とは何なのか ! ? = 色はすべて変更 さらに、実際には lPv4 / IPv6 トンネリング / トランスレーション ⑤マルチキャスト 上記とまったく同じ理由で、ビット数を除 けば同じレイヤ 3 のアルゴリズムを使って いる以上、 IPv4 と IPv6 の違いはありません。 ⑥ QoS QoS についても違いはありません。 そのほかの誤解 IPv6 にはそのほかにも奇妙なバラ色の夢 が流布されていますが、その多くは誤解です。 ■ P2P IPv6 による E2E のリーチャビリティが実 現すれば、確かに P2P は容易になります。 しかし、これは F / W を使わない場合の話で あり、 F / W を使うのであれば IPv4 でのポー トフォワーディングと大差はありません。 ■情報家電 情報家電ならば IPv6 の意味があるとは必 ずしもいえません。一番の問題は、情報家電 の定義がはっきりしないことです。 仮に家電同士が P2P 的に通信しあう場合、 IPv6 のほうが望ましい側面はあっても、使 用する物理ネットワークは電灯線か Wi - Fi に なると思われます。そうなると、インターネッ トとは異なるうえ、セキュリティを考慮する とインターネットへの接続はできず、世界規 模での E2E は不可能です。そもそも TCP/IP である必要性すらないため、 IPv6 が「導入」 される可能性はあっても、 IPv4 から「移行」 する必要性は少ないのです。 旧 v4 / IPv6 の互換性、接続性 IPv4 と IPv6 は互換性がなく、アプリケー ションからルータまですべて取り替えになり ます。しかし、それでも IPv4 との接続はで きないのです。このあたりは、当然 IPv6 推 進派も気にしており、トンネリング、トラ ンスレータなどの提案はあるものの、 IPv4 などの設定も入るためもっと複雑 ファイアウォール スイッチングハプ TCP / 旧ドライバ アプリケーション ィーサカード 旧アドレス設定ー ヨ P アドレス設定 炉乃ド CIP アドレス設定、 注 ) ケープルの取り替えは一切不要 図 3 移行に必要な変更点 アドレス不要、アプリケーションの無改造、 IPv4 マシンとの E2E という、 3 つの条件を 同時に満たすことはできません。結局は、世 の中がすべて IPv6 にならない限り、 IPv6 の メリットはないのです。 旧 v6 における最大の問題 IPv6 最大の間題は、互換性のなさからく る移行コストです ( 図 3 ) 。 これだけの変更をするのに、どれほどのコ ストがかかるのでしようか。いつも痛感する こうしたプロトコルを決定する側の認 のは、 識と一般のエンジニアの認識とが乖離してい ることです。「ネットワーク技術者」であっ ても IP アドレスの割当てすら困難な状況で、 UNIX magazine 2006 Summer 39
サービス資源の ボリュームゾーン 新たに出現する サービス資源 旧 v4 シングルスタックサーバ 旧 v6 シングルスタックサーバ 旧 v6 テータセンタ ネットワーク テュアルスタック テュアルスタック化 旧 v4 テータセンタ ネットワーク ロロ 旧 v6 シングルスタックホストと lPv4 シングルスタックホストの 通信を実現するミドルシステム インターネット 旧 v6 インターネット 旧 v4 インターネット アクセスネットワーク 旧 v6 インターネット アクセスネットワーク テュアルスタック化 旧 v4 シングルスタック クライアント 旧 v6 シングルスタック クライアント デュアルスタック クライアント 図 9 旧 v6 シングルスタックホストのための解決策 トワークは、 IPv6 の割振り・割当てがすで 旧アドレスプラックマーケットの に開始されていることから、 IPv6 をサポー 危険性 トすることは理論的に可能です。しかし、 IPv6 のみをサポートしているホスト・ネッ 一方、 IP アドレスが枯渇点に達すると、 トワークは、 IPv4 アドレスが枯渇している IPv4 アドレスの公式な供給がストップする ことを考えれば、 IPv4 をサポートすること ため、混在型ネットワークとはまったく別の は理論的に不可能です。しかし、 IPv4 のみ 間題が発生することが考えられます。その間 をサポートするサービスがしばらくの間は残 題の 1 つが、 IPv4 アドレスのプラックマー ると考えると、 IPv6 のみしかサポートしな ケットにおける取引です。 いホスト・ネットワークから、 IPv4 ネット 報告書の付録にある Virtual Round Table ワークへアクセスできる方策を講じておくこ において、 Geoff Huston 氏もその可能性に とは、 IPv4 から IPv6 へスムーズな移行を行 ついて触れています。 なうために必要です。 IPv4 アドレスは、 IPv4 でネットワークサー 実は、この逆も真であり、古い OS など ビスを提供するために必要不可欠です。また を利用しているクライアント系ホストでは、 枯渇点を迎えても、急には IP ⅵを用いたサー IPv6 をサポートしないケースがあります。 ビスはなくなりません。この段階でどれほど 企業などではこうしたホストが今後もしばら のエンドユーザーが、 IPv4 のみしかサポー くは使われていく可能性が高く、これらは トしていないかにもかなり依存すると考え IPv6 ネットワークへの直接のアクセスが不 られますが、 IPv4 を用いてさらにサービス 可能となります。 を拡充したり、サービスの都合上どうしても いずれの場合でも、 IPv4 ネットワークか IPv4 アドレスを用いなくてはならないケー ら IPv6 ネットワークへのアクセスを間題な スも考えられます。このようなニーズを背景 くできるようにするための方策が、必要であ に、現在未使用となっている空間を持っ組織 ることは変わりありません。 が、レジストリによるアドレス分配の枠を超 この関係を模式的に表した図を図 9 に示 えて、独自に IP アドレスを売買するかもし します。詳しくは報告書を参照していただけ れません。これがプラックマーケットの始ま ればと思います。 りになると考えられます。 牆 1 インターネット利用者の ボリュームゾーン 新たに出現する インターネット利用者 一 P 《 6 Ø一 7 28 UNIX magazine 2006 Summer
6 とは何なのか ! ? プレスリリースの報道は、 IT 系の Web メ 旧 v4 アドレス枯渇への ディアを中心に数件見受けられました。各社 正しい対策は ? の端的なまとめ方から、的確に受け止められ たものが多いような印象を持ちました。 4 月 3 日に公開した「 IPv4 アドレス枯渇 メーリングリスト、掲示板、あるいは個人 に向けた提言」は、 こまでに述べてきたよ のプログなどでの反応には、よい評価もあれ うな認識や思いとともに、活動としてひと区 ば悪い評価もあり、考えさせられるものも 切りとなりつつあります。 多々ありました。 冒頭で述べたように この報告書の検討を もっとも印象に残ったのは、 IPv6 推進へ 始めた動機は、 IPv4 アドレスが枯渇する日 の扇動のメッセージとしてとらえたもので が数年後に訪れそうだという状況を広く正し す。日く「 IPv6 は今や政府予算を伴う産業 く知らしめることでした。なぜそれが必要 であり、推進に携わる人々は自身の利益誘導 か ? それは、何らかの対策が行なわれない のためにそう主張するだけで、その主張に技 と、インターネットが今までどおり動かなく 術的妥当性はない」などとするものです。 なることが明らかだからです。 この報告書を検討し公開するにあたって、 今回、この報告書を機に IPv4 アドレスの ここに述べているようにできる限り上記のよ 枯渇に対する対策が再び論じられることとな うなバイアスがかからないように心がけたっ りましたが、大別して 3 つの立場があるよ もりですが、そのような配慮が効果を発する うに思います。 のは相当難しいようです。あたかも IPv6 と ① IPv6 こそが IPv4 アドレス枯渇の後も いう文字列が自動的にそういうイメージを引 インターネットを動かし続けるための き出すかのように思えます。 ソリューションである このような場合に極端な意見や反対意見が ② IPv6 ではなく、 IPv4 をベースに 目立ち、「穏健な意見や賛成意見はみえない NAT などを用いた IPv4 アドレス有効 から過度に悲観する必要はない」という観測 活用策を用いることで対処可能である ③ がなされることがありますが、筆者はむしろ、 IPv4 アドレスは黎明期に割当てを受 いずれにしても大半の意見は表に出てこない けた組織が膨大なスペースを死蔵し であろうと考えるに至っています。 ており、その返却を促進することで また意見の中には明らかな誤謬を含むもの IPv4 インターネットの持続的運営が も見受けられます。例えば、「 JPNIC が内々 可能である これらには、それ以外の立場からの反論や更 に規則や方針を立て、それを押し付けよう としている」というとらえ方が度々なされま なる再反論があります。 ① ' す。しかし、実際にはむしろオープンでポト IPv6 に移行するためにはインター ネット上のすべての端末とネットワー ムアップな方針策定過程となるように強い意 クを IPv6 化しなければならず、莫大 志を持って取り組んでいるのです。 これ以降論じていく技術的な観点も含め、 なコストがかかる。また一気に移行す 人の数だけ感じ方や理解の仕方、入手する情 るのは極めて難しい ① " IPv6 はすでに Windows 、 BSD 系 O 報は異なりますので、知られていないことを 知らせる、間違った認識を正していただくと S 、ルータソフトウェアなど、合理的 なコストで入手可能である。また現実 いった努力は、地道に継続的に行なっていこ 的にはデュアルスタックで移行してい うと再認識しました。 33 UNIX magazine 2006 Summer
アドレスのプラックマーケットでは、需要 に対する供給の少なさから、アドレスに対す る料金は相当高騰するものと考えられます。 これは、 IPv6 によるネットワークの普及か 早期に進むことによって、徐々になくなると 考えられます。 しかし IPv6 の普及が遅れ、枯渇点を迎え てもなお IPv6 の普及が充分でない場合には、 このようなマーケットがしばらくの間活躍す る可能性があります。アドレス料金の高騰は、 そのままサービス料金へと反映され、 IPv4 サービスの高騰を引き起こすでしよう。 このようなことがないように IPv6 の普及 を促進するか、プラックマーケットを排除し 管理されたオープンマーケットの上でアドレ スの取引を行なう必要性があるのです。 提言の基本的な考え方 こまでアドレス枯渇予測、枯渇点を迎え るにあたっての動向予測などを解説してきま これらの予測は、インターネット利用者に IPv4 アドレスが枯渇すると宣言し危機感を あおろうとしているのではありません。むし ろ、 IP ⅵの利用状況と枯渇した場合に考え られる事柄を、正しく把握し、枯渇に向かっ て、私たちが何をすべきかを考えるための材 料としてほしいと考えているものなのです。 報告書ではこの考え方に基づいて、イン ターネットの各担当分野をレジストリ、 ISP 、 利用者、 IP 技術開発者の 4 つに分類してい ます。さらに利用者については、サービス提 一般ユーザーの 3 つ 供者、企業ユーザー に分類し、合計 6 つに分けたうえで提言を 行なっています。 こでは、これらの提言のなかから、本誌 の読者層に近いと思われる IP 技術開発者の 方々への提言について、その考え方を解説し たいと思います。 旧 6 とは何なのか ! ? 旧技術開発者は何をすべきか 報告書では、 IP 技術開発者に対する提言 を以下のように記述しています。 「べンダーをはじめとする IP 技術開発者 は、 IPv4 アドレス枯渇を意識し、より一層 の IPv6 技術開発に取り組むべきである。特 に、 IPv6 / IPv4 併存環境における課題に対 しては、他のプレイヤーと連携をとりながら 迅速に間題解決を図る必要がある。」 誤解のないように訂正しますが、提言では IP 技術開発者が IPv6 技術の開発に努力をし ていないとはいっていません。彼らの IPv6 関連技術の開発努力には敬服しています。し かしいくつかの場面、特に IPv4 と IPv6 が 複雑に混在している環境などにおいて、いく っかの間題が生じているのが現状です。すで に生じている間題は各所に報告され、実装レ ベル、プロトコルレベルで迅速な対応がとら れています。とはいえ、今後 IPv6 が本格的 に利用されるようになると、さらに多くの問 題が生じると予測されます。このような事態 に向けて、べンダーやメーカー、そしてそれ らを含む IP 技術開発者の方々に、より一層 の尽力をお願いしたいと思います。 特に、今日のようにインフラ化したイン ターネットにおいては、セキュリティ技術が 非常に重要視されています。しかし、 IPv6 に対応したセキュリティ製品は、充分とはい えない状況にあります。 IP 技術開発者が担当する範囲は、ネット ワーク、アプリケーション、そしてセキュリ ティと多岐にわたるため、それらが統一的 に IPv6 でカバーできるようになるには、時 間がかかると思われます。しかしながら、 IP 技術開発者コミュニティの相互協力によっ て、現在そしてこれから発生するだろう問題 を解決し、次世代インターネットへのスムー ズな移行がなされることを願っています。 UNIX magazine 2006 Summer 29
19 2 . 16 8 . 10 0 . 110 0 0 0 0 0 .10101000. 01100100 . ここでは切れるけど ここでは切れない。 2 進数が わからないから・ 未熟な技術者でも IPv4-IPv6 移行作業が できるようにする必要がある。 図 1 ネットワーク技術者 ( 自称 ) の実態 であり、これがレイヤ 3 、レイヤ 7 の両面か らサポートされることを望みます。 また DDos * 2 対策も必要となります。 ACCS * 3 への DDoS 攻撃を覚えているで しようか。これは IPv4 では原理的に防御が 不可能という点で、技術者に波紋を投げかけ ました。しかし TCP/IP べースでは、この問 題の解決は難しいと考えています。 ④モバイル ADSL や光ファイバなどは、勢いよく帯域 が拡張されていますが、本当に需要はあるの でしようか。携帯電話を例にみても、固定電 話より通信が不安定で料金が高いとしても、 モバイルという魅力が携帯電話を正当化し ています。ノート PC も同じで、ユーザーが 求めているのはモバイルなのです。このニ ズを考えず、技術論だけで独善的に構築され た通信インフラは、必ずマーケットから拒絶 ⑤マルチキャスト あります。 IPv4 でモバイルをするには、 イル化する必要があるのです。 されます。つまり、インターネットもモバ 多くの間題が しかし現行の ような気もしますが、マルチメディア的展開 個人的には、太い回線がすべてを解決する ⑥ QoS 必要であると考えています。 あるかどうかはともかく、マルチキャストは レイヤ 3 で行なう必要性および合理性が 6 とは何なのか ! ? に関し、このあたりを気にする人もいます。 旧 v6 で解決できること / 旧 v4 では無理なこと 以上の 6 つの要求項目に対し、 IPv4 で解 大変ですが、これは IPv6 でも同じです。ま を持っているのです。 IPsec は管理・運用が の Windows は IPv6 と同等のセキュリティ IPsec は標準搭載されています。つまり、今 IPv6 は標準搭載されていませんが、 IPv4 の さらに、現在の Windows 2000 / XP には ないのです。 PC というのが大量に出回ることを阻止でき けでもありません * 7 。 IPsec 非対応の IPv6 ての IPv6 対応 PC に IPsec を導入できるわ 面での差はありません。また、必ずしもすべ IPv4 十 IPsec と IPv6 の間に、セキュリティ 「 IPsec までサポートしていること」を除けば、 IPv6 完全対応と謳う際の認定基準である むしろ悪化するのです。 ビリティ * 6 を実現すれば、セキュリティは End tO End (EtoE/E2E) * 5 の IP リーチャ 意味がありません。 IPv6 推進派が主張する な文言が見受けられます。しかしこれには も、「 IPv6 によるセキュリティ」という奇妙 において ているセキュアジャパン 2006 * せん。政府が何十億円も使って進めようとし IPv6 は、セキュリティ問題を解決できま ①セキュリティ 旧 v6 では解決できない 6 つのこと 項において、それを検証していきます。 ち、何 I っ解決することができません。次 です。また IPv6 はこの 6 つの要求項目のう ます。その点はむしろ、 IPv6 こそ不利なの を普及させるために必要な条件は市場にあり これらは研究レベルでは解決しており、これ 渇問題ではなくモバイルと DDoS 対策です。 決の目処が立っていないのは、アドレス枯 * 2 Distributed Denial of Service ある特定のサーノヾに対し膨大 な量のバケットを送りつける ウイルスを作り、それをばら 撒きます。このウイルスに感 染したパソコンは、特定の サーバをひたすら攻撃し続け ます。もし何十万台ものパソ コンから一気に攻撃を受けれ ば、どれだけ大容量のサーバ でも耐えられません。 * 3 コンピュータソフトウェ ア著作権協会 http://www.bits.go.jp/ active/kihon/pdf/sj_2006. pdf * 5 サーバなどを経由せず、ま たネットワーク管理者の定めた ルールを気にせずに、 PC か ら PC ヘデータを直接届ける こと。セキュリティは、各 PC のパーソナルファイアウォー ルやアンチウイルスの設定に 依存し、ネットワーク管理者に は依存しません。個人の自由 の尊重という観点からは面白 いですが、組織の統制という 観点からは問題があります。 Reachability . 通信到達 * 6 性 この場合、形式的に lPv6 完全対応とは謳えなくなりま すので、 lPv6 対応と呼ぶこ との是非はここではおいてお きます。 UNIX magazine 2006 Summer 37
旧 6 とは何なのか ! ? 東京大学情報基盤センター 関谷勇司 SEKIYA Yuji 当初実装したものは、すでに IPv4 に実装 機能を補足してモジュールを作りました。今 されていたものを基にしました。 2003 年に はカーネルに暗号モジュールが人っています それを netdev に投稿したところ、メンテ が、きっかけは USAGI だと思います。 そうして同年川月に、パッチを投げま ナーからは IPv4 のものとの統合が望まれま した。そこでさっそくコードの投稿と議論を した。これは IPv4 にも対応しているうえに NetfiIter Project のメーリングリストで行な トンネルモードも可能で、 TAHI テストで うようにしました * 4 。比較的すんなりと進 の点数も品質も最良でした。しかし大きな められたのは、デザイン段階からしつかりと パッチであったため、メンテナーの反応は悪 議論したためだと思います。また、スタート かったのです。最終的にカーネルにマージさ 時点ですでに USAGI の知名度が高かったこ れたコードは David S. MiIIer 氏と AIexey とや、開発と並行して IPv6 バケットフィル Kuznetsov 氏のもので、 IPv4 だけに入りま タのバグを大量に修正し信頼を得たのも要因 した。これは、 IPv6 を見ていないようなも だと思っています。 のであったため、移植するためにはひたす ら細かな調整が求められました。当時は、 昨年、統合版の Connection Tracking が カーネルに採用されました。最近ではコード IPv6 が必要だという意識が低かったのかも の変更や修正をする場合に IPv6 のことを考 しれません。 慮に入れる習慣が定着しており、バケット 最近では、コミュニティの IPv6 に対する フィルタ自体も IPv4 と IPv6 の統合化が進 理解が進みました。以前は IPv6 を無視した パッチをよく見かけましたが、最近では同時 ( 小堺康之 ) んでいます。 にメンテナンスするものが見受けられます。 我々は、以前はよいモノは取り入れられる と信じていました。それはある意味正しく、 USAGI では品質向上活動として、大きく ある意味間違いだったと思います。コードは 2 つの活動をしており、そのうちの 1 つが 大切ですが、それ以上に政治的な側面も大切 IPv6 Ready Logo * 5 の取得活動です。 IPv6 だったのです。我々の戦略ミスは、事前のディ Ready Logo とは、 IPv6 の普及を促進する スカッションを疎かにしたことと、パッチを 国際団体の IPv6 Forum*6 が、 IPv6 への仕 小出しにしなかったことです。全部できてか 様適合性および機器同士の相互接続性を有す らメンテナーに出すのではなく、少しずつ見 ると認めた製品に与えるロゴです。 Linux の せて、感触を得るという作業が必要だったの IPv6 の品質は高水準に達し、これを証明す です。この経験は、現在の活動に活かされて るためにもロゴ取得に力を入れています。 ( 宮澤和紀 ) います。 もう 1 つの品質向上活動は、レグレッショ ンテスト環境の構築です。 Linux は世界各地 の多く人が積極的に開発・改良しています。 そのため、ある人が開発・改良した機能が他 Linux カーネル 2.4 にはすでに IPv6 に対 の機能を壊してしまうという事態が稀に生じ 応したバケットフィルタが実装されていて、 ます。そこで USAGI では、毎日リリースさ 残る不足機能は Connection Tracking でし れるスナップショットカーネルに対し、自動 た。これはネットワークフローの状態変化を 的にテストをかけるレグレッションテスト環 追跡する機能で、動的なフィルタリングなど 境を構築しました。仕様に準拠しているか に利用されています。 エヌ・ティ・ティ・ソフトウェ ア株式会社技術センター 主任工ンジニア 高宮紀明 TAKAMIYA Noriaki 1994 年 4 月、エヌ・ティ・ ティ・ソフトウェア株式会 社に入社。当初は DB ミドル ウェア連携、 Web アプリケー ションの開発に従事。 1 999 年より IPv6 関連業務に従事。 2001 年 5 月 USAGI プロ ジェクト参加、主に M lPv6 の開発を担当。 横河電機株式会社技術開発 本部ュビキタス研究所所属 宮澤和紀 MIYAZAWA Kazunori 1 999 年 4 月横河電機株式 会社に入社。 2001 年より USAGI プロジェクトに参加。 主に IPsec を担当。 品質向上活動 株式会社東芝研究開発セン ター通信プラットホームラ ボラトリー 小堺康之 KOZAKAI Yasuyuki 2002 年 4 月、株式会社東芝 に入社。入社時より lPv6 関 連の研究開発に従事。 2003 年 6 月より USAGI プロジェ クトに参加し、特にバケッ トフィルタを担当。 2005 年 1 0 月 Netfilter P「0 」 ect のコ アチームに参加。 N etfilter 59 UNIX magazine 2006 Summer
6 とは何なのか ! ? * 21 . ・ 電刄や水道の遠隔検針 * 22 しかし、 i モードは NTT ドコモ網の中では TCP / IP で すらありません。 i モードプ ロトコルと旧 v4 TCP/IP を、 レイヤ 7 のゲートウェイで変 換することにより外に出ます。 E2E や lPv6 がいかに無意味 かを物語っているのです。 * 23 自動車同士が通信を行な い、交通事故の防止や渋滞の 緩和を図るもの。 i D C L A N ・ . グローノヾル IP アドレス リバース プロキシ N A T S R V 図 7 旧アドレス多重利用 ( サーバサイド ) そのほかには、携帯電話、メッシュネット、 ドメインネーム : www.example.com 車 - 車間ネットワークが挙げられます。携帯 HTTP IOO. IOO. IOO. 101 電話の場合は、もともと IPv6 の必要性が高 100.100. IOO. 101 HTTP いうえにキャリアが支配する世界なので、例 HTTP 1 OO. 100.200.101 HTTP 1 OO. 100.200.102 えば i モードは NTT ドコモ網の中で IPv6 オ S MTP IOO. 100.100.101 10025 ンリーと宣言すれば、突如 IPv6 の世界にな 図 8SRV のイメージ * 22 ゾァ るのです。久に挙げたメッシュネットと ることでポートフォワーディング設定を自 は、無線 LAN を結合し、巨大な無線ネット ワークを作る技術です。これは新しいネット 動化するプロトコルで、 NAT ルータさえ対 ワークのため互換性が不要であり、 IPv6 導 応していれば、アプリケーションや OS の対 入が容易です。また構成員として、自らの 応は不要です。唯一の問題は、相手ルータも 無線 LAN を開放する個人も考えられます。 NATS 対応が必須という点ですが、 IPv6 へ この場合、 NAT でローカルアドレスを配る の移行よりは、はるかに簡単です。 のは困難であり、 IPv6 の必要性は増大しま ■まとめ す。その次の車ー車間ネットワーク * 23 への 退蔵アドレスの回収とアドレスの多重利用 IPv6 導入は面白いかもしれません。データ を組み合わせるだけで、 IPv4 アドレスの延 グラム配送でも構わない用途が多く、アドレ 命を何十年も図ることができるのです。 スが変わっても対処しやすいためです。 旧 v6 の未来 そして最後の可能性としては、研究や実験 です。筆者も、このような用途に関しては賛 成です。しかし、必要なのは実験的な IPv6 とはいえ、まったく IPv6 が使われないと ネットワークを作ることであり、世界中を いうのではなく、限定的な分野である程度使 IPv6 に移行させることではありません。ま われていくと考えています。 ずすべきことは、既存の IPv6 ネットワーク IPv6 の間題点は、互換性の欠如による膨 の有効活用で、これを IPv4 経由のトンネリ 大な移行コストであり、逆に互換性を無視で ングで世界的に結ぶのです。そこで画期的な きる場合には、積極的な選択肢となります。 新アプリケーションが出てくれば、 IPv6 も 例えばビル内監視システムやテレメトリング * 21 にも利用されるでしよう。 一気に普及すると思われます。 ボート番号 分散比率 プロトコル 1 0 % 10% 40% 40% 1 OO% 0 0 8 0 0 8 0 8 8 8 43 UNIX magazine 2006 Summer
の中から各事業者の判断で対策を行ない、じ きに浸透していく、という方式になっている ことがわかります。そのようなモデルで運営 してきたからこそ、インターネットが ' で急激に発展し、社会資本として利用される に至るまで機能し続けているのです。 今後の JPN ℃の取り組み、業界 に期待するもの 繰り返しますが、このような事業者それぞ れの自律的な判断とその連鎖が、今まで急激 な拡大を続けてきたインターネットの運営手 法であり、今後社会基盤としてますます拡大 するインターネットにおいても不可欠であろ といえるのです。 渇の問題はまさにインターネット運営の問題 のパートで述べたとおり、 IPv4 アドレス枯 また「 IPv6 推進から一線を隔した検討」 うと考えます。 動かしていくことは不可能だと思います。 ターネットインフラ運営コミュニティ全体を て次の議論を組み立てていかなければ、イン どれほど確かなのかを精査し、その上に立っ のほうが簡単だ」という観測の 1 つ 1 つが ない」、「 NAT を用いたアーキテクチャ変更 資が掛かる」、「 IPv4 アドレスは実は枯渇し つまり、「 IPv6 の移行には多大な出費や投 メータに関して、まだまだ精査が足りません。 る出費や投資の規模などのさまざまなパラ では周辺状況、前提条件、対処に必要とされ どれかを選択する必要があるとして、現段階 事業者によって上述の 3 つの対処方法の 情報を充分に提供することなのです。 さんにより的確な判断をしていただくための ろが行なうべき活動は、第 1 に事業者の皆 のできない仕事をやる」 JPNIC というとこ ら、インターネットの安定運営に欠かすこと 業者や組織の自助努力では達成できないなが ところなのか」の項で述べたように、「各事 そのような中で、「 JPNIC とはどのような 6 とは何なのか ! ? これら 1 つ 1 つの材料を示し、議論を喚 起して、日本だけでなく世界に向けてもコン センサス醸成の手助けをしていくというの が、今後取り組もうとしていることなのです。 筆者自身や専門家チーム、および JPNIC は、 IPv4 アドレス枯渇にあたり、インター ネットを持続的に運営するための適切なソ リューションは、やはり IPv6 であろうと考 えています。次世代のプロトコルとして開発 された IPv6 は、 IPv4 アドレスの枯渇を根本 的に解決するだけでなく、圧倒的に広大なア ドレススペースを背景に IPv4 では実現でき ない新たなコンピューティング環境を実現す るはずであるからです * 1 。 しかしながら、たとえ実際に選択したソ リューションが、我々が想定している IPv6 インターネットへの移行でなかったとして も、適切なソリューションによって IPv4 ア ドレス枯渇を克服し、インターネットの持続 的運営という目的が達成されるのであれば、 それは我々の取り組みの成果だといってよい と考えています。 報告書は本稿執筆時点で英訳作業中であ り、皆さんが本稿をお読みになっているこ ろには英語版が公開され、全世界のコミュニ テイからの意見を受けることになります。議 論が積み重なるごとに精密になり、次第にク リアな判断ができるようになるでしよう。 日本人の気質には、真面目できめ細やかな 配慮が利くという点があると、筆者は思いま す。日本のインターネットインフラ運営コ ミュニティは、世界的にみても意思疎通がし やすく、密な連携が取りやすいコミュニティ であるのは間違いありません。 世界中が IPv4 アドレス枯渇の問題を鶏と 卵の問題のように手をこまねいている時に いち早く技術開発と技術運用が両輪となった プレークスルーシナリオや運用モデルを提案 することができるのは、日本のコミュニティ であると筆者は思っています。 * 1 。念のために付け加えます が、これはインターネット に関して lPv4 アドレスの枯 渇が問題となるだけです。イ ントラネットを初めとする プライベートネットワーク や lPv4 アドレスで構築され た部分だけで完結するシステ ムに関しては IPv4 が問題な く機能するでしよう。また、 新たに分配する lPv4 アド レスがなくなったとしても、 IPv4 インターネットはすぐ にはなくなりません。 UNIX magazine 2006 Summer 35
ことでした。そこで原則として、 lnternet- Draft の段階の仕様を実装したものは snap で公開し、 RFC に対する実装のみを BSD へ 還元する方針としたのです。 DHCPv6 関係 のプログラムは現在、 WIDE-DHCPv6 とし て sourceforge. net * 8 で保守されています。 ■ lPsec KAME プロジェクトで開発された IPsec コードは、カーネル空間での IPsec そのも のの実装と、ユーザー空間での鍵交換ソフ トウェアに大別できます。 KAME プロジェ クトの IPv4 および IPv6 用の IPsec は、 FreeBSD や NetBSD にマージされています が、 OpenBSD が独自に実装している IPsec のコードのほうが暗号ハードウェアとの相性 がよいため、将来は OpenBSD 由来のコー ドで置き換えられると考えられます。ただ、 KAME プロジェクトが仕様をいち早く実装 し、誰でも自由に使え、安定して動作する IPsec スタックを提供したことの意義は大き いといえます。 また、鍵交換ソフトウェアとして「 racoon 」 と呼ばれる IKE デーモンを開発しました。 racoon バージョン 1 は、 BSD のみならず Linux でも採用され、現在 IPsec-TooIs とし て sourceforge. net*9 で保守されています。 一方、 racoon バージョン 2 は、現在 WIDE プロジェクトの IPsec WG のメンバーの協 力により開発されています。これはポリシー を管理する部分がユーザー空間で実装されて いることと、 IKE バージョン 2 と KINK * 10 の両方をサポートしていることが大きな特徴 で、相互接続実験において良好な結果を出し ています。現在、より仕様に忠実となるよう 、加えて Mobile IPv6 でも利用可能とな るように開発が進められています。 ■ Mobile lPv6 Ericsson により口一ダブルモジュール として開発された MobiIe IPv6 のコードを snap にマージし、その後コアとなった島慶 6 とは何なのか ! ? 一氏 ( インターネットイニシアテイプ ) が、 独自の MobiIe IPv6 コードのカーネル空間 での開発、維持に従事しました。ただし、そ の仕様は snap で提供されるのに留まり、現 在は SHISA というコードが実装されてい ます。 2004 年から開始された SHISA は、 IPv6 スタック上に構築された、 IPv6 移動通 信プロトコルです。それ以前の Mobile IPv6 スタックはカーネル内部で実装されており、 機能の拡張はカーネルの拡張を意味していま したが、 SHISA ではカーネルで実装しなけ ればならない機能と、ユーザー空間で実装で きる機能を分離することにより、不要なカー ネル拡張を排除したのです。現在、 SHISA では Mobile IPv6 に加え、前述の特許間題 を解決した NEMO BS ( 基本仕様 ) を実装し、 さらに複数ネットワークインターフェイス利 用のための拡張や、 IPv4 ネットワークのサ ポート、 BSD へのマージなど、総合的な IP モビリティサポートを提供しています。 ■マルチキャスト IPv4 ではマルチキャスト中継機能が、 OS ごとに独立して実装されていたため、 OS に よってサポート状況が異なったり、マルチ キャスト対応 OS 間でも API が異なったりと いう統一性のなさが、 IPv4 マルチキャスト 普及の足枷の一因になっていました。そこで KAME プロジェクトでは神明氏が中心とな り、 IPv6 マルチキャスト中継機能および経 路制御ソフトウェアをすべての BSD に共通 な形で実装し、すべての BSD へマージした のです。このため、どの BSD でも同じ IPv6 マルチキャスト経路制御ソフトウェアを使用 できるようになりました。 これは IPv6 マルチキャスト普及にとって、 大きな前進でした。なお KAME プロジェク トの開発した IPv6 マルチキャスト経路制御 ソフトウェアは、現在 SSM 機能や Linux の サポートも含めた形で、 sourceforge. net の mcast-tools プロジェクトにて保守されて * 8 http://wide-dhcpv6. sourceforge. net/ * 9 http://ipsec-tools. sourceforge. net/ * 1 0 K ー N K : K e 「 b e 「 i z e d lnternet Negotiation of Keys UNIX magazine 2006 Summer