【隔離】IPv4.6推進専用スレ

> サーバ側が対応して、拡張アドレス部分を維持するってんなら、動く。

アドレスを拡張するって目的においては、v6もサーバ側が対応しないといけないのは同じじゃん。

結局、何を実現したいかの議論が抜けているから、すれ違った不毛な議論になる。

ひとこと抜けた。

対応したもの同士がIPv4のインフラ上で拡張アドレスで通信できるってのが、もとの提案なんでしょ。

それ以上の何を期待して、皆、提案者を叩いているんだ？

>相手の立場を知らないと議論にならない

それは議論のための議論だからだな。

技術的な議論にそもそも立場は関係ない。

>>28 そうすると>>19のような否定のための否定しか出てこないんだ。

パケットの形だけが同じであることを「互換」とは言わない。

実際、v4のままv4.6が利用できる要素はひとつもない。

>>49 v4がv4.6に互換なんじゃなくてv4.6がv4に互換なんだよ。わかる？

AMD64に対応したプロセッサでもx86のコード動くでしょ？

親の育て方が悪いとバカになるんだな。

>>50

> >>49 v4がv4.6に互換なんじゃなくてv4.6がv4に互換なんだよ。わかる？

で？

それになんの意味があるの？

◆6V8RpP7i3I が

> 親の育て方が悪いとバカになるんだな。

というようなセリフを吐くような奴だということはわかった

俺、>>51 以前にこっちのスレには何も書いてないんだが…

◆6V8RpP7i3I が

> 知能障害起こしちゃったｗ

とか

> お前の母さん、昨日腰振ってたぞ

とか

そういうレスを書くような奴だということはわかった

母はゾンビになったらしい。困ったものだ

>>66 ぽか〜ん

v4.6がv4に互換であることになんの意味があるの？

>>70 既存のv4インフラを何ら変更することなく、

アドレス拡張が出来る。

47 = 4 です。

>> 48 互換性は維持できるし (以下省略)

別の書き方をします。

拡張アドレス部分は、TCPのオプションを使うことになっていたはずですよね？

TCPオプションは、相互で違っていてもかまわないものなので、IPv4しか

しらないサーバからの応答に、拡張アドレスオプションは維持されません（よね？）

よって、IPv4.6からの発信は、IPv4ノードに届くかもしれませんが(※)、

応答は、発信元のIPv4.6ノードまで到達できません。(拡張アドレスが失われるので)

上位互換性が無いので、部分的な置き換えはできないと思います。

参考 ⇒ hhttp://www.atmarkit.co.jp/fwin2k/network/baswinlan016/baswinlan016_02.html

※未知のTCPオプションを弾くFireWallやルータが、居るかもしれない。

>>71 もちろんです。v4.6で通信するには、

双方がv4.6に対応していなくてはいけません。

片方が対応してない場合、その通信はv4と同じになります。

>>73

v4.6 to v4.6でも途中のルータがオプションの中身を捨てることがあるって話をしてるのがわかんないのかなぁ。

>>74 勝手に捨てちゃ駄目でしょ。仕様なんだから。

>>74 そんな実装見たこと無いけどな

また平気で嘘をつく。。。。

>>中身を捨てることがある

ソースきぼんぬ

>>75

規定されていないオプションを継承しないといけないなんて仕様はないと思うけど。

>>73　片方が対応してない場合、その通信はv4と同じになります。

同じIPv4アドレスを共有している、複数のIPv4.6ノードを特定できない(よね？)

といっています。

>>74 >>76

私はそっち系ではないので、でっかい高いルータは知りません。

経路によっては、MSSの解釈と書き換え はあるはず。(想像です)

解釈できない未知のオプションは、普通なら維持するでしょうが、

誤動作するヤツがいても不思議はないと思います。(これも想像)

FireWallについても想像ですが、解釈できないとか、なにかが普通と

違うパケットを、独自の基準で選別して、通過させない製品があります。

どんな基準で実装がされているのやら、まったく判りませんが、

既存のものと違うわけですから、通過できない可能性はあると思います。

これらは、いずれも想像ですので「居るかもしれない」と書いています。

オプションとして規定されてるんだか継承しなきゃいかんだろ。

それにヘッダサイズはどうすんだよ。

>>78

v4.6拡張アドレスは現状オプションとして規定されていないでしょ？

否定のための妄想は止めないか？

「かもしれない」って全部妄想じゃん。

>>80

そういう実装があっても何ら仕様に違反しないわけだが。

そういうルータを途中で一個でも挟んだだけでおじゃん。

>>81 拡張領域だから何入れても良いんだよ。

実際暗号に使う情報入れれるし。

>>82 じゃあ仕様に準してないそのルータが悪いよ。

>>83

その「暗号に使う情報」を通さないルータはあるかもね。

>>84

仕様は満たしているよ。

>>85 パケットの拡張領域を勝手に削除するのがv4の仕様なのか？

>>90 はいできません。

>>90 IPSecって知ってる？

通らないルータがあるかもしれませんね＜IPsec

>>94 飛ばない飛行機もあるかもしれんが、

それは飛行機とは呼べませんな。

>>92

同じIPv4アドレスを共有している、複数のIPv4.6ノードを特定できないと、

「片方が対応してない場合、その通信はv4と同じになります」という動きが

できないんですが、それも了解ですか？

>>92 IPsecって知ってる？

質問の意図を量りかねますが。いちおう知っています。

IPsecは、私の勘違いでなければ、IPのペイロードにAHヘッダー積んで、

その後にTCPつけてとか、IPのペイロードにESP積んで … というヤツで、

IPヘッダは、AHとかESPの前で完結していたはずですけど？

>>94

それは無いと思うけど。通らなかったら不具合だわ。

IPsecもヘッダの拡張領域を利用しているわけだが、

IPsecが通らないルータがv4.6を通さないのは仕方がない。

だってそのルータが仕様を満たしてないんだもん。

>> 97

それは間違い。

確証が無かったので、ぐぐってきました。

hhttp://hccweb1.bai.ne.jp/emiglass/img/ipsec.png

ここの画像のバイナリ部分に注目。

先頭14バイトがEthernet Header で、DST/SRC/TYPE

次の20バイトがIP Header で、IPv4/HLENは 4Byteｘ5

次の0x0022からがESPヘッダーで、最初はSPI値(0x3c760edf)

ESPヘッダは、IPヘッダの次にあって、IPヘッダの中ではないです。

>>103 はふぃ。君は拡張領域はペイロードの前にあるから、

IPヘッダの次と勘違いしてるようだけど、

拡張領域も含めてIPヘッダだし、ESPヘッダは拡張領域に納められるから、

この画像で間違いないよ

>>104

解りやすそうなページを探してきた。このページの説明でいくと…

hhttp://opentechpress.jp/kernel/internal22/node251.shtml

ihl(IPヘッダ長)は、オプション領域まで含めたヘッダ長 であり、

ihl＝５は、オプションなし　を意味する。だと思うんですが？

了解でしょうか？

＃ だいぶんスレ違いだな

>>105 了解です

>>了解です。

ihi=6なら、24バイトがIPヘッダになりますが。

v4.6パケットをそのまま通せないv4ルータがあるかどうかは重要な議論ではない。

v4ルータはどのみちv4.6パケットを正しくルーティングできない。

こっちのがよっぽど重要だろ。

ロカールアドレスでもルーティングしますが。

ポート番号ではルーティングできませんね。

>>124

NATはNAT BOXのENDノード側のプライベートアドレスを特定するために、

ポート番号を使いますが、経路途中のIPv4ルータが、ポート番号で

ルーティングするような必要性は、ありません。

>>129

IPv4.6 が、IPv6のアンチテーゼとして、IPv4との互換性を維持したアドレス

拡張として考案されたのであれば、当然のこととしてIPv4ルータでも、

ルーティングできることが期待されます。（限定的には可能かもしれないが）

ともかく、IPv6のルーティング可否との比較は、意味がありません。

v6がふがいないからですね。

>>131

だから能書きはいいんで、実装は？

机上の議論だけでいい所を喧伝するなんて今のv6以下

>>132 実装するのが面倒だから実装しません。普及しないもの実装しても時間の無駄じゃん。

別にこのスレでv4.6を普及させよう。なんて思ってません。

でもv6本スレの議論ループよりましだと思います。

この議論によってv6が普及するかもしれないし。

本スレも >>134 ばかりな池沼ばかりで、

全然技術論が話し合われないものな。

頭が悪いとかおかしいとか言い合って、

それでネットワーク環境が良くなるのかと。

>>137 そんなのわかてるよ。通信技術板で技術の話してるのに、

「お前頭おかしいな」なんて発言は、

「私は技術の知識がないのに構って欲しいんです」っておでこに書いてるようなものだし。

どうして頭がおかしいのか理由を述べないとテストでも０点だね

>>139 IPsecの仕様に関して僕の間違いとはなんですか？

面倒だけど丁寧に相手しましょう。

>>139 の二番目

はい、v4ルータはv4.6のパケットをv4パケットとして正しくルーティングできますが、

v4.6パケットとしてはルーティングできません。

>>139 の三番目

はい、その通りです。

>>140

めんどうですが、ピックアップしましょうか。。

>>83 (?) >>97,99,100,102,104

了解でしょうか？

>>140 >>142

それを希望されているようでしたので、技術面から、まともに反論してるのですが。

同意頂けるのは在りがたいですが、論破されていることが認識できないのは、

ちょっと切ないですね。 さすがにちょっと疲れました。(^^;

>>144 v4.6のNAPTと比べての優位点は、単純にIPアドレスで外側からアクセスできることです。

NAPTの場合、例えばWinnyでP2Pしたい場合、ルータでポートフォワードの設定をして、

かつそのポート番号を相手に知らせなければなりません。

しかしv4.6同士の場合はその必要がありません。

>>当然のこととしてIPv4ルータでも、ルーティングできることが期待されます。

v4のパケットとしてはルーティングできますよ。互換なのだから。

>v4.6のNAPTと比べての優位点は、単純にIPアドレスで外側からアクセスできることです。

それ、port forwardの設定をv4.6のアドレスに言い換えてるだけだから。

>ルータへのポートフォワードの設定は誰がするの？

v4.6のアドレスの設定は誰がするの？

>>153 v4.6ではパケットにソースアドレスが入ってるから、

誰かが設定しなきゃいけない。ってことはないです。

>>160

おまえの出番は終わったよ。

ていうかおれんちでは普通にNATの内側で

グローバルアクセス可能なhttpdを

運用しているわけだが

>>161 2台置きたいときはどうするの？

>>163

load balanceでもするのか？

>>165 2台置けないとアドレス拡張の意味内じゃん

わざわざ

hhttp://111.111.111.111:80/

hhttp://111.111.111.111:33822/

とかしていしなきゃいけないなんて。。。。。。。。。。。。

>>173

たったそれだけでNATが使い続けられるなら非常に安価な対応コストだと思うが

SRVを使う手もある

机上の空論で済ませるつもりらしいが、それにしても

他の案とくらべてメリットが薄い

>>175 IPsecの情報はIPヘッダに入ってないとかいいたいのかな、こいつ

>>180 URIで指定できないSMTPとかどうするのか。の問題について。

>>181

SRV

>>182 なんかDNSに依存するのはやだな。。

これは個人的な好き嫌いだけど。

>>183

エンドノードのスタックを書き替えないと恩恵にあずかれない頭の弱い方式よりも

ずっとスマートだと思うが

>>184 v4.6はスタック書き換えれば済むけど、

SRVは全ネットアプリケーション書き換えなきゃな。。

キミらさ、なんで俺の相手してるの？

>>218

いや、黙るな。

>>217

違っているのは言葉じゃなくておまえの理解だ。