アカウント名:
パスワード:
> なるほど、IPV6へ移行しようという掛け声だけは大きいけど、方式すら決まっていなくて誰もどうしようもない情況が延々と続いているということですか。
いいえ、方式はすでにできあがっています。問題は理解できない人・理解しようとしない人には難しいだけです。
> 何で方式一つ決められないのでしょう?何年も前から枯渇するっていわれていてもなおかつ大多数が全く対応しない/出来ないというのはなぜなのでしょう?
ユーザの多くが相応のコストを払わないからです。10万程度の(安価な)ブランチルータなら普通に IPv6 も実装されていますが、多くの人は高くて2万程度の
> 問題は理解できない人・理解しようとしない人には難しいだけです。今ネットワーク使ってる全員が問題を理解できるほどネットワークに(詳しい|詳しくできる)とでも思ってるんなら、それこそ問題を理解していない・したくないんじゃないの。直後のコメントを見る限り、理解しなくていいから金払えということらしいけど。> 無線LANって、大して変わってないですよね、ここ10年で 11a,b,g,n くらいしか変わってません。> 携帯電話は毎年規格がリリースされていますが、後方互換を相当に意識した作りをしています。> 現在でも R99 どころか GP
>> 問題は理解できない人・理解しようとしない人には難しいだけです。>今ネットワーク使ってる全員が問題を理解できるほどネットワークに(詳しい|詳しくできる)とでも思ってるんなら、それこそ問題を理解していない・したくないんじゃないの。直後のコメントを見る限り、理解しなくていいから金払えということらしいけど。
ええ、楽をしたいなら相応のコストを支払えということです。
>> 無線LANって、大して変わってないですよね、ここ10年で 11a,b,g,n くらいしか変わってません。>> 携帯電話は毎年規格がリリースされていますが、後方互換を相当に意識した
ダサいとかいう以前に動かないでしょ。
たとえば、IPv4 ルーターを通るところでフラグメントが生成されたらどうなるのですか?
6to4 gateway を使えば済む話を、動かない実装で置き換えようとしているようにしか見えませんが。
どこでフラグメントを再構築して転送するんですか。IPv4 の仕組みでは、フラグメントを再構築するのはあて先のホストなんですが。
IPv4 でフラグメントを再構築するのがあて先のホストということになっている理由を、理解してないようですね。フラグメント化されたパケットが同じルーターを通ってくれる保証なんてありません。どうやってルーターでの再構築を保証するんでしょうか。ひょっとして、xxx.xxx.xxx.xxx.*.*.*.* へのパケットは必ず一つのIPv4+ルーターで全部処理し、フラグメント化されたパケットを見つけたときは残りが届くまで保持するなんて実装とか?
だいたい、フラグメントが発生した場合に起こることに対する理解が足りないですね。フラグメントが発生するときは、yyy.yyy.yyy.yyy.*.*.*.* から xxx.xxx.xxx.xxx.*.*.*.* への通信が片っ端からフラグメントを起こして、再構築するためのルータに飛ぶことになります。ホスト間ではなく、ネットワーク間でIPv4ルーターを通して送られているものでそれが起きるので、膨大な量のパケットでそれが起こります。アドレスの拡張部分はペイロードに入っていますから、フラグメントの2番目以降のパケットでは、拡張部分が失われています。ということは、yyy.yyy.yyy.yyy から xxx.xxx.xxx.xxx への通信にしか見えないパケットが大量にルーターに届けられることになります。元のパケットを再構築するための情報は、送信元、送信先と、たった16ビットしかない識別子だけです。送信元と送信先はすべてのパケットで同じになっていますから、識別子も一致してしまうパケットが頻繁に出現するのは確実ですね。再構築ができると思うのは考えが甘い。
> > ひょっとして、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+ は不合格だと思いますが。
これはひどい。コスト以前に動かないということに気づくべきです。ルーターの負担もさることながら、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 をやろうとしているだけ。
# 違いますかね。
フラグメント禁止は、送信できなかったという通知の ICMP が送信元に届かないと、通信できなくなってしまいます。IPv4ルーターが認識する送信元は 32ビットアドレスなので、そこに通知が飛びます。結局、IPv4 の送信元アドレスのホストがそれを受け取り、フラグメント処理をそこでやるか、あるいは、なんとかしてIPv4+の送信元を見つけ出して通知する必要が発生します。
いずれにしても、純粋なIPv4 パケットを使い、全パケットをペイロードに入れることによって送信元と送信先アドレスの変な縛りなしにトンネリングすれば、何も損をせずに解決する問題です。それだと IPv6の全パケットを入れてトンネリングするのと何も変わらなくなってしまうわけですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
DHCPでIPV6を選べばいいだけじゃないの? (スコア:0)
Re: (スコア:5, 参考になる)
1)家庭用ルータの問題
家庭用ルータは、買い替えが必要になる可能性が大きい。
家庭用ルータは、IPv6のブリッジ機能があればいいほうで、まともにIPv6に対応しているものは、ほんの一部である。
IPv4アドレスの相手先との接続性を確保する方式が複数あり、プロバイダごとに対応が異なる。どの方式か確定しないと、家庭用ルータが選択できないし、現在採用が検討されている方式に対応した家庭用ルータは、事実上存在しない。
最悪、パソコンはア
Re: (スコア:0)
何で方式一つ決められないのでしょう?何年も前から枯渇するっていわれていてもなおかつ大多数が全く対応しない/出来ないというのはなぜなのでしょう?
無線LANもどんどん変わっているし、携帯電話もどんどん変わっていけているのに、インターネットって旧態依然としてどうしようないんですね。
Re: (スコア:2, 参考になる)
> なるほど、IPV6へ移行しようという掛け声だけは大きいけど、方式すら決まっていなくて誰もどうしようもない情況が延々と続いているということですか。
いいえ、方式はすでにできあがっています。
問題は理解できない人・理解しようとしない人には難しいだけです。
> 何で方式一つ決められないのでしょう?何年も前から枯渇するっていわれていてもなおかつ大多数が全く対応しない/出来ないというのはなぜなのでしょう?
ユーザの多くが相応のコストを払わないからです。
10万程度の(安価な)ブランチルータなら普通に IPv6 も実装されていますが、多くの人は高くて2万程度の
Re: (スコア:0)
> 問題は理解できない人・理解しようとしない人には難しいだけです。
今ネットワーク使ってる全員が問題を理解できるほどネットワークに(詳しい|詳しくできる)とでも思ってるんなら、それこそ問題を理解していない・したくないんじゃないの。直後のコメントを見る限り、理解しなくていいから金払えということらしいけど。
> 無線LANって、大して変わってないですよね、ここ10年で 11a,b,g,n くらいしか変わってません。
> 携帯電話は毎年規格がリリースされていますが、後方互換を相当に意識した作りをしています。
> 現在でも R99 どころか GP
Re: (スコア:1)
>> 問題は理解できない人・理解しようとしない人には難しいだけです。
>今ネットワーク使ってる全員が問題を理解できるほどネットワークに(詳しい|詳しくできる)とでも思ってるんなら、それこそ問題を理解していない・したくないんじゃないの。直後のコメントを見る限り、理解しなくていいから金払えということらしいけど。
ええ、楽をしたいなら相応のコストを支払えということです。
>> 無線LANって、大して変わってないですよね、ここ10年で 11a,b,g,n くらいしか変わってません。
>> 携帯電話は毎年規格がリリースされていますが、後方互換を相当に意識した
Re: (スコア:0)
作れると思うよ。
しかし、IPアドレスの不足に対して、IPv4を拡張するのではなくNATでIPアドレスを節約する道が選ばれたんだよ。
ちなみに、かつてIPv6は日本ローカルと揶揄された時代、はなからIPv4からのシームレスな移行は考慮されてなくて、そんな面倒な上に過去の遺産に足を引っ張られるのは美しくないから真っ新なところから天地創造やり直すんだ、っていう風に見えてたよ、少なくとも俺の目には。
Re: (スコア:2, 興味深い)
>作れると思うよ。
作れるとしたら、それは画期的なことです。 博論くらい余裕でかけます。是非、貴方が思うだけでなく
行動に移してください。
作るとしたら具体的にどのように作りますか?
それは今から作り出して IPv4 が枯渇するときまでに世界中へのデプロイが完了しますか?
もちろん、IPv4 との後方互換があるのですから、デプロイは一瞬のはずですが。
>しかし、IPアドレスの不足に対して、IPv4を拡張するのではなくNATでIPアドレスを節約する道が選ばれたんだよ。
1993 RFC1519 CIDR
Re: (スコア:0)
学部生の卒論でも無理でしょう。
すでに誰かが考えて提案し、そして、あまりにダサい方法だと一蹴されて、早々に論外に追いやられ、蒸し返すことも許されてないでしょうから。
> 作るとしたら具体的にどのように作りますか?
たとえばIPv4+という名前にするとして、IPアドレスをxxx.xxx.xxx.xxx.qqq.qqq.qqq.qqqとします。
IPヘッダのバージョンのフィールドは4のまま、プロトコルのフィールドにIPv4+を示す値を入れ、送信元と送信先のIPアドレスのqqq.qq
Re: (スコア:0)
ダサいとかいう以前に動かないでしょ。
たとえば、IPv4 ルーターを通るところでフラグメントが生成されたらどうなるのですか?
6to4 gateway を使えば済む話を、動かない実装で置き換えようとしているようにしか見えませんが。
Re: (スコア:0)
IPv4の仕組みに従ってフラグメントを再構築してから転送すればいいのですから。
Re: (スコア:0)
どこでフラグメントを再構築して転送するんですか。IPv4 の仕組みでは、フラグメントを再構築するのはあて先のホストなんですが。
Re: (スコア:0)
この場合、IPv4から見た宛て先のホストは、IPv4+対応のルーターになるのですから。
Re:DHCPでIPV6を選べばいいだけじゃないの? (スコア:0)
IPv4 でフラグメントを再構築するのがあて先のホストということになっている理由を、理解してないようですね。フラグメント化されたパケットが同じルーターを通ってくれる保証なんてありません。どうやってルーターでの再構築を保証するんでしょうか。ひょっとして、xxx.xxx.xxx.xxx.*.*.*.* へのパケットは必ず一つのIPv4+ルーターで全部処理し、フラグメント化されたパケットを見つけたときは残りが届くまで保持するなんて実装とか?
だいたい、フラグメントが発生した場合に起こることに対する理解が足りないですね。フラグメントが発生するときは、yyy.yyy.yyy.yyy.*.*.*.* から xxx.xxx.xxx.xxx.*.*.*.* への通信が片っ端からフラグメントを起こして、再構築するためのルータに飛ぶことになります。ホスト間ではなく、ネットワーク間でIPv4ルーターを通して送られているものでそれが起きるので、膨大な量のパケットでそれが起こります。アドレスの拡張部分はペイロードに入っていますから、フラグメントの2番目以降のパケットでは、拡張部分が失われています。ということは、yyy.yyy.yyy.yyy から xxx.xxx.xxx.xxx への通信にしか見えないパケットが大量にルーターに届けられることになります。元のパケットを再構築するための情報は、送信元、送信先と、たった16ビットしかない識別子だけです。送信元と送信先はすべてのパケットで同じになっていますから、識別子も一致してしまうパケットが頻繁に出現するのは確実ですね。再構築ができると思うのは考えが甘い。
Re: (スコア:0)
> フラグメント化されたパケットを見つけたときは残りが届くまで保持するなんて実装とか?
その通り。
最初はNAT越えの手段として使われますので、必ず1つのIPv4+ルーターを通ることは問題ありません。
とても高コストな処理ですが、末端のNAT箱で行うので、大した問題にはならないでしょう。
ISP側のNATで処理する段になると問題になりますが、そもそも標準的なトラヒックに対してフラグメントを生じるというのはイレギュラーだと思いますよ。
> 元のパケットを
Re:DHCPでIPV6を選べばいいだけじゃないの? (スコア:1)
> > ひょっとして、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+ は不合格だと思いますが。
Re: (スコア:0)
これはひどい。コスト以前に動かないということに気づくべきです。ルーターの負担もさることながら、xxx.xxx.xxx.xxx が落ちてしまうと IPv4 のネットワーク経由で通信できなくなるというのもひどいし。
たとえば、以下のような構成のネットワークがあったとします。
ルーターX, Y, Z はすべて IPv4+ に対応してます
Re:DHCPでIPV6を選べばいいだけじゃないの? (スコア:1)
とある匿名の臆病者な人の脳内では、 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 をやろうとしているだけ。
# 違いますかね。
Re: (スコア:0)
Re: (スコア:0)
フラグメント禁止は、送信できなかったという通知の ICMP が送信元に届かないと、通信できなくなってしまいます。IPv4ルーターが認識する送信元は 32ビットアドレスなので、そこに通知が飛びます。結局、IPv4 の送信元アドレスのホストがそれを受け取り、フラグメント処理をそこでやるか、あるいは、なんとかしてIPv4+の送信元を見つけ出して通知する必要が発生します。
いずれにしても、純粋なIPv4 パケットを使い、全パケットをペイロードに入れることによって送信元と送信先アドレスの変な縛りなしにトンネリングすれば、何も損をせずに解決する問題です。それだと IPv6の全パケットを入れてトンネリングするのと何も変わらなくなってしまうわけですが。
Re: (スコア:0)