IPv6アプリコンテスト2003アイデア部門入賞作品が発表されていた。正直、IPv6の必然性を感じない作品も少なくないのだが……まあ私もかつて「Java大賞」なるコンテストに参画していたわけで、「なぜJavaでないといけないのか」というところを突かれたら私も同罪だ。
先月の日経IT Proの「記者の目」に「IPv6は普及するのか？――第1部：事例に見るv6のメリット」という記事があったのを思い出す。この中で、IPv6採用のメリットとして挙げられた4点は、「(1)セキュリティ、(2)マルチキャスト、(3)個体の把握、(4)プッシュ型配信」なのだが、このうち、「個体の把握」については考えさせされたところがある。ここで紹介されているのは、CDショップの各店舗に設置された音楽試聴機の各個体を、サーバで識別するためにIPアドレスをそのまま使うという話のようだ。そうした個体の識別は、アプリケーション屋の発想からすれば、アプリケーションレベルで実現するのが普通に思える。その点について記事では、
もちろん，こうしたことはアプリケーションを工夫することによってIPv4であっても実現できないわけではない。しかし，IPv6を用いれば，シンプルに実現できる可能性がある。
と結んでいる。
シンプルかどうかは疑問だ。IPアドレスレベルで識別しさえすればアプリケーションレベルでの新たな識別子が完全に不要となるアプリケーションでは、たまたま偶然にシンプルとなるものの、ものによっては、IPアドレスで識別した上に、アプリケーションレベルでも別の識別子が必要という、二度手間になる場合もあるはずだ。
とはいえ、これをシンプルだとしたい気持ちはわからないでもない。これは、Javaで言えば、java.util.Observableクラス（など）の考え方にたとえられるかもしれない。これは、オブジェクト指向プログラミングにおける「Observerパターン」を実現するクラスで、イベントを通知してほしいときに、イベントの通知先の識別子として、オブジェクトへの参照そのものを直接的に使う（アプリケーションレベルの識別子ではなく）という設計思想だ。オブジェクトへの参照は、実体としてはオブジェクト用に割り当てられたメモリアドレス（のようなもの）となっていて、一意性が保証されている。その一意性をアプリケーションレベルで借用していると見ることもできる。これは、下層の仕掛けを上層で活用するという点で、上のIPv6アドレスの個体把握への利用の話に共通する。
しかし、そうしたやり方は、システムのプリミティブな部分ではそのまま活用できるものの、より大局的な部分で、別の識別子を導入せざるを得なくなるということは、アプリケーションプログラマなら経験していることだろう。上層で発生した識別子を下層の仕掛けで共通して扱えるように仮想化するということも可能なのだが、それはフレームワーク開発者としては面白いけれども、本当に実用的なのか疑問に思ったことがある。Java RMIとJINIはその最たる例だ。分散システムのあらゆる部品を、個体識別をJava RMIの「リモート参照」で、機能種別をJava言語の型（interface）で、統一的に扱おうという考え方だ。上層の概念を下層の機構で解決しようとしている。これがいまだいまいち成功しておらず、時代はSOAPに流れたというのがなぜなのかを考えてみた方がよい。
元の話題に戻ると、IPv6アプリコンテストの入賞作品を見ると、IPv6の意義を捻出するために個体識別を取り上げた作品が目に付く。「Parking Control System with MIPv6」では、
自動車が駐車場に入った時点で、このシステムと何らかの無線技術でIPv6通信を行う。このシステムは、グローバルIPv6アドレスを基に自動車を識別、どの場所に駐車すべきかを知らせる。
とある。自動車の識別はアプリケーションレベルの識別子によってでも可能なはずだ。この自動車は、駐車場の入場ゲートで、何らかの方法で、このパーキング制御システムに自分自身の存在を伝え、登録処理をするわけで、このときに、駐車場がセッションIDを発行して、自動車がセッションIDを保持し、セッションIDを渡しながら案内を受けるという方法でも実現可能だ。
これには次のような反論があるかもしれない。この作品は、自動車側に駐車場システム専用のソフトウェアを搭載させるのではなしに、単に任意のメッセージを表示する汎用ソフトウェアを持っているだけで、駐車場側からのプッシュ型配信により情報が通知されるのだと。その場合は、メッセージ送信の通信先として、IPアドレスで自動車を特定する必要があるので、そのアドレスをそのまま識別子とすればよく、セッションIDは不要だということになる。
しかし、そうしたプッシュ型配信のサービスは実運用に耐えられるのだろうか。たとえば、「未承諾広告」をどうやって防ぐのか。オプトアウト方式で合意が得られるなら、送信元IPアドレスごとに拒否設定をするのだろうか。オプトイン方式とするのなら、最初にユーザ登録をするのであるから、アプリケーションレベルで個体識別に対応すればよいし、プッシュ型配信を使う必要がないように思われる。
これは「どちらでもできる」という話なのか。つまり、IPアドレス識別 + プッシュ型と、アプリケーションレベル識別子 + ポーリングという2種類の方式があり、どちらでもいいのだと。現在では一部を除きほとんどのアプリケーションが後者の方式となっている。IPv6推進陣営からすれば、その原因が、IPv4の限界とNATの蔓延にあるとしたいのかもしれないが、本当にそれだけなのか。
ここでプライバシーについて考慮してみよう。アプリケーションレベルの識別子は、一時的なID（セッションID）とすることができる。Webアプリケーションでは一般的な方法だ。最初に何らかの方法でユーザ認証を行った後は、一時的なIDを使って個体識別を継続する。この場合、最初のユーザ認証の時点で、ユーザの意思により個体識別を許しているので、プライバシーの問題は生じない。（ユーザ認証にも、個人を特定した後に権限を確認する方式だけでなく、個人を特定せずに権限だけ確認する方式もあり得る。）それに対し、IPアドレスを個体識別に使う方式では、通信をしただけで即座に個体識別されてしまう。通信相手が信頼できないところかもしれない状況では、プライバシーの懸念が生ずる。
Amazon.comのような、積極的にユーザの好みに応じた画面表示をするネットショップを考えてみる。買い物をすると、何を買ったかの記録から、店の陳列棚の内容がそれに応じて変わるわけだが、買わなくても、ただ商品を閲覧しているだけで、何を閲覧したかの情報さえも記録して、それにより推奨商品が決定される仕組みもあり得る。そうした記録が嫌であれば、ユーザは、ログインせずに（ログアウトした状態で）商品を閲覧すればよい。リアルショップでも、店員に話しかけられることなく商品を見たいこともあるし、店員に相談しながら見たいこともある。ユーザの意思表示によってオン/オフが切り替えられるのが理想的だろう。ネットショップの例では、アプリケーションレベルの識別子（具体的にはcookieに格納されるID）の有無によってオン/オフが切り替わる。
IPアドレスによる識別では、識別されることから逃れることができない。通信しただけで識別されてしまう。サービス提供事業者側が、IPアドレスを記録しないように（オフの間は）システムを作ることはできるが、本当に記録していないのかという疑いが生ずる。オプトインしていない事業者のプライバシーポリシーを信じざるを得なくなる。
しばしば、技術者からこういう声が聞こえることがある。現在のWebアプリケーションで、セッション追跡のためにcookieなどを使っているのは、HTTPの出来が悪いからで、しかたなくなのだと。その考え方でいくと、さらにはこういう声も出てくるかもしれない。「IPv6ならばIPアドレスで追跡できるので、cookieなんぞいらない。cookieでセッション追跡なんてのは邪道だ」と。
たしかに、cookieという仕組みが必要だったのは、IPv4世界ではIPアドレスによる追跡があてにならないことも一因だったかもしれない。しかし、cookieが発明された際に、EZWebのsubscriber IDのように固定IDをWebブラウザに持たせるという、安易な方式を採るのでなしに、サーバが必要に応じて一時的なIDを発行できるように設計されたのは、cookie発明者が、固定IDがもたらすプライバシーの問題を理解していたための配慮であろう。
現在のWebアプリケーションで、一時的なIDを発行する方式が主流となっているのは、偶然なのか必然なのか。IPv4世界でたまたまIPアドレスが識別に使えなかったからの「偶然」なのか。そうではないだろう。もし最初からIPv6世界でWebが始まり、IPアドレスでユーザ識別をする仕組みが発展していたなら、必ずプライバシー侵害の懸念が問題化していたはずだ。現状の一時的ID方式は、結果的に得られたものであるが、必然だったと思う。
さて、ここまできたところで、IPv6の「匿名アドレス」について考える。IPv6には、RFC 3041: 「Privacy Extensions for Stateless Address Autoconfiguration in IPv6」という規格がある。通常のIPv6アドレスでは、下位64ビット（インターフェイスID）が、ネットワークデバイスのMACアドレスから一意に決定されるため、そのデバイスがどこのネットワークに移動しても下位64ビットは変化しないという、固定IDとなる。デバイスが個人所有のものであるならば、個人追跡に利用され得ることになる。EZWebのsubscriber IDと同じだ。そこで、下位64ビットをランダムに生成するようにし、ある程度の時間とともに値が変化するようにしようというのが、RFC 3041である。RFC 3041が書かれた経緯について、山根さんがまとめている。アプリケーション屋が問題点を指摘したというところが興味深い。
RFC 3041の実装は進んでいるようだ。Windows XPに搭載されているIPv6プロトコルスタックは、RFC 3041をサポートしている。実際に試してみると、通常のIPv6アドレス（public）と、RFC 3041により生成された匿名アドレス（anonymous）の2個のアドレスが用意されることがわかる。しかし、この匿名アドレスはどのように使うのかがよくわからない。 考えられるのはこういうことだろうか。WebブラウザやMUA（メーラ）などのクライアントソフトウェア（ポーリング型プログラム）では、anonymousアドレスを使い、サーバソフトウェアや、P2P型のソフトウェアでは、publicアドレスを使うという使い分けだ。それが常識化してくると、将来こんなセキュリティ脆弱性情報が流れるかもしれない。「○○が誤ってpublicアドレスを使用する脆弱性」などと。IPv6styleのサイトには、「EdMaxにIPv6対応してもらいました」という企画が掲載されているが、EdMaxはanonymousアドレスを使っているのだろうか。説明は見あたらない。それとも私の上の理解が間違っているだろうか。
そうやって必要に応じて匿名アドレスを使い分けるのだとしても、まだ疑問がある。IPv6アドレスのプレフィクス部（上位64ビット）はどうなるのかだ。典型的な例として、一般消費者が家庭にIPv6ネットワークをひくときを想定してみる。プラグ・アンド・プレイ対応のルータを設置すると、ルータが自動的に接続プロバイダからIPv6アドレスを取得する。このときのアドレスはどのように決定されるのだろうか。ADSLの同じ電話局から提供される全回線に同じプレフィクスアドレスが割り当てられる運用も考えられるし、契約者（回線）ごとにあらかじめ決められたアドレスが固定的に割り当てられる運用も考えられる。前者であれば、従来のダイヤルアップ接続と同レベルのプライバシーが確保できる（匿名アドレスを使ったソフトウェアの場合）が、後者の場合は匿名アドレスを使ったとしても、上位アドレスによって個人を追跡できてしまう。両者の中間として、ルータをリセットしたときなどのタイミングで、毎回異なるプレフィクスアドレスが割り当てられるという方式も考えられる。
RFC 3041は制定済みだし実装も進んでいるのだから、こうしたプライバシー懸念は運用で解決されるのだということなのだろう。だが、こうした運用についての議論を見かけない。たとえば、先のIPv6styleのサイトにある「素朴な疑問」のページには、いろいろな議論が載っているが、プライバシーに関するものは載っていない。
固定IPアドレスの問題は、IPv6ならではの問題ではなく、IPv4においても、近年の常時接続の普及により顕在化しつつある。IPv6技術者は、「今だって常時接続は固定アドレスなんだから今までと変わらない」と言うかもしれないが、今だって本当は問題があると考えるべきだろう。ADSLや光、ケーブルなどの常時接続提供業者は、アドレスを変更する機能を提供するべきだと思うが、どうか。これは消費者が望まなければサポートされることはないだろう。
この日記を始めた当初から書きたかったのは、「望まなければ得られない」ということだ。つまり、消費者が望まない限り事業者側からプライバシーが供給されることはないということなのだが、これは近々なんとかまとめたい。
もうひとつ別の論点を述べておきたい。IPv6推進派は、RFC 3041でIPv6のプライバシー懸念は回避可能になっていると主張するかもしれないが、その一方で、IPv6の意義が語られるとき、匿名アドレスを使わないことを前提としたものが目立つことに注意してほしい。たとえば、冒頭で紹介したIPv6アプリコンテストの入賞作品には、こんな記述が見られる。
さらにこのシステムでは、自分の割り当てた位置に個々の自動車が正しく駐車したかどうかを識別する。割り当てられた場所と違っていたり、2つ以上のスペースを使用していた場合には自動的に割増料金を請求する。
このシステムは、駐車場内でアドレスを故意に変えられると正常に機能しなくなる（課金上の不正を許すことになる）ので、匿名アドレスは拒否するのだろう。
IPv6の活用意義を捻出したいばかりに、プライバシーが損なわれかねない応用が次々と構想されているところに、そこはかとない危惧を感じる。もちろん私は、IPv6反対派とか、IPv6懐疑派などではない。普及したらいいねと願っている。
他にいくつか例を挙げておく。Slammerワーム騒動後の荒野高志氏の日経ネット時評「ワームによるネット障害、究極の対策は――IPv6と教育」にはこう書かれていて、正直、目が点になった。
ソフトウエアも含め、すべての製造物／コンポーネントが製造者の手を離れてもトレースできる仕組みがあると、解決の糸口になりそうだが、これにはすべてのものを統一的にアクセス可能にするIPv6の発展を待つしかない。
「なんでIPv6で解決するの？」と疑問に思った。またそれは、「IPv6を待つしかない」ものなのだろうか。その後、荒野氏とは日経デジタルコアの研究会でお会いする機会が多くなったので、今度直接聞いてみるとしよう。
古いところでは、日本IBMのサイトに掲載されている、村井純教授のコラム「end-to-endのコミュニケーション」だ。
テープレコーダーでも電子レンジでも、この先インターネットにつながる可能性のあるものはすべて、ちゃんと特定の「住所」を持っているべきだからだ。そうすれば、これらを使った新しいシステムを作ろう、という新しい発想を伸び伸びと、自由に支援することができるからである。
この種の、最も汎用的に設計しておくのがスマートであるという技術的原理主義は、私も同意するところもあるのだが、それによって拡大するであろうプライバシーの問題をどう解決するのかについても述べてもらいたいところだ。これは、5月20日の日記に書いたように、何かお考えはおありのようなので、今度詳しく話を伺うまではあまり書かずにおく。 すべての物が住所を持つということについて、電話がたとえに借り出されることがある。「IPv6 Online Journal」に掲載されている「Mobile IPv6で可能になるPush型サービス」という記事には次のように書かれている。
例えば、位置情報システムとの連携により、商店街のエリア内に入ってきたターゲットに対して即座にピンポイントでセール情報を提供することができるようになる。 携帯電話でも、電話番号が固定であるため、類似のサービスを実現している。
たしかに、プッシュ型サービスは携帯電話に馴染むものだろう。IPv6が普及すればインターネットも同じようにプッシュ型のサービスが馴染むようになるということなのだろう。電話も固定IDで、人々はそれを受け入れてきた。だが、昔は発信者通知機能がなかったのだし、通知機能が導入された現在でも、非通知をいつでも選択できるようになっている。それに対して、IPアドレスは非通知にできない。
非通知という仕組みが簡単に実現可能なのは、電話網が、特定の事業者（政府に認可された電気通信事業者）によって運営されているからだ。事業者が守秘義務を負うことによって、プライバシーの問題は解決されている。しかし、インターネットはそういう性質のものではない。インターネット上のサービスは誰でも自由に参入できるところに価値がある。信頼できる事業者も、あまり信頼できない事業者も混在することになる。そういう状況で、固定アドレスの使用とプライバシーをどうやって両立させるのかだ。
ただし、固定IPアドレスが常にプライバシーの問題を生じさせるわけではない。完全に受動的なソフトウェア（たとえば、単にメッセージを受け取って表示するだけなど）ではプライバシーは問題にならないだろう。能動的なソフトウェア、つまりたとえば、Webブラウザのようにユーザの意思によってアクセス行動が変化するようなもので、プライバシー問題が生ずる。また、事前に決めた特定の相手としか通信しないソフトウェアもプライバシーの問題を生じさせない。Webブラウザのようにいろいろなサイトに接続するものに、問題が生じる。
同一のソフトウェアであっても、プライバシーの懸念がある処理ではanonymousアドレスを使用し、それ以外ではpublicアドレスを使うという作り方もあるのかもしれない。そのときには、何がプライバシーの問題を生じ得るのかを見極める必要がある。受動的なソフトウェアでも、特定の条件（位置情報などに基づいて）でのみ情報を受け取るシステムでは、その条件と固定アドレスとが結びついてしまうことが考えられる。このあたりの見極めが難しそうだ。この見極めを誤ったソフトウェアの続出で、セキュリティホールの新たな一分野「プライバシーホール」が生まれるのかもしれない。
最後にもう一点。財団法人情報処理相互運用技術協会の情報家電安全性技術委員会が出している「情報家電向けIPv6最小要求仕様案 (Ver.4.2 2002-2-19)」には次のように書かれている。
RFC3041ではIPv6 addressのインターフェイス識別子を乱数化してプライバシーの強化を図る提案がされている．しかし，本稿で実装必須とした手動鍵交換との併用は運用に無理がある．この場合は自動鍵交換の実装を検討しなければならない．
むむむ、大丈夫なのだろうか。「強化」という表現が使われているのも気がかりだ。一般に、「プライバシーを強化」という表現は、通常の日本語の用法では、「これまでもプライバシーはそれなりに確保されていたが、さらに強化した」ということをイメージさせるもの（関連: [memo:4768]の「セキュリティをさらに強化しました」参照）だろう。RFC 3041を使わない場合のプライバシーの懸念が軽く見られているように垣間見られて不安を覚える。
「山根さんがまとめている」というところで出てくる、RFC 2964: 「Use of HTTP State Management」の著者でもあるKeith Moore氏は、なんと、Jack Dongarra先生のところの方だったのですね。というか、6年前のこのときの彼の発表を聞いたはずだし、Ninfのことで質問メールもらってるやん。あいかわらず他人の名前を覚えられない私、ダメすぎ……。ちなみに、私はIETFには全く無縁であることを白状しておきます。調べてみると、Keith Moore氏はいろいろとご活発なのですね。NAT有害論派？ 力武さんも議論しているなあ。ちょうどここでも話題になってるし。
関連する記事で、昔読んだ覚えがあるがどれのことだか思い出せなかった記事を発見。RFC 3041のことが書いてあったと記憶していたのだが、違った。NymIPプロジェクトのことだった。NymIPはその後どうなったのだろうか。
昨年2月の日経ネット時評「シリーズ：ＩＰＶ６」の全部を読んでみた。7人中、誰一人プライバシーについて触れていない。
「IPv6アプリコンテスト2003」の本家ページは、こっちの「IPv6普及・高度化推進協議会」のサイトにあった。IPv6アプリコンテスト2003 受賞作品に、応募作品のプレゼン資料が置かれていて、詳しいことがわかる。また、審査員のコメントがある。