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

主演： 自称プロ ◆6V8RpP7i3I ( #iij )

2get

提供：

IPv6スレ ver4
http://pc11.2ch.net/test/read.cgi/network/1188010461/

>> 315

乗り遅れの今更ですが、ちゃんと説明してるのが無いっぽいので。

[SERVER] -- [ROUTER A] -- ???? --- [ROUTER B] -- [CLIENT]

CLIENT から SERVER に TCPコネクション張るため SYN を送ったとする。
拡張アドレス情報は、ROUTER A に到達するまでは保持されるだろうし、
経路制御は、既存のIPv4前提の機材でもうまくいく(と思う)
しかし、SYNを解釈し、SYN-ACKを送信する時点で、拡張部分が失われる。

SYN-ACKは、ROUTER B までは到達する（だろう）
が、拡張部分は失われているので、CLIENT まで到達できない。

例示の経路じゃなく、経路中にNATがあるとか、対応ROUTERがあればとか、
いろいろあるように見えて、実はサーバが対応してないなら、拡張部分は
失われる ってのは確実。

結論：機能するとは思えない

動かすには、拡張部分を保持して、必要に応じて補完するヤツが要るが、
それをうまく実現しているのが NAT とも言える。見方によっては。

サーバ側が対応して、拡張アドレス部分を維持するってんなら、動く。
そういうツッコミは散見されるけど、動かない説明が不十分そうなので
つらつら書いてみました。

長文失礼

> サーバ側が対応して、拡張アドレス部分を維持するってんなら、動く。
アドレスを拡張するって目的においては、v6もサーバ側が対応しないといけないのは同じじゃん。
結局、何を実現したいかの議論が抜けているから、すれ違った不毛な議論になる。

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

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

じゃ、これでおしまい。

つか、ClassE にキープされてるアドレスから拡張すれば？
なんか電話番号と同じだね。桁数増やすと交換機を入れ替えなくちゃならん。
SIP/enum のフレームワークなんかが透けてみえて気持ち悪い。

>つか、ClassE にキープされてるアドレスから拡張すれば？
今から機器をClassEに対応させてまわっても確保できるアドレスは
たかだか256^3個しかないので、コストに見合わない。
それやるくらいなら素直にIPv6化したほうがずっといい。

再利用浮上

IPv6に洗脳されちゃった人ってかなりイタイよね

それは見えない敵です

うーん、ルーズソースルートで代用可能な気がするんだが、
IPv4.6を新しく作る意味が解らん。

>>14
本質的にNATと同じ、というかNAT以下の機能。

NATは32bit+port番号16bitで、xxx.xxx.xxx.xxx:port で表現され、
v4.6は32bit+拡張32bit+16bitで、xxx.xxx.xx.xxx.yyy.yyy.yyy.yyy:port で表現される。

IPv4.6の目的は
「アドレスが不足してもホストを沢山繋げることができて、しかも、
既存のv4機器でもサポートしていれば通信できて、
サポートしていなくてもアドレス前半のホストまで到達できるようにする」
だったらしいが、
つまりNAT。

NAT再発明したものの、結局NATより普及しないバカプロトコルを提案して瞬殺されたというオチ。

>>15 ポート番号じゃルーティング出来ないじゃん
v4.6は後半:yyyy.yyyy.yyyy.yyyyでもルーティングするんだよ

>>16
だから、変なルーティングしたいなら
ルーズソースルートが用意されてるんだけど
それじゃ駄目なの?

>>17 そんなこと言ったらなんでv6にするんだよ。
v4で駄目なの？

>>16
だからNAT箱でのポートフォワードがstatic routeと同義
結局やってることは同じ

劣化NATだってば

>>19 ローカルアドレス持てばダイナミックルーティングできるお

>>20
だったら最初からIP-in-IPだけでいいわけだが

>>21 そうだね。v4 over v4 でもいいと思うよ。

とｋろで>>21のv6への立場はどっちなん。
推進派？否定派？

v6推進/否定は関係ないだろ。
ここはIPv4.6スレなんだから。

>>24 何のためにv4.6を話し合うかの前提じゃん

知ったところでどうなるんだ。
どうせv4NATとしか比較しないんだろ？

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

>相手の立場を知らないと議論にならない
それは議論のための議論だからだな。
技術的な議論にそもそも立場は関係ない。

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

>>19は技術的に妥当な結論だからどうしようもない。

>>29への唯一可能な答えは

そう思いたいのですね

ってとこか。

どんな技術でも肯定も否定もできるんだ。
だからそんなことしても意味ないでしょ？
v6のあそこが悪いだのココがいいだの言い合っても。

建設的な意見で重要なのは互いが同意するか、
どうしないまでも落としどころを見付けることだと思う。

その前提として、キミの立場を聞いてるんだ。
答えたくないならそれでもいいけど。

学生さん？

技術で飯食ってる人間は、技術的な議論に変な落としどころを
つけることがどんなに危険かよく知ってるからなあ。
口車でごまかそうとしても無駄だよ。

>>32 どう危険なんですか？
落としどころ付けないと仕事にならないんですが。

> 落としどころ付けないと仕事にならないんですが。
v4.6みたいな腐った仕様を導入すると
ネットワークインフラそのものが崩壊しかねない。

>>34 じゃあキミは何がベストな方法だと思うの？
アドレスの枯渇って問題に対して。

あんたの術中にハマるほど頭悪くないよ。
相手してくれる人が出てくるといいね。

なんだよ術中ってｗ

「あんたの術中にハマるほど頭悪くないよ。」って書いちゃうぐらいには、
頭が悪いってことだな。

建設的な意見： v4.6でバカが考えたアホ仕様だから、そんなの議論するよりNAT使いつづけるかv6使うか議論した方が時間が有効に使える。従ってｽﾚ終了。

>>39 お母さんが見たら泣くような書き込みですね

フシアナも出来ないヘタレが何か言ってるぜｗｗｗｗ

えらいねー
えらいねー

>>31
スレ違い。
ここはIPv4.6スレです。IPv6の話をしたいならよそでやってください。

フシアナできる人は根性あるからきっと実名で書いてくれるんだろうなー
フシアナもできない俺のようなヘタレとは違って当然すぐ実名出してくれるよなきっと

隔離スレにまで出しゃばってくるなんて、よっぽど寂しいんだね

◆6V8RpP7i3I 涙目

>>5 >>6 >>7 ＆ >>15
IPv4.6 は、サーバ側が対応していなければ動かない
NAT は、サーバ側が対応していなくても動く（ように作られている）

目的違うんでしょうが、NATの再発明にもなってないです。

IPv4.6 は、IPv4の後継として、アドレス空間を広げること を目的としている。
IPv6 との違いは、移行のしやすさ である。 IPv4.6は、IPv4の上位互換として
機能し、IPv4のアドレス空間を広げるが、同時にIPv4.6未対応のIPv4機器に
対しては、IPv4互換として動作するため(※)、IPv4機器との接続性を維持した
まま、容易にIPv4.6へと移行できる。

…のつもりで発案されたようですが、互換性を維持できておらず、実際は
サーバ側の対応が必須になっています。よって存在意義はありません。
それ(※)が理解できないようで「勉強してこい」と叩かれたと思います。

互換性は維持できるし、もちろんv4.6を使おうとするとサーバ側の対応は必要だけど、
必要な部分から移行できるので、それが最大のメリット。

パケットの形だけが同じであることを「互換」とは言わない。
実際、v4のままv4.6が利用できる要素はひとつもない。

>>49 v4がv4.6に互換なんじゃなくてv4.6がv4に互換なんだよ。わかる？
AMD64に対応したプロセッサでもx86のコード動くでしょ？
親の育て方が悪いとバカになるんだな。

◆6V8RpP7i3I が
> 親の育て方が悪いとバカになるんだな。
というようなセリフを吐くような奴だということはわかった

>>51 知能障害起こしちゃったｗ 技術論で言い返して来いよ。
お前の母さん、昨日腰振ってたぞ

俺、>>51 以前にこっちのスレには何も書いてないんだが...
◆6V8RpP7i3I が
> 知能障害起こしちゃったｗ
とか
> お前の母さん、昨日腰振ってたぞ
とか
そういうレスを書くような奴だということはわかった

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

俺の人間性はわからなくていいから、自分がバカだってことをわかれよｗｗｗｗ

アプリ的な話なら、IPv6だってIPv4互換だよなぁｗ
IPv6に対応したアプリなら黙ってたってIPv4で動くｗ

>>55 うごかねえよｗｗｗ
そもそもアドレスの表記からして違うｗｗｗ

ぽか〜ん

>> というようなセリフを吐くような奴だということはわかった
>> 母はゾンビになったらしい。困ったものだ
>> ぽか〜ん

まともな反論ができないってことはわかったｗｗｗｗ

ぽか〜ん

いいから騙されたと思って、dual stackのマシンで、IPv6のサーバ
プログラム、AF_INET6つかったの簡単なの動かしてみろよ。
そんで、IPv4でつないでみろ。

◆6V8RpP7i3Iが頭いいとは思わんけど、
anonymousは頭悪いな

ぽか〜ん

>>60
騙されるわけねーだろ、(ﾟдﾟ)ﾊﾞｰｶ
まともな反論してみろよｗｗｗ

おまえらこのページ見てみろよ！
http://www.ie.u-ryukyu.ac.jp/~e055738/b.html

俺が勉強不足でサーセンｗｗｗｗｗ

ちょｗｗ 何この流れｗｗｗ

>>50
> >>49 v4がv4.6に互換なんじゃなくてv4.6がv4に互換なんだよ。わかる？
で？
それになんの意味があるの？

>>66 ぽか〜ん

58 ： ◆6V8RpP7i3I ：sage ：2007/11/21(水) 22:08:38 ID:???
まともな反論ができないってことはわかったｗｗｗｗ

>>66 >>49の間違いを正したんだが。

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

47 = 4 です。
>> 48 互換性は維持できるし (以下省略)

別の書き方をします。

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

TCPオプションは、相互で違っていてもかまわないものなので、IPv4しか
しらないサーバからの応答に、拡張アドレスオプションは維持されません（よね？）
よって、IPv4.6からの発信は、IPv4ノードに届くかもしれませんが(※)、
応答は、発信元のIPv4.6ノードまで到達できません。(拡張アドレスが失われるので)

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

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

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

>>70 既存のv4インフラを何ら変更することなく、
アドレス拡張が出来る。

>>71 もちろんです。v4.6で通信するには、
双方がv4.6に対応していなくてはいけません。

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

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

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

>>74 そんな実装見たこと無いけどな
また平気で嘘をつく。。。。

>>中身を捨てることがある
ソースきぼんぬ

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

オプションとして規定されてるんだか継承しなきゃいかんだろ。
それにヘッダサイズはどうすんだよ。

>>78
全部NO-OPにするかもしれないよ？

否定のための妄想は止めないか？
「かもしれない」って全部妄想じゃん。

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

>>80
そういう実装があっても何ら仕様に違反しないわけだが。
そういうルータを途中で一個でも挟んだだけでおじゃん。

>>81 拡張領域だから何入れても良いんだよ。
実際暗号に使う情報入れれるし。

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

>>84
仕様は満たしているよ。

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

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

なんかすごいこと言い始めたな。
無知ってこわい

未知のオプション情報ごと中継しないといえないという仕様は無いよ。
もちろん中継してもいい。

あんまり変な情報を詰め込むと、オプション情報の最大サイズを
決めうちにしているネットワークスタックとか困ったことになると
思うけどなぁ。

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

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

>>74 >>76

私はそっち系ではないので、でっかい高いルータは知りません。
経路によっては、MSSの解釈と書き換え はあるはず。(想像です)
解釈できない未知のオプションは、普通なら維持するでしょうが、
誤動作するヤツがいても不思議はないと思います。(これも想像)

FireWallについても想像ですが、解釈できないとか、なにかが普通と
違うパケットを、独自の基準で選別して、通過させない製品があります。
どんな基準で実装がされているのやら、まったく判りませんが、
既存のものと違うわけですから、通過できない可能性はあると思います。

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

>>89 IPsecって知ってる？

>>90 はいできません。
>>90 IPSecって知ってる？

俺も言わしてくれ。IPSecって知ってる？

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

知ってるよ！バカにするな。知らない奴はミジンコｗｗｗｗ

>>94 飛ばない飛行機もあるかもしれんが、
それは飛行機とは呼べませんな。

IPsecもヘッダの拡張領域を利用しているわけだが、
IPsecが通らないルータがv4.6を通さないのは仕方がない。
だってそのルータが仕様を満たしてないんだもん。

>>94 詭弁のガイドライン
2.ごくまれな反例をとりあげる

いま一生懸命IPsecをぐぐってるんだろうなあ

ぐぐり終わって涙目？もう書き込めない？ｗｗｗｗ

>>92
同じIPv4アドレスを共有している、複数のIPv4.6ノードを特定できないと、
「片方が対応してない場合、その通信はv4と同じになります」という動きが
できないんですが、それも了解ですか？

>>92 IPsecって知ってる？

質問の意図を量りかねますが。いちおう知っています。
IPsecは、私の勘違いでなければ、IPのペイロードにAHヘッダー積んで、
その後にTCPつけてとか、IPのペイロードにESP積んで … というヤツで、
IPヘッダは、AHとかESPの前で完結していたはずですけど？

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

>>101 はい了解です。

あなたは勘違いしています。IPsecのヘッダはパケットのペイロードではなく、
拡張領域に格納されます。

>> 97
それは間違い。

確証が無かったので、ぐぐってきました。
http://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

解りやすそうなページを探してきた。このページの説明でいくと…
http://opentechpress.jp/kernel/internal22/node251.shtml

ihl(IPヘッダ長)は、オプション領域まで含めたヘッダ長 であり、
ihl＝５は、オプションなし　を意味する。だと思うんですが？
了解でしょうか？

＃ だいぶんスレ違いだな

>>105 了解です

あああああああああ、りょうかいじゃねえよ
ihl=5て5バイトしか無いってことじゃん。
ばかかおまえ

>>107
IPv4ヘッダのレングス部分は４ビットしかないので、４で割った値を書きます。
パディングして４の倍数長にするのはそのためです。

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

了解ですか？

>>了解です。

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

v4.6パケットをそのまま通せないv4ルータがあるかどうかは重要な議論ではない。
v4ルータはどのみちv4.6パケットを正しくルーティングできない。
こっちのがよっぽど重要だろ。

ARPをいじくる必要あるね。

v4.6はNAT以下だな
やはりバカプロトコル

>>110 v4ルータはv4.6パケットをルーティングできないけど、
v4パケットとしてはルーティングできるし、
そこがいちばん肝なんだけど。

間違ったルーティングに何の意味が？

>>114 間違ったルーティングって具体的に？

>>114 キミたち否定のための議論だからバカっぽいんだよねｗｗｗｗ

まさかv4の範囲内でしかルーティングしないなんて言わないよな？

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

何でここでローカルアドレスが出てくるんだ？
頭大丈夫か？

v4.6の基本概念は、拡張領域にローカルアドレスを入れようって話なんですが。

IPv4アドレスのないとこで使えないじゃん。
それでいいならNAT使うだろ。

v4.6はNAPT「も」使えます。

つまり、最初からv4.6は不要。

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

能書きはいいんでどこかに実装はない？

v4ルータはv4.6の拡張部分をルーティングできないんだろ？
なら同じことだ。

つか、NATSでいいやん

NATSというよりはnutsだな。

>>126 v4ルータはv6パケットをルーティングできませんが。
>>127 ええ、NATSでもいいと思います。

v6の議論は足踏み状態だと思うのです。
このスレは第三の方法を議論するところですね。

現在ある技術よりも劣ったものを議論してどうするのかと。

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

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

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

>>132 実装するのが面倒だから実装しません。普及しないもの実装しても時間の無駄じゃん。
別にこのスレでv4.6を普及させよう。なんて思ってません。
でもv6本スレの議論ループよりましだと思います。
この議論によってv6が普及するかもしれないし。

なるほど、すべてを理解した。
こいつ頭が悪いんじゃなくて
頭がおかしいんだな。

だから隔離スレなんだね。その隔離スレに乗り込んでくるキミはもっと頭おかしいね

本スレも >>134 ばかりな池沼ばかりで、
全然技術論が話し合われないものな。

頭が悪いとかおかしいとか言い合って、
それでネットワーク環境が良くなるのかと。

技術の知識なくてサーセンｗｗｗｗｗ
ただ頭がいい奴をバカにしたいだけﾌﾟｹﾞﾗｗｗｗｗ

>>137 そんなのわかてるよ。通信技術板で技術の話してるのに、
「お前頭おかしいな」なんて発言は、
「私は技術の知識がないのに構って欲しいんです」っておでこに書いてるようなものだし。

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

>>109
では、IPsec仕様を勘違いしたままあなたが展開した論理や皮肉は、
全て間違いであった。ということを認めてくださいね。

>>118
できません。
文脈では、IPv4.6非対応のルータが正しくルーティングできるか？
という議論のはずです。

>>110
そのとおりです。同じIPアドレスを共用するIPv4.6ノード間の通信は、
IPv4のみ対応のルータを経由しては成立しません。
しかし…(次レスに関連)

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

>>111
そうですね。ARPをいぢくって 同じIPアドレスを共用するIPv4.6ノードの
代表者が、マルチキャストの物理アドレスを伴うARP応答をする みたいな
トリッキーな動きをすれば、ENDノード側直近のルータが、IPv4のみ対応
であっても、動作する可能性はありますね。

もっとも、これだと IPv4 NAT と同じ利用形態となり、かつ サーバ側の
IPv4.6対応が必須なわけですから、NAT以下の互換性となるわけですが。

>>141 >>123
そのとおりなんですが、サーバ側の対応が必須ですから、NATの代わりに
すら なりません。 お分かりかと思うのですが、NAT置き換えできる能力
すら ない ってことを強調させていただきました。

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

>>139 の二番目
はい、v4ルータはv4.6のパケットをv4パケットとして正しくルーティングできますが、
v4.6パケットとしてはルーティングできません。

>>139 の三番目
はい、その通りです。

>>47 の中の人が変わってるなｗ

>>124
NATはNAT BOXのENDノード側のプライベートアドレスを特定するために、
ポート番号を使いますが、経路途中のIPv4ルータが、ポート番号で
ルーティングするような必要性は、ありません。

>>129
IPv4.6 が、IPv6のアンチテーゼとして、IPv4との互換性を維持したアドレス
拡張として考案されたのであれば、当然のこととしてIPv4ルータでも、
ルーティングできることが期待されます。（限定的には可能かもしれないが）

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

今日の>>47のひとはNATが好きなんだなー。
別にそれでもいいと思うよ。

#iijの中の人もややこしいから識別子つけてくれる？

>>145
なんつーかな、技術的な話に完結したいのか罵しり合いがやりたいのかはっきりしろ

>>144 v4.6のNAPTと比べての優位点は、単純にIPアドレスで外側からアクセスできることです。
NAPTの場合、例えばWinnyでP2Pしたい場合、ルータでポートフォワードの設定をして、
かつそのポート番号を相手に知らせなければなりません。
しかしv4.6同士の場合はその必要がありません。

>>当然のこととしてIPv4ルータでも、ルーティングできることが期待されます。
v4のパケットとしてはルーティングできますよ。互換なのだから。

別に誰が書こうと関係ないでしょ。書き込み内容で判断すれば。

>もっとも、これだと IPv4 NAT と同じ利用形態となり、かつ サーバ側の
>IPv4.6対応が必須なわけですから、NAT以下の互換性となるわけですが。
どうやらあんたの頭はマトモのようだ。
NATと同様のステートを後付けで入れる拡張は今更意味がない。

>>150 自作自演乙 (*>`艸<)ッ

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

>v4.6のNAPTと比べての優位点は、単純にIPアドレスで外側からアクセスできることです。
それ、port forwardの設定をv4.6のアドレスに言い換えてるだけだから。

>ルータへのポートフォワードの設定は誰がするの？
v4.6のアドレスの設定は誰がするの？

>>153 うんごめんね。あなたのいうとおりだ。
完全敗北です。半年間ＲＯＭります。すみませんでした。

当初からトリップ割れしていたから、こうなるオチは
見えていたがgdgdだな

以上、すべて俺様の自演でお送りしました。
ってことにすればいいのか？

>>153 NATだとNATの内側でhttpdが立てられないと思うよ

httpdにかぎらず、1023以下のポートを使うサーバだけど
でもv4.6ならできるな。

>>157
ズコー

>>153 v4.6ではパケットにソースアドレスが入ってるから、
誰かが設定しなきゃいけない。ってことはないです。

ていうかおれんちでは普通にNATの内側で
グローバルアクセス可能なhttpdを
運用しているわけだが

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

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

>>161 はDMZ設定してるだけだろうなー

>>163
load balanceでもするのか？

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

>>161 は自分家でサーバ立てて気取ってる程度ってことだよ

ポートフォワーディングだとポート番号が決まっているアプリケーションだと、
そのNATの内側にひとつのアプリケーションしか立ち上げられないね。

>>168
具体的には何？

うぇるのーんぽーとを使うアプリケーション

SSTPとか

>>170
それらのアプリケーションはURIなどのスキームでポート指定ができないの？

わざわざ
http://111.111.111.111:80/
http://111.111.111.111:33822/
とかしていしなきゃいけないなんて。。。。。。。。。。。。

>>145
変わってないし、別にNAT好きでもないが、NATは普通に使っています。

きみが発案の過程で、IPv4.6非対応のノードとは、IPv4として通信できるうんぬんと、
IPv4との互換性を強調していなければ、NATとの対比は出てこなかったと思います。

代わりに、各種トンネル技術やら xx over IPv4 との対比をされて、
存在意義を否定されたでしょう。。。ガイシュツだったような気もしますね。

>>140
めんどうですが、ピックアップしましょうか。。
>>83 (?) >>97,99,100,102,104
了解でしょうか？

>>140 >>142
それを希望されているようでしたので、技術面から、まともに反論してるのですが。
同意頂けるのは在りがたいですが、論破されていることが認識できないのは、
ちょっと切ないですね。 さすがにちょっと疲れました。(^^;

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

了解でしょうか？って聞かれて反論してるっていうのもなー

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

◆6V8RpP7i3IのIPsecの解釈はおかしくないと思うが。。

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

机上の空論で済ませるつもりらしいが、それにしても
他の案とくらべてメリットが薄い

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

>>181
SRV

>>182 なんかDNSに依存するのはやだな。。
これは個人的な好き嫌いだけど。

>>183
エンドノードのスタックを書き替えないと恩恵にあずかれない頭の弱い方式よりも
ずっとスマートだと思うが

>>184 v4.6はスタック書き換えれば済むけど、
SRVは全ネットアプリケーション書き換えなきゃな。。

>エンドノードのスタックを書き替えないと恩恵にあずかれない頭の弱い方式よりも
>ずっとスマートだと思うが
なおかつスタックを書き替えてもたいして嬉しくないことも判明しているしなあ。

>>185
スタックの再実装とDNSの書き替えのどちらが安いかの判断もできないぐらい馬鹿なの？

>>187 SRVはDNSの書き換えだけで済まないでしょ。
アプリケーションの対応が必要だお

>>187 バカはどっちか身を挺して表現しちゃったなｗｗｗｗっｗ

>>188
SRVへの対応は一部のアプリですでに完了している

v4.6はアプリ全書き換えが必要だろこの池沼

>>190 一部完了してます！って自慢げにいわれてもなあ。
v4.6は初期の段階ではアプリケーションの対応はいらないお
ルータが対応すればいいだけ

>>191
おまえネットワーク知らないだろ

>>192 だからさ、俺がネットワークを知らないと思う、
お前の根拠も書けよ。

>>191
Sendmailとかは対応済みだしな
恩恵にあずかりたいアプリだけが対応すればよくて、未対応のアプリは
既存のポートでサービスすればいい

>>193
どの程度SRVが使われているか知らない点

> お前の根拠も書けよ。
あんたが自分で書いてるじゃん。

>>194 まあそれもそうだね。
だけどDNSを勝手にいじれないクライアント環境とか、
DNSの遅延とか考えると、使い勝手は悪そう。
あくまでも個人的な意見だが。

>>195 どれくらいつかわれてるの？

>>196 どこに？

>>197
NATの裏からサービス提供しようって話なのにDNSが触れない環境とか
どんだけ無理な条件設定だよ

もうお前は口を開くだけ馬鹿を晒すから黙ってた方がいいよ

>>197
超絶的に頭悪そうな意見だな

お前らってさ、「俺のすごさは月の裏に置いてあるノートに全部書いてあるぜ！」
って、全然根拠示せてないんだよね。

「こういう統計があるのでSRVはこれだけ使われています」とか
「あなたのこの書き込みが矛盾しているので、あなたはネットワークのこと理解していませんね」とか
書けないのかね。

詭弁のガイドライン
>>195 5.資料を示さず持論が支持されていると思わせる
>>201 9.自分の見解を述べずに人格批判をする

>>200 NATの裏からサービスを提供することと、
DNSが触れない環境になんら相関関係がないと思うけど。

＞＞２００ お前の方から隔離スレにきておいて、
俺様に黙ってろってなにごとだ！

俺がだまってたら、このスレに誰がかきこみするんだよ！

> >>200 NATの裏からサービスを提供することと、
> DNSが触れない環境になんら相関関係がないと思うけど。
ねえ、本当にそう思ってるのか？

ディズニーランドに来ておいて、ミッキーに「あっち池」っていうようなものだしねｗｗ
>>200の父さん土方なんだってな

>>206 思ってるよ。無駄に聞き返すなよ。はげ

詭弁のガイドライン
>だけどDNSを勝手にいじれないクライアント環境とか、
6.一見、関係がありそうで関係のない話を始める
>DNSの遅延とか考えると、使い勝手は悪そう。
6.一見、関係がありそうで関係のない話を始める
4.主観で決め付ける

あくまでも個人的な意見だが。
って断ってるからな。

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

>>197
>だけどDNSを勝手にいじれないクライアント環境とか、
どの文脈でクライアント環境ってのが出てきたの？

> キミらさ、なんで俺の相手してるの？
いけぬまが隔離スレから出てこないように
生殺しをキープ

>>212
こいつの脳内はいろんなキーワードが
ランダムに出てくるようになってる。
なかなか便利だな。

>>213 だったら>>200になんとか言ってやってくれ

>>215
いや、俺がその200だから。

>>212 それは本当の#iijじゃなくて俺が書いたんだけど、
クライアント環境ってのは言葉が違った。ごめそ。

じゃあ黙ってる

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

>>218
いや、黙るな。

>>185 >>190
IPv4.6対応するには、恐らくほとんどのアプリ書き換えが必要ですが、
もしかしたらIPv6対応のアプリは、スタック入れ替えだけで動くかもしれません。

sockaddr_storage 構造体を利用し、構造体の中身を直接操作しないプログラムなら、
その中身が sockaddr_in だろうが、sockaddr_in6 だろうが構わず動けるはずで、
だとすれば sockaddr_in46 (そんな定義はないけど) でも動けるはずだから。

ま、UI破綻するだろうし、極めて限定的な動作になることは、容易く想像できますがね。

> もしかしたらIPv6対応のアプリは、スタック入れ替えだけで動くかもしれません。

正確にはaddress family independent socket programmingに従ってるソフトウェアは、
だな。

>>202
お前らの中に私も含まれるかと思うので、リクエストに応えてみます。
お題は >>191 について。

IPv4.6に対応するには、IPv4.6で拡張されたアドレスを取得したり、保持する能力が
必須ですが、IPv4用に用意されていた初期のSOCKET関数には、アドレス形式に依存し
ないプログラム開発ができる機能が十分に揃っていませんでしたので、そのような
アプリケーションは、極めて稀有であると言えましょう。(※)

※極めて限定的には可能だが、gethostbyname とか使ってる時点でNG。

つづき

したがって、IPv4用のアプリケーションの大多数は、アプリケーションの書き換えが
必要です。アプリケーションを特定せず、アプリ書き換え不要とする、あなたの主張
は、誤りであると断定できます。

この点において、あなたはネットワーク(※)のことを、理解していませんね。

※ま、ここではソケットプログラミングのことなんだが。

まあもう真の#iijは来ないだろうけどな

>>222 そうです。フォローありがとう。
それにしても、んーー、残念だなぁ…

それにしても inet_ntop では protocol independent に書けない点について

client A 192.168.0.1 - router A 100.100.100.100 - interner - router B 200.200.200.200 - client B 192.168.0.1

router A, B ともv4.6に対応しているものとする。
1. client Aはv4.6アドレスである200.200.200.200.192.168.0.1にアクセスする。
2. router Aはv4ルーティングにより200.200.200.200に到達
3. router Bは192.168.0.1にルーティング
4. client Bのスタックがv4.6に対応していない場合、client Aのアドレスは失われるが、それはrouter Bによって補われる。

idがでないって便利だな

>>228
4でさ、clientBはどのIPv4アドレスからパケットが届いたように見えるの？

router Bにきまってるわと予想

見てたら source routing option 思い出したｗｗｗｗ

ところで、v6 の hop-by-hop option header って ISP にフィルタされないのかね・・・・？
DoS vulnerable と言われてたような気がするんだが

>>231
じゃあ、clientAから200.200.200.200.192.168.0.1宛てにTCP SYNが
送られたとして、200.200.200.200からTCP SYNを受けたclientBは
200.200.200.200にSYN ACKを返すと。router BはTCPの通信をきちんと
把握していて、100.100.100.100.192.168.0.1にTCP SYN ACKが返る訳ね。
なるほどなるほど。

>>223-224 の47、何とか言えよ

client A 192.168.0.1 - router A 100.100.100.100 - interner - router B 200.200.200.200 - client B 192.168.0.1

router A, B ともNATに対応しているものとする。
1. client Aはv4アドレス・ポート番号である200.200.200.200:80にアクセスする。
2. router Aはv4ルーティングにより200.200.200.200に到達
3. router Bは192.168.0.1にポートフォワーディング
4. client Bではclient Aのアドレスは失われるが、それはrouter Aによって補われる。

NATと何が違うん？

>>229 芸風で識別してくださいな。(^^;
>>231 や、ROUTER Aのエンドノード側でしょう？
>>233 UDPも考えてみると楽しいですよ。

>>235 NATと変わらないからいいんとちゃうん

>>235
client Aが、IPv4.6対応である というところ。
NATでは、client Aは IPv4でかまいません。
実装がなく、可能なことが証明されていないってところも違いますね。

(global)(global)とか書くと面白いことができちゃいそうだな

>>227
極めて限定的 の説明が必要でしたでしょうか？
特定のポートをLISTEN/ACCEPTするだけのサーバアプリケーションでしたら、
見かけ上 IPv4 を偽装するSOCKET関数をもつ 機能拡張されたプロトコルスタックの
実装は可能です。 が、ご指摘の件含めて ざる なので、意味なしですね。

偽者さんも出てきたようなので、以降は anonymous でいきます。(^^ゝ

>>18
ルーズソースルートは v4 の話だ。
私は、v4 でルーズソースルートを使わずに
v4.6 を使うべき理由があるのかを聞いたんだが?

そもそも v6 では、ルーズソースルートと呼ばず、
拡張ルーティングと呼ぶのを知らんのかね?

だから最初から劣化NATと言われているのに。

可能なかぎりポジティブに評価しようとは思うんだが、
どう探してもNATより優れている点がみつからない。

漏れは結構いい感じに思けどなあ

じゃあ実装して使ってみろよ。

　　　　 !　 .／ / i:::::::::i::::::::::::/i::::i　 i::iﾄ､:::::::::::::::::::::i::::::i:::::::i:::::::::::::::i:::::i:::::::::::i＼　　 ＼
　　　　 |／　 /　i::::::::ｉ::::::::::::ｉ i::::i 　 i::i i:i ､:::::::::::::::::::i､::ヽ:::::i::::::::::::::i:::::i:::::::::::i＼＼　 /
　　　　 ￣/7　　i:::::::i:::::::::::::トｉ､ｉ_　　i:i　ヾヽ::::::::::::::::::iヽ::iヽ::::i_;::-‐:i'´::l:::::::::::i　 ゝ_}/　
　　　　　/ノ　　 l::::::::l::::::::::::i　i:i　｀‐-|!　　ヽ ＼::::::::::::i_,.i斗´､::::::::::i|:::::l:::::::::::l　　＼｀ヽ　　　　>>245
.　　　　/　i＼　 i:::::::::i:::::::::::!　|!　　　 i＼ 　 ＼ ＼::／ir'　|!　 ヽ:::::i i::::i::::::::::::ﾄ,　 ／ヽ ヽ
　　　 /　/::::/ヽ|:::::::::::i:::::::::l,､＿＿＿＿､ヽ　　 ＼　＼;{＿i＿_ ､::ﾉ_i:/:::::::::::::i/／i:i::::::｝ i
　　　 !　/:::::l　 i::i::::::::::ﾄ､:::::l弋于旡示ﾘ｀　　　　　ヽ　ｲ{旡天歹Vｧ/i:::::::::::::::ｉ|　 i::l::::::iV
　　　　V:::::::l　i:::|:::::::::::ｉ::ヽ::l ゞし砂ンﾉ　 　 　 　 　 　 ゞく砂_ンﾉ / i:::::l:::::::|:::i　 !::l:::::l
　　　　 |:::::::l　l　|:::::::::::::i i ﾄ{　 ｀￣￣　　　　　　　　　　｀￣￣´　　 l:::::l:::::::|:::l　i::::l:::::|
　　　　 |:::::::|__|r'|::i:::::::::::::ﾊ　　　　　　　　　　 ､　　　　　　　　　　　 i:::::i:::::::i::::レ'::::l:::::!
　　　 　 i::::i ヾ/i i:::ｉ:::::::::::ｉ ﾍ　　　　　　　　　　 　 　 　 　 　 　 　 /i::::i:::::/ !:::i　｝:i}::/
　　 　 　 i::i　/ |　i::::i:::::::::::i　 ゝ、　　　　　　 -‐- 　 　 　 　 　 ／ i::::i::::/　i:::i ∧//
　　　　 　 i| i 　 !　!:::ﾄ、::::::i　　 ＼　　　　　　　　　　　　　　／　 //:::::/　/::i　i　i/
　　　　　　　|　　i　i::::i ﾍ:::::::i　　　　ｉゝ、　　　　　　　　,.. イ　　 //::::::/　/:/　/　｝
　 　 　 　 　 i　　 i　i::i　ﾍ:::::::i　　　 ト､ ｀ ヽ､　__ ,.　 '´　 /　　//i:::::/　/:/　/　/
　　　　　　　 ヽ　 ヽ ヾヽ　ヾ::ヽ　 　 !　｀ヽ　　　　　-‐'´/　　 ｲ j::::/　 ｼ ／ ／

http://www.iij.ad.jp/news/pressrelease/2007/1203.html
漏れはこれに応募するお

ttp://www.v6pc.jp/
サイトの情報が古すぎ。こいつらほんとにv6普及推進する
つもりあるんかね？

IPv6あげ

4.6？

NTT　VPNワイドを構築しようとしてるんだが、訳わからなくなった。
ルーター？「N500」まではすでに繋がっているらしい

社内ワークグループだと、\\グループ名￥フォルダ名で探せるんだけど
どう打てばいいの？教えて、偉い人
ワークグループは作ったけど、それだけじゃ無理？