アカウント名:
パスワード:
> なるほど、IPV6へ移行しようという掛け声だけは大きいけど、方式すら決まっていなくて誰もどうしようもない情況が延々と続いているということですか。
いいえ、方式はすでにできあがっています。問題は理解できない人・理解しようとしない人には難しいだけです。
> 何で方式一つ決められないのでしょう?何年も前から枯渇するっていわれていてもなおかつ大多数が全く対応しない/出来ないというのはなぜなのでしょう?
ユーザの多くが相応のコストを払わないからです。10万程度の(安価な)ブランチルータなら普通に IPv6 も実装されていますが、多くの人は高くて2万程度の
> 問題は理解できない人・理解しようとしない人には難しいだけです。今ネットワーク使ってる全員が問題を理解できるほどネットワークに(詳しい|詳しくできる)とでも思ってるんなら、それこそ問題を理解していない・したくないんじゃないの。直後のコメントを見る限り、理解しなくていいから金払えということらしいけど。> 無線LANって、大して変わってないですよね、ここ10年で 11a,b,g,n くらいしか変わってません。> 携帯電話は毎年規格がリリースされていますが、後方互換を相当に意識した作りをしています。> 現在でも R99 どころか GP
>> 問題は理解できない人・理解しようとしない人には難しいだけです。>今ネットワーク使ってる全員が問題を理解できるほどネットワークに(詳しい|詳しくできる)とでも思ってるんなら、それこそ問題を理解していない・したくないんじゃないの。直後のコメントを見る限り、理解しなくていいから金払えということらしいけど。
ええ、楽をしたいなら相応のコストを支払えということです。
>> 無線LANって、大して変わってないですよね、ここ10年で 11a,b,g,n くらいしか変わってません。>> 携帯電話は毎年規格がリリースされていますが、後方互換を相当に意識した
当時その意見を真面目に取り合ってくれそうなのはdjb先生くらいしかいませんでしたね。で、フタを開けてみればdjb先生が予言したとおり。http://www.unixuser.org/~euske/doc/ipv6ex/ [unixuser.org]綺麗な現状報告に見えるだろ? 2003年に書かれたんだぜ、これで…現状と食い違ってるのはGoogleがdjb先生の想像さえも斜め上に行くほどふつーの会社じゃなかったことくらいですね。ふつーの会社ならこんな投資株主が許さないでしょう。
ダサいとかいう以前に動かないでしょ。
たとえば、IPv4 ルーターを通るところでフラグメントが生成されたらどうなるのですか?
6to4 gateway を使えば済む話を、動かない実装で置き換えようとしているようにしか見えませんが。
どこでフラグメントを再構築して転送するんですか。IPv4 の仕組みでは、フラグメントを再構築するのはあて先のホストなんですが。
「全世界の機器が『えいっ』と一気にIPv6に切り替えないといけない」なんて戯言を未だに本気で信じてる奴がいるとは思わなかった。
>この話を10年以上前に教授にしたら、他力本願すぎるし、これは通信技術ではなく社会計画の範疇だし、>君の手の出せない部分の大きな協力に依存している絵空事でしかないと、呆れられちゃいましたよ。
ダサいか否かは主観的な観点が入るので断定できないが、少なくとも、貴方のアイディアは十分通信技術として成立する内容ですよ。特許出願すべきでしたね。私なら真っ先に出願していました。随分視野の狭い教授に教わっていたんですね、残念です。
なお、冗談では言ってません。IPDLで検索してみると、V4アドレス枯渇対策の技術は結構な数の特許出願がされています。
IPv4 でフラグメントを再構築するのがあて先のホストということになっている理由を、理解してないようですね。フラグメント化されたパケットが同じルーターを通ってくれる保証なんてありません。どうやってルーターでの再構築を保証するんでしょうか。ひょっとして、xxx.xxx.xxx.xxx.*.*.*.* へのパケットは必ず一つのIPv4+ルーターで全部処理し、フラグメント化されたパケットを見つけたときは残りが届くまで保持するなんて実装とか?
だいたい、フラグメントが発生した場合に起こることに対する理解が足りないですね。フラグメントが発生するときは、
# だんだん、コメントをもらう部分が減ってるんですが、それらには反論しない/できないという# 理解でいいんですかね。# いや、匿名の臆病者が同一人物であるという保証が無いので別の人が個別に反応しているだけ# かもしれませんが。
> > せめて IPv4 の Option フィールドに入れるべき値だと思いますが。> いいえ、IPv4のヘッダ長の可変に対応していないハードウェアへの親和性を考えると、> Optionフィールドは使わないほうが良いと思います。
いや、Option フィールドに入れるのも十分ダサいけど、ペイロードに入れるのはもっとダサいというだけの話なんですが。IPv4 のヘッダ長の可変に対応してないルータ(というか、L3スイッチというべきかな、時期的には)は、先頭 20OCTETS しかみないだけでしょ? 貴方の言う、IPv4+ 非対応ルータと何も動作は変わらないと思うけど。あと、IPv4 では Option フィールドの実装は MUST じゃなかったっけ。 それに対して、ペイロードに何の断りも無く拡張アドレスを入れるのは問題が無いといえるの?間に L4 を見る装置が無いことをどこで保証するの?
> > IPv4+ 対応の装置はどこから出てくるのでしょう。 実装しないといけませんね。> もちろんです。
それを実装してまでヘンテコな(だって IPv4+ の技術詳細は貴方の妄想の中にしかないもん)プロトコルを実装する意味はあるの?IPng に提案したって相手にされないと思うけど(これは後述の1990年代前半に対する返答ね)。
> > また、エンドユーザが持つアクセスルータ(ブロードバンドルータ)が、IPv4+ に対応することは絶望的> ではないでしょうか。> 2010年の今からは無理でしょうね。> すでに、別のNAT対策が実装されたモデルへの買い替えが済んでしまってますからね。> (もしかして、なんちゃらメッセンジャーをNATの内側から使うために、ブロードバンドルーターを買い替える> ブームがあったのをご存じない?)
ブロードバンドルータを買い換えるほどのブームになったメッセンジャーソフトは知りませんわ。いったいどんなムーブメントなんだろう。
> > IPv4+ よりも圧倒的に IPv6 のデプロイの方が進んでますが・・・。> それは2010年の今の話でしょ? ここでやっているのは、1990年代前半の話ですよ。
よっぽど教授に相手にされなかったのが悲しかったのでしょうね。1990年代前半の時点でも相手にされないと思うけど。
ところで、貴方の言う IPv4+ 対応ルータは、 PEなの? CEなの?エッジ って何を指しているの(PEなの?って確認したんだけど)。
貴方の言う IPv4+ 対応ルータを入れるとして、PE なら http://srad.jp/comments.pl?sid=511060&cid=1843668 [srad.jp]に対する対策をきちんと述べてほしいし、
CE なら NAPT と意味が変わりませんよ。
# しかし、1990年代前半の段階で IPng の存在を知らないか、はたまた知ってる上で俺々# プロトコルを世界標準に!! なんて1人で言ってたとしたら、教授も困っただろうなあ。# そしてそれから10年以上経っても当時の自分の考えは浅かったなあと思わないところも、# 嫌いじゃないですよ。
# 年代的に私と一緒か私より上なんだよなあ・・・。なんというか興味深い。# JANOG とかに来てたりしますか?# できれば 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+ は不合格だと思いますが。
これはひどい。コスト以前に動かないということに気づくべきです。ルーターの負担もさることながら、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)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
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:DHCPでIPV6を選べばいいだけじゃないの? (スコア:0)
学部生の卒論でも無理でしょう。
すでに誰かが考えて提案し、そして、あまりにダサい方法だと一蹴されて、早々に論外に追いやられ、蒸し返すことも許されてないでしょうから。
> 作るとしたら具体的にどのように作りますか?
たとえばIPv4+という名前にするとして、IPアドレスをxxx.xxx.xxx.xxx.qqq.qqq.qqq.qqqとします。
IPヘッダのバージョンのフィールドは4のまま、プロトコルのフィールドにIPv4+を示す値を入れ、送信元と送信先のIPアドレスのqqq.qqq.qqq.qqqの部分は、IPヘッダではなくペイロード部分に格納します。
IPv4対応のルータにとっては、TCPやUDPではないが、しかし普通のIPパケットです。
IPv4+対応のルータやホストは、それを解釈して、そのように処理します。
移行は次のように行います。
まず、アドレス数枯渇対策としてではなく、NATとの親和性の悪いアプリでのNAT越えの手段としてIPv4+を普及させます。
その次に、NATに無関係なアプリもIPv4+対応させます。
主要なアプリが対応を済ませたら、ISPがユーザーにIPv4のグローバルアドレスを1つずつ配布するのをやめ、IPv4のTCPとUDPはNATで提供するようにします。IPv4のみ対応のレガシーなアプリはNATで、IPv4+対応のアプリはNATせずにネイティブに処理されます。
このような方法なら、ネットワークのコア部分はIPv4のままで良く、エッジまわりのみIPv4+対応すれば済みます。
しかし、UPnPなどのNAT対策が既に普及した今となっては、手遅れですね。
なぜ、この方法が採用されないのかというと、まず第一にダサいのと、技術的な解決とは言えないからです。
この話を10年以上前に教授にしたら、他力本願すぎるし、これは通信技術ではなく社会計画の範疇だし、
君の手の出せない部分の大きな協力に依存している絵空事でしかないと、呆れられちゃいましたよ。
Re: (スコア:0)
当時その意見を真面目に取り合ってくれそうなのはdjb先生くらいしかいませんでしたね。で、フタを開けてみればdjb先生が予言したとおり。
http://www.unixuser.org/~euske/doc/ipv6ex/ [unixuser.org]
綺麗な現状報告に見えるだろ? 2003年に書かれたんだぜ、これで…
現状と食い違ってるのはGoogleがdjb先生の想像さえも斜め上に行くほどふつーの会社じゃなかったことくらいですね。ふつーの会社ならこんな投資株主が許さないでしょう。
Re: (スコア:0)
ダサいとかいう以前に動かないでしょ。
たとえば、IPv4 ルーターを通るところでフラグメントが生成されたらどうなるのですか?
6to4 gateway を使えば済む話を、動かない実装で置き換えようとしているようにしか見えませんが。
Re: (スコア:0)
IPv4の仕組みに従ってフラグメントを再構築してから転送すればいいのですから。
Re: (スコア:0)
どこでフラグメントを再構築して転送するんですか。IPv4 の仕組みでは、フラグメントを再構築するのはあて先のホストなんですが。
Re: (スコア:0)
「全世界の機器が『えいっ』と一気にIPv6に切り替えないといけない」なんて戯言を
未だに本気で信じてる奴がいるとは思わなかった。
Re: (スコア:0)
この場合、IPv4から見た宛て先のホストは、IPv4+対応のルーターになるのですから。
Re:DHCPでIPV6を選べばいいだけじゃないの? (スコア:1)
>この話を10年以上前に教授にしたら、他力本願すぎるし、これは通信技術ではなく社会計画の範疇だし、
>君の手の出せない部分の大きな協力に依存している絵空事でしかないと、呆れられちゃいましたよ。
ダサいか否かは主観的な観点が入るので断定できないが、
少なくとも、貴方のアイディアは十分通信技術として成立する内容ですよ。
特許出願すべきでしたね。
私なら真っ先に出願していました。
随分視野の狭い教授に教わっていたんですね、残念です。
なお、冗談では言ってません。
IPDLで検索してみると、V4アドレス枯渇対策の技術は結構な数の特許出願がされています。
Re: (スコア:0)
IPv4 でフラグメントを再構築するのがあて先のホストということになっている理由を、理解してないようですね。フラグメント化されたパケットが同じルーターを通ってくれる保証なんてありません。どうやってルーターでの再構築を保証するんでしょうか。ひょっとして、xxx.xxx.xxx.xxx.*.*.*.* へのパケットは必ず一つのIPv4+ルーターで全部処理し、フラグメント化されたパケットを見つけたときは残りが届くまで保持するなんて実装とか?
だいたい、フラグメントが発生した場合に起こることに対する理解が足りないですね。フラグメントが発生するときは、
Re:DHCPでIPV6を選べばいいだけじゃないの? (スコア:1)
>> 是非、貴方が思うだけでなく行動に移してください。
>学部生の卒論でも無理でしょう。
>すでに誰かが考えて提案し、そして、あまりにダサい方法だと一蹴されて、早々に論外に追いやられ、
>蒸し返すことも許されてないでしょうから。
当初の条件である、 'IPv4 と上位互換が取れること' を満たせてるとは到底思えません。
>> 作るとしたら具体的にどのように作りますか?
>たとえばIPv4+という名前にするとして、IPアドレスをxxx.xxx.xxx.xxx.qqq.qqq.qqq.qqqとします。
>IPヘッダのバージョンのフィールドは4のまま、プロトコルのフィールドにIPv4+を示す値を入れ、
>送信元と送信先のIPアドレスのqqq.qqq.qqq.qqqの部分は、IPヘッダではなくペイロード部分に格納します。
>IPv4対応のルータにとっては、TCPやUDPではないが、しかし普通のIPパケットです。
>IPv4+対応のルータやホストは、それを解釈して、そのように処理します。
せめて IPv4 の Option フィールドに入れるべき値だと思いますが。
IPv4+ 対応の装置はどこから出てくるのでしょう。 実装しないといけませんね。
しかも、通常の IPv4 ヘッダよりも後ろにアドレスがくると言うことは、IPv4 をフォワードすることを
前提に作られた HW ルータでは、ASIC で処理できない可能性が極めて高いです。
そうすると、HW から設計のし直しです。
>移行は次のように行います。
>まず、アドレス数枯渇対策としてではなく、NATとの親和性の悪いアプリでのNAT越えの手段としてIPv4+を普及させます。
>その次に、NATに無関係なアプリもIPv4+対応させます。
>主要なアプリが対応を済ませたら、ISPがユーザーにIPv4のグローバルアドレスを1つずつ配布するのをやめ、IPv4のTCPとUDPはNATで提供するようにします。IPv4のみ対応のレガシーなアプリはNATで、IPv4+対応のアプリはNATせずにネイティブに処理されます。
>このような方法なら、ネットワークのコア部分はIPv4のままで良く、エッジまわりのみIPv4+対応すれば済みます。
>しかし、UPnPなどのNAT対策が既に普及した今となっては、手遅れですね。
根本的な話になりますが。 ネットワークのコアに IPv6 を導入するのは簡単です。
2000年初頭の段階で既に多くのベンダは IPv6 のフォワーディングに対応していました。
コアへの導入は簡単なんです。 装置の入れ替えの際に、IPv6 の主要なルーティングプロトコル(OSPFv3/BGP4+)に
対応していて、ASIC がハードウェアフォワーディングをサポートするだけでよいのですから。
仮に、エッジ(PEのことですよね?)が IPv4+ に対応したとしましょう(この段階で上位互換でも何でもないですし、
コアルータと PE ルータ、どっちが数が多いかは自明ですね)。また、エンドユーザが持つアクセスルータ
(ブロードバンドルータ)が、IPv4+ に対応することは絶望的ではないでしょうか。
ところで、
移行は次のように行います。
まず、アドレス数枯渇対策としてではなく、NATとの親和性の悪いアプリでのNAT越えの手段としてIPv6 を普及させます。
その次に、NAT に無関係なアプリも IPv6 に対応させます。
主要なアプリが対応を済ませたら、ISPがユーザーにIPv4のグローバルアドレスを1つずつ配布するのをやめ、
IPv4のTCPとUDPはNATで提供するようにします。
IPv4のみ対応のレガシーなアプリはNATで、IPv6 対応のアプリはNATせずにネイティブに処理されます。
あれ??
IPv4+ よりも圧倒的に IPv6 のデプロイの方が進んでますが・・・。
>なぜ、この方法が採用されないのかというと、まず第一にダサいのと、技術的な解決とは言えないからです。
>この話を10年以上前に教授にしたら、他力本願すぎるし、これは通信技術ではなく社会計画の範疇だし、
>君の手の出せない部分の大きな協力に依存している絵空事でしかないと、呆れられちゃいましたよ。
まさしくその通りだと思います。 IPv4 の上位互換になっていませんし、
既存の IPv4 しかサポートしていない大多数の装置への再実装が必要になります。
1993年以前に教授ではなく IETF に提案していたら、ひょっとしたらひょっとしたかもしれません
(私はひょっとしないと思いますが)。
が、現状の IPv6 の立場と同じで、2010年の段階で IPv4+ に対応している装置も世に出回ってないと思います。
さらに、最小アロケートサイズが /32 となり、それ以上細かくすることはできません。
IPv4+ に対応していないコアルータ(BGP ルータ内)では /32 のルートが爆発し、コアルータではブラックホール
ルーティングもできません(/32 単位でブラックホールにぶち込んでいいのなら別ですが、そもそも /32 より
細かいアドレスを個々のユーザに配布する前提ですよね?)。
Re: (スコア:0)
> フラグメント化されたパケットを見つけたときは残りが届くまで保持するなんて実装とか?
その通り。
最初はNAT越えの手段として使われますので、必ず1つのIPv4+ルーターを通ることは問題ありません。
とても高コストな処理ですが、末端のNAT箱で行うので、大した問題にはならないでしょう。
ISP側のNATで処理する段になると問題になりますが、そもそも標準的なトラヒックに対してフラグメントを生じるというのはイレギュラーだと思いますよ。
> 元のパケットを
Re: (スコア:0)
いいえ、IPv4のヘッダ長の可変に対応していないハードウェアへの親和性を考えると、Optionフィールドは使わないほうが良いと思います。
> IPv4+ 対応の装置はどこから出てくるのでしょう。 実装しないといけませんね。
もちろんです。
> しかも、通常の IPv4 ヘッダよりも後ろにアドレスがくると言うことは、IPv4 をフォワードすることを
> 前提に作られた HW ルータでは、ASIC で処理できない可能性が極めて高いです。
IPv4のみ対応の機器がIPv4パケットとして処理できるようにするために、拡張部分をペイロ
Re:DHCPでIPV6を選べばいいだけじゃないの? (スコア:1)
# だんだん、コメントをもらう部分が減ってるんですが、それらには反論しない/できないという
# 理解でいいんですかね。
# いや、匿名の臆病者が同一人物であるという保証が無いので別の人が個別に反応しているだけ
# かもしれませんが。
> > せめて IPv4 の Option フィールドに入れるべき値だと思いますが。
> いいえ、IPv4のヘッダ長の可変に対応していないハードウェアへの親和性を考えると、
> Optionフィールドは使わないほうが良いと思います。
いや、Option フィールドに入れるのも十分ダサいけど、ペイロードに入れるのはもっとダサい
というだけの話なんですが。
IPv4 のヘッダ長の可変に対応してないルータ(というか、L3スイッチというべきかな、時期的
には)は、先頭 20OCTETS しかみないだけでしょ? 貴方の言う、IPv4+ 非対応ルータと何も動作
は変わらないと思うけど。
あと、IPv4 では Option フィールドの実装は MUST じゃなかったっけ。 それに対して、
ペイロードに何の断りも無く拡張アドレスを入れるのは問題が無いといえるの?
間に L4 を見る装置が無いことをどこで保証するの?
> > IPv4+ 対応の装置はどこから出てくるのでしょう。 実装しないといけませんね。
> もちろんです。
それを実装してまでヘンテコな(だって IPv4+ の技術詳細は貴方の妄想の中にしかないもん)
プロトコルを実装する意味はあるの?
IPng に提案したって相手にされないと思うけど(これは後述の1990年代前半に対する返答ね)。
> > また、エンドユーザが持つアクセスルータ(ブロードバンドルータ)が、IPv4+ に対応することは絶望的
> ではないでしょうか。
> 2010年の今からは無理でしょうね。
> すでに、別のNAT対策が実装されたモデルへの買い替えが済んでしまってますからね。
> (もしかして、なんちゃらメッセンジャーをNATの内側から使うために、ブロードバンドルーターを買い替える
> ブームがあったのをご存じない?)
ブロードバンドルータを買い換えるほどのブームになったメッセンジャーソフトは知りませんわ。
いったいどんなムーブメントなんだろう。
> > IPv4+ よりも圧倒的に IPv6 のデプロイの方が進んでますが・・・。
> それは2010年の今の話でしょ? ここでやっているのは、1990年代前半の話ですよ。
よっぽど教授に相手にされなかったのが悲しかったのでしょうね。
1990年代前半の時点でも相手にされないと思うけど。
ところで、貴方の言う IPv4+ 対応ルータは、 PEなの? CEなの?
エッジ って何を指しているの(PEなの?って確認したんだけど)。
貴方の言う IPv4+ 対応ルータを入れるとして、PE なら http://srad.jp/comments.pl?sid=511060&cid=1843668 [srad.jp]
に対する対策をきちんと述べてほしいし、
CE なら NAPT と意味が変わりませんよ。
# しかし、1990年代前半の段階で IPng の存在を知らないか、はたまた知ってる上で俺々
# プロトコルを世界標準に!! なんて1人で言ってたとしたら、教授も困っただろうなあ。
# そしてそれから10年以上経っても当時の自分の考えは浅かったなあと思わないところも、
# 嫌いじゃないですよ。
# 年代的に私と一緒か私より上なんだよなあ・・・。なんというか興味深い。
# JANOG とかに来てたりしますか?
# できれば IPv4+ の詳細をもっと知りたい。
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)