アカウント名:
パスワード:
NAT や proxy を通ることで End to End の通信が出来なくなるので、一般ユーザから見た場合に最も広範に利用される Web アプリケーションなどの領域では、「通信相手が本当に最初に通信してきたユーザなのか」を識別する方法が異様に狭くなる訳ですが。
そこまでしてサーバ/クライアント共にコストを払って IPv4 を使い続けるより、IPv6 で匿名アドレスで利用してくれたほうが余程サーバもクライアントも楽です。
また、インスタントメッセージングなどの分野でも、みんな NAT などの場合には UPnP 対応機器などを利用していないと簡易ファイル転送が利用できないなど、一部機能が利用できないなどの問題がありますね。
IPv6 で一番嬉しいのは気軽に End to End で利用できることな訳で、NAT が必要というだけで面倒でたまらなく感じますよ。
# NAT や Proxy を使わないといけないという段階で IPv4 アドレスが不足していると認識する方が素直だと思います。
IPv4 + cookie の場合に、盗用された cookie と本当の cookie であることが IPv4 アドレスから判別することが困難ですから、単純に reject するのが難しくなりますね。同一 proxy 内でやられたらサーバ側としては判断不能でしょう。
これを指して「サーバもクライアントも余程楽」と言っているのですが。IPv4/IPv6 両対応の Web アプリなどでは、IPv4 部分で認証周りの処理でコストがかかります。
また、インスタントメッセージングの分野などでは、IPv4 - IPv6 gateway の役割をサーバがこなせば問題ありませんね。IRC で IPv4 と IPv6 が断絶していないように。移行中はそれでなんら問題はないと思いますけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
コスト？ (スコア:5, すばらしい洞察)
回収・再利用のための市場整備をすべきなんじゃないかなぁ
いってみれば、環境保護でCO2の排出権利再販というのがあるけど、あれみたいな。
土管としてのIPv6は回線屋には若干のメリットがあるものの、
サービス上はサービス提供者にも利用者にも何らメリットがないわけで
それでいてコストをかけろというのは技術屋の驕りとしか思えない。
ちゃんとIPv4の取引市場を整備すれば、IPv4の価格が上昇していって
移行コストを上回り始めた段階で、それぞれが自発的意図に基づいて
IPv6に移行する。技術屋の役割はその移行を可能にする技術の整備までで、
その先の市場整備をサボって「なくなるから移行しろ移行しろ」では
意図的に早期のIPv4の根絶で商機を作ろうとしているようにしか受け取れない。
Re:コスト？ (スコア:0)
のロジックがよくわからないんですが、そんな面倒なことしなくても
IPv6を推進したいところがIPv4をがめちゃえばいいんですよ。
なくなるんじゃないんです、なくすんですｗ
Re:コスト？ (スコア:0)
見事なまでのアンチキャンペーンになってしまっているんですって。
最大の問題はIPv4が枯渇することではなく、移行するための
妥当な経済モデルが存在しないことです。このために市場側からは
移行する動機が最後の瞬間まで存在しないので、ある日突然
枯渇→破局する終末しか描けなくなっている。
これを解決し、よりスムーズな移行を行うためにはIPv4の市場化が
必要だと私は考えています。
Re:コスト？ (スコア:0)
一気に終末とはならない気がしますが。
少なくとも国内の個人ユーザレベルではほとんど問題が起きないのでは？
#企業が新しく固定IPアドレスを取れなくなるのは問題ですけどね。
Re:コスト？ (スコア:3, すばらしい洞察)
今はISPがユーザ数以上のIPアドレスを常に確保しているから問題が起きて
いないんですよ。
ユーザ数以上のIPv4アドレスが確保できなくなったら、「IPv4で接続したいと
思った時に常に接続できる」という保証が全くなくなりますけど、それでも
「ほとんど問題が起きない」ですか？
Re:コスト？ (スコア:3, 参考になる)
>>今はISPがユーザ数以上のIPアドレスを常に確保しているから
確保してないですし。そもそも現在のシステムはユーザ数と同じ固定IPを必要としていません
ましてや実際の運用としてでの常時接続を行っているユーザ数は少数ですから
IPアドレスや帯域どころか同時接続コネクション数ですら十分な確保さえせずに
実運用を行えていたダイヤルアップ時代のノウハウはいまだに有効活用できます
Re:コスト？ (スコア:1)
すまぬ、投稿してから不正確なことに気が付きました。
「ISPが同時接続数以上のIPアドレスを常に確保している」というのが正確な言い方。
で、もし同時接続数以上のIPアドレスを確保できなかったら、次はシステム的に接続数を減らして
いく方法に進むでしょう。
例えば「1時間以上通信のない接続は強制切断」とか、「通信開始から24時間で有無を言わせず
強制切断」とか。
さらに、有料の「切断回避オプション」が出てきたりとか、固定IPアドレスの需要が多くなって
固定IPアドレスの値上げがでてきたりとかいうことも想像できますね。
そういうことも含めると「まったく問題起きない」とはいえないでしょう。
と、ここまでは単純にプールアドレスの使い方の問題。
もっと問題なのは、今後IPアドレスが取れなくなると回線系事業への新規参入が事実上不可能に
なってしまうこと。資金力のある会社なら、不採算のISPを買収してIPアドレスごと取得する
なんてこともできるかもしれないけど、ベンチャー系はそんなこと不可能だし。
結局、ユーザーに恩恵があったかもしれない事業が、IPアドレス枯渇のせいで立ち上がらない
ということが起こる。
そう考えたら、「アドレスが枯渇してもユーザーには問題なし」とはとても言えない。
Re:コスト？ (スコア:0)
つマスカレード
つProxy
何かを勘違いしているようだが、
そもそもユーザ側から見たIPv4の枯渇なんてないよ。
1つのグローバルIPをシェアする形になるだけ。
ユーザはネットに繋がれば良いのであって、
グローバルIPを必要としているわけではない。
（一部のマニアを除く）
と言うか、CATV系はネットワークの構造上、
CATV網内をプライベートIPで、出口にProxy置いてると言うケースは少なくない。
お陰で誰かがアク禁喰らうと全滅、なんて面白いことも前には起きてたな。
＃実はその巻き添えを食らったことがあるのでAC
Re:コスト？ (スコア:2, すばらしい洞察)
NAT や proxy を通ることで End to End の通信が出来なくなるので、一般ユーザから見た場合に最も広範に利用される Web アプリケーションなどの領域では、「通信相手が本当に最初に通信してきたユーザなのか」を識別する方法が異様に狭くなる訳ですが。
そこまでしてサーバ/クライアント共にコストを払って IPv4 を使い続けるより、IPv6 で匿名アドレスで利用してくれたほうが余程サーバもクライアントも楽です。
また、インスタントメッセージングなどの分野でも、みんな NAT などの場合には UPnP 対応機器などを利用していないと簡易ファイル転送が利用できないなど、一部機能が利用できないなどの問題がありますね。
IPv6 で一番嬉しいのは気軽に End to End で利用できることな訳で、NAT が必要というだけで面倒でたまらなく感じますよ。
# NAT や Proxy を使わないといけないという段階で IPv4 アドレスが不足していると認識する方が素直だと思います。
Re:コスト？ (スコア:0)
それすらもちっとも現状認識してないわけだが。
なぜ知らないのに知ったかぶりするのかねぇ……
Re:コスト？ (スコア:0)
>
>また、インスタントメッセージングなどの分野でも、みんな NAT などの場合には UPnP 対応機器などを利用していないと簡易ファイル転送が利用できないなど、一部機能が利用できないなどの問題がありますね。
>
>IPv6 で一番嬉しいのは気軽に End to End で利用できることな訳で、NAT が必要というだけで面倒でたまらなく感じますよ。
そこまでしてサーバ/クライアント共にコストを払って IPv6に
Re:コスト？ (スコア:1)
IPv4 + cookie の場合に、盗用された cookie と本当の cookie であることが IPv4 アドレスから判別することが困難ですから、単純に reject するのが難しくなりますね。同一 proxy 内でやられたらサーバ側としては判断不能でしょう。
これを指して「サーバもクライアントも余程楽」と言っているのですが。IPv4/IPv6 両対応の Web アプリなどでは、IPv4 部分で認証周りの処理でコストがかかります。
また、インスタントメッセージングの分野などでは、IPv4 - IPv6 gateway の役割をサーバがこなせば問題ありませんね。IRC で IPv4 と IPv6 が断絶していないように。移行中はそれでなんら問題はないと思いますけどね。
Re:コスト？ (スコア:0)
> NAT や proxy を通ることで End to End の通信が出来なくなるので、一般ユーザから
> 見た場合に最も広範に利用される Web アプリケーションなどの領域では、「通信相手が
> 本当に最初に通信してきたユーザなのか」を識別する方法が異様に狭くなる訳ですが。
まさかIPアドレスでユーザの識別をやっているアプリとか書いているんですか？そういう事はやっちゃダメ、なんてのは、前世紀の常識だと思っていましたが。