ているのです。自由にかっ最高のクオリティ で世界にリファレンスコードを配布できる組 織がなければ無理であると確信しました。 そこで私は WIDE のエンジニアに対し、 何かが決まったらすぐにソースコードとプロ トタイプを作り、実験をしようと呼びかけま した。そして協力してくれるグループを再構 築することで、 1 つのプロトコルスタックに することになりました。 IPv6 の仕様は 1995 年に決まりましたが、 WIDE ではすでにプロ トタイプのインプリメンテーションやさまざ まな議論で盛りあがっていました。次世代イ ンターネットの問題を理解しているエンジニ アが作ったコードを基に、 BSD のフレーム ワークで進めていこうということで KAME は始まったのです。 KAME の成功 当時のリーダーであった山本和彦氏から、 「 KAME の研究者が開発に専念できる環境を 作ってほしい」と話がありました。これは KAME 成功の 1 つの要因だと考えています。 優秀なエンジニアを専念させてくれた各企業 や組織、そして、本当に頑張ってくれたエン ジニアに感謝しています。 その後、 KAME には国際的な大きな事件 が起こるのです。 IPv6 のプロトコルスタッ クは、他の国々でも別の 2 つのインプリメン テーションを作っていたので、合計 3 っ存在 していました。それらと技術的な競争をした 結果、その 2 つが KAME へと統合されるこ ととなったのです。つまり IPv6 のリファレ ンスコードは、世界のコミュニティの協力で、 プロセスを経て KAME に一本化されたわけ です。私は日本のソフトウェアの歴史の中で、 これだけオフィシャルなプロセスを経て、世 界に貢献できた例は他に知りません。 そして、このリファレンスコードはさまざ まなところで使われるようになり、定期的な 6 とは何なのか ! ? UNIX magazine 2006 Summer さった皆様に厚く御礼を申しあげます。 我々の夢に長い間付き合い、支えてくだ のです。 それが KAME が「完成した」という意味な 情報社会の基盤を作ることに貢献すること、 持ってほしいと思っています。そして未来の げたもので世界が動いているという自信を 次の世代の人たちには、自分たちが作りあ づけにつながったと考えています。 会を作る」という所信表明演説が今日の位置 喜朗前総理の「 IPv6 を使い、 IT で日本の社 います。行政の方の支援もありましたが、森 とはありませんが、そう考えている方は多く になると思います。日本でブッシュをしたこ あり、それがプルになれば、新しいステージ ませんでした。しかしそれはまだブッシュで IPv6 があり、 IPv6 をただ推すものではあり イノベーションの中国へと変わるきっかけに いうテーマで、デベロップメントの中国から デベロップメントからイノベーションへ」と 中国での IPv6 サミットは「プロダクトの おいては最高潮だと感じています。 ロッパでの開発や期待が大変大きく、中国に IPv6 を取り巻く状況は、アメリカやヨー 旧 v6 を取り巻く状況 使われるようになりました。 で、 Apple を初めとした沢山のべンダーにも アップデートや標準化への貢献をしていく中 写真 1 村井純氏 (KAME 記念完成バーティにて )

リ N ー X U 5 e 「 P 「 0 i e ( を R e p 0 「 t 日本 NetBSD ユーザーグ ループ / 株式会社プレインズ 上林将郎 UEBAYASHI Masao 連絡先 . uebayasi@.」 p.netbsd.org uebayasi@brains. CO. 」 p NetBSD プロジェクトの近況 NetBSD プロジェクトの近況として、 3.0 報交換を目的として、 1999 年に設立された リリースと現在進められている開発、特に 任意団体です。会の運営方針は、年に一度行 機種依存部を中心に紹介します。 NetBSD の なわれる定期総会で決定します。 開発について、より長期的な展望については 現在は、主に以下のような活動をしており ROADMAP ファイル * 1 、貢献が望まれてい ます。 る作業については NetBSD Projects*2 を参 jp. netbsd. 0「g の管理・運営 照してください。 (WWW 、 FTP 、 ML) 本題に入る前に、日本の NetBSD の中心 ・年に一度の総会と BOF 的なコミュニティであります、日本 NetBSD ・イベントへの参加・出展 ューザーグループについて簡単に紹介いたし ( 主に蛯原氏による ) ます。 WWW ドキュメントの翻訳 ( 主に岡野氏による ) 会員は随時募集しているので、興味のある ■ JNUG について 日本 NetBSD ユーザーグループ (Japan 方は是非 JNUG のホームページを覗いてく NetBSD Users' Group 、通称 JNUG 、以下 ださい。また、 JNUG の運営委員も大々的 JNUG) は、日本での NetBSD ユーザーの情 に募集中です。 NetBSD release graph stable(release)branch security/critical branches (release branch netbsd-3 created; no new dis 「 uptive feature additions on the release branch) NetBSD-3.0 BATA http://cvsweb.netbsd. org/bsdweb.cgi/src/doc/ ROADMAP?rev=HEAD * 2 http://www.netbsd. org/contrib/projects.html main(HEAD)branch NetBSD-2.99.17 NetBSD-3.99.1 bug fixes NetBSD-3.99.2 NetBSD-3.0 RCI bug fixes NetBSD-3.99.3 NetBSD-3. O(release) bug fixes secu 「 ity fixes NetBSD-3.99.4 secu rity fixes NetBSD-3.1 (release) NetBSD-3.0.1 (release) NetBSD-3.99.5 bug fixes netbsd-3 branch netbsd-3-I branch netbsd-3-O branch in CVS repository in CVS repository in CVS repository $NetBSD: release-graph. fig,v 1.6 2004 / 07 / 06 08 : 55 : 07 he Exp $ 図 1 NetBSD リリースの系譜 NetBSD-current H EAD in CVS repository 128 UNIX magazine 2006 Summer

マイクロソフト株式会社業務執行役員最高技術責任者 ! 田中芳夫氏 マイクロソフトディベロップメント株式会社 及川卓也氏 ウインドウズ開発統括部グループプログラムマネージャ 楠正憲氏 マイクロソフト株式会社最高技術責任者補佐 Windows Vista イ汐ーネットへのアプローチ IPv6 の普及に、クライアント OS など ユーザー側環境の対応が重要なの はいうまでもありません。その上で、 2006 年Ⅱ月より Windows Vista を リリースするマイクロソフトの動向は注目したいところですマイクロソフト、およびクライアント OS の立場からみた、インターネット、および IPv6 について、田中氏、及川氏、楠氏にお話を伺いました セキュリティは多層防御であるべきと考えて 旧 6 は目的ではなく、手段 います。どれか 1 つで充分ということはなく、 IP よりもさらに下のレイヤー 2 から、一番 まずは、クライアント OS の立場から、 外側のレイヤー 8 、いわゆる人的なところま lPv6 ( 以下、 (6) をどう評価されていらっしや で、それぞれにセキュリティポリシーを設け、 るのかをお伺いしたいと思います。すでに、 実施する必要があるという考えです。 Windows XP から v6 ready になっていま 及川氏 : IPsec に関していえば、私どもは従 すが。 来から Windows を端末として考えた場合、 田中氏 : まず、 v6 は目的ではなく手段で トンネルモードよりも、トランスポートモー す。マイクロソフトとしてはさまざまなコン ドを重視しています。しかし、それも企業の ピューティングのあり方を考えています。 利用形態に依存するところがあります。例え 及川氏 . インターネットは本来 E2E 、もし ば ISA サーバといわれているファイアウォー くは P2P の形でした。しかし、今となって ル兼 VPN サーバには、 IPsec のゲートウェ はクライアント / サーバに縛られているとい イ機能を用意していますので、トンネルモー うことで、いびつになっているのではないか ドを含むすべての手段をオプションとして提 という思いがあります。もっと、クライアン 供させていただいています。 ト側 PC のいろいろな機能を利用するべきで ネットワークのアーキテクチャは P2P あって、そのためにはクライアント / サーバ であるべきということですね。しかし、一方 型にするのではなく P2P という概念を推進 でそれを利用した Winny は、その使われ方 したいと考えています。そのときにはどうし が問題となりました。 ても IPv4 ( 以下、 (4) では限界があるので 楠氏 . 私どもはテクノロジーとしての P2P と、その使われ方は区別して議論するべきだ v6 で進めるということです。 例えばセキュリティなども、クライアン と考えています。 Windows Vista では、無 線 LAN でのプロジェクタ接続、あるいは同 トの手元でやるべきということでしようか。 じ部屋の中にあるコンピュータ同士のアド つまり lPsec という蛇口がついているのだか ホックモードでの接続を、 P2P 技術で可能 ら自分で閉めなさいということでしようか。 田中氏 : それについては、 IETF でも多くの にしています。しかし、 P2P で何でもでき るから何でもしてよいということではなく、 議論があります。マイクロソフトとしては、 1 16 UNIX magazine 2006 Summer

ロロ N F E R E N ロ EkR E P ロ R TJ * 6 h t t p : / / w w w. ⅱ v e - eclipse.org/index.html のページ下部に各観測隊が撮 影した日食のダイジェスト版 が掲載されている。 皆既日食の前後に波打つ ような影が観測されること。 たが、このアプリケーションをすべての現場 ネタリウムのドーム上に、実サイズの黒い太 で導人していなかったことが挙げられます。 陽とコロナを投影することに成功しました。 3 つ目の原因は、 QTVR のコンテンツ自体が ■リビア・市川隊からの報告 観測地で制作したもので、中継が始まる直前 次にリビア隊の渡辺道和氏より、リビアで に完成したことにありました。そこで、いく 撮影されたビデオの上映と説明がありまし っかの改善方法が提案されました。 た。今回のビデオ制作では日食の様子のほか ①同一の Web 構築環境を、体験版などを利 に、氏が撮影したリビアでのスチール写真が 素材として使用されました。制作されたビデ 用し作成する ②可能な限り早く、事前の Web ページ作り オにはメイキングの様子も含まれており、日 食のみならず、リビアの雰囲気が前面に表れ 込みを行なう 写真 5 渡辺道和氏 現地観測班からの報告 * 6 ・トルコ隊からの報告 トルコ隊は下田哲郎氏より報告されまし LE2006 で現地観測を行なった 4 つの隊の た。トルコ隊は複数の候補地のなかから、日 うち、エジプト隊、リビア・市川隊、トルコ 食 3 日前の天気図を基にアドラサンに決定 隊の 3 つの隊から、実際の日食観測につい されました。現地は晴天に恵まれ、若干の雲 ての報告がされました。 は発生したものの付近の山脈に阻まれ、結果 ・エジプト隊からの報告 エジプト隊からの報告はプリント配布 ( 尾 的に雲がない美しい状態で観測されました。 K コロナの観測が行なわれ、シャドーバンド 久土正己氏作成 ) に代えられました。エジプ 7 の観測に成功したとのことでした。 ト隊はサルームを観測地とし、インターネッ ト中継用に太陽の拡大像とプラネタリウム全 天周像の観測を行ないました。現地の天候は 晴れで、観測自体は順調だったそうです。し かし、太陽拡大像については撮影に成功した ものの、皆既日食後に日本までデータが届か ないというアクシデントが発生しました。 またプラネタリウム全天周像は、東京都の タイムドーム明石のデジタルプラネタリウム に、全天周の静止画像を 2 分ごとに 1 枚と いう割合で送信されました。その結果、プラ 写真 6 下田哲郎氏 103 UNIX magazine 2006 Summer

* 5 Xeon 3.2GHz の CPU を 2 つ、メモリは PC2-3200 400Hz DDR2 の 4GB を搭 載したサーバで、 OS は Win dows 2003 Server Enter prise Edition R2 であった。 な現象を回避するためには、事前に配信が止 CPU 使用率が約 100 % 、ロードアベレージ まった場合のアクションを準備する必要があ が約 20 % であったのに対し、メモリ使用率 るとのコメントがありました は常に約 25 % であったことから、サーバの チューニングの余地が残っていたことがうか がえました。またチームでは、エンドユーザー が使用しているプレイヤーや OS などを調査 していました。 写真 2 東正美氏 プレゼンテーションチームからの報告 プレゼンテーションチームからは、工藤め ぐみ氏より Flash Video の配信報告がされ 写真 3 工藤めぐみ氏 ました。今回の中継では、 Flash の機能を活 広報からの報告 かしたインターフェイス作りをされたそう です。 Flash Video 配信システムは、東京と 広報からは岩城邦典氏より報告がありま 大阪に 2 台ずっ用意し、 XML を用いた負荷 した。今回は和歌山大学のデザインチーム 分散を行ないました。今回の負荷分散方式に BOX や個人、学生に Web ページの HTML より、サーバの負荷でクライアントが参照 コーディングを依頼したそうです。今回は複 するサーバを決定するということが可能に 数地点からの中継を同時に配信するというこ とが特色なので、 2 画面同時生成を行ない、 なったそうです。また配信には FIashMedia QuickTime VR (QTVR) と連動してリビア Server Version 2 が使用されました。前回 まではべータ版を使用していたためパフォー からの配信を行ないました。 QTVR につい マンスがよくなかったが、今回は正式版を使 ては、現地で観測を行なった市川雄一氏が制 用することにより、パフォーマンスが向上し 作しました。今回の反省点として、以下が挙 たとの報告がなされました。 げられました。 ①人手不足 インターフェイスでは、エンドユーザーが 視聴したい場所を選択する UI を備え付け、 ② Web ページ制作の共同作成環境の構築 映像が表示されるウインドウには中継場所と ③ QTVR から配信へのリンクが探しにくい 接続先サーバ名、サーバの設置場所が表示さ ④配信事故によるアナウンスを作成していな れるようになっています。また、現在のサー かった バのアクセス状況などを表示するものを作成 1 つ目の原因としては、 Web ページの作 したそうです。工ンドユーザーあたりのスト 成に携わった人間が、作業に注力できる時間 リーム数は、プレビュー用ストリームを 2 つ、 をなかなか取れなかったことにあります。ま 選択した場所のストリームが 1 つで、合計 3 た 2 つ目の原因は、 Web 制作にあたり、あ つを受信できます。それぞれのサーハ * 5 の るアプリケーションの共同作業機能を使用し 102 UNIX magazine 2006 Summer

6 とは何なのか ! ? 何千万の常時接続が可能になった結果がこの 情報漏えい社会です。 D 氏 : 漏えいの問題に関しては、 P2P の問 題というより、 OS やアプリケーション側が アーキテクチャとしての P2P はどう 防御面の開発をサポっている部分もあるよう なっていくのでしよう。 Winny を例にする にも見えますね。 と、機密の漏えいという文脈では語られてい A 氏 : プログラマーには OpenBSD の責任 るけれど、 P2P アーキテクチャとしてはほ 者である Theo de Raadt ぐらいのテクノロ とんど表面化していません。 ジと発言力が要求されるんじゃないかという A 氏 : はやりに乗るわけではないですが、い 話があります。一方で、自由でオープンであ わゆる Web 2.0 を実現しているセントリッ るからこそ、皆がプログラムを作って、よい クなシステムとして、 GoogIe や、 Amazon も悪いも含めて広まって、セキュリティホー があります。一方で、コンテンツの配信は全 ルもありつつ、そこから新しいアイデアが生 部 P2P でやりましようという流れがありま まれてきたのです。 す。つまり、集中と分散ですね。データベー D 氏 : ネットワークにつないだ以上、いく スがコンピュータシステムの 1 つの本質です らアプリケーションや OS が堅牢になろう から、まずはセントリックなデータベースを と、必ず穴があると考えたほうがよいですね。 引いて、そのデータからリッチコンテンツを 漏えい間題はなくなりません。アタックされ 引っぱってくるのは P2P アーキテクチャと るのがデフォルトで、ユーザーは皆、自衛す いうことになるのだと思いますね。 る意識を持つべきです。それに、ソーシャル D 氏 : Winny はよいアプリケーションだと 工ンジニアリングまでシステムで面倒は見切 は思いますが、クライアントでもありサーバ れないと思いますよ。 でもあるソフトウェアを、ユーザーが意識せ ずに使っているところに難しさがあり、危う さがあるという考え方を友人に教えてもらい ました。自分の手元にあるのはサーバなのだ 一般ユーザーに対して、ネットワークや から管理しなければならないということを、 コンピュータの危険性がきちんと伝えられて アプリケーションがユーザーに意識させなけ いないと感じています。例えば、銀行の指紋 ればならない。そこが欠如しているから、管 認証では、万が一その指紋データを格納して 理を意識しないユーザーは、「俺に責任はな いる DB がクラックされたらどうなるのか。 いよ」という。責任を持つのが嫌なら、シン 変更することができない ID がクラックされ クライアントにすればよいのでしようが。 ることのリスクがきちんと説明されていませ ん。一般ユーザーの情報リテラシはまだまだ 自分の PC がサーバになっていることを自覚 低いのが現状で、ネットワークや通信が安全 していません。サーバである以上、コピーコ だと思い込んでいるのではないでしようか。 ントロールなどの管理をしないとならないは D 氏 : 通信の秘密が通信事業者によって担 ずです。イリーガルなはずなのに、そんな意 保されていると思ってはだめですね。 IPsec 識もなくダダ漏れしている。これはアーキテ で暗号化できるようになっているのですか クチャの甘さなのでしようか。 ら、ユーザーは自分で自分を守るべきです。 今の状況を想像していなかったでしようね。 アーキテクチャとしての P2P インターネット・リテラシと教育 C 氏 : その通りですね。 P2P のユーザーは、 0 A 氏 : 5 年前、 e-Japan を推した人たちは、 A 氏 : しかし、そのことを議論すること自 87 UNIX magazine 2006 Summe 「

べきですね。 D 氏 : Google や Amazon は、テジタルで集 先ほどから話題となっている、インター められる情報や人のアクティビティを集めて ネットのアーキテクチャを含め、日本ではそ 解析しているというのがおもしろいと思いま の「社会システムデザイン」をしている人が す。そういうアプローチをする会社が日本に 少ないように思えるのですが。 もあるとよいのにと思います。 A 氏 : 少ないのではなくて、いないですね。 D 氏・この国のネットワークをどのように イフログというのがおもしろいですね。その したい、という議論があるようには思えませ 日の行動なり、食事なりの記録をつけていく。 ん。総務省の発表でも、携帯電話が 9000 万 人間の欲望の 1 つに、後世に自分の名前を残 台あるとか、光を 3000 万回線にするとか、 したいというのがあるとすると、お墓の代わ 箱物の議論がほとんですよね。 りに、ログを残して ID を振って、みたいな C 氏 : いろいろな人がいて社会的な前提条件、 サービスが出てくるかもしれませんね。 技術的な前提条件がありますから、どうした いかという議論は難しいのだと思いますよ。 例えば Amazon のように、その中から自分 こそこそっと決めるか、大勢の流れ に適している情報を選んで整理して、アップ で決めるかがこの国の決め方ですね。そのど デートする、そんなサービスがほしいですね。 ちらも嫌だけど。 : デジタルコンシェルシュですね。 を決めるべきです。そのほうが建設的ですよ。 ではなく、必要なメールを優先するテクノロ ジをインプリメントしてほしいですね。自分 め方はどうであれ、結果が大切ですね。いっ に重要なメールがどれなのかを学習する機能 までも決め方について議論しているのは不毛 がほしいのです。本当に必要なものに対して です。また、ある程度クローズされた中で方 の帯域制御を行なう機能、 QoS と同じですね。 針を決めなければ、短時間では結論が出せま C 氏 : 最近のビデオレコーダーのお任せ録 せん。重要なのは、その後どのようにコンセ 画はかしこいですよ。キーワードに引っか ンサスを得るか、それをディスクローズして かって録画しても、再生しなかったり、見な いくか、ということでしよう。 いで消去した番組は次から録画しなくなる し、 DVD に焼いた番組は必ず録画するとい うように優先順位を変えてくれる。メーラも それぐらいできると思うのですが。 A 氏 : 梅田望夫さんの「ウエプ進化論」の おかげで GoogIe が話題になっていますが、 たかとか、誰に対して返信したかどうかなど 実は、 Google は密かにこれまでの情報をアー を条件にして優先順位をつければ、それでア カイプしているのではないかと思ってます。 ルゴリズムができますね。 Gmail のインター 「 GoogIe だって、他に優れたプログラムがで フェイスを見ていると、それぐらいできそう たら、すぐっぷれる」という主張があったの な気がします。 ですが、違うのではないかと。 Google のア ドバンテージは、プログラムを作るという技 ういうところに使ってほしいな。個人にとっ 術ではなくて、これまでに溜め込んだ情報資 ては「優先」するテクノロジ、マスに対して 産の大きさだと思いますね。 は「ドロップ」するテクノロジですね。 A 氏 : その点で個々人の視点に立っと、ラ 1 D 氏・これだけ世の中に情報が溢れていると、 一 P 《 6 化回Ø一 7 B 氏 C 氏 D 氏 : メーラもそろそろ、スバムをはじくの D 氏 : 決め方の議論ではなくて、何をするか A 氏 : 誤解を恐れずに極論してしまうと、決 次世代 Web サービスに必要なのは テジタルコンシェルジュ A 氏 : そのメールをどのくらい注意してみ D 氏 : フィルタやシェーパのテクノロジをそ 86 UNIX magazine 2006 Summer

6 とは何なのか ! ? IPsec といった、次のテクノロジが開発され 個人情報保護を声高に主張する学園紛争の反 てきたということは重要だと思います。で 体制世代がメディアに人っている。 も、今デザインするとしたら携帯電話のよう B 氏 : 日本のマスコミのゆがみ方って、そ に、オプジェクト・アイデンティファイと、 こに起因するところが大きいと思いますね。 ロケーション・アイデンティファイの明確な A 氏 : また、監視カメラを例にすると、もと 分離を前提としたり、 NAT というコンセプ もと体制側はこっそりやっていて、一方で絶 トをもっと意識したデザインがあるんじゃな 対許さないという人たちがいました。だけど、 いでしようか。また、 IPv6 はアドレス枯渇 日本でもさまざまな事件が起こる中で、役に の間題は解決するとしても、今、我々が抱え 立っ代物だということがわかったので既成事 ている the lnternet の問題、つまり過剰な 実化されています。さらに、 9.11 の事件で 匿名性と、欠落した公平性という問題につい セキュリティに対する意識が大きく変わった てはソリューションを持っていないのです。 のもあると思います。 the lnternet のアーキテクチャをデザインす 英国には、世界の 40% の Web カメラ るなら、プロトコルだけではなく、レジスト があるといわれていて、街中のいたるところ リ、ガバナンスまで含めて考える必要があり に Web カメラが設置されています。多少の ます。例えば、韓国ではユーザー 1 人 1 人 プライバシーを犠牲にしたとしても、安全が にグローバル IP アドレスを割り当てるサー 担保されるのであればよい、セキュリティと ビスを開始するとも聞きました。 プライノヾシーのトレードオフという結論を国 民が出しています。日本でも、年中小学生が 全員に付与された個人 ID でサービスを受け 事件に巻き込まれるような状況です。英国と るという土壌があるので、抵抗がなかったの 同じようにあちこちに Web カメラをつけると でしようね。また、韓国はもともと、 ISDN いうことを議論してもよいと思うのですが。 というフェーズがなくて、インターネットは C 氏 : IPv6 を有効に用いたソリューション ADSL から始まったという歴史的事情があり の 1 つはそれですよね。安全のためには、そ ます。そういう事情が国ごとにあるので、イ れなりにプライバシーを供出するという考え ンターネットアーキテクチャもそれぞれ違っ 方ですね。 A 氏 : 家の中のような、プライベートな場 てきますね。 所はもちろん嫌だけれども、セミパプリック をどうデザインしたいのか、きちんと考えな 以上の場所であれば、ある程度はしようがな ければなりません。もやもやっとしたグロー いという考え方ですよね。 バルスタンダードという言葉の上で踊っても こうしてみると、さらにアーキテクトと しようがないですね。日本のデジタル情報社 オペレーターの乖離があるような気がします。 D 氏 : 今のインターネットの匿名性という 会をどうデザインしようかという話がまず必 のは、そのようにデザイン・実装してきてい 要なのだと思います。 るからそうなっているだけであって、デジタ ル社会はどういう方向にももっていけるわけ うな気がしますね。匿名性への要求が大ぎい です。 IPv6 だって、韓国のように個人に IP というか、個人情報に対して過剰にディフェ を配って、ソーシャルセキュリティナンバー ンシプだと思います。 のように使うということだって可能です。ど うするかは、社会システムのデザインである メディアによる影響が大きいと思いますよ。 C 氏 : もともと「住民登録番号」という国民 D 氏 : そう。それぞれの国でアーキテクチャ B 氏 : こど、今の日本は匿名性が高すぎるよ A 氏 : 日本人の個人情報に対する過敏さは、 85 UNIX magazine 2006 Summer

* 5 ようですね。もう 1 つ付け加えると、オペ チンワークである、といい切ってしまえばコ レーターは今日、デベロッパーは明日、リサー スト削減の対象になるのですね。 チャーは明後日を見ている、というイメージ B 氏 : オペレーターにゲームマスターぐらい ですね。オペレーターは今日のことで手一杯 の市場価値があれば相対的にバリューがあが じゃないですか。 ると思いますよ。でも、製造に極めて近い部 D 氏 : 特に、インターネット上でサービス 分でのオペレーションということになると、 を提供している xSP * 5 のオペレーションに 低く見られるという傾向があるのでしよう。 ついていうと、その組織のモデルを再考する D 氏 : オペレーションには、「保守と運用」 必要がありますね。つまり要求仕様をまとめ という役割があります。保守は、ルーチンワー て、実装して、メンテナンスフィールドに落 クの部分ではあるけれども、運用は違います。 ちる、というループが簡単にできる組織をつ 製造業のような計画経済のクローズドな世界 くらなければなりません。フィールドが大き では、保守・保全の考え方で完結するのかも くなってくると、反応が悪くなりますから。 しれないけれど、オープンな世界では、外部 例えば、 Amazon や、 Google がソフトウェ からの攻撃や顧客満足度を保たなければなら ア開発のチームを社外に持っていると私は思 ないという点で、運用でしかあり得ません。 デジタル系は永遠の未完成品であるという部 えないのです。 : 逆のいい方をすると、彼らは、ネッ 分にコストを積まないから元気が出ませんよ トワークのオペレーションを外注してもよい ね。それではオペレーションの進化を止めて わけでしよう ? しまいます。 D 氏 : そう、彼らからみれば、ネットワー A 氏 : 運用をやっている人たちに対して、あ クそのものはどうでもよくて、ビジネスとし まりにも周囲からの支援がなさすぎるという て重要なのはサービスですね。 ことですね。 今はそれぞれのプロセスのバリューの構成 が、以前に比べると逆転しています。つまり、 製造フェーズやオペレーションのバリューが ペレーションで小細工をしなければならない 相対的に低くなっていて、何を作るか、どう やって売るか、というフェーズの価値が高く という現状がおかしいのです。皆よくわかっ なっています。 ている善人だからそんなことはしないよねと いう前提条件が崩れていることを認識するべ クだと見られているからです。しかし、実際 きです。アーキテクチャそのものに、ガタが にはそうでない部分がかなりあります。イン きているような気がしますね。 : 間違っているかどうかも問題ですが、 ターナルなネットワークの運用は別として、 ISP がなぜオペレーションを残しているのか そもそもアーキテクチャにオルタナテイプが ないことが問題でしよう。カウンタブロポー というと、日々進化する外からの攻撃に対応 ザルがあって、両者を比較、あるいは融合し しなければならないからです。 A 氏 : 顧客への対応もオペレーションですが、 てアーキテクチャが決まるというのが当たり ルーチンワークで対応するか、オンデマンド 前だと思いますが。 D 氏 : 1 つの考え方として、電話がアナログ で対応するかというところはグレーゾーンで す。だから顧客対応もパッケージ化してルー からデジタルになる過程で、制御信号とデー xSP: 旧 P や ASP など、ネ ットワークを介してサービス を提供する各種サービスプロ ノヾイダの総称 1 一 P 《 6 作回Ø一 7 B 氏 : マーケティングの見地から発言すると、 インターネットに対する カウンタブロポーサル rNGN 」 D 氏 : そもそも、外からの攻撃に対して、オ D 氏 : それは、オペレーションがルーチンワー 82 UNIX magazine 2006 Summer

6 とは何なのか ! ? * 10 [ 1 ] Y. K. DalaI, R. M. Metcalfe, Reve 「 se Path Forwarding of Broadcast Packets, 旧 : Communications Of the ACM, 2 1 ( 1 2 ) : 1 040-1 048 , 1978. 最大参加者 : 30 m a t s u 「 i 1 参加者数 つつ・つ一 すっ・つ一 つつ・つ つ一・つ の寸・ 7 ナ 7 ・つ 7 のつ・の一 寸っ・つ一 す・つ 7 つ一・つ 7 っ 0 ・つ一 、つ・つ一 一す・つ * 1 1 Lorenzo Aguilar, M U 凵刊 C A S T V ー R T U A L C 旧 CUIT SERVICES FOR PACKET SWITCHING, Ph. D dissertation, The OhiO State University, 1 992 時刻 最大トラフィック : 3.5Mbps 3600 ℃ k c 2700. O k 8 1800.0 k の 900.0 k 0.0 k 8 1 0 1 2 14 1 6 18 20 22 0 2 図 5 参加者とトラフィックの様子 事情が変わってきたのです。アドレスリス lnternet Research Group で提案していまし ト方式による同報は、 1984 年には AguiIar た。この lnternet Research Group につい 氏が、さらに遡ると 1978 年の段階で Y. K. ての詳細は不明ですが、どうやら IETF がま * 10 、、 DaIaI 氏と R. M. MetcaIfe 氏か発案し だ存在しなかった時代に、インターネットの ていたのです。 Aguilar 氏はこのテーマで プロトコルについて議論する会合だったよ Ohio state University の博士学位 * 1 1 を取 うです。筆者は、 ISOC と IANA と IETF と 得し、 IEEE SIGCOMM に論文が採録されて IRTF を混ぜこぜにした、ご先祖様みたいな ものだと考えています。 いました。 つまり、現在インターネットの標準となっ しかし、彼の提案は会合において完全な賛 ているグループアドレス方式が現れる前に 同を得ることはできませんでした。宛先リ Multicast という言葉はすでにこれらの論文 ストを IPv4 オプションとして埋め込もうと で使用されていたのです。 XCAST のアイデ したため、同報できる宛先が少なすぎると アが特徴的なのは、 1978 年および 1984 年 されたのです。とはいえ、インターネット に、同時に複数の人間によって発見されたと 上での遠隔会議に MuIticast が必要であると いうだけでなく、約 20 年後に同じアイデア いうコンセンサスは形成されました。これが が、まったく独立して再発見されたという点 元となり、有名な 1985 年の "Host groups: にあります。 A multicast extension tO the lnternet ProtocoI" (RFC 966 ) が生まれました。 lnformational RFC への投稿により、 その後、 Multicast 技術の標準化および実 RFC-editorial board による査読が行なわれ、 考えてもみなかった大変興味深い昔話が明ら 装の成熟は、多くの優秀な研究者によって 争うように進められてきました。インター かになりました。 Agu ⅱ ar 氏は学位を取得し た後、 Stanford Research lnstitute に移り、 ネット 2 では多くの大学がマルチキャスト 初期のインターネットコミュニティに深く 網に接続され、 AccessGrid の成功の重要な 鍵となりました。一方で、いまだ商用マル 関与していました。そして自身の MuIticast チキャストの普及には至っていません。この を、多地点会議のためのプロトコルとして 8 1 0 1 2 14 1 6 6 4 UNIX magazine 2006 Summer