実際のところ、移行コストはサーバ側もクライアント側も、デュアルスタックで構成すると大したことはありません。サーバ側は 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 の応答を返したマシン名を取得するこ
IPv6移行の手間隙 (Re:TVデジタル化より難事業) (スコア:2, 興味深い)
アクセス制御などの難しい話ではなく、単に、プロバイダに加入する大半の普通のユーザはプロバイダによるウィルスやスパムのフィルタを頼らずにE2Eでネット接続するような冒険はしないのではないか、というだけの意味です（フィルタが実は気休め程度のものであったとしても）。redundant気味なので詳述しませんでした。
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 のままサービスを提供することとなります。