実際のところ、移行コストはサーバ側もクライアント側も、デュアルスタックで構成すると大したことはありません。サーバ側は IP アドレス指定がある部分を IPv4/IPv6 の両定義を行う程度で、動作周りの設定はそのままでいけますし、クライアント側はプロトコルスタックに依存するようなアプリの作り方は (依存しなければならないファイアウォール製品等のものでもなければ) 普通しません。IP 層までは気にする必要がないものが大半ですから。IP アドレスを 32bit int で保存している DB とかだと影響は大きいと思いますけど。;)
実際のところ、移行コストはサーバ側もクライアント側も、デュアルスタックで構成すると大したことはありません。サーバ側は IP アドレス指定がある部分を IPv4/IPv6 の両定義を行う程度で、動作周りの設定はそのままでいけますし、クライアント側はプロトコルスタックに依存するようなアプリの作り方は (依存しなければならないファイアウォール製品等のものでもなければ) 普通しません。IP 層までは気にする必要がないものが大半ですから。IP アドレスを 32bit int で保存している DB とかだと影響は大きいと思いますけど。;)
TVデジタル化より難事業 (スコア:3, すばらしい洞察)
Xデーが2011年ということは、日本の地上デジタルTV完全移行と同時期ですね。 国家が明確なスケジュールと強制力を根拠に進めているTVデジタル化でさえ、計画を延期する国が相次いでいる状態なのに、両方とも存在しないIPv6への移行が始まる目処は何かあるのでしょうか？
他でも指摘されているとおり、NATやルータに制約されない自由な接続、という謳い文句も、一般ユーザ向けには厳しいものがありますよね。 Xデーのその日まで32ビットアドレスの再配分がまったく考えられずに皆ひたすらアドレス確保に邁進する、という仮定にも無理を感じますし。 CO2排出権取引市場のようなシステムをアドレス空間取引に応用すれば、32ビットアドレスの再配置は可能のように思われます。 そういうことを始める業者が自然発生することを期待したほうが、まだしも現実的のような。
Re:TVデジタル化より難事業 (スコア:1)
一般ユーザ向けに厳しいものがある、というのはどういった点からでしょうか? 経路制御が必要である以上、ルータに制約されないというのはありえない話なので、おそらく「市販ルータが普通に制御してくれる」事を「制約されない」と表現しているのだとは思いますが。
ルータが接続されているマシン名の一覧を表示して「このマシンに接続を許可する」「このマシンには接続を許可しない」といった、簡易な画面を用意できる形であったとしたらどうでしょうか? (KAME 由来の ping6 -w ff02::1%(インタフェース名/番号) を使うと、ping の応答を返したマシン名を取得することができたりします)
KAME 由来のプロトコルスタックを持っていないものに関しては、WINS なり DNS から引くなりして解決することになるでしょうけれど、そのように解決するのであれば、別に IPv4 と差はないよね、で終わってしまう話でしかありません。もしかしたら、ちょっとだけ IPv4 よりも便利かも、程度でしょうか。
32bit アドレスの再配置は、所詮数年の延命手段にしかなりえないと思います。使い果たすまでになんらかの延命手段が必要、という点に差がない点と、32bit で割り当て可能なアドレス空間が十分ではないという話には変わりがありませんから。
ISP レベルで NAT なり proxy なりを利用するのが基本となり、ISP 内部でローカル IPv4 アドレスを利用してアドレス空間を擬似的に広げて……なんてやるくらいなら、IPv6 を使った方が仕様も既に決まっている分、話が簡単としか思えません。
IPv4 を建て増し建て増し……で、擬似的に 32bit - 8 x n bit + 32bit、なんてやるくらいなら、さっさと 128bit まで増やしたほうが話は簡単に思えます。
IPv6移行の手間隙 (Re:TVデジタル化より難事業) (スコア:2, 興味深い)
アクセス制御などの難しい話ではなく、単に、プロバイダに加入する大半の普通のユーザはプロバイダによるウィルスやスパムのフィルタを頼らずにE2Eでネット接続するような冒険はしないのではないか、というだけの意味です（フィルタが実は気休め程度のものであったとしても）。redundant気味なので詳述しませんでした。
サーバサイドに限った更新コストを考えると、確かにその方が合理的かもしれません。 しかしクライアントサイドも含めた総とっかえを想定すると、たとえばPBXをIP電話に総交換するような大作業になることが大半ではないかと思います。 前世紀から続く壮大なIPv6プロジェクトに潜在的に求められていたのは、今どきの言葉でいうところのアジャイルなソリューションだったのではないでしょうか？
IP層のみの変更は一見エレガントなようでも、実際にはどこかのホストで思わぬ不具合が出るかもしれないから末端のテストを手抜くのは怖いし、Webサーバなどで番地依存なアクセス設定をしているとすべて見直さなくてはなりません。 加えて時が経つうちに、アプリケーション層でデータリンク層をでっちあげるSoftEtherのような代物まで出てきてしまいました。 レイヤ構造を思えばこんな不恰好なカスケーディングもありませんが、実際の運用ではこの手のアジャイルな（悪く言えばその場しのぎの）ツールの方が簡単に試せてしまいます。 アドレス枯渇どころか、やろうと思えばポート番号1ヶで相当に広範なアクセスも技術的に可能であることが、むしろ多くのセキュリティ管理者にとって悩みな訳です。
実際には、IPv6的にもっと要領のよい解決策があるのを私が知らないだけなのだろうと推測しますが、そのための教育コストをかけるよりは、技術を知り尽くしている人が作った至れり尽くせりツールをみんなでコピーして使ったほうが手っ取り早い、というところが現実だと思います。 たとえそれが醜悪な建て増しカスケードを作り上げるのだとしても。
Re:IPv6移行の手間隙 (Re:TVデジタル化より難事業) (スコア:1)
E2E 接続に関しては、現状の IPv4 であってもグローバル IPv4 アドレスを付与される訳で IPv6 になるから差ができるということはありません。ISP 側によるフィルタリングサービスを受けているのであれば、IPv6 でも同等のサービスを提供できない理由は全くありません。というか、できない方が不思議です。あるとしたら、機器が非対応とかいう範囲になるかと思います。
実際のところ、移行コストはサーバ側もクライアント側も、デュアルスタックで構成すると大したことはありません。サーバ側は IP アドレス指定がある部分を IPv4/IPv6 の両定義を行う程度で、動作周りの設定はそのままでいけますし、クライアント側はプロトコルスタックに依存するようなアプリの作り方は (依存しなければならないファイアウォール製品等のものでもなければ) 普通しません。IP 層までは気にする必要がないものが大半ですから。IP アドレスを 32bit int で保存している DB とかだと影響は大きいと思いますけど。;)
デュアルスタックでサービス提供していれば、とりあえず接続サービスだけは提供しつつ各種サーバ群はしばらく IPv4 のままいく、という形でも特に問題は起きませんし。(IPv6! IPv6! ってユーザは嫌がるでしょうけど、サービスを提供し続ける重要性を考えたら無視していいでしょう)
あと、SoftEther も VPN な訳ですが、そういうソリューションが必要である以上はプロトコルスタックは関係ない話だと思います。IPv6 の方が「無理をして繋ぐ」必要性が多少軽減できる、といった程度ではないでしょうか。
商用サービスを個人向けで提供できているのが金と時間を取る事が出来た IIJ と NTT コミュニケーションズくらい、というのが実情を表しているように思えます。
Re:IPv6移行の手間隙 (Re:TVデジタル化より難事業) (スコア:1)
もちろん、IPv6の移行後に不便が生じることのないように多くの技術的な努力が払われているであろうことは、信頼しています。 問題は、やはり多くの指摘があるように、小さなメリットだけではわずかな移行作業も実施する気にならない、ということでしょう。
IPアドレスを純粋に識別子として使っているネットワークでは大したことないかもしれませんが、実際には数値にあれこれ意味を持たせてしまっていることが少なくないでしょうから、何も考えずに運用変更できるケースばかりではないでしょう。 DBのアドレスフィールドを拡張するだけで済むなら、一度のバッチ処理で対応可能でしょうが、問題になるのはむしろ、httpd.confなどの設定ファイルに以下のような感じで書かれたルールではないでしょうか？
この上にさらにVirtualHostの入れ子構造が絡み合っていたりして。良くも悪くもオープンなネットの世界で、すべてのツールを手なずける番地ソリューションというのも、かなり難儀なのではないかと。
Re:IPv6移行の手間隙 (Re:TVデジタル化より難事業) (スコア:1)
IPv4 → IPv6 時に再設計を行うとは思いますが、IPv4 を捨てる必要もないので IPv6 側ネットワークはポリシーに合わせて 16bit 単位でマスクを切りなおすといった感じで再構築されると思いますので、その部分の書き換えコストは小さいと思います。おそらく洗い出しコストの方が高いと思います。
むしろ、設定する IPv4 アドレスをそのまま 32bit の識別子として利用する jail の実装といった、根本部分で IPv4 に依存している実装などで大きな問題があると思います。こうした実装を利用している場合、jail を使わずに chroot 環境に切り替えるなどの対応を迫られるか、当面 IPv4 のままサービスを提供することとなります。