07/11/14 23:09:07
2get
3:anonymous
07/11/14 23:12:17
提供：
IPv6スレ ver4
ｽﾚﾘﾝｸ(network板)
4:anonymous
07/11/16 15:02:40
>> 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 とも言える。見方によっては。
サーバ側が対応して、拡張アドレス部分を維持するってんなら、動く。
そういうツッコミは散見されるけど、動かない説明が不十分そうなので
つらつら書いてみました。
長文失礼
5:anonymous
07/11/17 14:20:01
> サーバ側が対応して、拡張アドレス部分を維持するってんなら、動く。
アドレスを拡張するって目的においては、v6もサーバ側が対応しないといけないのは同じじゃん。
結局、何を実現したいかの議論が抜けているから、すれ違った不毛な議論になる。
6:anonymous
07/11/17 14:22:47
ひとこと抜けた。
対応したもの同士がIPv4のインフラ上で拡張アドレスで通信できるってのが、もとの提案なんでしょ。
7:anonymous
07/11/17 14:24:01
それ以上の何を期待して、皆、提案者を叩いているんだ？
8:sage
07/11/17 14:37:22
じゃ、これでおしまい。
9:baz@foo.bar
07/11/17 15:08:15
つか、ClassE にキープされてるアドレスから拡張すれば？
なんか電話番号と同じだね。桁数増やすと交換機を入れ替えなくちゃならん。
SIP/enum のフレームワークなんかが透けてみえて気持ち悪い。
10:anonymous
07/11/17 15:53:21
>つか、ClassE にキープされてるアドレスから拡張すれば？
今から機器をClassEに対応させてまわっても確保できるアドレスは
たかだか256^3個しかないので、コストに見合わない。
それやるくらいなら素直にIPv6化したほうがずっといい。
11:anonymous
07/11/18 21:06:12
再利用浮上
12:anonymous
07/11/18 21:09:37
IPv6に洗脳されちゃった人ってかなりイタイよね
13:anonymous
07/11/18 23:42:33
それは見えない敵です
14:anon
07/11/19 01:57:31
うーん、ルーズソースルートで代用可能な気がするんだが、
IPv4.6を新しく作る意味が解らん。
15:anonymous
07/11/19 02:04:09
>>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より普及しないバカプロトコルを提案して瞬殺されたというオチ。
16:anno
07/11/19 04:32:03
>>15 ポート番号じゃルーティング出来ないじゃん
v4.6は後半:yyyy.yyyy.yyyy.yyyyでもルーティングするんだよ
17:14
07/11/19 08:35:43
>>16
だから、変なルーティングしたいなら
ルーズソースルートが用意されてるんだけど
それじゃ駄目なの?
18: ◆6V8RpP7i3I
07/11/19 08:37:56
>>17 そんなこと言ったらなんでv6にするんだよ。
v4で駄目なの？
19:anonymous
07/11/19 09:11:34
>>16
だからNAT箱でのポートフォワードがstatic routeと同義
結局やってることは同じ
劣化NATだってば
20: ◆6V8RpP7i3I
07/11/19 09:14:32
>>19 ローカルアドレス持てばダイナミックルーティングできるお
21:anonymous
07/11/19 09:27:53
>>20
だったら最初からIP-in-IPだけでいいわけだが
22: ◆6V8RpP7i3I
07/11/19 09:37:54
>>21 そうだね。v4 over v4 でもいいと思うよ。
23: ◆6V8RpP7i3I
07/11/19 09:38:46
とｋろで>>21のv6への立場はどっちなん。
推進派？否定派？
24:anonymous@ssl.sarasarado.org
07/11/19 11:04:43
v6推進/否定は関係ないだろ。
ここはIPv4.6スレなんだから。
25: ◆6V8RpP7i3I
07/11/19 11:15:12
>>24 何のためにv4.6を話し合うかの前提じゃん
26:anonymous@ssl.sarasarado.org
07/11/19 12:56:32
知ったところでどうなるんだ。
どうせv4NATとしか比較しないんだろ？
27: ◆6V8RpP7i3I
07/11/19 13:05:33
相手の立場を知らないと議論にならない
28:anonymous
07/11/19 14:30:30
>相手の立場を知らないと議論にならない
それは議論のための議論だからだな。
技術的な議論にそもそも立場は関係ない。
29: ◆6V8RpP7i3I
07/11/19 14:47:50
>>28 そうすると>>19のような否定のための否定しか出てこないんだ。
30:anonymous
07/11/19 15:12:42
>>19は技術的に妥当な結論だからどうしようもない。
>>29への唯一可能な答えは
そう思いたいのですね
ってとこか。
31: ◆6V8RpP7i3I
07/11/19 15:21:03
どんな技術でも肯定も否定もできるんだ。
だからそんなことしても意味ないでしょ？
v6のあそこが悪いだのココがいいだの言い合っても。
建設的な意見で重要なのは互いが同意するか、
どうしないまでも落としどころを見付けることだと思う。
その前提として、キミの立場を聞いてるんだ。
答えたくないならそれでもいいけど。
32:anonymous
07/11/19 15:43:34
学生さん？
技術で飯食ってる人間は、技術的な議論に変な落としどころを
つけることがどんなに危険かよく知ってるからなあ。
口車でごまかそうとしても無駄だよ。
33: ◆6V8RpP7i3I
07/11/19 15:46:34
>>32 どう危険なんですか？
落としどころ付けないと仕事にならないんですが。
34:anonymous
07/11/19 16:03:39
> 落としどころ付けないと仕事にならないんですが。
v4.6みたいな腐った仕様を導入すると
ネットワークインフラそのものが崩壊しかねない。
35: ◆6V8RpP7i3I
07/11/19 16:07:03
>>34 じゃあキミは何がベストな方法だと思うの？
アドレスの枯渇って問題に対して。
36:anonymous
07/11/19 16:21:22
あんたの術中にハマるほど頭悪くないよ。
相手してくれる人が出てくるといいね。
37: ◆6V8RpP7i3I
07/11/19 16:31:32
なんだよ術中ってｗ
38:anno
07/11/19 16:38:38
「あんたの術中にハマるほど頭悪くないよ。」って書いちゃうぐらいには、
頭が悪いってことだな。
39:anonymous
07/11/19 22:39:41
建設的な意見： v4.6でバカが考えたアホ仕様だから、そんなの議論するよりNAT使いつづけるかv6使うか議論した方が時間が有効に使える。従ってｽﾚ終了。
40: ◆6V8RpP7i3I
07/11/19 22:45:48
>>39 お母さんが見たら泣くような書き込みですね
41:anonymous@64.34.204.165
07/11/19 23:48:20
フシアナも出来ないヘタレが何か言ってるぜｗｗｗｗ
42:anonymous@tcatgi064005.adsl.ppp.infoweb.ne.jp
07/11/20 00:19:47
えらいねー
えらいねー
43:anonymous
07/11/20 00:45:11
>>31
スレ違い。
ここはIPv4.6スレです。IPv6の話をしたいならよそでやってください。
44:anonymous
07/11/20 00:45:18
フシアナできる人は根性あるからきっと実名で書いてくれるんだろうなー
フシアナもできない俺のようなヘタレとは違って当然すぐ実名出してくれるよなきっと
45: ◆6V8RpP7i3I
07/11/20 01:38:52
隔離スレにまで出しゃばってくるなんて、よっぽど寂しいんだね
46:anonymous
07/11/20 20:39:43
◆6V8RpP7i3I 涙目
47:anonymous
07/11/21 13:59:15
>>5 >>6 >>7 ＆ >>15
IPv4.6 は、サーバ側が対応していなければ動かない
NAT は、サーバ側が対応していなくても動く（ように作られている）
目的違うんでしょうが、NATの再発明にもなってないです。
IPv4.6 は、IPv4の後継として、アドレス空間を広げること を目的としている。
IPv6 との違いは、移行のしやすさ である。 IPv4.6は、IPv4の上位互換として
機能し、IPv4のアドレス空間を広げるが、同時にIPv4.6未対応のIPv4機器に
対しては、IPv4互換として動作するため(※)、IPv4機器との接続性を維持した
まま、容易にIPv4.6へと移行できる。
…のつもりで発案されたようですが、互換性を維持できておらず、実際は
サーバ側の対応が必須になっています。よって存在意義はありません。
それ(※)が理解できないようで「勉強してこい」と叩かれたと思います。
48: ◆6V8RpP7i3I
07/11/21 19:53:05
互換性は維持できるし、もちろんv4.6を使おうとするとサーバ側の対応は必要だけど、
必要な部分から移行できるので、それが最大のメリット。
49:anonymous
07/11/21 20:49:25
パケットの形だけが同じであることを「互換」とは言わない。
実際、v4のままv4.6が利用できる要素はひとつもない。
50: ◆6V8RpP7i3I
07/11/21 20:58:19
>>49 v4がv4.6に互換なんじゃなくてv4.6がv4に互換なんだよ。わかる？
AMD64に対応したプロセッサでもx86のコード動くでしょ？
親の育て方が悪いとバカになるんだな。
51:anonymous
07/11/21 21:08:25
◆6V8RpP7i3I が
> 親の育て方が悪いとバカになるんだな。
というようなセリフを吐くような奴だということはわかった
52: ◆6V8RpP7i3I
07/11/21 21:18:53
>>51 知能障害起こしちゃったｗ 技術論で言い返して来いよ。
お前の母さん、昨日腰振ってたぞ
53:51
07/11/21 21:44:34
俺、>>51 以前にこっちのスレには何も書いてないんだが...
◆6V8RpP7i3I が
> 知能障害起こしちゃったｗ
とか
> お前の母さん、昨日腰振ってたぞ
とか
そういうレスを書くような奴だということはわかった
母はゾンビになったらしい。困ったものだ
54: ◆6V8RpP7i3I
07/11/21 21:49:38
俺の人間性はわからなくていいから、自分がバカだってことをわかれよｗｗｗｗ
55:anonymous
07/11/21 22:00:42
アプリ的な話なら、IPv6だってIPv4互換だよなぁｗ
IPv6に対応したアプリなら黙ってたってIPv4で動くｗ
56: ◆6V8RpP7i3I
07/11/21 22:04:00
>>55 うごかねえよｗｗｗ
そもそもアドレスの表記からして違うｗｗｗ
57:anonymous
07/11/21 22:05:57
ぽか～ん
58: ◆6V8RpP7i3I
07/11/21 22:08:38
>> というようなセリフを吐くような奴だということはわかった
>> 母はゾンビになったらしい。困ったものだ
>> ぽか～ん
まともな反論ができないってことはわかったｗｗｗｗ
59:anonymous
07/11/21 22:12:12
ぽか～ん
60:anonymous
07/11/21 22:14:52
いいから騙されたと思って、dual stackのマシンで、IPv6のサーバ
プログラム、AF_INET6つかったの簡単なの動かしてみろよ。
そんで、IPv4でつないでみろ。
61:anno
07/11/21 22:15:18
◆6V8RpP7i3Iが頭いいとは思わんけど、
anonymousは頭悪いな
62:anonymous
07/11/21 22:16:05
ぽか～ん
63: ◆6V8RpP7i3I
07/11/21 22:22:46
>>60
騙されるわけねーだろ、(ﾟдﾟ)ﾊﾞｰｶ
まともな反論してみろよｗｗｗ
64: ◆6V8RpP7i3I
07/11/21 22:22:49
おまえらこのページ見てみろよ！
URLﾘﾝｸ(www.ie.u-ryukyu.ac.jp)
俺が勉強不足でサーセンｗｗｗｗｗ
65:anonymous
07/11/21 22:25:22
ちょｗｗ 何この流れｗｗｗ
66:anonymous
07/11/21 23:06:20
>>50
> >>49 v4がv4.6に互換なんじゃなくてv4.6がv4に互換なんだよ。わかる？
で？
それになんの意味があるの？
67: ◆6V8RpP7i3I
07/11/21 23:12:20
>>66 ぽか～ん
68:anonymous
07/11/21 23:46:56
58 ： ◆6V8RpP7i3I ：sage ：2007/11/21(水) 22:08:38 ID:???
まともな反論ができないってことはわかったｗｗｗｗ
69: ◆6V8RpP7i3I
07/11/22 00:14:13
>>66 >>49の間違いを正したんだが。
70:anonymous
07/11/22 00:35:09
v4.6がv4に互換であることになんの意味があるの？
71:47
07/11/22 00:40:57
47 = 4 です。
>> 48 互換性は維持できるし (以下省略)
別の書き方をします。
拡張アドレス部分は、TCPのオプションを使うことになっていたはずですよね？
TCPオプションは、相互で違っていてもかまわないものなので、IPv4しか
しらないサーバからの応答に、拡張アドレスオプションは維持されません（よね？）
よって、IPv4.6からの発信は、IPv4ノードに届くかもしれませんが(※)、
応答は、発信元のIPv4.6ノードまで到達できません。(拡張アドレスが失われるので)
上位互換性が無いので、部分的な置き換えはできないと思います。
参考 ⇒ URLﾘﾝｸ(www.atmarkit.co.jp)
※未知のTCPオプションを弾くFireWallやルータが、居るかもしれない。
72: ◆6V8RpP7i3I
07/11/22 00:41:09
>>70 既存のv4インフラを何ら変更することなく、
アドレス拡張が出来る。
73: ◆6V8RpP7i3I
07/11/22 00:44:13
>>71 もちろんです。v4.6で通信するには、
双方がv4.6に対応していなくてはいけません。
片方が対応してない場合、その通信はv4と同じになります。
74:anonymous
07/11/22 00:48:25
>>73
v4.6 to v4.6でも途中のルータがオプションの中身を捨てることがあるって話をしてるのがわかんないのかなぁ。
75: ◆6V8RpP7i3I
07/11/22 00:49:28
>>74 勝手に捨てちゃ駄目でしょ。仕様なんだから。
76:anno
07/11/22 00:51:58
>>74 そんな実装見たこと無いけどな
また平気で嘘をつく。。。。
>>中身を捨てることがある
ソースきぼんぬ
77:anonymous
07/11/22 00:55:15
>>75
規定されていないオプションを継承しないといけないなんて仕様はないと思うけど。
78: ◆6V8RpP7i3I
07/11/22 00:56:50
オプションとして規定されてるんだか継承しなきゃいかんだろ。
それにヘッダサイズはどうすんだよ。
79:anonymous
07/11/22 00:57:38
>>78
全部NO-OPにするかもしれないよ？
80: ◆6V8RpP7i3I
07/11/22 00:59:39
否定のための妄想は止めないか？
「かもしれない」って全部妄想じゃん。
81:anonymous
07/11/22 01:01:11
>>78
v4.6拡張アドレスは現状オプションとして規定されていないでしょ？
82:anonymous
07/11/22 01:03:23
>>80
そういう実装があっても何ら仕様に違反しないわけだが。
そういうルータを途中で一個でも挟んだだけでおじゃん。
83: ◆6V8RpP7i3I
07/11/22 01:04:15
>>81 拡張領域だから何入れても良いんだよ。
実際暗号に使う情報入れれるし。
84: ◆6V8RpP7i3I
07/11/22 01:05:06
>>82 じゃあ仕様に準してないそのルータが悪いよ。
85:anonymous
07/11/22 01:07:46
>>84
仕様は満たしているよ。
86:anonymous
07/11/22 01:09:35
>>83
その「暗号に使う情報」を通さないルータはあるかもね。
87: ◆6V8RpP7i3I
07/11/22 01:09:46
>>85 パケットの拡張領域を勝手に削除するのがv4の仕様なのか？
88:anno
07/11/22 01:13:39
なんかすごいこと言い始めたな。
無知ってこわい
89:anonymous@fw.sarasarado.org
07/11/22 01:16:19
未知のオプション情報ごと中継しないといえないという仕様は無いよ。
もちろん中継してもいい。
あんまり変な情報を詰め込むと、オプション情報の最大サイズを
決めうちにしているネットワークスタックとか困ったことになると
思うけどなぁ。
90:47
07/11/22 01:16:46
>>73 片方が対応してない場合、その通信はv4と同じになります。
同じIPv4アドレスを共有している、複数のIPv4.6ノードを特定できない(よね？)
といっています。
>>74 >>76
私はそっち系ではないので、でっかい高いルータは知りません。
経路によっては、MSSの解釈と書き換え はあるはず。(想像です)
解釈できない未知のオプションは、普通なら維持するでしょうが、
誤動作するヤツがいても不思議はないと思います。(これも想像)
FireWallについても想像ですが、解釈できないとか、なにかが普通と
違うパケットを、独自の基準で選別して、通過させない製品があります。
どんな基準で実装がされているのやら、まったく判りませんが、
既存のものと違うわけですから、通過できない可能性はあると思います。
これらは、いずれも想像ですので「居るかもしれない」と書いています。
91: ◆6V8RpP7i3I
07/11/22 01:17:12
>>89 IPsecって知ってる？
92: ◆6V8RpP7i3I
07/11/22 01:19:25
>>90 はいできません。
>>90 IPSecって知ってる？
93:anno
07/11/22 01:20:03
俺も言わしてくれ。IPSecって知ってる？
94:anonymous@fw.sarasarado.org
07/11/22 01:21:49
通らないルータがあるかもしれませんね＜IPsec
95:anonymous
07/11/22 01:22:01
知ってるよ！バカにするな。知らない奴はミジンコｗｗｗｗ
96: ◆6V8RpP7i3I
07/11/22 01:23:04
>>94 飛ばない飛行機もあるかもしれんが、
それは飛行機とは呼べませんな。
97: ◆6V8RpP7i3I
07/11/22 01:24:53
IPsecもヘッダの拡張領域を利用しているわけだが、
IPsecが通らないルータがv4.6を通さないのは仕方がない。
だってそのルータが仕様を満たしてないんだもん。
98:anno
07/11/22 01:27:14
>>94 詭弁のガイドライン
2.ごくまれな反例をとりあげる
99: ◆6V8RpP7i3I
07/11/22 01:28:29
いま一生懸命IPsecをぐぐってるんだろうなあ
100: ◆6V8RpP7i3I
07/11/22 01:33:52
ぐぐり終わって涙目？もう書き込めない？ｗｗｗｗ
101:47
07/11/22 01:47:14
>>92
同じIPv4アドレスを共有している、複数のIPv4.6ノードを特定できないと、
「片方が対応してない場合、その通信はv4と同じになります」という動きが
できないんですが、それも了解ですか？
>>92 IPsecって知ってる？
質問の意図を量りかねますが。いちおう知っています。
IPsecは、私の勘違いでなければ、IPのペイロードにAHヘッダー積んで、
その後にTCPつけてとか、IPのペイロードにESP積んで … というヤツで、
IPヘッダは、AHとかESPの前で完結していたはずですけど？
>>94
それは無いと思うけど。通らなかったら不具合だわ。
102: ◆6V8RpP7i3I
07/11/22 01:52:53
>>101 はい了解です。
あなたは勘違いしています。IPsecのヘッダはパケットのペイロードではなく、
拡張領域に格納されます。
103:47
07/11/22 01:53:46
>> 97
それは間違い。
確証が無かったので、ぐぐってきました。
URLﾘﾝｸ(hccweb1.bai.ne.jp)
ここの画像のバイナリ部分に注目。
先頭14バイトがEthernet Header で、DST/SRC/TYPE
次の20バイトがIP Header で、IPv4/HLENは 4Byteｘ5
次の0x0022からがESPヘッダーで、最初はSPI値(0x3c760edf)
ESPヘッダは、IPヘッダの次にあって、IPヘッダの中ではないです。
104: ◆6V8RpP7i3I
07/11/22 02:04:17
>>103 はふぃ。君は拡張領域はペイロードの前にあるから、
IPヘッダの次と勘違いしてるようだけど、
拡張領域も含めてIPヘッダだし、ESPヘッダは拡張領域に納められるから、
この画像で間違いないよ
105:47
07/11/22 02:15:03
>>104
解りやすそうなページを探してきた。このページの説明でいくと…
URLﾘﾝｸ(opentechpress.jp)
ihl(IPヘッダ長)は、オプション領域まで含めたヘッダ長 であり、
ihl＝５は、オプションなし を意味する。だと思うんですが？
了解でしょうか？
＃ だいぶんスレ違いだな
106: ◆6V8RpP7i3I
07/11/22 02:17:49
>>105 了解です
107: ◆6V8RpP7i3I
07/11/22 02:24:58
あああああああああ、りょうかいじゃねえよ
ihl=5て5バイトしか無いってことじゃん。
ばかかおまえ
108:47
07/11/22 02:42:58
>>107
IPv4ヘッダのレングス部分は４ビットしかないので、４で割った値を書きます。
パディングして４の倍数長にするのはそのためです。
> 次の20バイトがIP Header で、IPv4/HLENは 4Byteｘ5
了解ですか？
109: ◆6V8RpP7i3I
07/11/22 03:08:17
>>了解です。
ihi=6なら、24バイトがIPヘッダになりますが。
110:anonymous
07/11/22 06:44:02
v4.6パケットをそのまま通せないv4ルータがあるかどうかは重要な議論ではない。
v4ルータはどのみちv4.6パケットを正しくルーティングできない。
こっちのがよっぽど重要だろ。
111:sage
07/11/22 07:04:49
ARPをいじくる必要あるね。
112:anonymous
07/11/22 07:11:15
v4.6はNAT以下だな
やはりバカプロトコル
113: ◆6V8RpP7i3I
07/11/22 13:02:44
>>110 v4ルータはv4.6パケットをルーティングできないけど、
v4パケットとしてはルーティングできるし、
そこがいちばん肝なんだけど。
114:anonymous
07/11/22 13:06:36
間違ったルーティングに何の意味が？
115: ◆6V8RpP7i3I
07/11/22 13:26:44
>>114 間違ったルーティングって具体的に？
116: ◆6V8RpP7i3I
07/11/22 13:52:22
>>114 キミたち否定のための議論だからバカっぽいんだよねｗｗｗｗ
117:anonymous
07/11/22 13:54:42
まさかv4の範囲内でしかルーティングしないなんて言わないよな？
118: ◆6V8RpP7i3I
07/11/22 13:59:32
ロカールアドレスでもルーティングしますが。
119:anonymous
07/11/22 14:01:08
何でここでローカルアドレスが出てくるんだ？
頭大丈夫か？
120: ◆6V8RpP7i3I
07/11/22 14:27:30
v4.6の基本概念は、拡張領域にローカルアドレスを入れようって話なんですが。
121:anonymous
07/11/22 14:45:54
IPv4アドレスのないとこで使えないじゃん。
それでいいならNAT使うだろ。
122: ◆6V8RpP7i3I
07/11/22 14:49:36
v4.6はNAPT「も」使えます。
123:anonymous
07/11/22 14:53:57
つまり、最初からv4.6は不要。
124: ◆6V8RpP7i3I
07/11/22 14:56:33
ポート番号ではルーティングできませんね。
125:anonymous
07/11/22 14:57:32
能書きはいいんでどこかに実装はない？
126:anonymous
07/11/22 14:59:26
v4ルータはv4.6の拡張部分をルーティングできないんだろ？
なら同じことだ。
127:anonymous
07/11/22 15:00:04
つか、NATSでいいやん
128:anonymous
07/11/22 15:04:56
NATSというよりはnutsだな。
129: ◆6V8RpP7i3I
07/11/22 15:06:18
>>126 v4ルータはv6パケットをルーティングできませんが。
>>127 ええ、NATSでもいいと思います。
v6の議論は足踏み状態だと思うのです。
このスレは第三の方法を議論するところですね。
130:anonymous
07/11/22 15:10:24
現在ある技術よりも劣ったものを議論してどうするのかと。
131: ◆6V8RpP7i3I
07/11/22 15:17:23
v6がふがいないからですね。
132:anonymous
07/11/22 15:20:18
>>131
だから能書きはいいんで、実装は？
机上の議論だけでいい所を喧伝するなんて今のv6以下
133: ◆6V8RpP7i3I
07/11/22 15:26:14
>>132 実装するのが面倒だから実装しません。普及しないもの実装しても時間の無駄じゃん。
別にこのスレでv4.6を普及させよう。なんて思ってません。
でもv6本スレの議論ループよりましだと思います。
この議論によってv6が普及するかもしれないし。
134:anonymous
07/11/22 15:35:57
なるほど、すべてを理解した。
こいつ頭が悪いんじゃなくて
頭がおかしいんだな。
135: ◆6V8RpP7i3I
07/11/22 15:38:25
だから隔離スレなんだね。その隔離スレに乗り込んでくるキミはもっと頭おかしいね
136:anno
07/11/22 15:39:55
本スレも >>134 ばかりな池沼ばかりで、
全然技術論が話し合われないものな。
頭が悪いとかおかしいとか言い合って、
それでネットワーク環境が良くなるのかと。
137:anonymous
07/11/22 15:42:27
技術の知識なくてサーセンｗｗｗｗｗ
ただ頭がいい奴をバカにしたいだけﾌﾟｹﾞﾗｗｗｗｗ
138: ◆6V8RpP7i3I
07/11/22 15:47:25
>>137 そんなのわかてるよ。通信技術板で技術の話してるのに、
「お前頭おかしいな」なんて発言は、
「私は技術の知識がないのに構って欲しいんです」っておでこに書いてるようなものだし。
どうして頭がおかしいのか理由を述べないとテストでも０点だね
139:47
07/11/22 16:04:29
>>109
では、IPsec仕様を勘違いしたままあなたが展開した論理や皮肉は、
全て間違いであった。ということを認めてくださいね。
>>118
できません。
文脈では、IPv4.6非対応のルータが正しくルーティングできるか？
という議論のはずです。
>>110
そのとおりです。同じIPアドレスを共用するIPv4.6ノード間の通信は、
IPv4のみ対応のルータを経由しては成立しません。
しかし…(次レスに関連)
140: ◆6V8RpP7i3I
07/11/22 16:06:13
>>139 IPsecの仕様に関して僕の間違いとはなんですか？
141:47
07/11/22 16:06:48
>>111
そうですね。ARPをいぢくって 同じIPアドレスを共用するIPv4.6ノードの
代表者が、マルチキャストの物理アドレスを伴うARP応答をする みたいな
トリッキーな動きをすれば、ENDノード側直近のルータが、IPv4のみ対応
であっても、動作する可能性はありますね。
もっとも、これだと IPv4 NAT と同じ利用形態となり、かつ サーバ側の
IPv4.6対応が必須なわけですから、NAT以下の互換性となるわけですが。
>>141 >>123
そのとおりなんですが、サーバ側の対応が必須ですから、NATの代わりに
すら なりません。 お分かりかと思うのですが、NAT置き換えできる能力
すら ない ってことを強調させていただきました。
142: ◆6V8RpP7i3I
07/11/22 16:08:22
面倒だけど丁寧に相手しましょう。
>>139 の二番目
はい、v4ルータはv4.6のパケットをv4パケットとして正しくルーティングできますが、
v4.6パケットとしてはルーティングできません。
>>139 の三番目
はい、その通りです。
143: ◆6V8RpP7i3I
07/11/22 16:09:08
>>47 の中の人が変わってるなｗ
144:47
07/11/22 16:10:10
>>124
NATはNAT BOXのENDノード側のプライベートアドレスを特定するために、
ポート番号を使いますが、経路途中のIPv4ルータが、ポート番号で
ルーティングするような必要性は、ありません。
>>129
IPv4.6 が、IPv6のアンチテーゼとして、IPv4との互換性を維持したアドレス
拡張として考案されたのであれば、当然のこととしてIPv4ルータでも、
ルーティングできることが期待されます。（限定的には可能かもしれないが）
ともかく、IPv6のルーティング可否との比較は、意味がありません。
145: ◆6V8RpP7i3I
07/11/22 16:10:26
今日の>>47のひとはNATが好きなんだなー。
別にそれでもいいと思うよ。
146:anonymous
07/11/22 16:12:50
#iijの中の人もややこしいから識別子つけてくれる？
147:anonymous
07/11/22 16:13:38
>>145
なんつーかな、技術的な話に完結したいのか罵しり合いがやりたいのかはっきりしろ
148: ◆6V8RpP7i3I
07/11/22 16:14:21
>>144 v4.6のNAPTと比べての優位点は、単純にIPアドレスで外側からアクセスできることです。
NAPTの場合、例えばWinnyでP2Pしたい場合、ルータでポートフォワードの設定をして、
かつそのポート番号を相手に知らせなければなりません。
しかしv4.6同士の場合はその必要がありません。
>>当然のこととしてIPv4ルータでも、ルーティングできることが期待されます。
v4のパケットとしてはルーティングできますよ。互換なのだから。
149: ◆6V8RpP7i3I
07/11/22 16:15:29
別に誰が書こうと関係ないでしょ。書き込み内容で判断すれば。
150:anonymous
07/11/22 16:18:58
>もっとも、これだと IPv4 NAT と同じ利用形態となり、かつ サーバ側の
>IPv4.6対応が必須なわけですから、NAT以下の互換性となるわけですが。
どうやらあんたの頭はマトモのようだ。
NATと同様のステートを後付けで入れる拡張は今更意味がない。
151:anonymous
07/11/22 16:20:44
>>150 自作自演乙 (*>`艸<)ッ
152: ◆6V8RpP7i3I
07/11/22 16:21:37
>>150 ルータへのポートフォワードの設定は誰がするの？
153:anonymous
07/11/22 16:26:04
>v4.6のNAPTと比べての優位点は、単純にIPアドレスで外側からアクセスできることです。
それ、port forwardの設定をv4.6のアドレスに言い換えてるだけだから。
>ルータへのポートフォワードの設定は誰がするの？
v4.6のアドレスの設定は誰がするの？
154: ◆6V8RpP7i3I
07/11/22 16:30:09
>>153 うんごめんね。あなたのいうとおりだ。
完全敗北です。半年間ＲＯＭります。すみませんでした。
155:anonymous
07/11/22 16:33:33
当初からトリップ割れしていたから、こうなるオチは
見えていたがgdgdだな
156:anonymous
07/11/22 16:34:55
以上、すべて俺様の自演でお送りしました。
ってことにすればいいのか？
157: ◆6V8RpP7i3I
07/11/22 16:36:45
>>153 NATだとNATの内側でhttpdが立てられないと思うよ
158: ◆6V8RpP7i3I
07/11/22 16:37:20
httpdにかぎらず、1023以下のポートを使うサーバだけど
でもv4.6ならできるな。
159:anonymous
07/11/22 16:37:32
>>157
ズコー
160: ◆6V8RpP7i3I
07/11/22 16:38:31
>>153 v4.6ではパケットにソースアドレスが入ってるから、
誰かが設定しなきゃいけない。ってことはないです。
161:anonymous
07/11/22 16:39:09
ていうかおれんちでは普通にNATの内側で
グローバルアクセス可能なhttpdを
運用しているわけだが
162:anonymous
07/11/22 16:40:20
>>160
おまえの出番は終わったよ。
163: ◆6V8RpP7i3I
07/11/22 16:41:51
>>161 2台置きたいときはどうするの？
164: ◆6V8RpP7i3I
07/11/22 16:42:27
>>161 はDMZ設定してるだけだろうなー
165:anonymous
07/11/22 16:44:40
>>163
load balanceでもするのか？
166: ◆6V8RpP7i3I
07/11/22 16:45:37
>>165 2台置けないとアドレス拡張の意味内じゃん
167: ◆6V8RpP7i3I
07/11/22 16:46:30
>>161 は自分家でサーバ立てて気取ってる程度ってことだよ
168: ◆6V8RpP7i3I
07/11/22 16:51:01
ポートフォワーディングだとポート番号が決まっているアプリケーションだと、
そのNATの内側にひとつのアプリケーションしか立ち上げられないね。
169:anonymous
07/11/22 16:54:22
>>168
具体的には何？
170: ◆6V8RpP7i3I
07/11/22 16:55:43
うぇるのーんぽーとを使うアプリケーション
171: ◆6V8RpP7i3I
07/11/22 16:58:41
SSTPとか
172:anonymous
07/11/22 17:06:09
>>170
それらのアプリケーションはURIなどのスキームでポート指定ができないの？
173: ◆6V8RpP7i3I
07/11/22 17:17:42
わざわざ
URLﾘﾝｸ(111.111.111.111:80)
URLﾘﾝｸ(111.111.111.111:33822)
とかしていしなきゃいけないなんて。。。。。。。。。。。。
174:47
07/11/22 17:20:26
>>145
変わってないし、別にNAT好きでもないが、NATは普通に使っています。
きみが発案の過程で、IPv4.6非対応のノードとは、IPv4として通信できるうんぬんと、
IPv4との互換性を強調していなければ、NATとの対比は出てこなかったと思います。
代わりに、各種トンネル技術やら xx over IPv4 との対比をされて、
存在意義を否定されたでしょう。。。ガイシュツだったような気もしますね。
175:47
07/11/22 17:23:07
>>140
めんどうですが、ピックアップしましょうか。。
>>83 (?) >>97,99,100,102,104
了解でしょうか？
>>140 >>142
それを希望されているようでしたので、技術面から、まともに反論してるのですが。
同意頂けるのは在りがたいですが、論破されていることが認識できないのは、
ちょっと切ないですね。 さすがにちょっと疲れました。(^^;
176: ◆6V8RpP7i3I
07/11/22 17:23:19
>>174 IPsecの仕様に関して僕の間違いとはなんですか？
177: ◆6V8RpP7i3I
07/11/22 17:25:27
了解でしょうか？って聞かれて反論してるっていうのもなー
178: ◆6V8RpP7i3I
07/11/22 17:27:57
>>175 IPsecの情報はIPヘッダに入ってないとかいいたいのかな、こいつ
179:anno
07/11/22 17:31:21
◆6V8RpP7i3IのIPsecの解釈はおかしくないと思うが。。
180:anonymous
07/11/22 17:45:58
>>173
たったそれだけでNATが使い続けられるなら非常に安価な対応コストだと思うが
SRVを使う手もある
机上の空論で済ませるつもりらしいが、それにしても
他の案とくらべてメリットが薄い
181:anno
07/11/22 17:50:07
>>180 URIで指定できないSMTPとかどうするのか。の問題について。
182:anonymous
07/11/22 17:58:34
>>181
SRV
183: ◆6V8RpP7i3I
07/11/22 18:05:30
>>182 なんかDNSに依存するのはやだな。。
これは個人的な好き嫌いだけど。
184:anonymous
07/11/22 18:08:12
>>183
エンドノードのスタックを書き替えないと恩恵にあずかれない頭の弱い方式よりも
ずっとスマートだと思うが
185: ◆6V8RpP7i3I
07/11/22 18:11:34
>>184 v4.6はスタック書き換えれば済むけど、
SRVは全ネットアプリケーション書き換えなきゃな。。
186:anonymous
07/11/22 18:12:47
>エンドノードのスタックを書き替えないと恩恵にあずかれない頭の弱い方式よりも
>ずっとスマートだと思うが
なおかつスタックを書き替えてもたいして嬉しくないことも判明しているしなあ。
187:anonymous
07/11/22 18:16:42
>>185
スタックの再実装とDNSの書き替えのどちらが安いかの判断もできないぐらい馬鹿なの？
188: ◆6V8RpP7i3I
07/11/22 18:18:45
>>187 SRVはDNSの書き換えだけで済まないでしょ。
アプリケーションの対応が必要だお
189: ◆6V8RpP7i3I
07/11/22 18:20:39
>>187 バカはどっちか身を挺して表現しちゃったなｗｗｗｗっｗ
190:anonymous
07/11/22 18:21:18
>>188
SRVへの対応は一部のアプリですでに完了している
v4.6はアプリ全書き換えが必要だろこの池沼
191: ◆6V8RpP7i3I
07/11/22 18:24:21
>>190 一部完了してます！って自慢げにいわれてもなあ。
v4.6は初期の段階ではアプリケーションの対応はいらないお
ルータが対応すればいいだけ
192:anonymous
07/11/22 18:25:32
>>191
おまえネットワーク知らないだろ
193: ◆6V8RpP7i3I
07/11/22 18:29:02
>>192 だからさ、俺がネットワークを知らないと思う、
お前の根拠も書けよ。
194:anonymous
07/11/22 18:31:25
>>191
Sendmailとかは対応済みだしな
恩恵にあずかりたいアプリだけが対応すればよくて、未対応のアプリは
既存のポートでサービスすればいい
195:anonymous
07/11/22 18:32:13
>>193
どの程度SRVが使われているか知らない点
196:anonymous
07/11/22 18:33:04
> お前の根拠も書けよ。
あんたが自分で書いてるじゃん。
197: ◆6V8RpP7i3I
07/11/22 18:34:09
>>194 まあそれもそうだね。
だけどDNSを勝手にいじれないクライアント環境とか、
DNSの遅延とか考えると、使い勝手は悪そう。
あくまでも個人的な意見だが。
198: ◆6V8RpP7i3I
07/11/22 18:34:45
>>195 どれくらいつかわれてるの？
199: ◆6V8RpP7i3I
07/11/22 18:36:34
>>196 どこに？
200:anonymous
07/11/22 18:37:20
>>197
NATの裏からサービス提供しようって話なのにDNSが触れない環境とか
どんだけ無理な条件設定だよ
もうお前は口を開くだけ馬鹿を晒すから黙ってた方がいいよ
201:anonymous
07/11/22 18:37:25
>>197
超絶的に頭悪そうな意見だな
202: ◆6V8RpP7i3I
07/11/22 18:38:34
お前らってさ、「俺のすごさは月の裏に置いてあるノートに全部書いてあるぜ！」
って、全然根拠示せてないんだよね。
「こういう統計があるのでSRVはこれだけ使われています」とか
「あなたのこの書き込みが矛盾しているので、あなたはネットワークのこと理解していませんね」とか
書けないのかね。
203:anno
07/11/22 18:40:25
詭弁のガイドライン
>>195 5.資料を示さず持論が支持されていると思わせる
>>201 9.自分の見解を述べずに人格批判をする
204: ◆6V8RpP7i3I
07/11/22 18:42:13
>>200 NATの裏からサービスを提供することと、
DNSが触れない環境になんら相関関係がないと思うけど。
205:anonymous
07/11/22 18:44:03
＞＞２００ お前の方から隔離スレにきておいて、
俺様に黙ってろってなにごとだ！
俺がだまってたら、このスレに誰がかきこみするんだよ！
206:anonymous
07/11/22 18:44:12
> >>200 NATの裏からサービスを提供することと、
> DNSが触れない環境になんら相関関係がないと思うけど。
ねえ、本当にそう思ってるのか？
207: ◆6V8RpP7i3I
07/11/22 18:46:40
ディズニーランドに来ておいて、ミッキーに「あっち池」っていうようなものだしねｗｗ
>>200の父さん土方なんだってな
208: ◆6V8RpP7i3I
07/11/22 18:47:13
>>206 思ってるよ。無駄に聞き返すなよ。はげ
209:anonymous
07/11/22 18:49:33
詭弁のガイドライン
>だけどDNSを勝手にいじれないクライアント環境とか、
6.一見、関係がありそうで関係のない話を始める
>DNSの遅延とか考えると、使い勝手は悪そう。
6.一見、関係がありそうで関係のない話を始める
4.主観で決め付ける
210: ◆6V8RpP7i3I
07/11/22 18:50:28
あくまでも個人的な意見だが。
って断ってるからな。
211: ◆6V8RpP7i3I
07/11/22 18:51:00
キミらさ、なんで俺の相手してるの？
212:anonymous
07/11/22 18:53:16
>>197
>だけどDNSを勝手にいじれないクライアント環境とか、
どの文脈でクライアント環境ってのが出てきたの？
213:anonymous
07/11/22 18:53:35
> キミらさ、なんで俺の相手してるの？
いけぬまが隔離スレから出てこないように
生殺しをキープ
214:anonymous
07/11/22 18:54:34
>>212
こいつの脳内はいろんなキーワードが
ランダムに出てくるようになってる。
なかなか便利だな。
215: ◆6V8RpP7i3I
07/11/22 18:55:34
>>213 だったら>>200になんとか言ってやってくれ
216:anonymous
07/11/22 18:56:38
>>215
いや、俺がその200だから。
217: ◆6V8RpP7i3I
07/11/22 18:58:35
>>212 それは本当の#iijじゃなくて俺が書いたんだけど、
クライアント環境ってのは言葉が違った。ごめそ。
218: ◆6V8RpP7i3I
07/11/22 18:58:51
じゃあ黙ってる
219:anonymous
07/11/22 19:00:01
>>217
違っているのは言葉じゃなくておまえの理解だ。
220:anonymous
07/11/22 19:00:30
>>218
いや、黙るな。
221:47
07/11/22 20:28:17
>>185 >>190
IPv4.6対応するには、恐らくほとんどのアプリ書き換えが必要ですが、
もしかしたらIPv6対応のアプリは、スタック入れ替えだけで動くかもしれません。
sockaddr_storage 構造体を利用し、構造体の中身を直接操作しないプログラムなら、
その中身が sockaddr_in だろうが、sockaddr_in6 だろうが構わず動けるはずで、
だとすれば sockaddr_in46 (そんな定義はないけど) でも動けるはずだから。
ま、UI破綻するだろうし、極めて限定的な動作になることは、容易く想像できますがね。
222:anonymous
07/11/22 20:32:11
> もしかしたらIPv6対応のアプリは、スタック入れ替えだけで動くかもしれません。
正確にはaddress family independent socket programmingに従ってるソフトウェアは、
だな。
223:47
07/11/22 21:17:03
>>202
お前らの中に私も含まれるかと思うので、リクエストに応えてみます。
お題は >>191 について。
IPv4.6に対応するには、IPv4.6で拡張されたアドレスを取得したり、保持する能力が
必須ですが、IPv4用に用意されていた初期のSOCKET関数には、アドレス形式に依存し
ないプログラム開発ができる機能が十分に揃っていませんでしたので、そのような
アプリケーションは、極めて稀有であると言えましょう。(※)
※極めて限定的には可能だが、gethostbyname とか使ってる時点でNG。
224:47
07/11/22 21:19:36
つづき
したがって、IPv4用のアプリケーションの大多数は、アプリケーションの書き換えが
必要です。アプリケーションを特定せず、アプリ書き換え不要とする、あなたの主張
は、誤りであると断定できます。
この点において、あなたはネットワーク(※)のことを、理解していませんね。
※ま、ここではソケットプログラミングのことなんだが。
225:anonymous
07/11/22 21:37:35
まあもう真の#iijは来ないだろうけどな
226:47
07/11/22 21:37:51
>>222 そうです。フォローありがとう。
それにしても、んーー、残念だなぁ…
227:anonymous
07/11/22 21:57:23
それにしても inet_ntop では protocol independent に書けない点について
228:itojun3
07/11/22 21:57:26
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によって補われる。
229:47
07/11/22 22:02:21
idがでないって便利だな
230:anonymous
07/11/22 22:08:47
>>228
4でさ、clientBはどのIPv4アドレスからパケットが届いたように見えるの？
231:47
07/11/22 22:11:44
router Bにきまってるわと予想
232:anonymous
07/11/22 22:16:28
見てたら source routing option 思い出したｗｗｗｗ
ところで、v6 の hop-by-hop option header って ISP にフィルタされないのかね・・・・？
DoS vulnerable と言われてたような気がするんだが
233:anonymous
07/11/22 22:21:19
>>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が返る訳ね。
なるほどなるほど。
234:47
07/11/22 22:34:29
>>223-224 の47、何とか言えよ
235:anonymous
07/11/22 22:42:53
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と何が違うん？
236:47
07/11/22 22:44:16
>>229 芸風で識別してくださいな。(^^;
>>231 や、ROUTER Aのエンドノード側でしょう？
>>233 UDPも考えてみると楽しいですよ。
237:anonymous
07/11/22 22:50:51
>>235 NATと変わらないからいいんとちゃうん
238:47
07/11/22 22:52:47
>>235
client Aが、IPv4.6対応である というところ。
NATでは、client Aは IPv4でかまいません。
実装がなく、可能なことが証明されていないってところも違いますね。
239:anonymous
07/11/22 22:57:02
(global)(global)とか書くと面白いことができちゃいそうだな
240:47
07/11/22 23:25:30
>>227
極めて限定的 の説明が必要でしたでしょうか？
特定のポートをLISTEN/ACCEPTするだけのサーバアプリケーションでしたら、
見かけ上 IPv4 を偽装するSOCKET関数をもつ 機能拡張されたプロトコルスタックの
実装は可能です。 が、ご指摘の件含めて ざる なので、意味なしですね。
偽者さんも出てきたようなので、以降は anonymous でいきます。(^^ゝ
241:14
07/11/22 23:58:30
>>18
ルーズソースルートは v4 の話だ。
私は、v4 でルーズソースルートを使わずに
v4.6 を使うべき理由があるのかを聞いたんだが?
そもそも v6 では、ルーズソースルートと呼ばず、
拡張ルーティングと呼ぶのを知らんのかね?
242:anonymous
07/11/23 01:17:16
だから最初から劣化NATと言われているのに。
243:anonymous
07/11/23 08:13:34
可能なかぎりポジティブに評価しようとは思うんだが、
どう探してもNATより優れている点がみつからない。
244:anonymous
07/11/23 13:04:38
漏れは結構いい感じに思けどなあ
245:anonymous
07/11/23 13:51:48
じゃあ実装して使ってみろよ。
246:hahiru
07/11/23 15:06:32
! .／ / 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::::/ ｼ ／ ／
247: ◆6V8RpP7i3I
07/12/10 02:46:08
URLﾘﾝｸ(www.iij.ad.jp)
漏れはこれに応募するお
248:anonymous@P061204000201.ppp.prin.ne.jp
08/02/07 18:05:38 OtdWoWWI
URLﾘﾝｸ(www.v6pc.jp)
サイトの情報が古すぎ。こいつらほんとにv6普及推進する
つもりあるんかね？
249:hoge
09/10/24 08:12:47
IPv6あげ