アカウント名:
パスワード:
楽ちんなIPv4完全上位互換でかつアドレス空間が32bitを越えるプロトコルが、あり得るものならば、IPngを選定する時点で提案されていて、いまのIPv6じゃなくてそっちが採択されてたのでは。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
実際のところ・・・ (スコア:1, 興味深い)
実際にIPv4のアドレスが枯渇して実際に困る状態にならなければ変わらないでしょうし、実際に困る状態になってもエンドユーザーは自身が困らなければ変わらないでしょう。
ですので、そのような流れを作るにはIPv4を使う場合にはIPv6を利用する場合に比べてエクストラコストを負担する必要があるなどの事情がある、IPv4を持っているユーザは既得権益の維持のために高額の負担をする必要があるように制度を改める必要があるのではないかと考えています。class A利用のためには年間100億くらいかかるとか。
実際にはそれは無理っぽいので、IPv4は永遠に続き、IPv4上に3.5層をかぶせる規格が出てくるんじゃないかと思ってます。
Re:実際のところ・・・ (スコア:3, すばらしい洞察)
いまとなってはIPv6は普及策自体が間違っていたんでしょうね。
・IPv6の基本設計としてIPv4とまったく異なるものとしたこと。
(単にIP層とトランスポート層のあいだにIP層をもう一層挟むようにし、
既存のclass Aホルダからどんどんアドレスを回収すればよかった。)
・エンドユーザに対するメリットとしてGlobal ID使い放題以外のメリットを
ちゃんと説明できていない。
(Global IDなんて意識して使っている人は少なすぎてエンドユーザに
移行コストを負担してもらえない。→誰もコストを負担してくれない。)
まあすべては後の祭りです。
自分は真に枯渇するときは来ないと見ています。
誰もネットワークを止めたくないわけで、(一部ネットワーク切り離されるとか、新規に分配されなくなるなどの事態はもちろんあると思いますが、)枯渇してもIPv4は動き続けることになるでしょうし、ほとんどのユーザはIPv4のままで生きていくことになるのではないでしょうか。
Re:実際のところ・・・ (スコア:1)
別に、IPv6の利用・普及に現実的に問題があるなら(もっと利用しやすいものを作るなら)
今からでも遅くないんでは?
一切これすなわち空(くう)かもしんなくてイエスキリストもきっと正しい。
Re:実際のところ・・・ (スコア:0)
今のうちにIPv6なんて捨ててしまって、IPv4互換の高い新しいプロトコルの導入をした方がよさそう。
Re:実際のところ・・・ (スコア:1)
IPv10 (スコア:0)
次のバージョンは 10 なので、IPv4+IPv6=IPv10 とか。
けど、両方に互換って、どうやるんだ?
Re:IPv10 (スコア:0)
IPv6ヘッダは継続したところで意味が無い。
妥協点があるとすれば、
拡張アドレス情報として128bitのIPv6アドレスを使うことぐらいだろうか。
もっとも128bitでは、IPv4ヘッダに収まりが悪いので、拡張アドレス部は32bitぐらいでいいと思うけど。
拡張32bit+現行32bitで64bitあれば、IPv4の当面の延命とすれば十分なのでは?
拡張アドレスの埋め込みは、Optionsフィールドを何とか使うか、サロゲートペア的な事をするしか無い。
もはやIPv4は普及しすぎていてそれ自体をIPv6に置き換えることなどできない。
Re:実際のところ・・・ (スコア:0)
1)IPv4 Optionsフィールドに拡張アドレス空間ヘッダを定義。(32bit)
2)DNSルートサーバに拡張アドレス空間ヘッダを使用してアクセスするべきアドレスをテーブルで保持。
3)拡張アドレス空間ヘッダが無い場合には0.0.0.0と仮定。
4)Private IPなどは変更なし。
とかすればよいのじゃないかなぁ。
a)クライアントからは拡張アドレスを扱えても扱えなくてもいちおう通信可能。
b)拡張アドレスでアクセスするべきかどうかクライアントから判別可能。
c)クライアントから拡張アドレスでアクセス可能。
d)前半32bitはIPv4ヘ
Re:実際のところ・・・ (スコア:2, 興味深い)
ad-hoc な解決だったら、port 番号の方から8bitぐらい持ってくるなんていう
手もあったと思う。
Re:実際のところ・・・ (スコア:1)
楽ちんなIPv4完全上位互換でかつアドレス空間が32bitを越えるプロトコルが、あり得るものならば、IPngを選定する時点で提案されていて、いまのIPv6じゃなくてそっちが採択されてたのでは。
Re:実際のところ・・・ (スコア:0)
IPv4の既存のインフラを使える様な物にしなければコストが掛かってしまうので意味が無い。
IPv6と違うのは、拡張された部分がすぐに使えるかどうかは別にして、
拡張アドレスが既存のインフラ網を素で(=IPv4のまま)通過できるという部分で、
機器の入れ替えコストを省くことができる事にある。
拡張アドレスにアクセスするには、どこかで拡張アドレスと、
旧来のアドレスをバインドしなければならないけど、
それはDNSとか、どこかに設置したアドレス変換器とか、
またはネットワークの上流の方で頑張ればいいんじゃないの?
IPng決定プロセスがどうだったかは知らないけど、
その決定が絶対に素晴らしいという事でも無いんじゃない。
Re:実際のところ・・・ (スコア:0)
>(単にIP層とトランスポート層のあいだにIP層をもう一層挟むようにし、
>既存のclass Aホルダからどんどんアドレスを回収すればよかった。)
ClassAを回収して、それをサブネット化して分配するっていう前提なのだと
思いますが、ルーティングテーブルサイズの問題があるので、本当にIPv4の全アドレス
を(細切れにして)使い切るのは難しいような気がしています。
もしかしたら、テーブルサイズだけが問題なら、ルーターやネットワーク自体の
速度向上で解消できるかも知れませんが、
その新しい中間層プロトコルに対応したルーターやOSに置き換えるのは、
IPv6対応のルーターやOSに置き換えるのと比べて、コストを含めてメリットが少なく
デメリットが多すぎるかと。
Re:実際のところ・・・ (スコア:0)
先行するIPv6の普及率は、これから考える新しいIPv4拡張プロトコルに対しては高いのは当然だが、
現状IPv6は普及できていないのだし、それに対してデメリットが大きすぎるかどうかは分からない。
Re:実際のところ・・・ (スコア:0)
機器が出てくるかと(古い機器は特に)。
IPv6に変わるだけなら、古い機器の使用が終わるまではルーターのトンネリングで対応しつつ、
新しい機器は順次IPv6化していくこともできるでしょう。
新しいプロトコルを導入しようとしても、
・新しい中間層プロトコルを開発する
・それを標準とするコンセンサスを得る
・そのプロトコルに対応した、OSやネットワーク機器を開発する
・ユーザを再度啓蒙する(v6もこれができてないの問題)
などは、
Re:実際のところ・・・ (スコア:0)
それがIPv4との互換を強く意識した物として設計されるなら、
既存のIPv4機器と通信できなくなるという事がまずあり得ないと思います。
IPv4互換を100%として、その上にアドレス拡張を施せば良いのです。
これならIPv4としてを使う限りは、IPv4そのまんまなのですから互換性の問題は発生しません。
IPv4に対する既存の技術は全て今まで通り使えるでしょう。(IPv6を含めて)
アドレス拡張部分については、オリジナルのIPv4に対してIPv6同様に非互換な問題を抱えますが、
既存のIPv4網に、拡張IPv4を解釈する仕組みを追加してアドレス変換を行いながらルーティングするようにすれば、
良いのです。
IPv4はアドレス長以外にも、色々な問題を抱えていると思いますが、
アドレス長以外の問題に対する解決も、IPv6以外のアプローチがあっても良いのではないですか。
Re:実際のところ・・・ (スコア:1)
良いのです。
ソレって「拡張IPv4」とやらがたまたまIPv6だったら結局IPv6 over IPv4トンネリングって言いませんか?
Re:実際のところ・・・ (スコア:0)
> 既存のIPv4網に、拡張IPv4を解釈する仕組みを追加してアドレス変換を行いながらルーティングするようにすれば、
>良いのです。
IPv4と、拡張IPv4なりを共存させる(解釈して適切に送信する)ためには、両者にアドレッシング/ルーティング の要素が含まれる以上、アプリや、OS内のプロトコルドライバー(IPv4,TCP,UDP,etc.)のみならず、
ネットワーク機器(ルーター等)の全てに変更が必要です。
それって実現が非常に難しいんじゃないですかね。特に古いOSや、販売済みのルーター/スイッチなどは。
Re:実際のところ・・・ (スコア:0)
そう言いますよ。
IPv6推進の方々はデュアルスタックまでは言うけど、
トンネリングまでは言わない方が多くて、
今そこにあるIPv4機器を捨てさせようする事が多いように見受けられます。
そんなんだったらIPv6なんていらなくて、
トンネリング前提の他のアドレス拡張プロトコル作った方が良いというのが私の主張です。
Re:実際のところ・・・ (スコア:0)
ので、アドレスの長さなどにはよらないはずです。
どちらかというとアドレス空間に余裕があればルーティングテーブルを小さくするような
アドレスの配布がやりやすくなるはずなのではないかなぁ。
Re:実際のところ・・・ (スコア:0)
インターネットに接続される企業/組織が増加する = ルーターが増える
→ ルーティングテーブルサイズが膨張する
と言いたいのでは?
つまり、IP Addressの数が足りないのが問題なんじゃじゃなくて、
ルーターの数が問題で、遅かれ早かれIPv4では(仮にアドレスの数が足りても)
対応できなくなると言ってるんだと思う。
(IP Addressの数(長さ) は問題であるとは言ってないように見えます)
Re:実際のところ・・・ (スコア:0)