無印吉澤（※新エントリはhatenablogに掲載中）

■[書評]なるほどナットク！ P2Pがわかる本

P2Pがわかる本(岩田 真一)

最近すっかり更新が滞ってしまって本書の出版からだいぶ経ってしまったのですが……このサイトの読者的には面白い本だと思うので、簡単に書評を書いてみます。

この本は、P2P技術に関連する話題を一通り網羅した解説本です。主な話題は以下のようになってます。

• P2Pの基礎・用語解説
• P2Pのメリット
• Napsterから始まるP2Pの歴史
• P2Pアプリでよく使われる技術の紹介
• P2Pアプリの例
• P2P技術をビジネス分野へ適用する際の注意点
• P2Pフレームワーク紹介

著者の岩田さんは、以前はP2Pのグループウェアを開発・販売するアリエルネットワーク社に勤めていたのですが、現在はSkype Technologies社に移られて、日本におけるSkype社のCTO的な立場で活動されている方です。そんなP2Pの専門家が

本書は、これまで筆者が訪問活動や講演活動、あるいは雑誌執筆などで行ってきたP2P技術の説明をまとめたものです。「P2Pとは？」という問いに対して、この1冊でかなり技術的に深いところまで理解していただける、というレベルを目指しました。（「はじめに」より抜粋）

ということで、多様な話題が整理されて読みやすくなってます。

ただ、P2Pファイル交換ソフトについては、P2Pの歴史に関する部分でNapster、Gnutella、KaZaA（FastTrack）が紹介されている程度なので、そちらを期待する向きには物足りないかもしれません。まあ、その辺は本書の対象外ということで……。

----

内容について簡単に触れると、この本には「P2P技術に興味のある初心者向け」の側面と「P2P技術に積極的に関わる人向け」の側面があります。

「P2P技術に興味のある初心者向け」の側面としては、前から後ろの章に向けて、用語の意味をはっきりさせながら、少し難しめの内容を着実に積み上げている印象を受けました。

例えば、p.14の「P2Pシステムの基本構成」では、P2Pネットワークで使われる接続を

1. 基本ネットワーク
2. ダイナミックP2Pアクセス

の2つに分類して、前者を「P2Pネットワークを維持するために常時張っている接続」、後者を「（Skypeにおける通話など）実際に必要なときのみ、当事者のノード同士で張られる接続」と定義しています。ここはP2Pという単語を使う際に誤解を招きやすいポイントなのですが、長年P2P技術に関わってきた著者だけに、そのあたりにはきちんと注意が払われていて誤解がないのではないかと。

また、「P2P技術に積極的に関わる人向け」の側面としては、ビジネス用アプリを開発する際の注意点や、P2Pアプリケーションを開発する際の注意点がまとめられています（前者はP2Pアプリに限らない話ですかね）。このあたりは、P2Pアプリケーションを作る際のチェックリストとして便利そうです……というか、読者にP2Pアプリを作らせようとしているとしか思えない内容です*1。初心者向けの本とは思えません。濃すぎ。

というわけで、これは毎日P2P todayをチェックしてしまったり、過去にうっかりP2P勉強会やらSkype Conferenceに参加してしまっているような人にはオススメの本です。

参考：ビジネスという現実に直面したP2P（第1回P2P勉強会での岩田氏の講演）
http://muziyoshiz.jp/20040911.html#p09

■[NAT][VoIP]MicrosoftとCiscoがICE対応を表明？　それがどうしたというのか（前編）

Microsoft と Cisco、『ICE』技術をサポート(Japan.internet.com)
http://japan.internet.com/webtech/20051111/12.html

Microsoft と Cisco Systems は10日、『Interactive Connectivity Establishment』(ICE) 技術をサポートすると共同発表した。サポートの狙いは、ファイヤーウォールやネットワークアドレス変換 (NAT) 機能を備えたルーターを超えてあまねく VoIP 通信を可能にすることにある。

ここで述べられているICEというのは、CiscoのJ. Rosenberg氏が2004年に提唱し、IETFで標準化が進められてきたNAT越え技術です。

NAT越え技術というやっかいな代物の標準化が進むのはすばらしいことです。とはいえ、今回の話については「MicrosoftとCiscoが『我々はIETF標準のNAT越え技術を使っている』と言えるようになる」という以上の意味は無い、というのが僕の個人的な感想です。

そこで、今日はそのあたりについてツッコミを入れてみたいと思います。

----

この日記を書いている時点で、ICEに関する最新のInternet Draftはdraft-ietf-mmusic-ice-06です。原文を読みたい方は、以下のサイトから当たってみてください。

Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
http://ietfreport.isoc.org/idref/draft-ietf-mmusic-ice/

あとで暇が出来たら、ICEのInternet Draftを読み直した上で図を書いて説明したいところなのですが（前に読んだときと比べてページ数が倍近くなってる！）、今回は話の前提として、ICEがどのようなNAT越え技術なのかを簡単に説明してみます。多分、基本的な話は変わってないと思いますので……。

ICEとは、シグナリングプロトコルを用いて確立するメディアストリームの経路を最適化することに特化したNAT越え技術です。ICEの想定する主なシグナリングプロトコルとはSIPなので、以下ではシグナリングプロトコル＝SIPとして話を進めることにします。

通常、SIPでメディアストリームを確立する際には、発側のSIP UA*1は自分が使えるIPアドレスやコーデックをSIPメッセージに含めて相手に渡します。そして、着側のSIP UAが通信を許可する（＝電話の場合は受話器を上げる）と、着側のSIP UAも同様の情報をSIPメッセージに含めて相手に渡します。このとき、通常なら教えあうIPアドレスはそれぞれ1つだけです。

一方、ICEに対応するSIP UAは、使える可能性のあるIPアドレスを事前に調べ上げておいて、それら全てをSIPメッセージに含めて相手に渡します。以下は、そのようなIPアドレスの例です。

1. 端末に割り当てられたIPv6アドレス、6to4アドレス、IPv4アドレス
2. 事前にSTUNで取得したNAT上のグローバルIPv4アドレス
3. 事前にTURNで取得したTURNサーバのIPv4アドレス

SIP UAはこれらのIPアドレスを順番に使ってパケットの送受信をテストし、それに成功したらメディアストリームを確立します（このテストにはSTUNプロトコルを用いる）。その結果として、ICEに対応するSIP UAは最も遅延の少ない通信経路を利用することができるわけです。

例えば、同じプライベートネットワーク上にあるSIP UA同士が通信する場合は、プライベートIPアドレスを使ってend-to-end通信を行うのが最短経路になります。SIP UAがICEに対応している場合は、この最短経路を見つけ出すことができます。

しかしSIP UAがICEに対応していないと、SIP UAはIPアドレスを1つしか相手に渡せません。そのため、SIP UAは事前にSTUNまたはTURNで取得したグローバルIPアドレスを相手に渡さざるを得ず、結果としてend-to-endでない通信になって無駄な遅延が発生してしまいます（STUNの場合はNAT経由*2、TURNの場合はインターネット上のサーバ経由の通信になる）。

----

うーん、どうですか？　こんな説明で、ICEの基本的な機能は伝わりましたでしょうか。ここまで書くのにだいぶ手こずってしまったので、後編は明日以降に書きます……。

■[NAT][VoIP]MicrosoftとCiscoがICE対応を表明？　それがどうしたというのか（後編）

前回の日記では、ICEというNAT越え技術はどのようなものか、というお話をしました。今回はその内容を踏まえて、メインのツッコミ部分に入っていきます。

ちなみに、今回の日記を書くにあたってICEのInternet Draft（draft-ietf-mmusic-ice-06）を一部読み直してみたのですが、全部で82ページもある面倒くさい代物なので、1〜6章と8〜12章だけ読んで済ませちゃいました。抜けがあったらそのせいです。そっと教えて下さい。

----

MicrosoftとCiscoがICEをサポートしても、それをきっかけとしてICEが広く使われるようになるとは思えない……と僕が考える理由は、主に2つあります。1つは、ICE自体がSIP UAの実装に大がかりな変更を要求すること。そしてもう1つは、特にSIPとの連携において、ICE自体に曖昧な部分が多いことです。

※以下の記述は個人的なメモとしての意味合いが強いので、細かい点に興味が無い方は一番下の「ICE対応＝独自実装対応」まで飛んで下さい。

■ SIP UAへの変更点

一口にICE対応と言っても、そのために必要なSIP UAの機能はとても多いです。

第一に必要な機能は、それぞれのSIP UAが、自分の使える可能性のあるアドレス（以下、アドレス候補）を取得して、相手のSIP UAに渡すための機能です。アドレス候補を取得するためにはSTUNクライアントやTURNクライアントの機能が必要ですし、そのアドレス候補を相手のSIP UAに渡すためにはSDPの拡張が必要です*1。

次に必要な機能は、相手から渡されたアドレス候補のうち、どれが使えるかを検査するための機能です。ICEではこの検査を接続性チェック（Connectivity Check）と呼んでいます。この接続性チェックは、かなり細かい状態遷移を伴う複雑な処理のようです。また、このチェックにはSTUNプロトコルを使うため、ICE対応のSIP UAはSTUNサーバを任意のポートで起動できる必要があります。

最後に必要な機能は、上記の接続性チェックに成功したソケットを、メディアストリームの受信に流用する機能です。しかも、Internet Draftに載っているシーケンス例では、一度メディアストリームの受信を開始したソケットについても、引き続きSTUNサーバとして動作することを要求しているふしがあります（必須ではないのかもしれませんが）。

このように、ICEをサポートするために必要な機能は、SIPのセッション確立に関わる全ての処理に影響しています。UPnPやSTUN、TURNといった単独で成り立つNAT越え技術とは異なり、ICEはシグナリングプロトコルと非常に密着しているのです。

■ ICE仕様の曖昧な部分

僕がInternet Draftをざっと読んだ印象では、ICEの仕様は非常に分かりにくい上に、曖昧な部分が多いような気がしました（この点について、詳しい人のコメント求む）。

特にSIPとICEの連携については、「接続性チェックによって生じる遅延の解消方法」と「STUN/TURNサーバの認証とSIPサーバの認証の連携方法」が曖昧な気がします。

前者の「接続性チェックによって生じる遅延」とは、200 OK送信からメディアストリーム開始までにかかる遅延のことです。ICE対応のSIP UAは、200 OKが送信されると接続性チェックを開始し、少なくとも1つのアドレス候補について接続性チェックが成功したあとで、ようやっとメディアストリームを開始することになります。この状況を電話にたとえると、受話器を上げてからしばらくの間は無音状態が続くということです……あまりよろしくないですよね。

で、この問題に対して、現在のInternet DraftはRECOMMENDEDとして以下の解決案を挙げています。

• 200 OKの前の18x provisional response（RFC3262）でSDPを交換して事前に接続性チェックをしてしまい、その後UPDATEメソッド（RFC3311）で最適なアドレスに切り替える
• RFC3262とRFC3311をサポートしていない場合は、unreliable 18x responseとre-INVITEで代替する
• とはいえ、unreliable 18x responseは相手側に届くことが保証されていないので、RFC3262にあるような再送を行うようにする

本来なら、この部分をもっとちゃんと決めておく必要があると思うんですが、このInternet Draftでは上記のような正常系について簡単に（全82ページのうち1ページ程度）触れているだけです。

一方、後者の「STUN/TURNサーバの認証とSIPサーバの認証の連携」はSTUNサーバやTURNサーバを勝手に使わせないようにするために必要になります。これは、管理外のSIP UAに使わせないようにする、ということも必要ですが、想定外の用途（ファイル転送など）には使わせない、ということも必要になるでしょう。特に、企業ユースなら尚更です。

STUNやTURNのプロトコルは元々単純なパスワード認証の機能を備えているのですが、そのためのアカウントをいつ発行し、どの程度の期間で無効にするのか？　ログイン時にアカウントを発行するのか、それともセッション確立時に発行するのか？　SIP UAはSTUN/TURNサーバをどうやって見つけるのか？　このあたりは、他社SIP UAとの相互接続性を考えると、曖昧なままでは困る部分ではないでしょうか。

■ ICE対応＝独自実装対応

以上のように、ICE対応というのは、従来のSIP UAに対する追加機能としては非常に重い機能であり、また曖昧な部分も多いと言えます。それに加えて、ICEはまだRFC化されていない不完全なプロトコルです。そう考えると結局、ICEに対応するということは「MicrosoftとCiscoの独自な仕様解釈に合わせてソフトウェアを作り込む」ことに他ならなくなってしまうのではないでしょうか？

また、その他のSIPソフトウェアメーカにとって、今更SIP UAをICEに対応させるメリットがあるかどうかも疑問です。というのも、今までIETFでSIP UA側のNAT越え技術を標準化するのが遅れすぎたため、SIP IP電話の世界では、既にSIP ALGやSBCといった、SIP UAに対して透過的にNAT越えを実現するサーバ製品が普及してしまっているからです。

要するに、今回の話はMicrosoftとCiscoがようやくIP電話に本腰を入れ始めたという以外の意味はないと思います。NAT越えの標準技術が採用されたからといってSIPの相互接続性が上がることはなく、Microsoft・Cisco連合とその他大勢の間の相互接続性は逆に下がっていくような気がしてなりません……。僕が悲観しすぎてるだけならいいんですけどね。

■[Teredo][IPv6][NAT]KAMEとTeredoと「どこでもIPv6」

KAMEプロジェクトの完成宣言 − IPv6研究開発：運用と応用に軸を置いた新段階へ（プレスリリース）
http://www.wide.ad.jp/news/press/20051107-KAME-j.html

「KAMEプロジェクト」と言えば、WIDEの人たちが集まってBSD系OS向けIPv6スタックを開発するという内容の、極一部では非常に有名なプロジェクトです。しかし、最近はIPv6の基本的な仕様と実装の安定化に伴い、IPv6スタックそのものを大勢で作り込むこともなくなり、今回のプロジェクト「完成」に至ったようです。

正確に言うとプロジェクトの完了は2006年の3月になるということですが、部外者ながら、関係者の皆さまにはお疲れ様でしたと言いたいです。不完全な仕様＆実装を作り込んでいく仕事は、きっと楽しかったでしょうね……。部外者の勝手な想像ですけど、うらやましい限りです。

で、そのKAMEプロジェクトの歴史や内部事情をまとめた面白い記事が、IPv6styleで公開されていました。

IPv6style:KAME プロジェクトの歴史と成果
http://www.ipv6style.jp/jp/special/kame/20051121/index.shtml

個人的は、2ページ目の特許問題の話がこの中で一番面白かったです。一部引用。

KAME プロジェクトでは、 特許問題のないプロトコルはもちろんのこと、特許が取得されていても契約なしに無料で利用できるのであれば実装してきた。しかしながら、契約が必要であったり、使用料を払わなければならない場合は、実装しない方針をとっていた。

理由は次の通り。まず、KAME プロジェクトの成果物は無償だから、使用料がかかるのは困る。次に契約についてだが、対象が実装者と利用者の 2 つの場合がある。実装者である KAME プロジェクトに契約が求められる場合、KAME プロジェクトには契約を結ぶ枠組みがない。

また、利用者に契約が求められる場合、KAME プロジェクトでは面倒をみれないし、KAME プロジェクトの成果物に契約を結ぶといった制約が加わることは、我々の望むところではない。そもそも、誰に対して契約を求めているのか明確でない特許もあった。

• Source Specific Multicast(SSM)
• Modular Exponential(MODP)
• Network Mobility(NEMO)
• Internet Key Exchange version 2(IKEv2)
• Intra-Site Automatic Tunnel Addressing Protocol(ISATAP)
• Virtual Router Redundancy Protocol(VRRP)
• SEcure Neighbor Discovery(SEND)
• NAT Traversal(NAT-T)/UDP-ENCAP

このリストには載っていませんがTeredo*1にも同様の問題があって、そのためにKAMEでは（USAGIでも）Teredoが実装されていない、という噂を聞いたことがあります。IETFで公開されているTeredoのIPRを見る限りでは実装者に契約を求めているため、これが成果物をオープンソースとして公開するための障害になっているのかもしれません。

この問題さえなければ、Teredoは他社でももっと使われていておかしくない面白い技術なんですけどねえ……。

----

ところでTeredoと言えば、最近NTTコミュニケーションズが発表したOCNの新サービス「OCN IPv6」って、やっぱりTeredoを使ってるんでしょうか？

「どこでもIPv6」サービスをNTTコムが12月に提供開始(＠IT)
http://www.atmarkit.co.jp/news/200511/22/ipv6.html

「OCN IPv6」は、ユーザー認証に基づく動的なIPv6 over IPv4トンネリングサービス。ユーザーには固定と非固定のIPv6アドレスブロック（ルーティング・プレフィックス）がそれぞれ/64のサイズで1つずつ提供され、家庭内LAN上のIPv6機器に外出先からアクセスする、あるいは一時的に2つの家庭内LANをつなげるなどの使い方ができる。利用しているネットワークのルータ設定を変更する必要はまったくない。

（中略）

OCN IPv6に採用されているトンネリング技術について、NTTコムは現在のところ詳細を明らかにしていない。しかしUDPを使ってIPv6パケットをカプセル化する標準ベースの技術であり、マイクロソフトの次期OS、Windows Vistaにも搭載されるものだという。

「UDPでIPv6をカプセル化」「標準ベースの技術」「Windows Vistaにも搭載」というあたりでTeredoしか無いと思うのですが、技術の詳細が公開されていないので確証は持てずにいます。記事によると、ルータメーカ向けには仕様を公開しているらしいので、これを一般にも公開してくれたら嬉しいんですけど……。

しかし、これがもし本当にTeredoだとしたら、NAT越えのためにIPv6（＝Teredo）を使うという考え方のアプリ*2が普及するきっかけになるかもしれません。今後の展開が楽しみです。

■[gadget]W-ZERO3を買おうかどうしようか悩み中

「W-ZERO3」、12月14日発売(ITmedia +D モバイル)
http://plusd.itmedia.co.jp/mobile/articles/0511/30/news028.html

ウィルコムは11月30日、Windows Mobileを搭載したPDA型端末「W-ZERO3」を12月14日から発売すると発表した。合わせて、オンラインショップ「ウィルコムストア」や主な代理店で、12月9日から予約を受け付ける。

（中略）

ウィルコムストアで公開されている予価は、新規4万2800円、年間契約を行うと3万9800円。

うーん。5万を切るとは聞いてましたけど、新規＋年間契約だと4万を切ってますね。

ちなみに、僕は（まだ）WILLCOMユーザじゃないです。初代G'zOneでDoCoMoからauに乗り換えて、今はG'zOne TYPE-Rの赤いやつを使ってます。このG'zOneはこれでかなり気に入っていて、買った当初は手に取るたびにニヤニヤしてましたし、今でも時々ニヤニヤしてしまうんですが、このW-ZERO3も良いですよねえ……。

しかし端末の値段が安くても、データ定額にしようと思うと最低でも月3,950円（ウィルコム定額プラン2,900円＋データ定額1,050円〜）かかるので、やっぱりauとWILLCOMの併用にはまだ抵抗があります。うーん。でも、やっぱり欲しいなぁ。

出来ることなら実物を見てから買うか決めたいところですが、事前に予約しておかないと売り切れてしまいそうな気もしますし、悩みどころです。うーん。

----

（2005/12/01追記）
一晩経って冷静になってみて「そういえば、W-ZERO3なんて知らない人がほとんどかもしれない」ということに今更気が付いたので、紹介記事も置いておきますね。

ウィルコム、Windows Mobile搭載のW-SIM対応端末「W-ZERO3」(ケータイWatch)
http://k-tai.impress.co.jp/cda/article/news_toppage/26175.html