社団法人日本ネットワークイ ンフォメーションセンター 旧分野担当理事 フランステレコム日本研究所 前村昌紀 MAEMURA Akinori 1994 年より国内大手 ISP の 立ち上げに参加。以降、ネッ トワーク設計、対外接続を担 当。 2000 年グローバルワン に移り IP プロダクトの技術 サポート、 lPv6 テストべッ ドの運用などを担当。改組 転籍などを経て現在フラン ステレコム日本研究所勤務。 J PN ℃ ( 日本ネットワークイ ンフォメーションセンター ) IP 分野担当理事兼 IP 事業部 長、 APN ℃ (Asia Pacific N e t w 0 「 k ⅲ f 0 r m a t i 0 n Centre) 理事会議長、国際 大学 GLOCOM フェロー アドレス枯への対処 前バートでは報告書、「 IPv4 アドレス枯渇に向けた提 * 1 」の内容を概説しました。 ここでは報告書の検討や公開、そして公開後の議論などを振り返り、 lPv4 アドレス枯渇という問題にどう向き合っていくべきかを論じます。 向の違い、つまり消費ペースが早まっている JPN ℃とは ことになります。 どのようなところなのか 2009 年というのはかなり悲観的だと思い 筆者はこの記事を、 JPNIC の IP 分野担当 ましたが、楽観的な予測でも 2 田 6 年です。 理事という立場で書きます。そこで最初に ひと言「数年で枯渇する」とした予測は、筆 のポジションを説明いたします。 者にはショッキングでした。しかし専門家 JPNIC は「社団法人日本ネットワークイ チームを編成した 2005 年 12 月の時点で、 ンフォメーションセンター」の略で、前身で このショッキングな内容が日本国内で充分認 ある任意団体は 1991 年に発足しています。 識されているようには思いませんでした。 その歩みは「 JNIC から JPNIC へ 10 年の歩 例えば 5 年としましよう。 5 年というのは み」 * 2 で紹介されていますが、インターネッ 概ね計算機設備や通信設備の減価償却期間と トを動かすために必要ながら、各組織ででき なります。つまりこれから 5 年で技術的な るものではない IP アドレスの管理や JP ド 変化が起こるとすれば、それに対応した設備 メイン名の登録を行なってきました。 に更新するには、まさに今の期を逃してはな JP ドメイン名の登録業務は 2002 年に日 らないはずです。つまり IPv4 アドレス枯渇 本レジストリサービス (JPRS) * 3 に移管し、 に対し、すでに何らかの方策を立てないとい 現在は筆者が責任者をしている IP アドレス けないのです。そのような認識が業界全体で 管理業務と、インターネット基盤事業として 共有されているのであれば、 IPv4 アドレス 普及啓蒙活動や新技術への取り組みを行なっ 枯渇をどう乗り越えるのかという議論が建設 ています。いずれの事業も、当初の方針に従 的に行なわれているはずです。 い行なっております。 それではなぜそのようにならないのでしょ う。おそらく IPv4 アドレス枯渇という話題 新たな寿命予測に鈍感な業界 が、少しずっ内容を変え、すでに何度となく 語られてきているからだと思うのです。 IPv6 の仕様が策定された 1990 年代中 Cisco の Tony Hain 氏、 APNIC の Geoff Huston 氏から、 IPv4 アドレスの寿命予測が 盤には、 IETF で ALE ー Address lifetime 発表されたのがそれぞれ 2005 年 9 月と同年 Expectations というワーキンググループ が組織され、 2008 年士 3 年という予測が Ⅱ月でした。 提示されました * 実は Huston 氏は 2003 年に最初の寿命 しばらく時間をおいた 2001 年 3 月、 ICANN*5 から McFadden / 予測を 20 幻年と発表しました。 2005 年の HoImes レポート * 6 が出され、 2004 年から Hain 氏の論文は最短 2009 年、 Huston 氏は 最短 2 田 3 年としています。これらの違いは 2017 年の間という寿命予測が提示されまし 2004 年、 2005 年の IP ⅵアドレス消費の傾 た。またこれ以外にも IPv6 推進の立場から 1 一 P 《 6 化直Ø一 7 報告書は JPN ℃の Web ページから入手可能です。プ レスリリース文に要約が掲載 されており、そこから報告書 の PDF にたどり着くことも 可能です。 1 OO ページを超 える大作となりましたが、是 非お手に取ってご覧いただき たいと思います。 http://www.nic.ad.jp/ja/ topics/2006/20060403 ー 01 . html http://www.nic.ad.jp/ ja/history/10th/index. html * 3 http://jprs.co.jp/ ftp://ftp.ietf.cnri . 「 eston. va. us/ietf-online- proceedings/94dec/area. and. wg. reports/ipng/ale/ ale-minutes-94dec. txt 30 UNIX magazine 2006 Summe 「

0 東京大学大学院 情報理工学系研究科 電子情報学専攻 石田真一 ISHIDA Shinichi 2000 年 3 月岐阜県立斐太高 等学校卒業。 2005 年 3 月東 京大学工学部電子情報工学科 卒業。 2005 年 4 月東京大学大学院 情報理工学系研究科入学。 Live E! Project Live E! Project ( 以下、 Live (!) は、センサーノードを地球上に多数配置し、個々の情報を インターネット上から参照できるようにすることで、センサーの情報からさまざまなサービスを 提案することを目的としたプロジェクトです。 今回はこのプロジェクトの技術ワーキンググループに所属している若手研究者 5 名に、プロジェ クトに対する想いなどを語っていたたきました・ 1 。 自己紹介 トワークを用いて、うまくデータ配信をした いと考えています。 まず初めに自己紹介をお願いします。 石塚 : 東京電機大学の石塚宏紀です。 WIDE 知史です。石塚君と一緒に Live E! のチェア Project の中で Live E ! のチェアをしていて、 をしています。プロジェクトの中では技術グ 関東側の取りまとめを担当しています。 ループの担当をしていて、主に取りまとめと : 東京大学の落合秀也です。主にシステ システム構築をしています。修士では「地理 ムの構築や実装関係を進めていて、オーバー 位置情報の属性付き P2P ネットワーク」に レイネットワークについて興味を持っていま ついて研究を行ないました。 Live E! には、 す。卒業論文では「大規模小型ノードネット オーバレイネットワークに興味を持っている ワークにおける XML 翻訳機構の導人」とい 人は多いので、ゆくゆくはそういったところ う研究を行なったのですが、この研究成果も で貢献したいと考えています。 Live E! で使えるようにしていきたいと思っ ています。 石田 : 東京大学の石田真一です。研究内容は Live E! は、どのようなきっかけで始め 「アプリケーションマルチキャスト」です。 られたのですか ? Live E ! ではこれを利用して大規模センサー 松浦 : もともと小学校には、理科の実験など ネットワークに展開し、データ配信をしよう に使う百葉箱があります。これをデジタル化 としています。 しインターネットにつなげたもの ( デジタル 洞井 : 奈良先端科学技術大学院大学の洞井 百葉箱 ) を、東京大学の江崎浩先生の IPv6 晋ーです。奈良先端大側のデータベースや チームや広島の学校の人たちが共同して開発 Web を管理しています。オーバーレイネッ しました。そして、センサーデータを社会的 松浦 : 奈良先端科学技術大学院大学の松浦 東京電機大学大学院 工学研究科 石塚宏紀 ISHIZUKA Hiroki 2001 年 3 月私立開智高等学 校卒業。 2006 年 3 月東京電 機大学工学部情報メディア学 科卒業。 2006 年 4 月東京電機大学大 学院工学研究科入学。 Live E! とは 東京大学大学院 情報理工学系研究科 電子情報学専攻 落合秀也 OCHIAI Hideya 2002 年 3 月静岡県立韮山高 等学校理数科卒業。 2006 年 3 月東京大学工学部電子情報 工学科卒業。 2006 年 4 月東京大学大学院 情報理工学系研究科入学。 この対談は 2006 年 5 月 に行われました 打ち合わせ風景 写真 1 写真 2 石塚宏紀氏 106 UNIX magazine 2006 Summer

4 アドレス今後の動向 旧 v4 アドレスは本当に枯渇するのだろうか ? 識者による枯渇予測レポートのポイントをまとめたうえで、これからの旧 v4 アドレスを取り 巻く環境を解説し、旧 v6 へ移行するにあたり旧技術開発者がいま何をすべきかについて提 言します。 まほろば工房 近藤邦昭 KONDOU Kuniaki 1970 年北海道生まれ。神奈 川工科大学・情報工学科修 了。 1 992 年に某ソフトハウ スに入社。主に通信系ソフ トウェアの設計・開発に従 事。 1 995 年株式会社ドリー ム・トレイン・インターネッ トに入社し、バックボーン ネットワークの設計を行な う。 1997 年株式会社イン ターネットイニシアテイプに 入社。 BGP4 の監視・運用 ツールの作成、新規プロトコ ル開発を行なう。 2002 年株 式会社インテック・ネットコ アに入社。 2006 年独立、現 在に至る。その他、日本ネッ トワーク・オペレーターズ・ グループ (JANOG) の会長も 務める。 IPv4 アドレスの枯渇予測でよく知られ 旧 v4 アドレス枯渇予測 表 1 に示す 4 つです。この ているものは、 うち 3 つは、 APNIC の lnternet Research Scientist の Geoff Huston 氏によるもので、 日本ネットワークインフォメーションセン 残り 1 つが Cisco の Tony Hain 氏によるも ター ( 以下、 JPNIC) では、 4 月に「 IPv4 ア のです。 ドレス枯渇に向けた提言」を公開しました。 Geoff Huston 氏が 3 つもの枯渇予測レ この報告書は、 JPNIC の呼びかけによって、 ポートを出しているのにはいくつかの経緯が IP アドレスの需要動向やインターネットの ありますが、新しいものになるにつれて、そ 動向に見識のある方々を集めて構成された の考え方がより現実的になっているといって 「番号資源利用状況調査研究専門家チーム」 よいと思います。 によって書かれたもので、筆者はこのチーム 実際、枯渇予測の分析を担当したチームの のチェアを務めました。 メンバーが Geo 仕 Huston 氏にコンタクトし この報告書は、海外の識者による IPv4 ア ていくうちに、古い予測ページが新しいもの ドレス枯渇予測の分析に始まり、日本でのア に置き換わってしまったということなどもあ ドレス需要の変化、そして、 IPv4 アドレス ります。おそらく、新しいものを参照しなさ 枯渇に向けた提言といくっかの要素に分かれ いという彼のメッセージなのでしよう。この ており、全体で 100 ページを超えるものと ような経緯もあって、報告書で触れている枯 なっています。まず、この報告書における一 渇予測レポートにたどり着けないものもすで 番の基本となる IPv4 アドレスの枯渇予測を に存在します。 見ていきます。 1 〒《 6 Ⅳ一回Ø一 7 RIR MIANA 予測の特徴 発行年月 筆者 ドキュメント名 BGP 〇過去 IO 年間の傾向を 将来に延長して予測 〇 BGP の経路数を考慮 〇過去 IO 年間の傾向を 将来に延長して予測 〇 BGP の経路数を考慮 〇過去 5 年間の傾向を 将来に延長して予測 2003 年 7 月 Geoff Huston The ISP Column ( HOW long have we got ? ) 2029 年 2022 年 2021 年 2022 年 8 月 201 6 年 1 月 201 3 年 2005 年 12 月 28 日 Geoff Huston 旧 v4 Address Report ( POta r00 ) lnternet Protocol Journal ( A P 「 agmatic Report on IPv4 Add 「 ess Space Consumption ) 2005 年 9 月 Tony Hain 2009 年 ~ 201 6 年 〇過去 3 年間の傾向を 2027 年 2012 年 将来に延長して予測 1 月 1 6 日 1 月 24 日 〇 BGP の経路数を考慮 ( * ) Web 上で日々データが更新されているため、日々枯渇予測日が変わる 2013 年 3 月 23 日 2005 年 1 1 月 Geoff Huston The ISP CoIumn ( NumeroIogy ) 表 1 各レポートのサマリー 20 UNIX magazine 2006 Summer

2000 年末 2000 年末時点での 2005 年の予測 旧の主流なノヾックボーン回線速度は ? 典型的アクセス速度 64kbps 1 OMbps 2000 年末の約 1 56 倍 6 とは何なのか ! ? ユーザー数 4708 万人 8720 万人 2000 年末の約 1 .9 倍 実際は 2005 年 1 2 月現在 東京 - 大阪 . 1 OGbps x 4 がもっとも広帯域な区間 ( 平成 13 年度版通信白書より ) 44.5Gbps 150Mbps x 1 56 x 1 .9 もはや既存のインフラでは支えきれない ! 図 3 アクセスのプロードバンド化がもたらす需要 ( 5 年前 ) のためのインフラからデータのためのインフ ラへという発想の転換だったのです。 増加し続けるトラフィック 図 3 は、 5 年程前にプロードバンドをテー マにしたあるフォーラムで話をした時に使っ たスライドです。ちょうど電話からデータ通 信への主役交替が起こり始めた頃です。 2000 年末時点では 64kbps が典型的なア クセス速度で、ユーザー数は 4708 万人、ま た IIJ バックポーンは 150Mbps でした。当 時の通信白書によると、 2005 年には典型的 アクセス速度が lOMbps になり、ユーザー 数が 8720 万人になると予測されていまし た。この条件から、大雑把かっ単純な計算 で 2005 年時点でのバックポーンの必要帯域 を予測した結果、 44.5Gbps となりました。 44.5Gbps などという回線は、当時の通信イ ンフラ上には存在し得ないほど高速であり、 実際、今もまだ商用では存在していません。 そうすると、必然的にこのプロードバンド化 の需要を既存のインフラでは捌くことができ ないということになります。つまりインフラ の作り方や、バックポーンを構築する際の考 え方を変えないとならなくなるのです。実際 は 2005 年末現在、東京ー大阪間に 9.6Gbps の回線を 4 本引いて使っているため、この 予測はまったく当たらなかったわけではない と、いえなくもありませんが いずれにせよ、現状でもトラフィックの増 加は続いており、既存のインフラではもはや インターネットの成長を支えきれません。時 間の問題なのです。そしてこれが、フェーズ 2 の始まりであります。 旧自身の変革 いまさら触れる必要もありませんが、物理 的なインフラだけではなく、 IP 自体もスケー ラビリティの間題に直面しています。それが 1991 年に間題提起された、 IP アドレスの枯 渇とルーティングテープル爆発の予測です。 IP アドレスが枯渇すれば新規にユーザーを つなげられなくなります。一方、ルーティン グテープルが爆発してルータの動作に間題が 発生すれば、インターネット自体が動かなく なります。これは非常に衝撃的な予測でした。 そこで短期解と長期解の 2 つの対策が考 えられました。短期解は、現在の CIDR に基 づく階層的なアドレス割振りと経路集約の しくみです。それはプライベートアドレス十 NAT を用い、インターネットに直接アクセ スしないデバイスにはアドレスを消費させな いという施策です。既存の IP を利用しなが ら、アドレスの利用を節約し、かっ経路制御 のオーバーヘッドを抑えるという付加的なも のでした。 UNIX magazine 2006 Summer 47

http://www.Iinux-ipv6. org/memo/mipv6/ 注意点 MIPv6 では、どこでも同じ IP アドレスが 動作しなかった場合は、ファイアウォール 利用できるほか、 TCP のセッションを切る などの設定を見直してください。 MIPv6 で ことなく移動が可能になるなど、いくっかの は IPsec を利用しており、 IPsec を通過させ 利点が存在しています。もちろん経路最適化 る必要があります。 を Debian / GNU Linux やめて、 VPN とし て利用することも可能です。また、移動して ・まとめ いかがでしたでしようか。より詳細な説明 も IP アドレスが変わらないという特性から、 7 に記述 ブッシュ型のアプリケーションと相性がよい は Mobile IPv6 for Linux Guide されていますので、興味を持たれた方はぜひ かもしれません。実際に MIPv6 を体験した あと、あなたはどのような面白いアプリケー 参照してください。 まだ実装としてこなれていない部分はあり ションを思いついたでしようか ますが、実際に触れることのできる実装が出 魅力的なアプリケーションの登場に期待し てきたことは、実に喜ばしいと考えています。 ています。 ( 國武功ー ) 牆 1 〒《 6 一回Ø一 7 USAGI: 一 P 《 6 0 コ Linux 写真 3 USAGI 定例ミーティングの様子 NodeConfig MN; DoRouteOptimizationCN disabled; DoRouteOptimizationMN disabled; UseCnBuAck disabled; 工 nterface "eth0" { Mn 工 fPreference 1 ー MnRouterProbesRA 1 ー MnRouterProbesLinkUp 0 ー MnHomeLink "eth0 ” { HomeAgentAddress 2001:db8:abcd:2000: : 1 ー HomeAddress 2001 : db8 : abcd : 2000 : :abcd/64; UseMnHa 工 Psec enabled; IPsecP01icySet { HomeAgentAddress 2001 : db8 : abcd : 2000 : : 1 ー HomeAddress 2001 : db8 : abcd : 2000 : :abcd/64; # 工 psec の設定に依存する。注意して setkey ・ conf と見比べて # ほしい。 工 PsecP01icy Mh UseESP 257 258 ー 工 PsecP01icy TunneIMh UseESP 259 260 ー 工 PsecPoIicy 工 CMP UseESP 261 262 ー IPsecPoIicy Tunne1Pay10ad UseESP 263 264 ー N EWS ( 2006 / 06 / 01 ) 2006 年 6 月 1 日に 帝国ホテルで行なわれた 「 2006 年度電波の日・ 情報通信月間」記念中央 式典において、 USAGI プロジェクトが 2006 年度情報通信月間総務大 臣表彰を授賞。 リスト 5 モバイルノード用設定 UNIX magazine 2006 Summer

」 IJS 報告 大学院大学 ) 、高田敏弘 ( N 幵 ) 、建部修見 ( 筑 ら軽量プログラミング言語が一堂に会す珍し 波大学 ) 、谷村勇輔 ( 産業技術総合研究所 ) 、 さまざまな軽量プログラミ いイベントです。 戸辺義人 ( 東京電機大学 ) 、南里豪志 ( 九州 ング言語の実力、楽しさ、面白さを体験する 大学 ) 、中村素典 ( 京都大学 ) 、廣津登志夫 ( 豊 またとない機会です。ぜひ、ご参加ください。 橋技術科学大学 ) 、前田香織 ( 広島市立大学 ) 、 山崎克之 ( 長岡技術科学大学 ) ・問合せ先 プログラム委員長 ( 植原、永見 ) e-mail : ic2006-submission@jus.or.jp ■開催概要 名称 : Lightweight Language Ring ( 通称 LL Ring) 主催・ LL Ring 実行委員会 協賛 : アスキー 日本 UNIX ユーザ 会、 Kahua プロジェクト、 T0kyo Perl Monge 「 s 、日本 PHP ユーザ 日本 Python ユーザ会、日本 Ruby の会、日本 GNU AWK ユーザー会ほか 開催日 : 2006 年 8 月 26 日 ( 土 ) 2003 年は LL Saturday 、 2004 年は LL 時間 : 1 0:30 ( 開演 ) ~ 21 :OO ( 終了予定 ) Weekend 、 2005 年は LL Day and Night 、 として LL ファンの期待に応えてきた 場所 : 新木場 1 stRlNG (http://west-c. com/l string/) Lightweight Language カンファレンスが、 参加費 : 3500 円 ( 予定 ) 今年もやってきます。 今年は、 LL Ring ! 場所を新木場 定員 . 300 名 ( 予定 ) 1 stRING に移し、熱き戦いを繰り広げます。 内容 : 軽量プログラミング言語に関する総 ーリい口 カンファレンスです。各出版社による関連書 Ring は戦いの場であるとともに「輪」でも あります。数多くの LL が同じ場に集まり、 籍の展示・販売も行なう予定です。 1 年間のアップデートを披露します。自分の URL : http: 〃 ll.jus. or.jp/2006/ 参加申込 : 2006 年 6 月 26 日 ( 月 ) チケッ 知っている言語はもちろん、知らない言語の ト発売開始 ( 予定 ) 新機能も堪能することができるでしよう。 問い合わせ先 : LL Ring 実行委員会 昨年は、昼・夜の 2 部構成でしたが、今 年は朝から晩まで約 12 時間 ! LL の醍醐 e-mail : inf02006@Il.jus.0 「 :jp ※詳しい情報は、 http://ll.jus.0「.jp/2006/ 味を丸 1 日堪能してください。 昨年までと同様、今年も各プログラミング にて発表していきます。 コごュニティの協力を得て、それぞれの に一口ロ、、 言語の特徴などを比較しながら理解できる セッションを多数用意する予定です。 こ数年の間に、軽量プログラミング言語 の果たす役割は大きく、そして応用範囲はよ タイトル : もう一度じっくりとセキュリティ を考えてみよう り広くなってきています。 LL Ring は、これ Lightweight Language Ring 開催のお知らせ : 高野光弘 第 137 回 jus 勉強会報告 : 高野光弘 123 UNIX magazine 2006 Summe 「

0Jecf な価値ある情報として広く無償で配布し、ビ ジネスや環境間題、また教育に役立てようと いうことになり、 Live E! は産官学共同のプ ロジェクトとしてスタートしました。 先ほどの自己紹介では、 Live E ! に直接 関係するような研究をしている方は少ないよ うでしたが・・ 石塚 : むしろ Live E! があったために生まれ た研究が多いのだと思います。私の研究もそ の 1 つです。街中にインフラが整っていない 状態で無線が配置してあると、アドホックネッ トワークさえ組めません。そこで、街中を巡 回する清掃車や市役所の車で、センサーノー ドからの情報を収集する研究をしています。 という洞井君のようなケースもあります。固 定センサーの情報収集に運び屋として移動体 を使っていますが、奈良先端大では以前から lnternet CAR project * 2 を行なっていまし たので、それを Live E! に合わせた形です。 写真 4 落合秀也氏 洞井 : 私はもともと、移動体にセンサーが付 して扱えば有効だと考えています。 いていると、どのようなことが起きるのかと 洞井 : 例えば、実際に移動しながら採取した いうことを研究していました。そこで、実際 温度情報は当然ながら精度が悪く、止まって に車に温度センサーを取り付けて街中を走ら 採取したほうが精度がよいわけです。そこで、 せてみたところ、短い距離間隔で温度情報を 移動しながら集めたデータを補正しつつ収集 採取できたのです。それまでは、時間軸に対 するということができれば、移動体でもかな してデータを取ることはしていたのですが、 1 り精度が高いデータを集められるのではない 人が移動することで、多量でかっ短い距離間 かと研究しています。 隔のデータ収集が可能だとわかったのです。 プロジェクト内での研究は、かなり広範 これを利用して、将来的にはヒートアイラン 囲にわたりますね。 ド現象などの環境問題に対し、何かしらの提 松浦 : 広いという意味では、小型ノードを 言ができるのではないかと考えています。 絡めた場合はデータをどのように扱うかとい 松浦 : Live E! と組み合わせて移動体と固定 う、落合君の研究ですね。 センサーの両方を扱い、しかもそれを LiveE ! 落合 : 小型ノードの中にはマイコンノードと の基盤で動くようにするにはどうすればよい いうものがあります。このマイコンノードは かという観点で、 2 つを統合しようとしてい パワーが小さく、インターフェイスが貧弱に なります。そのような場合でも、すべてのノー ますよね。 石塚 : ええ。今後は移動体を使って固定セン ドが抽象的なレベルで統一的にみえるように サーのデータを収集する手法と、移動体にセ しようとしています。そこで私の研究モデル ンサーを付けてデータを収集する手法を統合 では、それらのヘテロジニアスな世界で、ア 奈良先端科学技術大学院大学 情報科学研究科 洞井晋ー DOUI Shin'ichi 2002 年 3 月明石工業高等 専門学校電気工学科卒業。 2005 年 3 月神戸大学海事科 学部卒業。 2005 年 4 月奈良先端科学技 術大学院大学情報科学研究科 入学。 奈良先端科学技術大学院大学 情報科学研究科 松浦知史 MATSUURA Satoshi 1 998 年 3 月静岡県立沼津 東高等学校卒業。 2003 年 3 月立命館大学理工学部数学物 理学科卒業。 2003 年 4 月奈良先端科学技 術大学院大学情報科学研究科 入子。 松浦 : 逆に自分の研究を Live E! に合わせた ( 五十音順 ) 107 UNIX magazine 2006 Summer

旧 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

の最大の還元であると考えます。これを達成 否かといったテストそのものには、 TAHI の できたとき、 USAGI は完成するのです。 IPv6 仕様準拠テストを利用しています。 れにより、ずいぶん原因を特定しやすくなり ( 関谷勇司、吉藤英明 ) ました。加えて最近では、その時々のバグの 傾向もわかるようになりました。 ( 知念充 ) 日本アイ・ビー・エム株式会 社事業開発推進 AP Linux 技術センター副主任 知念充 CHINEN Mitsuru 2000 年 4 月、日本アイ・ ビー・エム株式会社に入社。 入社時より Linux 関連の業 務に従事しており、当初は国 際化を担当。 2004 年 9 月よ り USAGI プロジェクトに参 加。 USAGI プロジェクト内 では主に品質管理を担当。 Linux でとても素敵な MobiIe 旧 v6 これからの USAGI Project MobiIe IP とは、誤解を恐れずにいえば、 携帯電話と同じようにどこにいても同じ番号 ()P アドレス ) を利用でき、なおかっ移動の USAGI はこれまで多くの成果をあげ、そ 際に通信 ( セッション ) を維持したまま移動 れらはカーネルに採り人れられ、 Linux にお ける IPv6 環境は大きく改善されました。 するための技術といえます。 IPv4 でも MobiIe IP という技術はありま しかし、これはまだ土台が整ったにすぎま したが、 IPv6 では外部工ージェントの廃止、 せん。この上で本当に IPv6 が使われるよう になった現在では、仕様上の問題点、運用者 経路最適化などいくっかの改善点がみられま や利用者に対する知識の普及において発生す こでは、 Linux で MIPv6 を利用する す。 る問題が生じています。 ための手順を紹介しようと思います。 これらを解決するためには、 USAGI とは 図 1 のように、 MobiIe IP ではノードが移 動しても、あたかもホームリンクに存在して 異なる観点からの取り組みが必要なのかもし いるかのように振舞えます。そのためには、 れません。しかし、 USAGI が新たな機能を 最低限、 MN と HA が必要です。誌面の関係 実装する際に、運用者や利用者が戸惑いなく 上、詳細には説明できませんが、この 2 つ 使えるという観点を忘れてはならないと考え ます。これこそが Linux が普及してきた理 を UMIP を使って構築してみます。 由であり、利用者を置き去りにした機能追加 ・カーネルの再構築 残念ながら、現時点で MIPv6 は本家の や変更は、コミュニティに受け入れられない Linux カーネルには取り込まれていないの ものとなるのです。 USAGI のこれからの目 で、カーネルにパッチを当てて再構築する必 標は、 Linux コミュニティに IPv6 を根付か 要があります。カーネルとそのパッチについ せることであり、これこそがコミュニテイへ 牆 1 一 P 《 6 Ⅳ回Ø一 7 USAGI ニ P 《 6 on Linux eth0 移動しても 同し IP アドレスが利用できる ホームエージェント ethl : 2 0 01 : db8 : abcd : 2 0 0 0 : : 1 HomeLink: 2001 : db8 : abcd : 2000 : : / 64 eth0: 2001:db8:abcd:2000::abcd(Home Address) ホームエージェント 図 2 サンプルネットワーク構成図 図 1 MobiIe 旧での移動 60 UNIX magazine 2006 Summer

画面 1 に取得からパッチ当てまでの ては、 手順を示します。 1 度でもカーネルを再構築 した経験があれば、それほど難しい作業では ありません。また選択しておくべきオプショ ンはリスト 1 に示しているので、コンパイ ル則に忘れず選択してください。すべてが整 えば、あとは再起動させるだけです。 ■ mip6d のコンノヾイル Linux の MIPv6 の実装では、極力ユーザー ランド空間で実装するという指針があり、 カーネルだけでは動作しません。そこで必要 になるのが、 mip6d です。これは HA 、 MN 共に必要となるデーモンです。 mip6d のコンパイルに関しては画面 2 を 参考にしてください。この mip6d には、必 要なドキュメント類も同梱されているので、 6 とは何なのか ! ? 英語に抵抗のない方は、読をお勧めします。 ーサンプルネットワークについて こでは図 2 に挙げるように : / 64 HA を動作させるには、対応したカー ■ HA の設定 とおりだと仮定します。 を割当てます。各インターフェイス名は図の 2 0 01 : db8 : abcd : 2 0 0 0 : : abcd を、モバイルノードには、 2 0 01 : db 8 : abcd : 2 0 0 0 : : 1 す。ホームエージェントには、 をホームリンクとするような場合を考えま 2 0 01 : db8 : abcd : 2 0 0 0 : ネノレ 以外に、以下のパッケージが必要です。 ・ radvd ・ mip6d [ ソースコードのダウンロード ] $ c d $ SOMEWHERE $ wget ftp: //ftp .1inux-ipv6.org/pub/usagi/mipv6/kernel $ wget ftp : //ftp .1inux-ipv6.org/pub/usagi/mipv6/kernel [ 解凍および patch 当て ] $ tar zxvf kernel ー S20051214 . し ar. gz $ cd kernel ー S20051214 $ zcat . / kernel ー S20051214 ー um 土 p ー 0 . 1 . d 土 ff . gz ー patch -p1 ー s2 0 051214 . し ar . gz ー S20051214 - um 土 p ー 0 . 1 . d 土 ff . gz 画面 1 ソースコードの用意 共通 EXPER 工 MENTAL SYSV 工 PC PROC FS NET INET IPV6 IPV6 MIP6 XFRM XFRM USER XFRM ENHANCEMENT 工 PV6 TUNNEL 工 PV6 ADVANCED ROUTER IPV6 MULTIPLE TABLES 工 NET6 ESP NET KEY NET KEY M 工 GRATE モバイルノード 工 PV6 SUBTREES リスト 1 必要なオプション wget ftp: //ftp. 1inux-ipv6.org/pub/usagi/mipv6/mipv6-s20051214-umip-0.1. diff .92 wget ftp: //ftp. linux-ipv6 .0r9 / pub / usag 土 / m 土 PV6 / miPV6 ー S20051214 . tar. gz tar zxvf m 土 pv6 ー S20051214 . し ar .92 cd m 土 pv6 ー S20051214 . / m 土 pv6 ー S20051214 ー um 土 p ー 0 . 1 . d 土 ff . gz ー patch -PI zcat -isystem $SOMEWHERE/kerne1-s20051214/inc1ude ー CPPFLAGS= ー make sudo make 土 ns し a11 . /configure -enable-vt 注 ) -isystem で指定するカーネルヘッダへのパスは絶対パスである必要がある。 画面 2 mip6d の準備 アンカーテクノロジー株式会 社開発部開発部長 国武功ー KUNITAKE Koichi 会社へ移籍。 年アンカーテクノロジー株式 究所 (RINT) へ移籍。 2003 株式会社ネットワーク技術研 ナーズ株式会社入社。同年、 2001 年グルーオンバート した USAGI Project へ参加。 る lPv6 Stack 開発を目的と 加。 2000 年 Linux におけ lPv6 Users Group JP へ参 用に携わる。 1 998 年 Lin ux ターネットへ出向。旧 P の運 会社ドリームトレインイン ワーク株式会社入社。株式 1997 年三菱電機情報ネット UNIX magazine 2006 Summe 「