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

IPv4アドレスの在庫、とうとう残り12ブロックに」記事へのコメント

  • IPV4無くなったからIPV6使えとプロバイダにいわれたら、ネットワーク接続のプロパティを変更すればいいだけの話でしょ?何か問題があるの?
    • Re: (スコア:5, 参考になる)

      by Anonymous Coward
      IPv6用のDHCPであるDHCPv6は、機能不足なので、使い物になるかどうか、疑問である。それに追加して、いくつかの問題がある。

      1)家庭用ルータの問題
       家庭用ルータは、買い替えが必要になる可能性が大きい。
       家庭用ルータは、IPv6のブリッジ機能があればいいほうで、まともにIPv6に対応しているものは、ほんの一部である。
       IPv4アドレスの相手先との接続性を確保する方式が複数あり、プロバイダごとに対応が異なる。どの方式か確定しないと、家庭用ルータが選択できないし、現在採用が検討されている方式に対応した家庭用ルータは、事実上存在しない。
       最悪、パソコンはア
      • by Anonymous Coward
        なるほど、IPV6へ移行しようという掛け声だけは大きいけど、方式すら決まっていなくて誰もどうしようもない情況が延々と続いているということですか。
        何で方式一つ決められないのでしょう?何年も前から枯渇するっていわれていてもなおかつ大多数が全く対応しない/出来ないというのはなぜなのでしょう?
        無線LANもどんどん変わっているし、携帯電話もどんどん変わっていけているのに、インターネットって旧態依然としてどうしようないんですね。
        • Re: (スコア:2, 参考になる)

          > なるほど、IPV6へ移行しようという掛け声だけは大きいけど、方式すら決まっていなくて誰もどうしようもない情況が延々と続いているということですか。

          いいえ、方式はすでにできあがっています。
          問題は理解できない人・理解しようとしない人には難しいだけです。

          > 何で方式一つ決められないのでしょう?何年も前から枯渇するっていわれていてもなおかつ大多数が全く対応しない/出来ないというのはなぜなのでしょう?

          ユーザの多くが相応のコストを払わないからです。
          10万程度の(安価な)ブランチルータなら普通に IPv6 も実装されていますが、多くの人は高くて2万程度の

          • by Anonymous Coward

            > 問題は理解できない人・理解しようとしない人には難しいだけです。
            今ネットワーク使ってる全員が問題を理解できるほどネットワークに(詳しい|詳しくできる)とでも思ってるんなら、それこそ問題を理解していない・したくないんじゃないの。直後のコメントを見る限り、理解しなくていいから金払えということらしいけど。
            > 無線LANって、大して変わってないですよね、ここ10年で 11a,b,g,n くらいしか変わってません。
            > 携帯電話は毎年規格がリリースされていますが、後方互換を相当に意識した作りをしています。
            > 現在でも R99 どころか GP

            • >> 問題は理解できない人・理解しようとしない人には難しいだけです。
              >今ネットワーク使ってる全員が問題を理解できるほどネットワークに(詳しい|詳しくできる)とでも思ってるんなら、それこそ問題を理解していない・したくないんじゃないの。直後のコメントを見る限り、理解しなくていいから金払えということらしいけど。

              ええ、楽をしたいなら相応のコストを支払えということです。

              >> 無線LANって、大して変わってないですよね、ここ10年で 11a,b,g,n くらいしか変わってません。
              >> 携帯電話は毎年規格がリリースされていますが、後方互換を相当に意識した

              • by Anonymous Coward
                > IPv4 と後方互換の取れるプロトコルって作れますかね?

                作れると思うよ。
                しかし、IPアドレスの不足に対して、IPv4を拡張するのではなくNATでIPアドレスを節約する道が選ばれたんだよ。

                ちなみに、かつてIPv6は日本ローカルと揶揄された時代、はなからIPv4からのシームレスな移行は考慮されてなくて、そんな面倒な上に過去の遺産に足を引っ張られるのは美しくないから真っ新なところから天地創造やり直すんだ、っていう風に見えてたよ、少なくとも俺の目には。
              • Re: (スコア:2, 興味深い)

                >> IPv4 と後方互換の取れるプロトコルって作れますかね?
                >作れると思うよ。

                作れるとしたら、それは画期的なことです。 博論くらい余裕でかけます。是非、貴方が思うだけでなく
                行動に移してください。

                作るとしたら具体的にどのように作りますか?
                それは今から作り出して IPv4 が枯渇するときまでに世界中へのデプロイが完了しますか?
                もちろん、IPv4 との後方互換があるのですから、デプロイは一瞬のはずですが。

                >しかし、IPアドレスの不足に対して、IPv4を拡張するのではなくNATでIPアドレスを節約する道が選ばれたんだよ。

                1993 RFC1519 CIDR
              • by Anonymous Coward
                > 作れるとしたら、それは画期的なことです。 博論くらい余裕でかけます。是非、貴方が思うだけでなく行動に移してください。

                学部生の卒論でも無理でしょう。
                すでに誰かが考えて提案し、そして、あまりにダサい方法だと一蹴されて、早々に論外に追いやられ、蒸し返すことも許されてないでしょうから。

                > 作るとしたら具体的にどのように作りますか?

                たとえばIPv4+という名前にするとして、IPアドレスをxxx.xxx.xxx.xxx.qqq.qqq.qqq.qqqとします。
                IPヘッダのバージョンのフィールドは4のまま、プロトコルのフィールドにIPv4+を示す値を入れ、送信元と送信先のIPアドレスのqqq.qq
              • by Anonymous Coward

                ダサいとかいう以前に動かないでしょ。

                たとえば、IPv4 ルーターを通るところでフラグメントが生成されたらどうなるのですか?

                6to4 gateway を使えば済む話を、動かない実装で置き換えようとしているようにしか見えませんが。

              • by Anonymous Coward
                IPv4でフラグメントされても全く問題ありませんよ。
                IPv4の仕組みに従ってフラグメントを再構築してから転送すればいいのですから。
              • by Anonymous Coward

                どこでフラグメントを再構築して転送するんですか。IPv4 の仕組みでは、フラグメントを再構築するのはあて先のホストなんですが。

              • by Anonymous Coward
                IPv4+対応のルーターで、フラグメントを再構築する。
                この場合、IPv4から見た宛て先のホストは、IPv4+対応のルーターになるのですから。
              • by Anonymous Coward

                IPv4 でフラグメントを再構築するのがあて先のホストということになっている理由を、理解してないようですね。フラグメント化されたパケットが同じルーターを通ってくれる保証なんてありません。どうやってルーターでの再構築を保証するんでしょうか。ひょっとして、xxx.xxx.xxx.xxx.*.*.*.* へのパケットは必ず一つのIPv4+ルーターで全部処理し、フラグメント化されたパケットを見つけたときは残りが届くまで保持するなんて実装とか?

                だいたい、フラグメントが発生した場合に起こることに対する理解が足りないですね。フラグメントが発生するときは、

              • by Anonymous Coward on 2010年10月21日 15時11分 (#1844977)
                > ひょっとして、xxx.xxx.xxx.xxx.*.*.*.* へのパケットは必ず一つのIPv4+ルーターで全部処理し、
                > フラグメント化されたパケットを見つけたときは残りが届くまで保持するなんて実装とか?

                その通り。
                最初はNAT越えの手段として使われますので、必ず1つのIPv4+ルーターを通ることは問題ありません。
                とても高コストな処理ですが、末端のNAT箱で行うので、大した問題にはならないでしょう。

                ISP側のNATで処理する段になると問題になりますが、そもそも標準的なトラヒックに対してフラグメントを生じるというのはイレギュラーだと思いますよ。

                > 元のパケットを再構築するための情報は、送信元、送信先と、たった16ビットしかない識別子だけです。
                > 送信元と送信先はすべてのパケットで同じになっていますから、識別子も一致してしまうパケットが頻繁に出現するのは確実ですね。

                いいえ、yyy.yyy.yyy.yyy.*.*.*.* から xxx.xxx.xxx.xxx.*.*.*.* への通信は全て、yyy.yyy.yyy.yyyからxxx.xxx.xxx.xxxへの通信として行われるわけで、IPv4パケットとしてのフラグメント再構築のための識別子を振るのはyyy.yyy.yyy.yyyのIPv4+ルータもしくは経路の途中のIPv4のルーターになりますから問題ありません。なお、IPv4+でのフラグメント識別子は、IPv4パケットのペイロード部分に書けばいいでしょう。

                そのようなトンネリングはコストが高いと言えばそうですが、しかし、互換性のためにコストを払うのは、よくあることだと思いますよ。
                そりゃぁ、いちど真っ新なところから最適な方法で構築すれば低コストで済みますが、しかし現実に長く拡張され続けられて使われるプロトコルというのは、特異点的な低コスト部分を狙ってはいないと思うんですよ。
                親コメント
              • > > ひょっとして、xxx.xxx.xxx.xxx.*.*.*.* へのパケットは必ず一つのIPv4+ルーターで全部処理し、
                > > フラグメント化されたパケットを見つけたときは残りが届くまで保持するなんて実装とか?
                > その通り。

                  *.*.*.* ・・・ 32bit ホスト分のフラグメントパケットを収容できるだけのバッファを持った装置、
                現在の技術でも相当難しいと思います。
                RFC にするときは、 SECURITY の項目に、
                    本実装はフラグメントパケットにより DoS に陥る可能性が高い。
                と書かなければなりませんね。

                > 最初はNAT越えの手段として使われますので、必ず1つのIPv4+ルーターを通ることは問題ありません。
                > とても高コストな処理ですが、末端のNAT箱で行うので、大した問題にはならないでしょう。

                末端の NAT 箱が PE か CE か知りませんが、 大した問題にはならない というのは現実を知らなさすぎ
                なんじゃという気がしますが。

                > ISP側のNATで処理する段になると問題になりますが、
                > そもそも標準的なトラヒックに対してフラグメントを生じるというのはイレギュラーだと思いますよ。

                貴方の言う(いや、別の匿名の臆病者の可能性もありますが) 1990年代後半、標準的なアクセス回線は
                ダイアルアップかフレッツISDN 程度でしょう。
                当時の MRU っていくつでしたっけ・・・(500~800くらいの記憶があるのですが)、一方、ホスト側
                はイーサで 1500 が一般的でしたね。 IPoAAL5 もありましたね。 あれだとデフォルトで 4000 OCTETS
                位になってた記憶がありますが。一体誰がフラグメントしてくれてたんだろう。

                > しかし、互換性のためにコストを払うのは、よくあることだと思いますよ。

                互換性、ありません。IPv4+ 対応装置をばらまいてる段階で互換性もクソもありません。
                片一方が IPv4 ホストで、片一方が IPv4+ ホストの場合、IPv4 ホストはどうやって特定の IPv4+ ホスト
                にセッションを張りにいけばいいのでしょう?

                最初は NAT 越えの手段として使われる?
                勝手に俺ルール追加しないでください。

                > そりゃぁ、いちど真っ新なところから最適な方法で構築すれば低コストで済みますが、
                > しかし現実に長く拡張され続けられて使われるプロトコルというのは、特異点的な低コスト部分を狙って
                > はいないと思うんですよ。

                おっしゃることは最もですが、その解と IPv4+ は不合格だと思いますが。

                親コメント
              • by Anonymous Coward

                これはひどい。コスト以前に動かないということに気づくべきです。ルーターの負担もさることながら、xxx.xxx.xxx.xxx が落ちてしまうと IPv4 のネットワーク経由で通信できなくなるというのもひどいし。

                たとえば、以下のような構成のネットワークがあったとします。

                   +--- ルーターY (IPv4アドレス xxx.xxx.xxx.xxx)
                   |
                 ルーターX
                   |
                   +-- ホストA (IPv4+アドレス xxx.xxx.xxx.xxx.qqq.qqq.qqq.qqq)
                   |
                   +--- ルーターZ --------> IPv4アドレスyyy.yyy.yyy.yyy のホストはこの先

                ルーターX, Y, Z はすべて IPv4+ に対応してます

              • とある匿名の臆病者な人の脳内では、 xxxx.xxx.xxx.xxx ルータの配下にしか、 xxx.xxx.xxx.xxx.qqq.qqq.qqq.qqq なホストは存在してはいけないことになってるんだと思います。

                xxx.xxx.xxx.xxx.yyy.yyy.qqq.qqq/48 と、 xxx.xxx.xxx.xxx.zzz.zzz.qqq.qqq/48 がくっついていない(同一の xxx.xxx.xxx.xxx に収容されていない) なんてあってはならないんだと思います。

                そして言ってることは、TCP/UDP の PORT を使わないで NAPT をやろうとしているだけ。

                # 違いますかね。

                親コメント
              • by Anonymous Coward
                いっそDF=1で桶
              • by Anonymous Coward

                フラグメント禁止は、送信できなかったという通知の ICMP が送信元に届かないと、通信できなくなってしまいます。IPv4ルーターが認識する送信元は 32ビットアドレスなので、そこに通知が飛びます。結局、IPv4 の送信元アドレスのホストがそれを受け取り、フラグメント処理をそこでやるか、あるいは、なんとかしてIPv4+の送信元を見つけ出して通知する必要が発生します。

                いずれにしても、純粋なIPv4 パケットを使い、全パケットをペイロードに入れることによって送信元と送信先アドレスの変な縛りなしにトンネリングすれば、何も損をせずに解決する問題です。それだと IPv6の全パケットを入れてトンネリングするのと何も変わらなくなってしまうわけですが。

              • by Anonymous Coward
                ただのトンネリングよりもシームレスな移行が実現できるという話なのだろう。IPv4ネットワークをトンネリングしてIPv6ネットワークに繋ぐ→IPv4残存組はIPv6ネットワークをトンネリングしてIPv4ネットワークに繋ぐという移行は表裏をひっくり返す作業になるし、そもそもIPv4アドレスの枯渇対策にはなりません。かといってキャリアグレードNATの重さや問題点は、件のIPv4+などというものと同程度でしょう。なぜなら、IPv4+はどうやら本質的にはNATらしいですから。

※ただしPHPを除く -- あるAdmin

処理中...