(cache) 移行コスト低減

□ 移行費用低減策

別項でも述べているように、私は、IPv6反対原理主義者ではなく、むしろ、IPv6反対原理主義反対者です。私が唯一反対しているのは、移行コストと延命コストの比較なしに、まず移行ありきを叫ぶ人々（＝IPv6原理主義者）です。繰り返しますが、私は、IPv6原理主義反対者かつ、IPv6反対原理主義反対者であって、 IPv6反対原理主義者ではありません。
このような観点から、IPv4延命策と同時に、v6移行コスト低減策も検討します。が、ロクなのないんだよな。

まずもっとも重要なのは、Teredo （てれーど）でしょう。 Teredo ってなんじゃ？という人も多いでしょうが、Windows Vista に入っている v6 on v4 のトンネリンングです（詳しく言うと、v6のL3生パケットを、v4 UDPに入れてる）。おいしいのは、UDP hole punching を使い、運がよければ、NATに穴を勝手に開け、設定なしでNAT越えができることです。英語的には「フナクイムシ」という意味らしく、それは、このあたりの、強引にNATに穴を開けるところからきているらしいです。アプリの変更は必要ですが、ルータは設定すら変更不要ですし、プロバイダも何の対応も不要です。こりゃ凄い。一番いいのは、べつに、v4だのv6だのと無関係に、単なるP2P/VoIPにおけるNAT越え手法として、それだけで有意義なことです。別の言い方をすれば、v6もアドレス枯渇も一切理解していない一般人にとっても、VoIPで手軽にNAT越えする技術として便利に使えることは特筆すべきです。こういった、敷居の低いところから徐々にv6を浸透させていく手法は、マーケティング的にも評価でき、わたしがいままで見たv6移行策の中では最も評価できます。
が、しかし。このよくできた技術ですら、いまいち普及してないんだよな・・・。執筆時点において、Vista登場1年を経過しているのにもかかわらず、まったく反応なし。フリガナ付けて解説付けないとだれも理解してくれない。一番笑うのは、普段v6v6と叫んで税金で食っているような連中ですら、てれーどぉ？あるねぇ。って程度。やる気ないでしょ、やつら。やっぱ、ムリじゃないか？v6。

それ以外ですと、まず、導入すべきは、ある種の短縮アドレスでしょう。いまのv6アドレスって、設定が面倒なんですよ。はっきりいって長すぎ。しかも、数字とアルファベットが混在している。これが、電話での説明を非常にめんどくさくしている。「いや、し、じゃないですよ。よんじゃないです、しーです、しー。」こんなこと、いちいちやってられない。よって、もっと短く、しかも、数字のみとかのアドレスがいいですな。
具体的にいうと、
１、ネットワーク部は、2430 5983 5432 2358 みたいな、クレジットカードみたいな番号。
しかも、なんとかして、非常に短くしてほしい。モールス通信やハフマン符号化みたいに、よく使うアドレス体系に短い符号を割り当てればなんとかなる・・・かも。って、よく使うアドレスってなんだ？
また、表記の仕方（4桁で区切る、とか）も統一する。また、入力のコンパネのLook And Feel も統一してほしい。 OSのバージョンごとにサポートマニュアルを作り CEをいちいち教育するのは面倒なんだよ。理解してほしいのは、その辺のコストもすべて最終的にはだれかは支払わなければいけないんだし、それより、とにかく、こんな細かいこともコストになるんだということを WIDEあたりの学究系の人に理解してほしいし、そして、その理解の下、こういったコストまで削減してほしい。あと、mod11でもなんでもいいので、ある種のチェックサムをつけ、エラーを防いでほしい。（このあたりもクレジットカードと同じ。）。同じことを書くけど、「アクセスできねーよ」→ 「IPアドレスは正しいでしょうか？」。こんなくだらない問い合わせに答えるコストも考えないといけないし、それを削減する方策も必須。
・・・いま、別の意見が届いた。 IPv6は自動設定が優れているのでアドレス設定問題は生じないだってさ。わけねーだろ。まあ、若干v4よりマシなのは認めるけど、それでも、どうせ、なんらかの事情（多分、管理の厳密化）により、手動設定せざるを得ない場面は出てくる。

２、内線番号＝IPアドレス。
ホスト部は、内線番号や社員番号と同じにしろ。さすがに、これなら間違えないだろ。さらに、それを前提に入力コンパネを統一してほしい。って、社員番号の書式とかは会社によって違うんで、どういう風に統一するかは微妙だけど。 DHCP的な手法で、設定書式をルータから自動的に取ってくるとか？

３、v4互換表記
もうひとつ、これは、某JPIXのN野氏の発案だが、 v4互換表記もいるかも。ようは、
3ffe:0501:0008:0000:0260:97ff:192.168.1.2
みたいな表記を可能にすることですね。こうすることにより、v4 → v6移行コストを若干でも削減できます。こんなのは、数学的にはまったく無意味なことなんです。どうしても、v4転写アドレスがほしいなら、ドット表記を自分で16進表記に変換すればいい。が、しかし、理解してほしいのは、現実的には、それを手作業で行わず、普通に入力するだけで転写できるようにすることは、＊とても＊重要ということ。
もっといえば、総合的にいうと、
2430 5983 5432 2358 : 192.168.1.2
みたいな表記がベストかも。いずれにせよ、現場で入力する連中（たとえば、結婚寿退社とテレビドラマしか頭にないOL連中とか）と、それを支援する電話サポートのヘルプとか、そのあたりの現状を理解して規格を作ってほしいね。

４、ドキュメント作成ツール、動作検証ツール
多分、JANOGのMLの連中はそこまで理解していないだろうが、現実に、現場で配線の施工をするということは、単に、つないでPing打って終わりじゃない。 SFCのキャンパスの中で学生がやるならそれでいいけど、カネとってプロとしてやるってのはそれじゃすまない。
実際には、まず、きっちりドキュメントを作る。 IPアドレス割り当て表とか配線図とかね。あと、そこに絶対にいるのが写真。デジカメで楽になりました。
さらに、動作検証も必要。それも、単にPingを打った、というだけではなく、たとえば、セグメントの全アドレス範囲にくまなくPingを打つとか、一晩Pingを打ってパケロスを検証するとか、一通りポートスキャンをかけるとか、何をするのかは場合によって違うけど、そういうことが必要。さらに、そのあたりをドキュメント化しないとだめ。以下の方針に基づき、このような動作検証を行い、このような結果を得ました、、、。みたいなのね。
で、以上の内容を、
・キレイに
・分厚く
まとめて、しかもそれっぽく製本する。あと、ウチなんかだと、よくA0サイズのポスターを作るね。「＊＊社社内LAN全構成図」みたいなの。出力業者に数千円で頼むだけなんだけど、これが意外と好評。
・・・と、ウダウダと書いたけど、こういった、見た目や量まで考慮するのが、カネをとる「客商売」。で、そのあたり、自動化してくれないかな。配線図から検証データまで、 PDFでドキュメントが勝手に出てくるのがいいのよ。
さらに、そのときに大切なのが、スキンっつーの？表面的な見かけをカスタマイズできること。どの業者も同じではマズいんだよ。逆に、カスタマイズさせないなら、 JPNICとかで標準化してほしい。そうすれば、同じ書式で出すことの言い訳ができるから。

５、診断ツールの拡充、標準化
たとえば、Windowsだと、PingですらGUI版は標準では入ってないでしょ。ファイル名を指定して実行 → cmd.exe → 半角小文字でぴぃあいえぬじぃ。このくだらないコンボの案内にどれだけコストがかかってると思ってんだよ。なんで、MSはGUI版を付けてくれないんだ？もうねぇ。
Pingだけじゃなく、一通りの診断ツールをすべてのOSに標準で付けさせると同時に、そのLook and Feel を標準化してほしい。 OSのバージョンごとにサポートマニュアルを作り、サポート要員を教育するコストを考えてほしい。
また、単に付けるだけじゃなく、その仕様は、徹底的にサポートする側の事情を汲んだものにしてほしいね。たとえばさ、IPアドレスだけど、手で入れるのはダメ。全角半角問題とかがある。電卓みたいなのが出てきて、マウスで入れられるようにしてくれ。また、アドレス欄の表示はとにかくデカくしてほしい。老人とかにとっては、小さい字は読めないんだよ。

というか、いま思ったんだけど、 WIDEの連中を、一週間でいいから、どっかのサポセンで強制労働させてくれないかな。一週間、江崎村井両センセイも含め、強制労働。バカユーザの怒号と罵声にひたすら耐える拷問。クレームがついたら、東大教授がユーザ宅訪問で土下座の刑。慶応SFCなんかに何年も通うより、よほどこの一週間のほうが勉強になると思う。
とにかくさ、サポートコストから何から全部考え、それを削減する努力をしない限り、IPv6なんて永遠に普及しないよ。って、WIDEの連中は普及しないほうが研究予算が続いていいんかもしれないけど。

６、Address Agnostic API
それ以外で考えるべきは、 Address Agnostic API の利用の促進です。 v6移行で一番面倒なのは、それは、アプリの移行なんですよ。たとえ、主要アプリがv6に移行しても、どうしても、ある特定アプリだけが移行してくれなかったりね。ほら、これ、2000年問題と同じなんですよ。よく、2000年問題の解説のとき、大昔のコードが残っていて、とか言っていたでしょ。たしかに、それは正しいんだけど、その「生存率」なんてほとんどゼロだった。ただ、ほとんどゼロであってまったくのゼロじゃなかったんで、そこを潰すのにあそこまで手間がかかった。それと同じこと。
いわゆる、doomsdayというのか、とにかく、v4最後の日に向けて、懸命にv4オンリーアプリを潰しても、最後の最後に必ず残るし、第一、そこまで気合入れて潰そうと思ったら、その手間たるや莫大過ぎる。よって、今からでいいから、アドレス形式に中立なAPIに切り替えてほしいわけっすよ。で、もっと具体的にいうと、128ビットなんてセコいことをいわず、もういっそのこと、256ビットとかにしてほしいんです。とりあえず、APIの次元でこれだけあれば、その向こうのプロトコルが何ビットでも、あとはなんとでもなるでしょ。
・・・とはいったものの、多分誰もやらない。たとえば、Apache。 Apache自体はいいんですよ。Apache2ならもうv6化してるし。が、しかし。 mod とかの絡みもあり、当分 Apache1も生き残り続ける。その間は、v4オンリー。さらに、どーせ、v6にしたらバグるmod とかもあるだろうから、 Apache2だからIPv6とは単純にはいかない。さらに面倒なのが、たとえば、ログ解析ツールやCGI。このあたりまですべて v6 にしないとダメなんだけど、それはすごい面倒。どこのサイトにも、むかし理工系大学の学生バイト君が置いていった謎のシェルスクリプトによる怪しいログ加工ツール、とかあるよね。この手のわけのわからないものまですべて v6化しないとダメだから、、、。
こんな手間のかかること、誰もしないよね。
また、サーバならともかく、クライアントの場合、設定のコンパネのアドレス欄の桁数、ユーザ設定値検査仕様などの問題があるんで、たとえ内部的には256ビット対応でも、実際にはかなりコードをいじらない限り128ビットですら入力できない。ようは無理なんだよ、v6移行なんて！。

と、ずらずら書いたんだけど、やっぱねぇ、、、、うーん、ろくなのないねぇ。正直、移行コストを大幅に削減するのは無理だと思いますし、ようは、IPv6移行そのものが無理だと思います。