アカウント名:
パスワード:
SEとしてどうかと思うのですが、複雑すぎて手をつける気になりません。まして自社に何の得もないのでは。
アドレス拡張だけにしてくれりゃよかったものを、ここぞとばかりにてんこ盛りしなくても。
いや、複雑というより、IPv4と互換性がないのが問題かな。
単に桁を増やすだけの拡張だったら（既存のIPv4は0.0.0.0.0として、1.0.0.0.0以降を新設とか）、難なく移行できたのでは？と思う。NW機器の実装も負荷も大変なことにはなるし、後世に汚点と判断されることは間違いないが、プラットフォームでは後方互換が何より重要であることはCPUやOSの進化の歴史が証明してる。
ipv4そっくりそのままだけでアドレスが長いプロトコルは、結局すべての機械のプロトコルスタックを入れ替えない限り使えないわけですから。
技術的には互換性を保った拡張は可能ですよ。IPv4はその程度の柔軟性は持ち合わせています。
IPv4ヘッダにはオプションという拡張可能なフィールドがあるので、送受信アドレスの拡張したケタはこのフィールドに記録すれば良いでしょう。このフィールドに描かれた値は非対応の装置は黙った無視される仕様です。こうすれば、従来のIPv4アドレスはIPv4的にはホストアドレスですが、拡張したアドレス体系においてはネットワークアドレスとして機能します。つまり、IPv4アドレス単位で木構造になるというトポロジー上の制約は加わりますが、互換性を保ったままのアドレス拡張は可能です。
一見互換性を保っていようが、End-to-Endで通信ができなきゃ意味が無い。組み込みなどの改修しようもない機器が相当数ある以上、「互換性を保った拡張」は無理。
End-to-Endで通信できますよ。互換性を保っているので従来の組み込み装置とも両立できますよ。
IPv４のホストにあたる拡張アドレスルータ以下は新規の実装が必要になりますが、そこから上の階層は従来のIPv4網そのままでいけます。BGPテーブルも拡大しません。拡張アドレスルータが隠蔽してくれますので。
このような拡張はIPを理解している人なら自然に思いつく程度の話と思われるので、RFC とまではいかなくても、インターネットドラフト程度にはなっているかもしれませんね。
それだと、拡張されたアドレスに対して、拡張されていないアドレスのホストに届いてしまいますね。例えば、大元のコメ [srad.jp]「既存のIPv4は0.0.0.0.0として、1.0.0.0.0以降を新設」だと、例えば、拡張された「XX.a.b.c.d」というアドレスに対し送るべきデータが、拡張IPv4非対応のルーターなどを通ると、IPv4のa.b.c.d=拡張IPv4の0.a.b.c.dというアドレスなホストに届けられてしまうわけです。つまり、既存のIPv4で割り当て済のアドレスは、拡張アドレスのベースとして使えないということです。今はまだ使っていない少数のIPv4アドレスが拡張のベースとして使われることになり、そして、既存のIPv4網からは、その少数の拡張アドレスなホストが、拡張IPv4網へのゲートウェイになる、と。
そして、End 側でも、アプリケーション層が拡張IPv4に対応していない場合は、拡張IPv4ホストと通信することはできない。それって、やってることはIPv6における 6over4と同じ。IPv4と互換性を保ってるという意味がどこにもない。
このような拡張の問題点はIPを理解している人なら自然に思いつく程度の話と思われるので、そんなのを本気でRFCに出すような間抜けな人はいないでしょうね。
下位ビットが拡張されるので、a.b.c.d.XX と表記するのが自然でしょう。
> IPv4と互換性を保ってるという意味がどこにもない。
ネットワークの基幹部に手を加える必要がないというのが最大のメリットです。いちいち、トンネルを掘る必要が無いのです。あとはサーバー側やクライアント側のエッジネットワーク単位で拡張アドレス対応していけば良いので(局所的に対応していけば良いので)、漸進的な移行が可能になります。
ネットワークの基幹部がごっそりIPv6に対応しないことには移行が始められない(=漸進的な移行が難しい)、というのがIPv6の問題点だと思いますがいかがでしょうか？
> 下位ビットが拡張されるので、a.b.c.d.XX と表記するのが自然でしょう。
まあそうですね。それは元コメのACの案が変。でもそれは表記だけの問題で本論ではないです。
IPv4のa.b.c.d を IPv4改のa.b.c.d.w.x.y.z に拡張したとして、a.b.c.d が既存のIPv4割り当て済なアドレスであった場合、a.b.c.d.w.x.y.z 拡張アドレスとしては使用できません。IPv4改に使えるのは、IPv4で使われていない少数のアドレスだけです。
で、IPv4網に送られたIPv4改なパケットは、既存IPv4レベルのアドレス単位でルーティングされて拡張対応ルーターが受取、そこから拡張アドレスネットワークに中継するわけです。
> いちいち、トンネルを掘る必要が無いのです。> あとはサーバー側やクライアント側のエッジネットワーク単位で拡張アドレス対応していけば良い
サーバー側・クライアント側の末端で拡張アドレスに対応していけばよいのそうでしょうけど、既存の拡張アドレスに非対応なホストは、拡張アドレスなホストと通信することができません。それって「既存IPv4網に、拡張IPv4網のトンネルを張っている」という状況ですね。私が前のコメで書いた通りの「IPv6における 6over4と同じ」ものであり、IP4と互換性を持っている意味がありません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
複雑すぎ (スコア:0)
SEとしてどうかと思うのですが、複雑すぎて手をつける気になりません。
まして自社に何の得もないのでは。
アドレス拡張だけにしてくれりゃよかったものを、ここぞとばかりにてんこ盛りしなくても。
同感。 (スコア:1)
いや、複雑というより、IPv4と互換性がないのが問題かな。
単に桁を増やすだけの拡張だったら（既存のIPv4は0.0.0.0.0として、1.0.0.0.0以降を新設とか）、難なく移行できたのでは？と思う。
NW機器の実装も負荷も大変なことにはなるし、後世に汚点と判断されることは間違いないが、プラットフォームでは後方互換が何より重要であることはCPUやOSの進化の歴史が証明してる。
Re: (スコア:2)
ipv4そっくりそのままだけでアドレスが長いプロトコルは、結局すべての機械のプロトコルスタックを入れ替えない限り使えないわけですから。
Re: (スコア:1)
技術的には互換性を保った拡張は可能ですよ。IPv4はその程度の柔軟性は持ち合わせています。
IPv4ヘッダにはオプションという拡張可能なフィールドがあるので、送受信アドレスの拡張したケタはこのフィールドに記録すれば良いでしょう。このフィールドに描かれた値は非対応の装置は黙った無視される仕様です。こうすれば、従来のIPv4アドレスはIPv4的にはホストアドレスですが、拡張したアドレス体系においてはネットワークアドレスとして機能します。つまり、IPv4アドレス単位で木構造になるというトポロジー上の制約は加わりますが、互換性を保ったままのアドレス拡張は可能です。
Re:同感。 (スコア:0)
一見互換性を保っていようが、End-to-Endで通信ができなきゃ意味が無い。
組み込みなどの改修しようもない機器が相当数ある以上、「互換性を保った拡張」は無理。
Re:同感。 (スコア:1)
End-to-Endで通信できますよ。互換性を保っているので従来の組み込み装置とも両立できますよ。
IPv４のホストにあたる拡張アドレスルータ以下は新規の実装が必要になりますが、そこから上の階層は従来のIPv4網そのままでいけます。BGPテーブルも拡大しません。拡張アドレスルータが隠蔽してくれますので。
このような拡張はIPを理解している人なら自然に思いつく程度の話と思われるので、RFC とまではいかなくても、インターネットドラフト程度にはなっているかもしれませんね。
Re:同感。 (スコア:1)
それだと、拡張されたアドレスに対して、拡張されていないアドレスのホストに届いてしまいますね。例えば、大元のコメ [srad.jp]「既存のIPv4は0.0.0.0.0として、1.0.0.0.0以降を新設」だと、例えば、拡張された「XX.a.b.c.d」というアドレスに対し送るべきデータが、拡張IPv4非対応のルーターなどを通ると、IPv4のa.b.c.d=拡張IPv4の0.a.b.c.dというアドレスなホストに届けられてしまうわけです。
つまり、既存のIPv4で割り当て済のアドレスは、拡張アドレスのベースとして使えないということです。今はまだ使っていない少数のIPv4アドレスが拡張のベースとして使われることになり、そして、既存のIPv4網からは、その少数の拡張アドレスなホストが、拡張IPv4網へのゲートウェイになる、と。
そして、End 側でも、アプリケーション層が拡張IPv4に対応していない場合は、拡張IPv4ホストと通信することはできない。それって、やってることはIPv6における 6over4と同じ。IPv4と互換性を保ってるという意味がどこにもない。
このような拡張の問題点はIPを理解している人なら自然に思いつく程度の話と思われるので、そんなのを本気でRFCに出すような間抜けな人はいないでしょうね。
Re:同感。 (スコア:1)
下位ビットが拡張されるので、a.b.c.d.XX と表記するのが自然でしょう。
> IPv4と互換性を保ってるという意味がどこにもない。
ネットワークの基幹部に手を加える必要がないというのが最大のメリットです。いちいち、トンネルを掘る必要が無いのです。あとはサーバー側やクライアント側のエッジネットワーク単位で拡張アドレス対応していけば良いので(局所的に対応していけば良いので)、漸進的な移行が可能になります。
ネットワークの基幹部がごっそりIPv6に対応しないことには移行が始められない(=漸進的な移行が難しい)、というのがIPv6の問題点だと思いますがいかがでしょうか？
Re:同感。 (スコア:1)
> 下位ビットが拡張されるので、a.b.c.d.XX と表記するのが自然でしょう。
まあそうですね。それは元コメのACの案が変。でもそれは表記だけの問題で本論ではないです。
IPv4のa.b.c.d を IPv4改のa.b.c.d.w.x.y.z に拡張したとして、a.b.c.d が既存のIPv4割り当て済なアドレスであった場合、a.b.c.d.w.x.y.z 拡張アドレスとしては使用できません。
IPv4改に使えるのは、IPv4で使われていない少数のアドレスだけです。
で、IPv4網に送られたIPv4改なパケットは、既存IPv4レベルのアドレス単位でルーティングされて拡張対応ルーターが受取、そこから拡張アドレスネットワークに中継するわけです。
> いちいち、トンネルを掘る必要が無いのです。
> あとはサーバー側やクライアント側のエッジネットワーク単位で拡張アドレス対応していけば良い
サーバー側・クライアント側の末端で拡張アドレスに対応していけばよいのそうでしょうけど、
既存の拡張アドレスに非対応なホストは、拡張アドレスなホストと通信することができません。
それって「既存IPv4網に、拡張IPv4網のトンネルを張っている」という状況ですね。
私が前のコメで書いた通りの「IPv6における 6over4と同じ」ものであり、IP4と互換性を持っている意味がありません。