iどさにっき shuffle 〜2007年6月中旬〜

by やまや
<< = >>

2007年6月11日(月)

IP アドレスは足りるのか

_ 池田信夫曰く、 IPアドレスは枯渇していないと。

IPv4のアドレスは約43億個、全世界のユーザー(約11億人)ひとり当たり4個もある。これに対して、現在のホスト数は約4億3000万なので、アドレスはまだ1割しか使われていないのだ。
なんで分母の全 IP アドレスは使われていないものまで含んだ数を出してるのに、分子のユーザ数はすでに使ってるものだけなんだろ。将来のユーザ数は考えなくていいの?

_ 世界には国中の IP アドレスをぜんぶ集めてやっと class C が1個分とか4個分という途上国も存在する(少なくとも1年前の時点では)。こういう国にインターネットが普及しだしたら、IPv4 アドレスなんてあっというまに足りなくなるのは間違いない。この先5年やそこらでそういった国に普及しないとしても、いざ必要になったときにすでにないというのでは困るので、今のうちから途上国のために空きを確保しておかなきゃいけないはず。そういうことはちゃんと考えてるのかな。考えてないだろうな。

問題を解決する方法は、簡単である。未使用のアドレスを、オークションで再配分すればいいのだ。
IP アドレスの割り当てというのは政治の問題のはず。これを経済の問題にすりかえるのは、つまり経済的に強い者が自分をもっと強くするためのエゴだよね。こういうところに市場原理を導入することの合理性を完全に否定するつもりはないけど、もしも「必要なところに割り当てる」ではなく「金のあるところに割り当てる」を唯一のルールにするのであれば途上国に普及する日はこないだろう。

_ 南北問題は忘れて、将来の潜在的ユーザを考えず、単純に43億個割る11億人でひとり4個が仮に成り立つとする。が、それでも見込みが甘い。意識的にか無意識的にか知らんけど、こういう主張をする人の中でたいてい暗黙の前提となっていることがひとつある。それは、「インターネットがこれからもずっと今のような使い方をされ続けるのであれば」という仮定。甘いね。蜂蜜やら練乳やらどっぷりかけたダダ甘ワッフルよりまだ甘い。

_ 今みたいにメールと Web だけでほとんど用が済むのであれば、たしかに IP アドレスの再配分だけでなんとかなるかもしれない。が、まずその仮定を暗黙の了解とせず、ほんとにそうなのか検討しなくちゃダメでしょ。で、検討してみるに、メールや Web のような旧来のデータ通信だけでなく、電話やテレビ放送なんかの機能も IP 網にのっけるいわゆるトリプルプレイ(もうこの言葉ははやってないけど)やら何やらがもうすぐそこまできている。用途はどんどん広がってるわけ。家電インターネットは何年前かは冗談だったけど、HDD/DVD レコーダーの番組表だとか家庭用ゲーム機だとかなんとかで普及がはじまってきている。この先もどんどん増えるだろう。これからも今と同じ、なんてずいぶん楽観的な推測だと思うね。こいつらも今のところは NAT でなんとかしてるから IP アドレスの消費は抑えられているけど、この先もずっとそれでなんとかなると期待するのはかなり無理があるんじゃないかな。

_ v4 アドレスが潤沢にあって v4 堅持派とみなされているらしいアメリカでも、一部の ISP は自分たちのビジネス(おもにトリプルプレイ関連)を拡大するためには自分たちの持っている IP アドレスだけじゃ足りないと気づきはじめているらしい。ネットワークに疎い一般の人にセットトップボックスを買ってもらうには、めんどくさい NAT じゃダメ、と。ソースなしの伝聞なのでアレだし、そもそもやつらは IP アドレスを節約しないでじゃぶじゃぶ使う考え方に慣れちゃってるのであんまり参考にはならんかもだけど。

_ NAT で現状困っていないアプリケーションならば今後も NAT のままで困らないだろう。でも、その影で内から外へ出るのは自由だけど外から内に入るのはめんどくさいという性質の NAT が普及しちゃったおかげで苦労しているアプリがあることも忘れちゃいけない。 NAT ってそもそも IP アドレスが足りないのをなんとかするトリックにほかならんわけで、それが一般的な技術になっている時点でおかしい。v4 アドレスは枯渇しない、ではなく、とっくに枯渇してるけど錬金術を発明しただけ。でも錬金術で生み出されたのはまがいものの金であって本物の金じゃないからあちこちで化けの皮がはがれる。それを隠すためにまたわけのわからん手品で隠す。その繰り返し。

_ P2P がファイル交換ソフト中心な使い方をされているのは今のうちだけで、そのうちにいろんなアプリケーションが P2P で実現されるようになると思うんだけど(従来のクライアント-サーバモデルはデータ量の増大にともなうサーバ/データセンターへのトラフィック集中についていけずに将来きっと破綻する)、Winny でいうところのいわゆる Port 0 問題のせいで NAT な環境どうしでは P2P はうまくつながらない。ちょっと前、Skype 創業者がはじめた P2P 動画配信の Joostで遊んでたんだけど(もう飽きた←ぉぃ)、うちが NAT なもんだから P2P な他のクライアントとの接続はほとんどできなかった。ある程度間隔をおいて何度か netstat を叩いて様子を見てたんだけど、接続先は Joost 側で用意したサーバばっかり。一般ユーザのクライアントと接続してたこともまったくないではなかったけど、でもあの程度じゃ P2P とは言いがたい。クライアント-サーバモデルは破綻しかかってるのに、それにかわる新たなモデルになりうる P2P は NAT で使いものにならない。どうすりゃいいんだろ。

_ それから、ネットワークゲーム。いや、ネトゲはやらんからあんまり知らんのだけどさ、ほとんど TCP でクライアント-サーバモデルな方式なんだよね(ほんとに知らんので違ってたらごめんなさい)。まあ、ものにもよるんだろうけど。応答性を考えれば TCP よりも UDP を使いたいだろうし、プレーヤー同士のチャットなんかはサーバで中継するよりもクライアント間を直接 P2P でつないだ方がサーバはよけいな処理はしなくてラクだと思うんだけど、NAT のおかげですべてご破算で願いましては。理屈の上ではもっとマシな通信方式はあるはずなのに、現実にそれをやってしまうと初心者が遊べないゲームになってしまうなんて。

_ あるいは、まったく未知の、でも斬新ですげー便利でステキななにかを将来誰か発明するかもしれない。でも、もしそれが NAT で IP アドレスをシェアするような使い方では実現不可能ないしは困難だったりしたらどうしよう? 今後も v4 NAT でいいよね、という考えは、こういう未知の可能性を潰しているかもしれないことは心に留めておいた方がいい。

_ そういうわけで、新たな使い方が開拓されていくと、IP アドレスがひとり1個なんて決定的に足りない。5個や10個あっても足りるかどうか。再配分すれば大丈夫とか言ってるのはまったく前が見えてない。今と同じ使い方が今後も続くわけがないし、万が一10年たっても新たな使い方が生まれなかったとしても、その次の10年に生まれるかもしれない新たな使い方を許容する余地は残しておかなければならない。10年前のインターネットを思いだしてみよう。携帯電話はインターネットにつながっていた? IP 電話知ってた? P2P なんてものを想像したことある? じゃあ、次は10年後のインターネットを想像してみよう。今と同じ使い方が続いてると思う? どんな機械がインターネットにつながってると思う? IP アドレスがひとり1個で足りると思う?

_ 別に IPv6 がいいと思ってるわけじゃないんだけどさ、だからといっていつまでも v4 だけを使い続けてパンクするのを待つのが正しい判断だとは思えない。いや、わしの言ってることが間違いで、実際は IPv4 アドレスは100年たっても枯渇しませんでした、が正解なのかもしれん。でも、だから今後も IPv4 だけでいい、というのは違うと思う。死蔵されている IPv4 アドレスをどんなにうまく配りなおしたところで、総数が人口よりも少ないんだから NAT なしではやっていくのは難しいだろう。将来ではなくすでに現実の問題として NAT な IPv4 じゃ不都合があるものはいっぱいあって、それらのうちのいくつが IPv4 の制約のない世界で普及を目指したい、というのならばそれを阻むのはよろしくない。v4 アドレスの再配分はどんどん進めなきゃいかんし、もしかしたらそれで十分足りるのかもしれんが、そのことと非 IPv4 ネットワークの整備はけっして相反するものではないはずだ。わしとしては、IPv4 はメールや Web といった旧来の用途に利用を限定して、それ以外の新しいアプリケーションは IPv6 上に住むのを前提としていくことを考えていかにゃならん時期に来ているんじゃないかと思ってる。

_ まっすぐ天に向かって成長したくても、天井でさえぎられていたら横に伸びるしかない。そうやって天を目指さず横やら下やらに伸びていっても空間にはまだまだ余裕はあるかもしれない。でも、それを異常と思わず、まだ空いてるんだからそれでいいじゃんと肯定してしまうのはいいことなんだろうか。天井をブチ抜く方法があるのならばブチ抜いて再び天を目指す方向に導いてやれないものだろうか。

_ え? コスト? あー、それは誰かえらい人考えといて。←長文書いてそんなオチかよ


2007年6月12日(火)

Leopard

_ WWDC のアレですが、 プレスリリースに ZFS の文字が見当らない。

_ まあ、ああいうのは裏方の機能であって、ユーザがいじる派手なフロントエンドではないからいちいち紹介しないのもアリなのかな、と思ったら、 採用しないってマジですかー? いや、まだあくまで噂だけどさ。これまで伝わってきた話では採用確定で間違いないってことじゃなかったんかい。なんでひっくりかえすかなー。

_ つーかさー、 この前VMWare にインストールした Solaris10 って、重すぎて使いもにならんからけっきょくほとんどさわってないんだよね。あれで ZFS な遊びやろうと思ってたんだけどなー。


2007年6月13日(水)

Leopard ZFS

_ なんだー、ちゃんと zfs あるじゃーん。やっぱデマだったんだね。

_ ……って、 read-onlyってどういうことだよっ。わざわざ Solaris で書いた ZFS のディスクをはずしてきて Mac に載せて読むのか? いったい何がうれしくてそんなアホなことをやるんだ。Interl Mac で OpenSolaris が動くらしいけど、そういう世界で何人もいない物好きのための機能か。ZFS をサポートしないというきのうウソの発信源のいってることだから、こいつもまたデマなんだろうなぁ、たぶんきっと。

_ ところで、CNET の記事では

Sunさえも、自社の「Solaris 10」において、デフォルトファイルシステムをZFSに切り替えていない。
とあるけど、これはファイルシステムの安定性、信頼性の問題というよりも、ZFS に対応したブートローダの開発に難航してるのが問題なんだよね。ルートが ZFS にあると起動できないから、デフォルトはこれまでどおり UFS にせざるをえない、という。とはいえ、つい最近 Nevada で ZFS からのブートについに成功したという記事をどっかで見たのでなんとかなったようだけど(どこで見たんだっけな?)。それはともかく、Solaris と OSX のブートローダはまったく別モノなんだから、Solaris のことが OSX にも当てはまるとはかぎらん。


2007年6月15日(金)

Outlook Express で submission + tls

_ ごく最近のWindows Updateで、Postfix TLSでのSMTP Auth送信がOutlook Expressからできなくなる件。関係ないキーワードが強調されてるので何が起きているのか見えにくいけど、Postfix とか SMTP AUTH とかはまったく関係なく、Outlook Express で submission ポート上の STARTTLS がサポートされた、という話だよね。

_ これまでは、25番ポートに対しては STARTTLS だけど、それ以外では SMTP over SSL(SSL トンネルの上に SMTP セッションを張る)をおこなうという実装だったので、STARTTLS には対応しているものの、submission ポートでは STARTLS ではなく over SSL をやろうとしてしまうのでうまく送信できず、SSL はオフにする必要があった。また、MSOE は SMTP AUTH で CRAM-MD5 や DIGEST-MD5 が使えないので、結果として OE では submission ポートでメールを送るには認証情報を平文で送るしかなく (*1)、OP25B の代替となるべき submission が TLS の使えた従来の25番よりも弱くなってしまう、とちょうど1年前の Interop の迷惑メール対策 BoF で名指しで批判されていた。今回の件は、submission での STARTTLS に対応してやっと25番並みに使えるようになった、ということ。まあ、ユーザからの投稿用ポートで STARTTLS / over SSL に対応してる ISP なんてめったに存在しないから(まったく存在しないわけではない)、対応したところで実質的にはほとんど変わらんのだけど。

_ ところで、587 で STARTTLS (smtpd_use_tls = yes) ではなく over SSL (smtpd_tls_wrapper_mode = yes) をやる設定ってはじめて見たんだけど、これって一般的なものはではない……よね?


(*1): サーバ側が MS Exchange ならば別の認証方式が使えるらしいので、まったく不可能というわけではない。また、submission + starttls ではなく465番(smtps)で over SSL なら以前から可能だった。

livedoor.com.net

_ ブログReaderクリップなど、ライブドアのサービスの多く(というか、見かけたかぎりでは全部)が domain=livedoor.com.net といううんこな cookie を食わせようとする。ぐぐってみたけどこの件について指摘してる人はまったくいないようだ。だれも気がついていないんだろうか。というか、ライブドアの中の人は開発のときに HTTP のレスポンスヘッダを眺めたりしないのだろうか。

_ まあ、ふつーのブラウザは黙って無視するので問題はないけど。受けいれてしまったらセキュリティホールなので。ふつーでない実装がどれだけあるのかは知らない。


<< = >>
やまや