パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

IPv6がまだ普及しない理由は「IPv4アドレスが買える」から?」記事へのコメント

  • by Anonymous Coward

    SEとしてどうかと思うのですが、複雑すぎて手をつける気になりません。
    まして自社に何の得もないのでは。

    アドレス拡張だけにしてくれりゃよかったものを、ここぞとばかりにてんこ盛りしなくても。

    • by Anonymous Coward

      いや、複雑というより、IPv4と互換性がないのが問題かな。

      単に桁を増やすだけの拡張だったら(既存のIPv4は0.0.0.0.0として、1.0.0.0.0以降を新設とか)、難なく移行できたのでは?と思う。
      NW機器の実装も負荷も大変なことにはなるし、後世に汚点と判断されることは間違いないが、プラットフォームでは後方互換が何より重要であることはCPUやOSの進化の歴史が証明してる。

      • 「桁を増やしただけのipv4」はipv4と互換性がないのですが。 「従来のipv4プロトコルスタックが取り扱える(拡張された機能が使えないにしても、壊さずにルーティングは出来る)」 が成り立つプロトコルのみが「互換性のあるプロトコル」でしょう。たとえば 電子メールのMIME拡張は、MIMEを知らないMTUでも「内容を壊さず宛先に届ける」ことはできます。

        ipv4そっくりそのままだけでアドレスが長いプロトコルは、結局すべての機械のプロトコルスタックを入れ替えない限り使えないわけですから。

        • 技術的には互換性を保った拡張は可能ですよ。IPv4はその程度の柔軟性は持ち合わせています。

          IPv4ヘッダにはオプションという拡張可能なフィールドがあるので、送受信アドレスの拡張したケタはこのフィールドに記録すれば良いでしょう。このフィールドに描かれた値は非対応の装置は黙った無視される仕様です。こうすれば、従来のIPv4アドレスはIPv4的にはホストアドレスですが、拡張したアドレス体系においてはネットワークアドレスとして機能します。つまり、IPv4アドレス単位で木構造になるというトポロジー上の制約は加わりますが、互換性を保ったままのアドレス拡張は可能です。

          • by Anonymous Coward

            一見互換性を保っていようが、End-to-Endで通信ができなきゃ意味が無い。
            組み込みなどの改修しようもない機器が相当数ある以上、「互換性を保った拡張」は無理。

            • End-to-Endで通信できますよ。互換性を保っているので従来の組み込み装置とも両立できますよ。

              IPv4のホストにあたる拡張アドレスルータ以下は新規の実装が必要になりますが、そこから上の階層は従来のIPv4網そのままでいけます。BGPテーブルも拡大しません。拡張アドレスルータが隠蔽してくれますので。

              このような拡張はIPを理解している人なら自然に思いつく程度の話と思われるので、RFC とまではいかなくても、インターネットドラフト程度にはなっているかもしれませんね。

              • by taka2 (14791) on 2012年07月23日 13時31分 (#2198378) ホームページ 日記

                それだと、拡張されたアドレスに対して、拡張されていないアドレスのホストに届いてしまいますね。例えば、大元のコメ [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に出すような間抜けな人はいないでしょうね。

                親コメント
              • by Super KUMASAN (34209) on 2012年07月23日 23時28分 (#2198687)

                下位ビットが拡張されるので、a.b.c.d.XX と表記するのが自然でしょう。

                > IPv4と互換性を保ってるという意味がどこにもない。

                ネットワークの基幹部に手を加える必要がないというのが最大のメリットです。いちいち、トンネルを掘る必要が無いのです。あとはサーバー側やクライアント側のエッジネットワーク単位で拡張アドレス対応していけば良いので(局所的に対応していけば良いので)、漸進的な移行が可能になります。

                ネットワークの基幹部がごっそりIPv6に対応しないことには移行が始められない(=漸進的な移行が難しい)、というのがIPv6の問題点だと思いますがいかがでしょうか?

                親コメント
              • by taka2 (14791) on 2012年07月24日 11時16分 (#2198921) ホームページ 日記

                > 下位ビットが拡張されるので、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と互換性を持っている意味がありません。

                親コメント

Stableって古いって意味だっけ? -- Debian初級

処理中...