(cache) PnP多段階NAT

全般としてまったくまとまってませんが、ようは、多段階NATを押し付けることにより、 NATの抵抗感をなくそう、という作戦です。書きながら内容を考えていたので、まとまっておらず恐縮です。

■ 提案：PnP多段階NAT

□ はじめに
このグダグダと鬱陶しいIPアドレス枯渇問題の最終解決案がここに。

ようは、私がグダグダとここで述べている IPアドレス枯渇対策の技術的な根幹は、ようはNATなんですよ。なんでもNATでいいとなれば、 E2E真理教徒という狂信者を排除できるのは当然として、アドレス枯渇問題そのものも解決できるはずです。

じゃあ、何がNATで問題なのか、といえば、ひとつは、NATの内側では外から内のコネクションが受けられない。これは、VoIPなどのときに致命的。もうひとつは、わざわざNATにする利点がない。もし、ICANNから十分なアドレスが随時供給される特権を持っていれば、べつにNATで節約する必要性はないでしょ。そうなってくると、たとえNATで節約すれば何とかなる状況でも、結局はアドレスの奪い合い。
一部、私の、NATでNATでNATで、しかもNATな主張に対する反論で、 NATの存在にもかかわらず、IPアドレスの消費は減ってない、というのがあるけど、そんなの当たり前。あればあったで便利な存在である以上、たとえ節約できても誰も節約しないのがIPアドレス。逆に言うと、NATで節約しないとマズい、またはNATを使うとなんか利点がある、このどちらかを達成しない限りNATでの節約は達成不可能。で、マイナスのインセンティブを与えるのは、それはまさにIPアドレス税なんだけど、効果は絶大でも政治的に非常に困難なんで、今度は、プラスのインセンティブ。つまり、NATにしないと罰金、という制度は政治的に難しいので、 NATにするとメリット、という方策を考える。
まとめると、
１、外から内へのコネクションを可能にする。
２、わざわざNATにする利点を作る。
この両方を達成すれば、IPアドレス枯渇問題は一挙に解決するはず。

もうひとつ、それと同時に考えないといけないのが、IPv6がなぜダメなのか。それは、顧客ニーズを考えていないから。マーケット無視、マーケティング無視といってもいいでしょう。
アドレスが不足している → 128ビットに拡張すればいいじゃん、というのは、数学的、学術的、といった次元では正解かもしれませんが、互換性を考えないやりかたは、マーケティング的には超不正解です。単に uint32 → uint128 の置換を実行、みたいな、こんなしょうもない「発明」で、自分は優秀だ、と思い込んでるんでしょうが、まず、これがどこが新技術なんかよくわかりませんし、（じゃあ、IA-32のソースをAMD64モードでコンパイルすれば新技術か？）、少なくとも、「優秀」と自称してるなら、とにかく互換性と互換性と互換性を入れてほしかったんですが。どーでもいいですが、繰り返し言ってますが、互換性を保ったまま、どんなに無理やりでもいいので、なんとか無理やりアドレスを拡張する無理やりな方法ってないんですかね。それを発明してくれれば、真の意味で「優秀」と認めます。どんなに無理やりでもOKなので、誰か何とかしてください。一説には、IPv6は、WIDEの行き場のない連中の失業救済策という説まであり、死にたくなります。
ニートやフリーターの救済ならともかく、なんで、「一流」（とされている）大学の博士課程まで卒業したような「優秀」とされている連中に救済策なんているんですかね。そんなに優秀なら自分で勝手に食っていってほしいんですが。

で、マーケティング的な話に戻すと、いま、顧客に需要がある案件って、正直、アドレス枯渇じゃないんですよ。もちろん、実際に最後の日が訪れれば大騒ぎするんでしょうし、それは、潜在的にはすごい需要があるということかもしれませんが、その日がくるまで、誰も問題の存在すら気づいていない以上、その潜在的需要を顕在化させるのはとても難しく、アドレスが拡張されました、枯渇問題がどーのこーのなどと説明しても、まったく反応はない。本当は、枯渇前に手を打たないとダメなんだけど、枯渇するまでは問題すら理解しない。よって、枯渇以外の訴求点があり、なおかつ枯渇に対応できる方法がよい。
で、枯渇以外の訴求点だけど、ウケるのはとにかくPnPですね。あとはセキュリティ。これがガチ二大需要。それ以外だと、信頼性、安定性とか。これは、ECとかEDIの進展もあり、これから伸びると思う。それ以外では、モバイル。あとはマルチキャスト、というかインターネット放送とVoD。・・・と、つらつら書いてきたけど、そのなかでも特大ホームラン級に重要なのはPnP。それ以外は正直これにくらべればどーでもいい。

ようは、繰り返しになるけど、
１、外から内へのコネクションを可能にする。
２、わざわざNATにする利点を作る。
に加え、３、それをPnPで。
以上を達成すればなんとかなるはず。

まず、１だけど、ようはリフレクタ使えば一発。
２だけど、ここがすげぇポイント。（というか、これを思いついたからこれを書いている）。いま、たとえばセキュリティなどのために、セグメントを分ける、ってのがある。ようは、社内LANにルータを入れていくやつね。正直、個人的には、そんなのはあまり意味はないと思っており、 1セグメントにL2で1000台ぐらいノードを浮かべても何とかなるんじゃないのか？と思ってるんだけど、とにかく、その手のLAN改修工事の需要はあるんだ。
で、この際に毎度問題になるのが、 LANの配線の現場作業をやっている会社は、 IPアドレスの切り分けやルータ設定ができないってこと。この手の会社って、もともとは電気や電話の配線の会社なんだよ。というか、いまでもそっちがメインだったりする。そーゆー会社の人って、作業服を着て床下に潜るのは得意なんだけど、それ以外はぜんぜんダメ。せいぜい、/24で切り分けるのがやっと。それ以上ができる会社を見たことがない。ましてや、動作検証やドキュメント作成まで総合的にやれる施工会社なんて皆無。なんと、こんなくだらないことにSIerのNEを使っている場合が多い。スゲェ無駄。
でも、よく考えたら、そんなことをしなくてもPnPでL3の切り分けって出来るはずじゃないか？。どうやるか、といえば、 LAN内部で、多段階にNATするんだよ。 NATルータを多段階に入れる。このNATは、ようは、内側が192.168で外側も192.168という変なNATだけど気にしない。ルータの外側のアドレスは、DHCPで上位のNATルータからもらう。ルータの内側のアドレスは、やはりDHCPで適当に決定する。・・・こうすれば、 PnPでL3の切り分けができるでしょ。TCPオンリーになっちゃうけどね。
・・・このアイディア、どうよ？。そう、NATは、PnPでL3の切り分けを実現する画期的技術であって、決して、アドレス枯渇問題に対応するために無理やり作られたセコいアドレス節約技術じゃないんだ！！！！。

なお、ここまで書いてきて気がついた。以上を読んでると、なんか、新しい仕掛けを導入させることが目的みたいに映ると思うが、それは間違い。ようは、NAT ＝ダサい、という状況を無理やり変えるのが目的。もっといえば、これは、大げさなマーケティング戦略であって、べつに何か具体的な効果（セキュリティ向上など）を目的としているわけではない。何の意味もなくても、イメージがよくなればそれでいい。
ごめんな、いまいちまとまっていなくて。

もうひとつ、これにより、社内LANを多段階NATにするとして、その上流のISPは、いわゆる私が勝手に言うところの「NAT ISP」にすべき。というか、このNAT ISPの抵抗感をなくすため（いわゆる「イメージ格差問題」の解決）に社内にも多段階NATを入れろっていってるわけだから・・・。逆に、社内が多段階NATなら、ISPも多段階NATで何が問題がある？。

で、そのために作った計画がこれ。特許も何も主張しませんので、だれか実行して。

設計目標（基本編）：
１、アドレス枯渇問題が解決できること（当たり前）。
２、たとえ、アドレスが不足していなくても利用する利点があること（重要）。
３、互換性、互換性、互換性
４、PnP、PnP、PnP

設計目標（実際編）：
１、NATの使用の抵抗をなくすこと。
２、互換性
３、PnP

ネーミング案：
まだ決まってないけど、、、。
Real PnP
Instant Internet
Secure connect
Dynamic Connect
Dynamic Security connect
Dynamic Secure Connect
Internet 2.0
IPv7
IPv8
IP4.6
IPv6-2
SuperIP
UltraIP
MegaIP
GigaIP
TeraIP
PnPIP

とりあえず、PnPがアピールできるような名前がいいな。あとは、ハッタリでセキュリティがアピールできるような名前とか。いまんとこ、Dynamic Secure Connect がいちばんいいっぽい。でも、略せばDSC？なんかヘボいなぁ。あとは、やっぱ、フカシでInternet 2.0みたいなのもいいかもね。 Web2.0に最適なISPはInternet2.0です、みたいなの。もうこんな屁理屈全く意味不明だけど、Web2.0はようはHTTPでTCPなんだから、 NATでいいんじゃないの？さらに、フカシをすすめて Internet3.0とか。2.0はどこに行った？というのは一切無視。とりあえず数字が大きいほうが素人はすごくおもうでしょ。 Internet64ってのはどうよ。64ビットPCにはInternet64が最適、とかいったら真に受けるかも。IPv64とかもいいかも。

具体的内容：
構成：
・LAN内部のすべてのルータを、DHCP+NATにする。
ようは、家庭用ブロードバンドルータをLAN内部で多段階接続しているようなイメージ。
・これは必須ではないが、ISPがリフレクタを用意してくれることを強く期待。別項でもいってるけど、もしv6に移行するとすれば、トランスレータが必須で、それはリフレクタとほとんど一緒なんだから、 v4延命でもリフレクタは用意すべきだと思う。
・これも必須ではないが、ISPは、NAT ISPを使う。つまり、多段階NATの上にさらに多段階NATを重ねる。
動作：
・PCは、（L2ハブ経由または直接）ルータに接続する。
・アドレスはローカル。それをDHCPで貰う。
・ただし、このアドレスは、そのルータ配下のみで使えるローカルアドレス。
・別のルータの配下にあれば、アドレスが被ってもいい。
・グローバルなインターネットへはNATで出る。
・クライアントPC同士でのP2Pな通信は、リフレクタを使わない限りは不可能。

JANOG的利点：
まず、顧客からすればどーでもいいのだろうけど、インターネット全体に対してデカいのは、これで、NATでいいじゃん、という合意が自然と形成されること。というか、この合意を無理やり作るのが目的なんだから。 NATの使用の抵抗をなくし、NATを無理やり普及させ、 NATによりアドレス枯渇問題を解決するのが、私の提案の技術的骨子ですからね。で、それによりアドレス枯渇問題も、別項で述べている「イメージ格差問題」も含め、解決される。

顧客的利点：
重要なのはこれ。まず相手のことを考えるという基本原則を忘れ、自分のわがままと得手勝手をゴリ押しするからWIDE連中はダメなのよ。

で、具体的な利点ですが、顧客向けにまとめると、こんなの。
１、IPアドレス設定なしに、自動的にLANがセグメント分割されます。
また、外部からのLANアクセスおよび内部でのP2Pの使用も禁止されます。
以上により、設定なしにセキュリティが向上されます。
２、ISPトラブル時は、予備系統に自動的に切り替え、高信頼性を達成します。
３、VoIP使用時のポートフォワーディングの設定が不要です。
・・・こんな風か？

もっと単純に書けば、
１、自動設定、設定不要、PnP、、、、
２、セキュリティ。ポートフィルタリング、P2P排除
３、代替切替。高信頼性。
４、VoIP完全対応
５、アドレス枯渇問題完全対応
このあたりを適当にアピールかな。

このあたりのウリが受けるかどうかを、とりあえずつらつらと検討すると、、、。

１、PnP。
とにかく、これこれこれこれ。なにがいいって、IPアドレス設定を考えなくても LANのセグメント化ができるんですよ。これはウケるよ。PnPでセグメント化だぜ。

２、互換性。
顧客からすればごく当たり前の空気のような事項であり、だれも気付かない思いますが、とにかく、繰り返し繰り返し繰り返し言いますが、これ、本当に重要なんです。
いーですか？JANOG/WIDEの自称「頭のいい」連中に、僭越ながら、このお馬鹿さんオカジマがここではっきり進言しておきますが、 PnPと互換性こそ、売れるすべてなんです。いーですか？「自称」アタマいい、というのはさんざん分かりました。だったら、なんとかして互換性を保った範囲でのアドレス拡張の手法を開発して欲しいんですが。本当に無理なの？これ。
で、話を戻すと、このあたりもウケるでしょう。 PnPで互換性を保ったまま自動的にセグメント化だよ。こりゃいい。

３、セキュリティ
現実問題としては、たいした機能はない。一応、セグメント化をしていくし、まあ、NATなんでセキュアといえばセキュア。また、クライアントPC同士でのP2Pができないので、構内での違法コピーとかはやりづらいとおもう。・・・が、それで安全とかいってもねぇ。でも、「安全です」と言い切っちゃえばそれなりに信じる人もいるでしょうし、それなりにウケるんじゃないかな。現実問題として、安全確保を名目のひとつにセグメント分割をやる事例って結構あるよ。
また、拡張構想としては、 DNS引くときに何らかの認証をかけるとか、 L4で強制的にSSL暗号化するとか、、、まあ、ネタとしてはないことはないね。
どれをとっても、マイナスイオン程度の効果しかないけど、マーケティング的に強引に言い切れば何とかなるでしょう、多分。とりあえず、某P2Pソフトだの個人情報保護法の狂乱だの、しょうもない一連の馬鹿騒ぎのせいで、このあたりの関心が高いのは事実で、どんなハッタリでもマイナスイオンよりマシならあったほうがいいかも。知らんけど。

４、信頼性、安定性
NATは、L4なんで、複数の経路を持つのも、マルチホーミング不要。よって、ここはL3で直にパケットを流すより圧倒的に優れている。ここまで作りこむかどうかは微妙だけど、とにかく、技術的には L4マルチホームは可能。これは、それを必要とするユーザには結構ウケるんじゃないかな。問題は、どれだけ広いユーザに受け入れるか、だな。法人ユーザとかにはウケるとおもう。
また、NATの先を強制的にSSLにすることにより、安全性を実現することもできる。問題は、やはり、この強制SSLがマーケティング的にいって、これがどれだけ顧客にアピールできるかだな。セキュリティと意図的に混同したハッタリマーケティングが有効かも。個人的には、セキュリティはアプリレベルでSSLとかすればいいんであって、ネットは透明なパイプに徹すべきであって、セキュリティまですべきではないと思っているんだけど、とにかく、顧客の要望がすごいんで、たとえマイナスイオンレベルのハッタリでも、とにかく、なんとなくセキュリティに効きそうな雰囲気を漂わせることは有効かも。

５、モバイルIP
これもイケる。 L4なんで、IPアドレスの変更は問題ないので、モバイルは簡単。正確にはL4でやると「IP」じゃなく、モバイルTCPになるけど気にしない。イメージ戦略としてはいいので、実装するつもり。問題は、これがどれだけ今現在で顧客に訴求するかだな。イメージ戦略としてはとてもいいし、中長期的には実需もでるんだけど、今現在の実需としては L3でのモバイルIPのローミングなんてゼロだからね。モバイルIPに関する論文をいろいろと読めば分かると思うけど、

６、インターネット放送、マルチキャスト、VoD
需要はすごく、もし可能なら入れ食い状況だけど、正直、マルチキャストはL3の話であってL4でどうこうじゃないんだよな。。。なんかいいアイディアないっすかね。これが可能なら、某柔らか銀行とか、某ハッピースカイとか、一発で乗ってきますよ。やつら、やりたくてやりたくてしょうがないんだから、、、。
いま思いついたんだけど、Joostみたいなのを入れるっつーのはどーよ？ブロードバンドルータに、JoostみたいなP2P機能が入ってるわけよ。で、PCの電源を落としても、ブロードバンドルータの電源が入ってれば、 Joost風プロトコルのノードとして勝手にP2Pとして中継する。この場合、ポート開放の設定なしで中継ノードが立ち上がるし、ブロードバンドルータの電源は通常は常にONなんで、それも利点でしょう。もちろん、ISPがIXとDSLAMのあたりにリフレクタをつければ全部解決するし、本来そうすべきと思うんだけど、そうなる前のつなぎとしては結構いいかも。問題は、P2Pというイメージが悪すぎることですな。なお、この仕掛けは、別にアドレス枯渇問題とはまったく関係のないものです。が、しかし、そんなの気にする必要性なし。 v4延命は、インターネット放送を可能にする、みたいなイメージで適当に売り込んでしまえばOK。ミッキーなんて技術のことぜんぜんわからないから、それで通っちゃいますよ。といっても、この方式にはすげぇ欠点がある。いまのFletsとかのPPPoEでは効果はいまいちなんだよな。ゼロじゃないけど、あまり大きくない。 Yahoo!BBのように、収容局の中だけでユーザ同士のP2Pができないと、効率が上がらない。 Fletsの場合、ユーザ同士のP2Pが、いちいちPOIまで行って戻ってくるので、すげぇ効率悪いんだよ。
・・・うーん、なんかいいアイディアないの？もしあれば、某スーパーサイヤ人なんて一発で釣れるよ。連中、やりたくてやりたくてしょうがないんだから。

実装：
NAT on NAT は、いまのブロードバンドルータでも普通に可能。よって、NAT on NATだけ実装するなら、まったく何も必要性はない。 5000円ぐらいのやつを買ってきて、ただつなげばOK。このあたりは、非常に重要なことで、たとえどれだけショボい実装でも、それが目の前で動いているのと動いていないのでは説得力がぜんぜん違うし、単に動いているだけなのと、それが5000円で秋葉原に山積みになっているのでは、やはり説得力がぜんぜん違う。
私が、この方法をイケるな、と思っている理由のひとつはこれ。ようは、これ、鶏と卵の問題があるんですよ。方式があたれば、当然秋葉原に機材が山積みになりますが、機材が秋葉原に山積みにならないと方式が当たらない。これを解決するのは結構ポイントなんですが、それがもともと解決ずみ。こりゃ結構あたるでしょう。しいて言えば、いまのブロードバンドルータそのままじゃなく、デフォルトの設定を PPPoE じゃなく NAT on NAT にすべきかも。すくなくとも、マニュアルにその辺りの詳しい解説がいる。ただ、いずれにせよ、そんな程度のことでいきなり動かせるのは、最初のきっかけとしてはすごくいい。この敷居の低さは、イケるかな、という感触をもたらします。
もちろん、それだけですべてが完璧に動くわけじゃなく、たとえば、P2P機能とかをつけるなら、当然ファームの改造は必要ですし、それ以外でも、モバイルIPやマルチホーミングなどもファームの改造が必須。それ以外でもファームレベルでは当然いろいろといじるところは出てくるでしょう。たとえば、多段階NATの管理のSNMP的機能を入れるとかさ。そうなれば、それようの管理ツールもいるし。ようは、実際問題としてはかなりの工数がかかる。
しかし、一番の基本機能だけなら、無改造でイケるってのは大きいですな。