IPv6 移行方法 ■ IPv6 移行コスト積算 WIDE/JPNICが夢想している、 いきなりPure v6に全員が移行、などというのが 非現実的なのは当たり前として、 じゃあ、実際にはどうやるの? というのは、その辺のサイトをググっても出てこない。 ようは、あれだけ実証実験などで税金をばら撒いたにもかかわらず、 移行方式すらまったく研究されてないという体たらくなんだが、 それを嘆いていても仕方ないので、 とりあえず提案。 用語定義: 組織 → 学校、会社、マンション内LANなど。定義としては、管理する側とされる側があること。 みんな仲良し、全員が信用できるユートピアではなく、 管理しないといろいろ起こってしまう現実社会。 個人 → 家庭など。複数台のPCがあってもよいが、 お互いが信用でき、管理の必要性がないのが前提。 といっても、最近は、某高市議員などによれば、 家庭でも子供用PCは管理が必要らしいけど。 □ 「組織」では、E2Eは論外。 ここでの「組織」とは、上の用語定義のものね。 この場合、管理の都合上、 LAN内部で管理者に無断で勝手なP2Pアプリなんて走らせることは 認められる訳がないので、 当然、L3のE2Eは論外。 それどころか、L4のリーチャビリティすら否定し、 L7で縛るのが当然になります。 L7でURLをフィルタリング、ロギング、監査などすると同時に、 ウイルスチェック、スパイウェアチェックも必須ですし、 今後は、漏洩フィルタも必要でしょう。 個人情報を含むファイルを変なところに送ってないか。 bccと cc の違いを理解しているか、、、みたいなの。 また、このへんに、SaaSなどがからむと、 またなんか厄介になりそうです。 この場合、なにも情報を漏らさないのでは、 SaaS使用が不可能になりますが、 実際問題、どういうフィルタリング条件にすべきなんでしょうか。 いずれにせよ、E2Eは組織では論外です。 □ SRCIPは国家機密か? それ以外にも、組織においてE2Eが不可能な理由があります。 たとえば、v6原理主義者が気づいていないくだらない 問題点に、SRCIPの問題があります。 某Fで、某A庁(いまは省か?)関係のローカルIP割り当てが 漏れた事件があったでしょ。 こんなの、本当にどうでもいいことで、 防衛庁庁舎の職員食堂のメニューのほうがよほど国家機密じゃねえか? いや、事務次官のネクタイの柄の好みのほうが機密かな?と 思えるのですが(ようは、あまりにもどうでもいいこと)、 が、しかし、 そのへんをわかっていない新聞記者が 防衛機密漏洩とか書いてくれたせいで話は一気に厄介に。 一応、こういった記事が出てる以上、 私が網を設計するとしても、 一言許可を取る必要性が出るんですよ。 「内部のIPアドレス割り当てが相手サーバのログに残りますが いいですね?」 じつにくだらないと思うでしょうが、 これ、素人は、「んーー、わかんないけど、 最近漏洩とかうるさいでしょ。一応秘密にしようか?」 となるんですよ。 さらに悪いことに、 IPv6の場合、下64ビットとかをイーサアドレスから作るので、 そうなると、PCのメーカ名、製造年月日とかが 大体わかるかもしれない。 それ以外でも、アドレスの割り当ての仕方から、 部署名、ルータの機種名などが推測できるかも。 もちろん、そんなのどうでもいいんだけど、 とにかく、一応、ひとこと断る必要性が出てくると思う。 あと、架空請求詐欺関係でもなんかあるかもね。 「IPアドレスを記録しました。もう逃れられません」みたいな 脅し文句ってあるでしょ。 あれだけでも、素人は、IPアドレスってヤバいよな、とか思っちゃう。 さらに、今後は、パソコンメーカー名から製造年月日まで 推測できるわけだから、脅しの効果は増えるよな。 現実問題として、iMode は、そのあたりが徹底していて、 ユーザの個人情報はプロキシで完全に遮断されていて 一切出てこない仕様となっている。 で、許可を取るとして、そのとき、 素人なので、 なにが安全で何が危険か全くわからないし、 単なるサラリーマンで責任を取りたくないから、 「とりあえず」なんでも秘密。 パスワードを生年月日にしているような状況のクセに、なんでも秘密。 こっちも、「お客様」にそういわれれば、唯々諾々と従うだけ。 ・・・問題点、わかった? この瞬間に、E2Eは絶対に不可能。NATかProxyが必須になる。 このくだらない問題だけで、いきなりE2Eは無理なんだけど、 そんなこと誰も気づいてもいない。 ほんと、こんな問題も洗い出せずに、何のために何百億円も実証実験に 税金をつぎ込んだんでしょうか。 あ、税金をつぎ込むことが目的か。なら納得。 □ 「1:1」のNAT? たとえ、LANのなかがv4ローカルだったとしても、 ルータの外側にv6グローバルが無数についていれば、 1:1のNAT(なんていうんだ?)ができるじゃん、 という意見があるかも。 これなんだけど、IPアドレス漏洩、プライバシー問題などを考えれば、 それは無理。 結局、1:nの普通のNATを使うことになる。 なんのためにIPv6に移行するんだか、ぜんぜんわかんねぇ。 □ 「個人」ではE2Eは可能。 ここでいう「個人」とは、やはり上の用語定義のものね。 で、ここではE2Eは可能。 複数台のPCを持っている人などは、 すべてにグローバルIPを割り当てるのが普通になるかもしれないし、 それどころか、 これから登場するであろうインターネット家電とかにも すべてグローバルIPアドレスを割り当てるかも。 セキュリティとか考えたら、 ちょっとヤバい気もするが、 割り当てるやつはいるだろうな。 □ 組織ではE2Eは論外、その2 しかし、繰り返しますが、 組織ではE2Eは論外です。 普通のデスクトップPCで無理な理由は上で説明しましたが、 インターネット家電でも同様の理由で不可能です。 ビル管理やエアコン制御をIPベースにして 効率化、省エネ化する、というような話はあります。 で、ここにIPv6を割り当てる、というのも出てくるでしょうが、 それは、グローバルでパブリックなInternetとは絶縁された ある種のVPNのような空間にのみ存在するノードでしょう。 たとえば、監視カメラを装った盗聴カメラが ひそかに社内にセットされていたらどうしますか? というか、監視カメラと盗聴カメラの定義の違いは? 盗聴器付きのあやしいインターネット家電が紛れ込んだら? たとえば、これからは、ネットラジカセとか、 とにかく、ネットから直接音楽を鳴らすラジカセなんてのは出てくるでしょう。 しかし、それをオフィスに持ち込むことは認められません。 なぜなら、盗聴器付きネットラジカセとかが紛れ込んだらシャレにならないもん。 それ以外でも、P2Pファイル交換機能付きネットラジカセとかも困るし。 JASRACあたりからいきなり訴状が届いたらどうする? くりかえしますが、組織ではE2Eは論外。 □ なぜE2E真理教が生まれたのか? WIDEの連中が現実を知らないから。 自分たちのできることは ほかのやつにもできると思い込んでいる。 だったら、なぜ、あんな勤務態度で 法外な賃金が請求できるんだ? 「ほかのやつにはできないことをやっているから」、 これ以外答えはないはずだし、 本人たちも、自称自分はすごく頭いい、と思い込んでおり、 さらに、論理的整合性はばっちりと思い込んでるみたいだけど、 彼らの論理はこの一点では完璧に矛盾している。 WIDEにできたからって一般人にできるとか限らないんだよ。 たとえばさ、WIDE連中が多数生息するIIJ。 聞きたいんだけど、じゃあ、社内はIPv6化されている? されたとして、E2Eを認める? 連結従業員1300人の東証一部上場企業だよ。 内部統制報告書だけでも何を書くの? それだけでも見ものだよ。 第一、1300人の従業員のうち、まともな意味で技術者と呼べるやつって何人?。 RFCとかIETFっていわれて何のことだかわかるやつが何人いる? 倍数減少とか輻輳崩壊といわれてわかるやつが何人? どうせ、100人切ってるでしょ。 そんな状況でE2E導入してどうやって管理するの? 内部統制報告書だけでも何を書くの? まずさ、NATは邪道だ、とかわけのわからないことをふかす前に、 自分の足元からIPv6にしろって。自分の足元からE2Eにしろって。 意味不明のパケットが自分のPCのイーサドライバのバッファに ガンガン飛び込んでくる状況。 パーソナルファイアウォールのアラートが一年中常に鳴りまくる状況。 この状況の中、東証一部上場企業の業務を 内部統制報告書の手順のとおりにきちんとやれって。 それができるんかい?でも、それをやらなきゃ。 あれだけ言ったんだから、 貰うものを貰ったんだから、 そして税金を使ったんだから、 どんなに困難でもやらなきゃ。 それが最低限の社会的責任です。 正直、E2Eがまともにできる組織なんて、 日本では、慶応SFCの村井研究室と、IIJの研究部門、 あとは会津大学だけだろうな。 IPv6対応は移行コストさえ考えなければほかの組織でもできるけど、 E2Eは難しい。 あとは、国立研究所でも国立大学でも、全部無理。 正直、東大の江崎研究室でも難しいと思う。 なんかあったとき、学内をどう説得するの? SFCなら、(自称)日本のインターネットの父、 村井純の看板で何とかなるんだろうけど、江崎さんに東大でそれができるか? いや、村井さんだって、慶応全部では難しいよ。 あくまで、SFC内部だけ。 ちなみに、いま、総務省(旧郵政省)が、 近々省内を全部v6化するとかいってます。 これ、E2Eを認めるんでしょうか。それとも、ファイアウォールやプロキシで がちがちに縛るんでしょうか。 ここ、とても興味ありますな。 あんだけ、IPv6、IPv6と騒ぎ、多額の税金を使った組織。 当然、その教義であるE2Eは守るんですよね(爆笑)。 守らなければ守らないで言行不一致もはなはだしいですし、 守ったら守ったで、 総務省の内部にバンバン怪しいパケットが流れ込みますし、 総務省の内部からエロサイトでもなんでもアクセスできちゃいますが、 それに耐えられるんでしょうか。見ものですな。 □ E2Eを諦めればアプリの互換性は解決する。 以上の議論でわかるように、組織でのE2Eなんて不可能なんですよ。 あきらめるしかない。 しかし、E2Eを諦めた瞬間にすごいメリットがある。 この場合、組織の中はIPv4でOK。 外に出るところに、v4 to v6のトランスレータなりNATなりプロキシなり、、、 を置くだけ。 逆に言うと、アプリもルータもOSも、組織内部は一切いじる必要性がない。 これはいいよ。 とくに、アプリをいじる必要性がないのは最高。 IPv6移行で一番大変なのがここだからね。 □ ここまでのまとめ 個人 → アプリ、OSも含めたIPv6/E2Eへの移行。 組織 → 組織内部は今まで同様v4。 □ 移行後構成、個人編 じゃあ、たとえば、個人で使っているやつは どういったシステムに移行するの?ってことだけど、 完全にIPv4アドレスが枯渇し、 ユーザにv4が配られなくなった状況を仮定して議論する。 この場合、ユーザのルータの外側には、 現実的にはほぼ無限大のIPv6グローバルアドレスがついているが、 残念ながらIPv4アドレスは付いていない。 で、IPv6推進派に都合がいい過程として、 そのころにはVistaのようなIPv6対応OSが普及しているものとする。 この場合、移行はかなり楽。 ブロードバンドルータさえ対応していれば、 何も考えずに移行できるかもしれない。 問題は、v4オンリーのアプリと、v4オンリーのサイトをどうするか。 結局、それをなんていうかはともかく、 トランスレータやNAT、プロキシなどをどっかに立てるわけだし、 そこにはIPv4グローバルアドレスが必要。 また、ユーザ側のアプリも、すべてをIPv6対応にするのは むりなので、 家庭内LANのなかにIPv4ローカルを配り、 NATなどで外側のIPv6グローバルに出て行けるような 仕様が必要。 ようは、ブロードバンドルータが、v4v6変換NATになる必要性がある。 それ以外に細かいことだと、 このあたりの移行の方法を標準化する必要性がある。 トランスレータなどの設定も、DHCPのような技法で勝手にできるようにしないと ダメ。 さらに、それにすべてのブロードバンドルータが対応する必要性がある。 ちなみに、この問題の一番のポイントは、 だれもそんなことを考えていないこと。 とにかく、IPv6推進派は税金を無駄遣いすることだけに情熱を燃やすからね。 大切なのは、こういった現実的な問題点を一つ一つ潰していくことなのに。 具体的なアクセス手順を書くね。 ケース1:v6アプリがv6サーバに接続する場合: 一番シンプル。普通にv6のパケットを グローバルv6アドレス(当然、個々のPCに少なくともひとつ以上 割り当てられている)でLANにながし、 それをブロードバンドルータが拾い、ISPに送る。 ISPは、それをv6対応のIXに流し(といっても、L2ではv6もv4もないけどな)、 あとは、相手のサーバに適当に流れていく。 簡単、簡単。 ケース2:v6アプリ同士がP2P: この場合もケース1と同じ。 ポート開放とか何も考えずにP2Pができるぞ。 ケース3:自分はv6アプリ。相手はv4サーバ: ようは、IE7とかからv4サーバを覗くわけ。 この場合、まず、インターネットのどこか、 もっというと、多分、普通はISPの網のどこかにあると思われる v6v4接続ポイントからv4の世界に出て行くことになる。 また、その際のIPアドレスは、この接続ポイントが所有しているもの。 逆に言うと、少なくとも、この接続ポイント用のグローバルIPv4アドレスだけは、 それが確保できなかったらv4サーバは見えなくなっちゃう。 一番重要なのは、設定を自動化すること。 トンネリング、トランスレータ、プロキシ、NATなどがいろいろと 複雑に絡むうえ、なにがどう必要でどう設定すればいいか、 みたいなのが、使うアプリなどによって変わってくるので、 とにかく、このあたりを標準化、自動化しないと、 v6 = どの電話番号にかけても不通の呪われた電話、みたいに思われるぞ。 ケース4:自分はv6アプリ。相手はv4のP2P: ケース3と一緒。 P2Pの仕様によっては、ポート開放も不要かも。 といっても、途中の「接続ポイント」あたりに リフレクタをいれれば、いずれにせよポート開放は不要と思われる。 ケース5:自分はv4アプリ。相手はv6サーバ: v6しかないWebサイトにつなぐとか。 まあ、そんな変なWebサイト、永遠に出ないような気もするが、 自宅サーバとかがそうなるんかも。 で、この場合だけど、 どこかで、Proxy/NATなどをかますしかない。 というか、多分、ブロードバンドルータが ローカルv4アドレスからグローバルv6アドレスに変換するんだろうな。 で、繰り返しになるけど、重要なのは自動化、標準化。 ケース6:自分はv4アプリ。相手はv4サーバ: やはり、プロキシ/NAT などで行く。 この場合、ローカルv4でLANを通り、ブロードバンドルータでグローバルv6に変換し、 それをv6v4変換ポイントでグローバルv4に変換し、、、、、となるわけで、 なんかすごく無駄だけど仕方ない。 で、繰り返すけど、大切なのは、この変で複雑な多段階変換に対する設定を 自動的にできるようにすること。 ケース7:自分はv4アプリ、相手もv4、さらにP2P。 ポート開放問題を除けばケース6と同じ。 リフレクタを使わない限り、 この場合は、すくなくとも、どちらかはポート開放が必須になる。 ただ、途中で変な変換をかけるぐらいなら、 そこにリフレクタをかまし、それによりポート開放を不要にしたほうがいい。 というか、ブロードバンドルータそれ自身をリフレクタにすることができると思う。 ケース8:自分はv4アプリ、しかし相手はv6、でもP2P。 これも、ポート開放問題を除けばケース6と同じ。 この場合、うまくやれば、どちらもポート開放しないでいい可能性がある。 しかも、リフレクタもいらないかも。 ・・・いま書いていて改めて思ったんだけど、 デュアルスタックの複雑さってすごいな。 本当に、この設定や運用を自動化標準化できるんだろうか。 それができない限り、IPv6移行なんて絶対無理だけど、 自動化をめぐる議論すらおこってないんだよな・・・。 正直、WIDEの連中って、税金を溶かすこと以外は、 ホントやる気ないんだよな。 □ 移行コスト試算: ISP側の費用を割愛し、 ユーザ側の費用のみを考える。 また、OSは、Vista、またはそれよりもさらにIPv6対応がすすんだOS に移行しているものとする。 この場合、個人用途では、 そんなに移行コストはかからない。 ブロードバンドルータさえ対応していれば、 それで何とかなる可能性がある。 もちろん、その前提として、 たとえば、トランスレータ設定の自動化などがあるし、 たとえ移行しても、トランスレータ運用コストの負担などもあるけど、 なんとかなる範囲に収まるんじゃないかな。 具体的にいえば、極端な話、移行コストゼロ、ってのも ありえなくはない。 すごくIPv6に有利な方向性に偏った試算だけど、 わたしはべつにIPv6反対原理主義じゃないんで、これでもOK。 とにかく、すべてが上手くいけば、場合によっては移行コストゼロってのは とてもラッキー。 しかも、この場合、IPv6信者の大好きなE2Eも実現できる。さらにラッキー。 □ 移行利益: 問題は、この場合、実は、移行利益。 枯渇問題への対処としては、相手がv4である以上は、じつは、NAT ISP (JPOPMで某国営通信企業の某氏が主張しているもの)と、その効果は変わらない。 もちろん、デュアルスタックサーバが増えれば、 トランスレータなしで接続できる場面は増えるけど、 じゃあ、トランスレータなしでWebサーバに接続して、 それが何の違い?。 トランスレータのオーバーヘッドなんて微々たるものだよ。 ようは、相手がIPv6でも、P2Pが多少はやりやすくなる、ってだけで、 それ以上の利益はまったくない。 というか、v4のP2Pだって、リフレクタ使えば一緒だって。 逆に、手間やトラブルも含め、 まったく移行コストがかからないことはまずなく、 期待値的にはやはり数万円単位で移行コストがかかると思われる。 ようは、コストベネフィット的には、移行はまったく意味がない。 □ そもそも実現しない。 というか、いま考えたら、 そもそも、IPv6オンリーのISPなんて誰も入らないだろうな。 なんか、長々と書いてきてむなしい。 以上の議論は、ユーザに配るv4アドレスが枯渇し、 IPv6オンリーのISPが現れることを前提としているんだけど、 多分、そんなの誰も入らない。 NAT ISPのほうがまだまし。 だって、できることは同じで、移行コストは低いんだもん。 よって、永遠にIPv6なんて実現しないと思う。 □ 移行後構成 組織編: 会社とかにおいては、なんども言うが、E2Eは不可能。 よって、LANのなかは今後もv4ローカル。 E2Eは行わず、 もしVoIPがやりたいなら、どこかにそれようのリフレクタを立てる。 じつは、E2Eさえ諦めれば、移行コストは大幅に下がる。 移行の意義も大幅に下がるけど。 この場合、ルータの内側がv4ローカルで、 外側がv6グローバル。 LAN内部のPCは、ProxyなりNATなりで外に出て行くことになる。 繰り返し言うが、まず、このあたりの設定の自動化標準化が必須。 □ 移行コスト試算、組織編: その会社がいままでどういった設定でどういった運用をやっていたかによるけど、 この場合、ファイアウォール、プロキシ、 (中と外の境界に入れる)ルータ(これ、なんていうんだ?)、 などの取替え、設定変更などは必須。 まあ、何十万円〜何百万円ぐらいはかかるかも。 □ 移行利益: 組織の場合、正直、個人よりもっと少ない、というかほぼゼロ。 E2EによるP2Pなんてことを、組織内部の勝手な判断で 勝手にさせることは無理。 絶対に情報システム管理部とかを 通してもらわないとこまる。 である以上、 VoIPなどは、どっかにリフレクタを立てて、 さらに、L7のProxyなどを作って、という話になる。 たとえば、スカイプってたしかファイル転送機能がなかったっけ? そうなると、そのあたりを適切にフィルタリングしない限り スカイプを通せないでしょ。 上長の許可なく下請けに見込み客名簿とか送っちゃうやつとかいるからね。 正直、個人的にはそんなのどうでもいいんだけど、 このご時世、個人情報保護法から内部統制報告書まで いろいろ考えれば、そのあたりも何とかせざるを得ない。 そうなると、E2Eなんて無理なのは当たり前で、 リフレクタ経由は当然として、 L7のフィルタリングも必須になる。 さらに、前にも述べているが、IPアドレスの秘匿一つとっても、 HTTPだってすべてL7のプロキシを通さざるを得ない。 つまり、すべての通信をL7でフィルタリングし、 しかも、SRC IPの変換までする。 こんな状況で、どういった移行利益があるんだか・・・。 話が長くなったけど、とにかく、P2Pは不可能。 それ以外の場合でも、v4をv6に変換して、、、といった 複雑な手順がかかる。意味ないよな・・・。無駄だよな・・・。 逆に、移行コストは、それがどれくらいかはともかく、確実にかかる。 ほんと、意味ないよな・・・。 □ 移行構成 サーバ編: まず、はじめに言っておくけど、 サーバなんて半永久的にv4オンリーで十分ですし、 実際にそうなるサーバも多いでしょう。 v6オンリーなんて、自宅サーバとか 訳のわからないやつだけでしょうから無視してもいいですし、 デュアルスタックも、グーグルなどの一部のメジャーな サーバだけになるかもしれません。 何がいいたいかというと、 ようは、 v4サポートを廃止するのって、ものすごく困難なんですよ。 よって、v4オンリーかv4/v6両方か、どちらかしか無理。 で、どっちにする?といわれれば、 どうせv4オンリーでもなんとかなっちゃうんで、 面倒だからv4オンリーという判断は最後の最後まで残る。 □ 移行コスト サーバ編: 正直v4オンリーで十分という気もするが、 あえてデュアルスタックという場合のコストを一応検討。 この場合、Apacheのmodやログ管理からIPアドレス制限まで、 すべてを二重化しないといけないので、 正直、めちゃくちゃ面倒。 イニシャル数百万円、年間数十万円とか掛かりそう。 □ 移行利益 サーバ編: なんにもない。 まず、v6オンリーへの移行なんて考えられない。 唯一ありうるとすれば、v4アドレスが取れなくなった場合だけど、 サーバ用のアドレスぐらい、どうせ半永久的に何とかなる。 よって、v6オンリーへの移行なんて考えられないし、 現実問題として出現しない。 サーバをデュアルスタックにした場合の唯一の利益は、 v6ユーザからのアクセスが、トランスレータを経由しないことだけど、 その利益って具体的に何?。 トランスレータのオーバーヘッドなんて微々たる物だよ。 ようは、サーバのIPv6移行なんて完璧に無駄。 □ 移行コスト アプリ編: アプリのIPv6対応のコストを試算してみる。 一見、すごく簡単そうでしょ。 単に、IPアドレスを管理する構造体の宣言をちょっといじって コンパイルしなおすだけ。・・・でも、実際にはこれではすまない。 □ アプリ修正コスト、仮想的ベストケース: まず、仮に、「ちょっといじってコンパイル」で済んだとする。 こんなのは、実際には起き得ない仮想的ベストケースだけど。 その場合でも、コストはかなりかかる。 というのは、 そのソフトのソースツリーがその場にあって、 その開発者がそこにいて、 コンパイル環境があって、 さらに、その人がIPv6対応修正の経験者とかなら簡単だよ。 そこまで都合いい状況があれば、作るだけなら1日で出来る。 しかし、その前提が都合よすぎ。 しかも、この都合いい前提でも、 動作確認、ドキュメント、、、などまで考えれば、結局1人月かかるな。 さらに、実際は、それをどう配布し、どうサポートし、、、というのが 出てくるので、 とても、「ちょっといじってコンパイル」では済まない。 どうも、WIDE/KAMEの連中はそれで済むと思い込んでいるようなフシがあるが、 市販ソフトはオープンソースのフリーウェアじゃねえんだよ。 ましてや、その「都合よすぎ」の前提が成立せず、 ソースツリーをどっかから引っ張り出してきて、 コンパイル環境を整えて、、、なんてところからはじめたら、 たとえ、ソースが存在し、Visual Studio の経験者がいて、、、 とかの条件がそろっていても、 3人月ぐらいはすぐかかるな。 とりあえず、知らない現場に放り込まれて、 クリーンインストール状態のPCを与えられてから、 とりあえず開発対象のソースがコンパイルできるようにするだけでも、 一週間ぐらいかかるのって当たり前だもんね。 その場合、 まず最初の仕事は、MSDNのDVDってどこだよ?ってところから始まるわけで、 ヘタすりゃそれで一週間つぶれるよ。 5秒で出てくる現場もあるけど、「MSDNってなんだ?」「そんなものの購入申請は認めない」とか凄いことを言い放つ「ソフトハウス」もあるからねぇ・・・。 □ アプリ修正コスト 現実の場合: 以上の場合は、仮想的ベストケースだったけど、 今度は実際にありうる場合。 問題は、WindowsとかのGUIアプリの場合、 単に、128ビットアドレスが扱えるようにするだけじゃなく、 GUIも変える必要性があるってこと。 アドレス直接入力の場合、すごく長くなるでしょ? ようは、入力欄を長くする必要性があると思う。知らんけど。 それ以外でも、普通は、AAAAレコードを引いて、 IPv6/v4は自動的に切り替えるんだろうけど、 実際には、手動で個別指定、とかも出てくるだろうし、 トランスレータに関する設定のプロパティとかもいるかもしれないし、 とにかく、GUIをいじらないとダメじゃないかな、知らんけど。 あれだけ実証実験に税金を投入したにもかかわらず、 このあたりのノウハウもデータも何も出てこないのもアレすぎるが、 とにかく、GUIをいじる必要があると思う。 で、GUIをいじるとなると、画面デザインもかわっちゃうし、 そのあたりまで変更するとなると、 開発だけでも1人月かかるし、開発に必要なスキルも高度化してしまう。 ようは、MFCとIPv6、両方ともを理解しているプログラマが必要だからね、、、。 で、そうなってくると、もう、やはり、 ソフト一本あたり、 数人月、数百万円のコストは必須なんだよな。。。 だれが負担するんだか、こんなコスト。 □ 移行コスト議論 まとめ: 以上の議論でわかったと思うけど、 デュアルスタック環境およびトランスレータ設定の自動化標準化、および そのブロードバンドルータへの実装が非常に重要。 ただ、個人的に一ついうと、 そのようなIPv6移行策を 政府の圧力でブロードバンドルータに無理やり入れるなら、 それと同時に、v4延命策も入れるべき。 たとえば、JANOG近藤邦昭元会長のNATSなど、 v4延命に有効なブロードバンドルータ関係の技術はいろいろある。 まずv6ありきのIPv6原理主義者、などと 不肖オカジマに叩かれたくないなら、 そのあたりも同時に入れるべきだと思う。・・・って、 まずv6ありきのIPv6原理主義者に言っても仕方ないか。 狂信者にかける言葉はないです。 |