IPv6スレ ver3
>>816
- garlic.itojun.orgには/etc/faithd.confがない(ようだ)
- faithd(8)にはログとり機能があるけどdebug optionつけるか/etc/syslog.conf書かないと記録されない
- garlic.itojun.orgで使われている(らしい)faithd prefixはgoogleで検索すると2ページ出てきて、その両方ともIETF関係のmailing list
ということは最後の2ページの設定が残っているひとは使えます。ひー。
いずれにしても不正利用したやつが処罰されるだけだからいいか(よくない)。
>>817
確かにNAT-PTベースだとUDPも通りますが、UDP要るものってなにがありますか?
とりあえずTCPの有名どころport numberを通しておけばIETFでも文句でないのは実証済みです。
N+I Tokyo 2007のinternet cafeはIPv6 only Vista + translatorでした。
ftpみたいにpayload書き換えないといけないものはどっちにしても特殊な処理が必要です。
それからskypeみたいなのは何をどうだまくらかしてもIPv6できません。暗号化しすぎだし、payloadにIPv4アドレス埋まってるし。
>>818
どういう意味で"hacked"でしょか。それによるなあ。
みんながIPv6使いたくなっちゃいそうなことなら考えてみるかもしれませんが。
あ、ということで、この"itojun"というのは偽物かもしれない可能性がありますよ:-)
ログはひろゆきさんに聞いてね。
- garlic.itojun.orgには/etc/faithd.confがない(ようだ)
- faithd(8)にはログとり機能があるけどdebug optionつけるか/etc/syslog.conf書かないと記録されない
- garlic.itojun.orgで使われている(らしい)faithd prefixはgoogleで検索すると2ページ出てきて、その両方ともIETF関係のmailing list
ということは最後の2ページの設定が残っているひとは使えます。ひー。
いずれにしても不正利用したやつが処罰されるだけだからいいか(よくない)。
>>817
確かにNAT-PTベースだとUDPも通りますが、UDP要るものってなにがありますか?
とりあえずTCPの有名どころport numberを通しておけばIETFでも文句でないのは実証済みです。
N+I Tokyo 2007のinternet cafeはIPv6 only Vista + translatorでした。
ftpみたいにpayload書き換えないといけないものはどっちにしても特殊な処理が必要です。
それからskypeみたいなのは何をどうだまくらかしてもIPv6できません。暗号化しすぎだし、payloadにIPv4アドレス埋まってるし。
>>818
どういう意味で"hacked"でしょか。それによるなあ。
みんながIPv6使いたくなっちゃいそうなことなら考えてみるかもしれませんが。
あ、ということで、この"itojun"というのは偽物かもしれない可能性がありますよ:-)
ログはひろゆきさんに聞いてね。
|
|
|
おっと見逃し。multicastは正直専門じゃないんですが、確かmulticast sessionの設立のあたりが全滅なんじゃないかと。
それから、multicast対応入りのtranslatorのRFC/draftは出てますが実装はどうだろうなあ。
もし買う気があるひとがいたら調べておきます。適宜ぐぐってくれてもいいかも。
それから、multicast対応入りのtranslatorのRFC/draftは出てますが実装はどうだろうなあ。
もし買う気があるひとがいたら調べておきます。適宜ぐぐってくれてもいいかも。
>>819
＞- garlic.itojun.orgには/etc/faithd.confがない(ようだ)
これを書いているのが本人でないとすると
garlic.itojun.orgは既に侵入されて乗っ取られているのか！？
それにしてもfaithdのlogging機能の弱さは普及する上で問題だな
実運用を見越していない単なる実装不足なので実装追加で済む話ではあるが
＞- garlic.itojun.orgには/etc/faithd.confがない(ようだ)
これを書いているのが本人でないとすると
garlic.itojun.orgは既に侵入されて乗っ取られているのか！？
それにしてもfaithdのlogging機能の弱さは普及する上で問題だな
実運用を見越していない単なる実装不足なので実装追加で済む話ではあるが
>>821
NAT箱で全部のsession「できた」「消えた」ってlogとりますか?
実際とってるひとはみたことないですな。
faithd(8)は一応理論限界同時接続32K TCP sessionsくらいなんですが、
NATで例えるとこれIPv4アドレス空間どのくらいのサイズをカバーできますか?
でかい組織でNAT運用したことないんで。
ていうか「でかい組織でNAT運用」するわけないです。IPv6にさせますよ。
garlic.itojun.orgにitojun以外のアカウントがある可能性はありますね。
これの完全な答えがわかるのはgarlic.itojun.orgにアカウント持っていて、
/etc/master.passwd(またはそれっぽいもの)を見れるひとだけ、つまり[email protected]。
次に近い(これはよほどのことがない限りものすごく近い)答えをもっているのは
/etc/passwd(またはそれっぽいもの)を見れるひと、つまり一般ユーザ@garlic.itojun.org。
fingerdはあがってないぽいですぞ大旦那様。
NAT箱で全部のsession「できた」「消えた」ってlogとりますか?
実際とってるひとはみたことないですな。
faithd(8)は一応理論限界同時接続32K TCP sessionsくらいなんですが、
NATで例えるとこれIPv4アドレス空間どのくらいのサイズをカバーできますか?
でかい組織でNAT運用したことないんで。
ていうか「でかい組織でNAT運用」するわけないです。IPv6にさせますよ。
garlic.itojun.orgにitojun以外のアカウントがある可能性はありますね。
これの完全な答えがわかるのはgarlic.itojun.orgにアカウント持っていて、
/etc/master.passwd(またはそれっぽいもの)を見れるひとだけ、つまり[email protected]。
次に近い(これはよほどのことがない限りものすごく近い)答えをもっているのは
/etc/passwd(またはそれっぽいもの)を見れるひと、つまり一般ユーザ@garlic.itojun.org。
fingerdはあがってないぽいですぞ大旦那様。
IPv6使えるひとにはないしょでtranslator箱使うためのヒントをみつけるgoogleのkeyword教えましょうか?
確かめられるよ。
その前に閉めろって? いやだれかに先にみつけてみてほしいんですよ。ぐぐり力で。
確かめられるよ。
その前に閉めろって? いやだれかに先にみつけてみてほしいんですよ。ぐぐり力で。
>>825
またまたあんまり知らずに書きますね。
繰り返しになりますが、RTPにいく前がそもそも全滅なんではないかと。IPv4アドレス埋まってるから。
そしてIPv4 multicast addressからIPv6 multicast addressの間の関係を定義しないといけないし、
rendezvous pointとかをどうすんのかとかよくわからないし。
まあ大変なんですよこれが。
またまたあんまり知らずに書きますね。
繰り返しになりますが、RTPにいく前がそもそも全滅なんではないかと。IPv4アドレス埋まってるから。
そしてIPv4 multicast addressからIPv6 multicast addressの間の関係を定義しないといけないし、
rendezvous pointとかをどうすんのかとかよくわからないし。
まあ大変なんですよこれが。
youtubeで求職活動中のitojun氏が2chにも進出ですか？
撮影中に咳き込んだら、ちゃんとリテイクしてくださいね。
撮影中に咳き込んだら、ちゃんとリテイクしてくださいね。
>>826
老婆心ながら、RTPはユニキャストで普通に使われていますよ。
IP電話など1対1アプリもそうですし、個別ストリーミングでもユニキャストです。
マルチキャストの問題と混同はいけません。
従来ながらのテキストを主体とする通信はTCP対応だけでいいでしょうが、
これからのマルチメディア時代はそれだけでは不十分と断言できるでしょう。
老婆心ながら、RTPはユニキャストで普通に使われていますよ。
IP電話など1対1アプリもそうですし、個別ストリーミングでもユニキャストです。
マルチキャストの問題と混同はいけません。
従来ながらのテキストを主体とする通信はTCP対応だけでいいでしょうが、
これからのマルチメディア時代はそれだけでは不十分と断言できるでしょう。
>>827
なんか咳とまんないんでむりー。
原因はなんでしょうねえ。ストレスじゃないといいけどね。何のストレスかな(かなり自明)。
>>828
もう3ffe::/16はIANAに返納されちゃっているんで、まずはアドレス空間を取得しないと。
自宅往復ビンタ問題が厳しいので自宅運用はカンベン。
うまく話をもっていく先をご存知ならがんばります。
できたらふとめの回線に繋がったdata centerのマシンを借りられれば嬉しい。
最善なのはKDD大手町のWIDEラックまで足をのばすことのできるマシンです。
2chプロバイダはだめかな? [email protected]にメールしたら反応してくれるかしら。
お手伝いしますのでお知恵をくださいませ。
なんか咳とまんないんでむりー。
原因はなんでしょうねえ。ストレスじゃないといいけどね。何のストレスかな(かなり自明)。
>>828
もう3ffe::/16はIANAに返納されちゃっているんで、まずはアドレス空間を取得しないと。
自宅往復ビンタ問題が厳しいので自宅運用はカンベン。
うまく話をもっていく先をご存知ならがんばります。
できたらふとめの回線に繋がったdata centerのマシンを借りられれば嬉しい。
最善なのはKDD大手町のWIDEラックまで足をのばすことのできるマシンです。
2chプロバイダはだめかな? [email protected]にメールしたら反応してくれるかしら。
お手伝いしますのでお知恵をくださいませ。
RTPのunicast利用についてですが、IP電話とかPolycomだったらH.323とかで先にネゴりませんか?
だとするとpayload書き換えがあるので相当アウトです。
これも専門外なんでよくわかりませんが。すいませんね。
だとするとpayload書き換えがあるので相当アウトです。
これも専門外なんでよくわかりませんが。すいませんね。
6to4 relay routerって、セキュリティ的に最悪最低なので
(得体も知らぬところからのパケットをとにかく変形させてぶんなげるんで…)、
多分誰も納得してくれないです。
configured tunnelならだいじょうぶ。BSD的にはgif(4)です。
(得体も知らぬところからのパケットをとにかく変形させてぶんなげるんで…)、
多分誰も納得してくれないです。
configured tunnelならだいじょうぶ。BSD的にはgif(4)です。
Bフレッツ網が global unicast で、外部に reachability のある IPv6 を
配るようになるのはいつなんだろう。ISPとの連結点が IPv6 対応するのは
NGN待ちなのだろうか。
配るようになるのはいつなんだろう。ISPとの連結点が IPv6 対応するのは
NGN待ちなのだろうか。
>>833
IP spoofingされることを前提ならば
gifによるtunnelでも
得体も知らぬところからのパケットをとにかく変形させてぶんなげてしまう
IP spoofingされていないことを前提ならば
6to4によるtunnelでも
2002::/16のIPv6 address内にIPv4 addressを埋め込むので
通信相手は元のIPv4 addressを確実に把握できてsecurity的には問題は全くない
つまり6to4の方がsecurity的に問題があると主張するのは間違い
IP spoofingされることを前提ならば
gifによるtunnelでも
得体も知らぬところからのパケットをとにかく変形させてぶんなげてしまう
IP spoofingされていないことを前提ならば
6to4によるtunnelでも
2002::/16のIPv6 address内にIPv4 addressを埋め込むので
通信相手は元のIPv4 addressを確実に把握できてsecurity的には問題は全くない
つまり6to4の方がsecurity的に問題があると主張するのは間違い
2chで『2chアクセス専用のIPv6-to-IPv4 translator』を運用してくれないかな？
そしたら v6 only でも後10年は戦える！
そんな面倒な事するぐらいなら…サーバにv6しゃべらせた方が速いかもしれんが…。
そしたら v6 only でも後10年は戦える！
そんな面倒な事するぐらいなら…サーバにv6しゃべらせた方が速いかもしれんが…。
【行政】総務省、ＩＰアドレス不足対策の研究会 来年3月末までに具体策
http://news22.2ch.net/test/read.cgi/newsplus/1186607504/
http://news22.2ch.net/test/read.cgi/newsplus/1186607504/
このスレを見ている人はこんなスレも見ています。(ver 0.20)
【社会保障】厚生年金：｢未納企業｣の従業員救済へ・既に倒産の場合も…政府、立法を検討 [07/07/11] [ビジネスnews+]
BIND その3 [UNIX]
【著作権】 “日本だけの不便なルール” デジタル放送のコピー、制限緩和要求へ…９回までＯＫ、孫コピーは×★５ [ニュース速報+]
【社会保障】厚生年金：｢未納企業｣の従業員救済へ・既に倒産の場合も…政府、立法を検討 [07/07/11] [ビジネスnews+]
BIND その3 [UNIX]
【著作権】 “日本だけの不便なルール” デジタル放送のコピー、制限緩和要求へ…９回までＯＫ、孫コピーは×★５ [ニュース速報+]
>>834
NTT東西がグローバルサービスやるとですね、いろいろとドキドキします。あらゆる意味で。
>>835
6to4の場合本気で「ip_srcはチェックできない」のに対し、
gifは「ip_srcはチェックできる」ので、
ここで既に総当たり攻撃するとしても2^32くらい違いがあります。
ついでにgifの場合はIPv4 IPsecを組み合わせればip_srcは絶対本物になります。
先方のegress pointの手前がどうなってるかはわからないんだけど、
gifの場合には状況によっては「ip6_srcは2001:xxxx:xxxx::/48じゃなきゃだめ」とかの
uRPF的絞りもできる。
6to4の場合にはそういうのは一切がっさいできない。ここでも2^48くらいの差があります。
いずれにしてもtunnellingからは卒業しないといかんのですが、
2^(32+48)の違いが有為でないと思われるのなら、うーん、ちょっとそれは… どうでしょう。
説明してくれると嬉しいです。
>>838
コピー回数はすっごい大バトルだったみたいです。せめて4bitになったことに大感謝せんと。
あとはnoguchi-nagoyaに期待すればいいと思います:-)
NTT東西がグローバルサービスやるとですね、いろいろとドキドキします。あらゆる意味で。
>>835
6to4の場合本気で「ip_srcはチェックできない」のに対し、
gifは「ip_srcはチェックできる」ので、
ここで既に総当たり攻撃するとしても2^32くらい違いがあります。
ついでにgifの場合はIPv4 IPsecを組み合わせればip_srcは絶対本物になります。
先方のegress pointの手前がどうなってるかはわからないんだけど、
gifの場合には状況によっては「ip6_srcは2001:xxxx:xxxx::/48じゃなきゃだめ」とかの
uRPF的絞りもできる。
6to4の場合にはそういうのは一切がっさいできない。ここでも2^48くらいの差があります。
いずれにしてもtunnellingからは卒業しないといかんのですが、
2^(32+48)の違いが有為でないと思われるのなら、うーん、ちょっとそれは… どうでしょう。
説明してくれると嬉しいです。
>>838
コピー回数はすっごい大バトルだったみたいです。せめて4bitになったことに大感謝せんと。
あとはnoguchi-nagoyaに期待すればいいと思います:-)
今度旅行に行くのだが、その際移動時間に
IPv6の本を読みたいのだが、何か良い本はないだろうか。
どうも最近IPv6がそこかしこで取り上げられてる気がするので。
宜しくお願いします先輩方。
IPv6の本を読みたいのだが、何か良い本はないだろうか。
どうも最近IPv6がそこかしこで取り上げられてる気がするので。
宜しくお願いします先輩方。
IPv4の枯渇をなるべくなくすためにIPv4アドレスの再利用を進めると
インターネットでやり取りされる経路情報が飛躍的に増大するような気がするけど
この辺りは大丈夫なのかな？
インターネットでやり取りされる経路情報が飛躍的に増大するような気がするけど
この辺りは大丈夫なのかな？
>>840
どのへんに興味がおありですか?
ユーザ空間のプログラミング、仕様策定の歴史、運用、カーネルの中身、などなど
教えてくださればソムリエします。
>>841
確かにありますね。
ただ、SIP proxy繋ぎまくりって嫌じゃないですか? トラブルシュートしづらそうで。
ただでさえSIPって地獄なのに。/etc/asteriskの下ってなんであんなに分量あるんだ。
>>842
/8の経路ひとつだったものを、返納後ちぎって配れば、もちろん経路表サイズ増大に貢献するでしょうね。
どのへんに興味がおありですか?
ユーザ空間のプログラミング、仕様策定の歴史、運用、カーネルの中身、などなど
教えてくださればソムリエします。
>>841
確かにありますね。
ただ、SIP proxy繋ぎまくりって嫌じゃないですか? トラブルシュートしづらそうで。
ただでさえSIPって地獄なのに。/etc/asteriskの下ってなんであんなに分量あるんだ。
>>842
/8の経路ひとつだったものを、返納後ちぎって配れば、もちろん経路表サイズ増大に貢献するでしょうね。
>>839
コピー回数が4bitになったことに大感謝って、ものすごい勘違いしていませんか？？
今回のコピー回数が９回や１０回可能というのは、
最初に放送から録画したHDDレコーダー等から、
その子コピーをDVDやら他の機器やらへすることができるだけです。
すなわち、子コピーのみが可能で、そこからの孫コピーは不可なので、
最初に録画したHDDレコーダー上から消えた時点で子コピーも不可となります。
例えば、子コピーであるDVDからはコピー不可なので、
そのDVDがいずれ読めなくなった時点で、全てが失われるという制度です。
メディアが劣化する前に他へバックアップということは一切出来ません。
その他にも説明は省略しますが、今回のような子コピーのみ可能というのは、
非常に不便かつ困った事態になるだけで、最悪な状況で無茶な決着をしたわけです。
それを大感謝と表現するのは、本質を分かっていないのでしょう。
コピー回数が4bitになったことに大感謝って、ものすごい勘違いしていませんか？？
今回のコピー回数が９回や１０回可能というのは、
最初に放送から録画したHDDレコーダー等から、
その子コピーをDVDやら他の機器やらへすることができるだけです。
すなわち、子コピーのみが可能で、そこからの孫コピーは不可なので、
最初に録画したHDDレコーダー上から消えた時点で子コピーも不可となります。
例えば、子コピーであるDVDからはコピー不可なので、
そのDVDがいずれ読めなくなった時点で、全てが失われるという制度です。
メディアが劣化する前に他へバックアップということは一切出来ません。
その他にも説明は省略しますが、今回のような子コピーのみ可能というのは、
非常に不便かつ困った事態になるだけで、最悪な状況で無茶な決着をしたわけです。
それを大感謝と表現するのは、本質を分かっていないのでしょう。
>>842
P2Pみたいに末端同士でトンネルつかってアドレスを融通しあえば
経路表問題はとりあえずクリアできない？
往復ビンタ問題があるけど、少なくとも隙間ありまくりのアドレスリユースは
できるからIPv4 vs IPv6という質的問題から帯域という量的問題に変換はできる。
P2Pみたいに末端同士でトンネルつかってアドレスを融通しあえば
経路表問題はとりあえずクリアできない？
往復ビンタ問題があるけど、少なくとも隙間ありまくりのアドレスリユースは
できるからIPv4 vs IPv6という質的問題から帯域という量的問題に変換はできる。
>>841
v4⇔v6のをSIP Proxyとは呼ばない
SIP Proxyはその定義により情報をスルーさせる
変換させるものははSIP B2BUAと呼ぶ
v4⇔v6変換だけでなく様々な種類のものがある
>>841
SIPだけでなくHTTPもFTPもProxy/Delegate/Gateway類は昔から大量に使われている
特にNATがらみでIPアドレス変換など十分な運用実積がそれぞれある
美しくないのでできれば避けたい世界だが
v4⇔v6変換という移行期にも必須な運用技術であることを認識すべきだ
asteriskの件はあの設計自体が糞なのはおいとくにしても
分量でかいのはSIP以外の体系やレガシーなものをひきずっているのが原因
あとは基本的にその対象をよく理解できていない者にとっては
意味や必要性がわからないため意味もなく分量がでかいと感じるケースもある
もしそうでないのならば問題点を具体的に指摘すべきだ
v4⇔v6のをSIP Proxyとは呼ばない
SIP Proxyはその定義により情報をスルーさせる
変換させるものははSIP B2BUAと呼ぶ
v4⇔v6変換だけでなく様々な種類のものがある
>>841
SIPだけでなくHTTPもFTPもProxy/Delegate/Gateway類は昔から大量に使われている
特にNATがらみでIPアドレス変換など十分な運用実積がそれぞれある
美しくないのでできれば避けたい世界だが
v4⇔v6変換という移行期にも必須な運用技術であることを認識すべきだ
asteriskの件はあの設計自体が糞なのはおいとくにしても
分量でかいのはSIP以外の体系やレガシーなものをひきずっているのが原因
あとは基本的にその対象をよく理解できていない者にとっては
意味や必要性がわからないため意味もなく分量がでかいと感じるケースもある
もしそうでないのならば問題点を具体的に指摘すべきだ
>>843
IPv6関連のカーネルの設計とプログラミングにおける問題点に興味があります
IPv6関連のカーネルの設計とプログラミングにおける問題点に興味があります
>>844
(これはIPv6と関係ないから続くようならメールでね)
「コピー一切禁止」にされちゃいそうだったところを無理無理頑張ったみたいなんですよ。
権利者側はすっごくすっごくコピーされたくないらしい。
わからんでもないがその前に「もっと大勢に見せればproduct placementできる」とかいうことを
わかってないのでは。
>>845
「融通しあう」は「余ってるIPv4 global addressがあるところが貸し出す」と読めますがそれであってます?
だとすると… 余ってるところありますかね。少なくともうちは/29(ISPルータがいっこ食べてて5個か)でもうパンパン。
そうじゃないとするとちょっとどういう姿なのかが見えません。
>>846
用語間違いはすんませんね。
SIPの本はゲーが出るほど読んでますが、分量問題じゃなくて内容問題でゲーが出ました。
draft-ietf-sip-hitchhikers-guide-03.txtの参考文献の数だけでダークな気持ちになりませんか?
不勉強ならすいませんが、http proxyを多段に繋ぐ例ってそんなにあります?
proxy serverを使えば使うほど障害、それから最適でない経路(往復ビンタとか)の可能性が上がりますが…
構成次第ですがcacheの効きもどうなるかなあ。
squidのIPv6対応したくらいですから必要性は重々承知しとりますよ。古いのだけどね。ご安心を。
>>847
kernelだったらこれ。
http://www.amazon.co.jp/exec/obidos/ASIN/0124477518
socket APIのユーザプログラムだったらこれ。手前みそですんません。他にないんで。
こっちはkame webpage探せば似たような内容のが出てきますが本の方が網羅的なはずです。
http://www.amazon.cojp/exec/obidos/ASIN/4756142362
最近のCFNetworkとか.Netの本もいいんじゃないかと思いますが、ちょっとみあたりません。すいません。
(これはIPv6と関係ないから続くようならメールでね)
「コピー一切禁止」にされちゃいそうだったところを無理無理頑張ったみたいなんですよ。
権利者側はすっごくすっごくコピーされたくないらしい。
わからんでもないがその前に「もっと大勢に見せればproduct placementできる」とかいうことを
わかってないのでは。
>>845
「融通しあう」は「余ってるIPv4 global addressがあるところが貸し出す」と読めますがそれであってます?
だとすると… 余ってるところありますかね。少なくともうちは/29(ISPルータがいっこ食べてて5個か)でもうパンパン。
そうじゃないとするとちょっとどういう姿なのかが見えません。
>>846
用語間違いはすんませんね。
SIPの本はゲーが出るほど読んでますが、分量問題じゃなくて内容問題でゲーが出ました。
draft-ietf-sip-hitchhikers-guide-03.txtの参考文献の数だけでダークな気持ちになりませんか?
不勉強ならすいませんが、http proxyを多段に繋ぐ例ってそんなにあります?
proxy serverを使えば使うほど障害、それから最適でない経路(往復ビンタとか)の可能性が上がりますが…
構成次第ですがcacheの効きもどうなるかなあ。
squidのIPv6対応したくらいですから必要性は重々承知しとりますよ。古いのだけどね。ご安心を。
>>847
kernelだったらこれ。
http://www.amazon.co.jp/exec/obidos/ASIN/0124477518
socket APIのユーザプログラムだったらこれ。手前みそですんません。他にないんで。
こっちはkame webpage探せば似たような内容のが出てきますが本の方が網羅的なはずです。
http://www.amazon.cojp/exec/obidos/ASIN/4756142362
最近のCFNetworkとか.Netの本もいいんじゃないかと思いますが、ちょっとみあたりません。すいません。
>>848
SIP proxyとHTTP proxyを比較することは筋違いで、
似ているものを比較するならばメールと比較すべき。
おおざっぱに言えば、SIP proxyはほぼMTAと同じ立ち位置。
メールの場合も、まずは送り元のMTUからMTAへ送られ、
そこから、DNSのMXで解決して送り先のMTAへ送られる。
さらにその組織内部で分かれていれば各部署のMTAへ送られ、最後に送り先のMUAへ。
SIPの場合も、まずは送り元のSIP UAからSIP proxyへ送られ、
そこから、DNSのNAPTRとSRVで解決して送り先のSIP proxyへ送られる。
さらにその組織内部で分かれていれば各部署のSIP proxyへ送られ、最後に送り先のSIP UAへ。
メールを送る仕組みをきちんと理解している者ならば、
以上のように全く同じであることに気付くはずで、
もしSIP proxyが複雑に見えるようならば超基礎的なしくみを理解していないだけ。
SIP proxyとHTTP proxyを比較することは筋違いで、
似ているものを比較するならばメールと比較すべき。
おおざっぱに言えば、SIP proxyはほぼMTAと同じ立ち位置。
メールの場合も、まずは送り元のMTUからMTAへ送られ、
そこから、DNSのMXで解決して送り先のMTAへ送られる。
さらにその組織内部で分かれていれば各部署のMTAへ送られ、最後に送り先のMUAへ。
SIPの場合も、まずは送り元のSIP UAからSIP proxyへ送られ、
そこから、DNSのNAPTRとSRVで解決して送り先のSIP proxyへ送られる。
さらにその組織内部で分かれていれば各部署のSIP proxyへ送られ、最後に送り先のSIP UAへ。
メールを送る仕組みをきちんと理解している者ならば、
以上のように全く同じであることに気付くはずで、
もしSIP proxyが複雑に見えるようならば超基礎的なしくみを理解していないだけ。
>>848
＞ 最適でない経路(往復ビンタとか)の可能性が上がりますが…
そのために、SIPではcontrolとdataが分かれていて、SIP本体ではcontrolだけを担っているのです。
controlの方、すなわちSIP自体は、通常、自分側と相手側のSIP Proxyを通りますが、
dataの方は、controlで指定されたプロトコル(音声や映像ならRTPなど)を用いて、
自分と相手の間でE2E(End-to-End)で直接通信が行なわれます。
つまり、往復ビンタといった問題は生じませんし、
NATを排除したIPv6時代に取り戻そうとしているE2E思想に基づいた設計となっています。
現在の乱れたIPv4よりもIPv6との親和性が良いとSIPが言われるのも、このためです。
＞ 最適でない経路(往復ビンタとか)の可能性が上がりますが…
そのために、SIPではcontrolとdataが分かれていて、SIP本体ではcontrolだけを担っているのです。
controlの方、すなわちSIP自体は、通常、自分側と相手側のSIP Proxyを通りますが、
dataの方は、controlで指定されたプロトコル(音声や映像ならRTPなど)を用いて、
自分と相手の間でE2E(End-to-End)で直接通信が行なわれます。
つまり、往復ビンタといった問題は生じませんし、
NATを排除したIPv6時代に取り戻そうとしているE2E思想に基づいた設計となっています。
現在の乱れたIPv4よりもIPv6との親和性が良いとSIPが言われるのも、このためです。
>>848
融通＝貸し出す、であってます。数は・・・総ノード数の推計からすると
余ってるんじゃないですかね。もっともアメリカのアドレスが日本で
使われたりすると国際ビンタでアイタタタですが（それでも利益が出るなら
やるユーザなりISPが出現しそうだ）。
まあ、この貸し出しができればOKというより、主軸としては各種サービスを
ネームベース運用するなどアドレス消尽が０な方法を中心にしつつ、どうしても
IPv4が必要なIPv6のみな所に融通するために使う、位ですかね。
融通＝貸し出す、であってます。数は・・・総ノード数の推計からすると
余ってるんじゃないですかね。もっともアメリカのアドレスが日本で
使われたりすると国際ビンタでアイタタタですが（それでも利益が出るなら
やるユーザなりISPが出現しそうだ）。
まあ、この貸し出しができればOKというより、主軸としては各種サービスを
ネームベース運用するなどアドレス消尽が０な方法を中心にしつつ、どうしても
IPv4が必要なIPv6のみな所に融通するために使う、位ですかね。
>>848
IETFの範囲外でしょうが、IMSではSIPは多段が基本かと。
IETFの範囲外でしょうが、IMSではSIPは多段が基本かと。
>>852
RFC3261の基本型でも、
SIP UA − SIP proxy − SIP proxy − SIP UA
と3段になるのが基本。しかしこれはメールの時代から一緒で、
MUA − MTA − MTA − MUA
と3段になるのが基本。メールでもSIPでも基本思想は全く同じで、
発信側と受信側の各ドメインに、User Agent と Transfer Agent (or Proxy) が存在するだけ。
ドメインベースの配送のしくみは、昔からIETFにおける基本思想となっている。
RFC3261の基本型でも、
SIP UA − SIP proxy − SIP proxy − SIP UA
と3段になるのが基本。しかしこれはメールの時代から一緒で、
MUA − MTA − MTA − MUA
と3段になるのが基本。メールでもSIPでも基本思想は全く同じで、
発信側と受信側の各ドメインに、User Agent と Transfer Agent (or Proxy) が存在するだけ。
ドメインベースの配送のしくみは、昔からIETFにおける基本思想となっている。
あ、説明が少なくてすまん、
同じ管理組織内でもxCSCFという名で
機能が階層分けされる、、、って意味。
同じ管理組織内でもxCSCFという名で
機能が階層分けされる、、、って意味。
>>854
それはIETFベースのSIP運用でもアリで、
各ドメインを管理して外部から受け付けるSIP Proxy (Inbound Proxy)と、
単に内部の各端末からの受け付けるSIP Proxy (Outbound Proxy)は、
機能的にも概念も分かれているが、
それらの自ドメイン内のSIP Proxyを一つで運用する単純ケースが、
>>853に掲げた各ドメイン毎に一つのSIP Proxyが設置される最単純パターン。
例えば、IPv6主流時代になっても内部にIPv4 SIP UAが残っていたとすると、
それらを収容するためにドメイン自体までも分離する必要は当然なくて、
IPv4専用のOutbound Proxyを別個に設けるだけでよい。
その場合、実際には、そのOutbound ProxyはそこでIPv4接続を終端させて、
本来のIPv6対応の自ドメインProxyへIPv6通信するため、B2BUAの形態をとる。
それはIETFベースのSIP運用でもアリで、
各ドメインを管理して外部から受け付けるSIP Proxy (Inbound Proxy)と、
単に内部の各端末からの受け付けるSIP Proxy (Outbound Proxy)は、
機能的にも概念も分かれているが、
それらの自ドメイン内のSIP Proxyを一つで運用する単純ケースが、
>>853に掲げた各ドメイン毎に一つのSIP Proxyが設置される最単純パターン。
例えば、IPv6主流時代になっても内部にIPv4 SIP UAが残っていたとすると、
それらを収容するためにドメイン自体までも分離する必要は当然なくて、
IPv4専用のOutbound Proxyを別個に設けるだけでよい。
その場合、実際には、そのOutbound ProxyはそこでIPv4接続を終端させて、
本来のIPv6対応の自ドメインProxyへIPv6通信するため、B2BUAの形態をとる。
>それはIETFベースのSIP運用でもアリで、
ま、CSCFつってもIETFベースのSIPだからな。
ま、CSCFつってもIETFベースのSIPだからな。
> DNSのNAPTRとSRVで解決して
そんなもの使わなあかんのか、、、じゃあ使えん。
そんなもの使わなあかんのか、、、じゃあ使えん。
>>857
もしかして、真性の無知者？？
まさか、メール配送の時にDNSでMXレコードを引いて解決することすら知らないのか？
MXはメール専用で他のサービスには使えず、
だからといって各サービス毎に専用のレコードを増やすときりがないので、
MXの仕組みを拡張する形で汎用性がある枠組みが20世紀の終りに導入されたわけだ。
この業界でMXやSRVやNAPTRを知らなかったら、モグリだぞ。
どちらにせよ最終的には、MXやSRVで得たサーバ名に対して、
さらにDNSのAAAAとAを引いて解決することで、ようやくIPv6/v4アドレスが得られる。
まずは各サービスとDNSの仕組みを勉強してから、このスレに来い。
もしかして、真性の無知者？？
まさか、メール配送の時にDNSでMXレコードを引いて解決することすら知らないのか？
MXはメール専用で他のサービスには使えず、
だからといって各サービス毎に専用のレコードを増やすときりがないので、
MXの仕組みを拡張する形で汎用性がある枠組みが20世紀の終りに導入されたわけだ。
この業界でMXやSRVやNAPTRを知らなかったら、モグリだぞ。
どちらにせよ最終的には、MXやSRVで得たサーバ名に対して、
さらにDNSのAAAAとAを引いて解決することで、ようやくIPv6/v4アドレスが得られる。
まずは各サービスとDNSの仕組みを勉強してから、このスレに来い。
>>849
http proxyは比較ではなくて、846へのお返事のつもりでした。
>>850
SIP問題はすなおに質問者にまわることにします。
話が戻りますが、IPv4しか使えないひととIPv6しか使えないひとのデータ(音声?)転送はどうするんでしょ?
SIPのcontrol channelとNAT-PT(なりなんなり)の間に協力関係がないといけなさそうですが。
なにかぐっとくる文書があったら教えてください。
http proxyは比較ではなくて、846へのお返事のつもりでした。
>>850
SIP問題はすなおに質問者にまわることにします。
話が戻りますが、IPv4しか使えないひととIPv6しか使えないひとのデータ(音声?)転送はどうするんでしょ?
SIPのcontrol channelとNAT-PT(なりなんなり)の間に協力関係がないといけなさそうですが。
なにかぐっとくる文書があったら教えてください。
>859
megacoを使えてRTPの終端を行うことが出来るメディアボックスが有れば解決。
megaco無しでB2BUAが一体化されていても良いが。
調べていないのでそういう製品が有るかどうかはしらないけど。
megacoを使えてRTPの終端を行うことが出来るメディアボックスが有れば解決。
megaco無しでB2BUAが一体化されていても良いが。
調べていないのでそういう製品が有るかどうかはしらないけど。
>>860
MEGACOは全く関係ない
今はSIPにおけるIPv4⇔IPv6通信の話がなされている
>>859
SIPだからといって特殊ではなく基本原理においては他と同じ
SMTPでもHTTPでもSIPでもIPv4⇔dual(IPv4/v6)⇔IPv6の形態しか取れない
ただしSIPの場合はSDPで指定されたRTPなども同様にdualで中継する
ようするにdualのところでB2BUAとなってSIPもRTPも一度終端する
MEGACOは全く関係ない
今はSIPにおけるIPv4⇔IPv6通信の話がなされている
>>859
SIPだからといって特殊ではなく基本原理においては他と同じ
SMTPでもHTTPでもSIPでもIPv4⇔dual(IPv4/v6)⇔IPv6の形態しか取れない
ただしSIPの場合はSDPで指定されたRTPなども同様にdualで中継する
ようするにdualのところでB2BUAとなってSIPもRTPも一度終端する
>>859
とりあえず
http://wbb.forum.impressrd.jp/feature/20070330/413
これとこの2ページめを読んで、雰囲気つかんで。
網間はIPに限らない前提になってるけど。
とりあえず
http://wbb.forum.impressrd.jp/feature/20070330/413
これとこの2ページめを読んで、雰囲気つかんで。
網間はIPに限らない前提になってるけど。
>>859
以下のようにSIP proxyとhttp proxyを比較するような発言をしたからでは??
＞ SIP proxy繋ぎまくりって嫌じゃないですか? (In >>843 )
＞ http proxyを多段に繋ぐ例ってそんなにあります? (In >>848 )
まあ結論としてはメール転送におけるMTA多段とSIP proxy多段は同じ状況ということがわかればいいと思うけど.
以下のようにSIP proxyとhttp proxyを比較するような発言をしたからでは??
＞ SIP proxy繋ぎまくりって嫌じゃないですか? (In >>843 )
＞ http proxyを多段に繋ぐ例ってそんなにあります? (In >>848 )
まあ結論としてはメール転送におけるMTA多段とSIP proxy多段は同じ状況ということがわかればいいと思うけど.
865 ：RFC：2007/08/12(日) 10:53:43 ID:gryZ4hZ7
>>864
IMSの話をしているわけではないので
そんなのを示してもかえって混乱するだけで意味がない
単にSIP/RTPにおける中継例ならば
RFC3665の3.5にSIPのALG/B2BUA利用時の例が載っている
汎用例だがIPv4/IPv6間通信でも適用可能
IMSの話をしているわけではないので
そんなのを示してもかえって混乱するだけで意味がない
単にSIP/RTPにおける中継例ならば
RFC3665の3.5にSIPのALG/B2BUA利用時の例が載っている
汎用例だがIPv4/IPv6間通信でも適用可能
>>848
>> proxy serverを使えば使うほど障害、
>> 構成次第ですがcacheの効きもどうなるかなあ。
まさかとは思うけど、
SIP proxyにおいてcacheを行なうと思い込んだりしていませんよね？
>> proxy serverを使えば使うほど障害、
>> 構成次第ですがcacheの効きもどうなるかなあ。
まさかとは思うけど、
SIP proxyにおいてcacheを行なうと思い込んだりしていませんよね？
そんな重箱の隅つついてまで引き伸ばす話題じゃないでしょ。
v6でアクセスした人が見た亀が踊るところをキャッシュされたものを
v4でアクセスした人が見れたりしますか？
v4でアクセスした人が見れたりしますか？
869 ：comedia：2007/08/12(日) 11:21:19 ID:vTolRqIp
SIPスレになってますね。
>>848
で、SIP proxy多段は普通です。
MTAみたいなもんだと思えば別に腹も立たないですよね。
そもそもSIPで広域名前解決が必要なアプリがまだ少ないし
どうせシグナリングだけなので、直接配送しないデメリットが少ないのです。
これ以上はSIPスレで。
>>848
で、SIP proxy多段は普通です。
MTAみたいなもんだと思えば別に腹も立たないですよね。
そもそもSIPで広域名前解決が必要なアプリがまだ少ないし
どうせシグナリングだけなので、直接配送しないデメリットが少ないのです。
これ以上はSIPスレで。
メールにおけるDKIMのようにシグネチャをつける枠組みがSIP Identityとしてあるが、
自分のドメイン名で署名してもらうには、DKIMと同様に、
まずは自分のドメインのサーバ（メールならMTA、SIPならproxy）へ送信する必要がある。
このように、ドメイン名ベースのプロトコルでは、
直接通信ではなく間にproxyなどがはさまる通信形態となるのが自然な形であると言える。
自分のドメイン名で署名してもらうには、DKIMと同様に、
まずは自分のドメインのサーバ（メールならMTA、SIPならproxy）へ送信する必要がある。
このように、ドメイン名ベースのプロトコルでは、
直接通信ではなく間にproxyなどがはさまる通信形態となるのが自然な形であると言える。
いわゆる4G携帯の普及がIPv6の爆発的普及の原動力となる
・・・のだろうか。
・・・のだろうか。
いえいえ、Mobile IPv6の時代になりますよ
携帯がそこまでして固定IP持ち運ぶかな。。。
動的IPにして、あとは上位レイヤにお任せって
ほうが実装が単純な気がしない？
動的IPにして、あとは上位レイヤにお任せって
ほうが実装が単純な気がしない？
>>873
そりゃホームはIPv4、気付きはIPv6みたいな運用ができればそうですけど、
それはMobileIPインフラの整備だとか、エッジユーザではなくインフラ側が
主体となって進めないといけないような色んな他人任せな前提があるわけで。
IPv6でつなぐもののトンネル箱を既存のIPv4セグメントに置かしてもらって
完了、なら、ビンタ効率激悪ながら各自のレベルでできて手軽だし、世界が
どう動こうと単純にIPv4 connectivityが欲しい2010以降の純IPv6ユーザからは
利用可能時期の予測確度が高い解決策という意味で嬉しいってことです。
まあ手軽な方式で目の前の課題をクリアしつつ、中長期的にはMobileIPだとか
native IPv6運用だとかに世の中が流れるような布石を打ってくというのが
現在〜2020位までの流れじゃないですかね。
そりゃホームはIPv4、気付きはIPv6みたいな運用ができればそうですけど、
それはMobileIPインフラの整備だとか、エッジユーザではなくインフラ側が
主体となって進めないといけないような色んな他人任せな前提があるわけで。
IPv6でつなぐもののトンネル箱を既存のIPv4セグメントに置かしてもらって
完了、なら、ビンタ効率激悪ながら各自のレベルでできて手軽だし、世界が
どう動こうと単純にIPv4 connectivityが欲しい2010以降の純IPv6ユーザからは
利用可能時期の予測確度が高い解決策という意味で嬉しいってことです。
まあ手軽な方式で目の前の課題をクリアしつつ、中長期的にはMobileIPだとか
native IPv6運用だとかに世の中が流れるような布石を打ってくというのが
現在〜2020位までの流れじゃないですかね。
>>874
携帯でもなんでも、網からもらえるIPアドレスは網を移れば変わります。
しかし、それとは別に、今たまたまいる網と独立に依存せずに、
固定なホームIPアドレスを並行して持ち、必要ならそれを用いて通信します。
MobileIPがなければ、おっしゃるように上位レイヤにお任せすることになりますが、
網を次々と移るたびにIPアドレスが変わって、そのたびに上位レイヤでは大変です。
たまに網を移るだけの利用で、しかも間欠的な利用ならば、上位レイヤでもいいのですが。
>>875
そのMobileIPインフラの整備は、順次進めていけばいいだけでよくて、
最悪、自分のホームと自分の端末しかサポートしていなくても機能します。
すなわち、他人任せな前提があるとおっしゃるのは誤解だと思います。
携帯でもなんでも、網からもらえるIPアドレスは網を移れば変わります。
しかし、それとは別に、今たまたまいる網と独立に依存せずに、
固定なホームIPアドレスを並行して持ち、必要ならそれを用いて通信します。
MobileIPがなければ、おっしゃるように上位レイヤにお任せすることになりますが、
網を次々と移るたびにIPアドレスが変わって、そのたびに上位レイヤでは大変です。
たまに網を移るだけの利用で、しかも間欠的な利用ならば、上位レイヤでもいいのですが。
>>875
そのMobileIPインフラの整備は、順次進めていけばいいだけでよくて、
最悪、自分のホームと自分の端末しかサポートしていなくても機能します。
すなわち、他人任せな前提があるとおっしゃるのは誤解だと思います。
IPv6普及のための鍵はMIP6の利便性ですな
まずはMIP6普及のためにgarlic.itojun.orgでもHAサービスを始めて欲しい
まずはMIP6普及のためにgarlic.itojun.orgでもHAサービスを始めて欲しい
MobileIP は一時某キャリアが熱心に取り組んでたけど、今はもう部隊残ってないよね。
事業化はもう断念したのかな？事情知ってる人いる？
事業化はもう断念したのかな？事情知ってる人いる？
>>876
む、たしかに。
経路最適化はともかくとして、トンネリング相当だったら自分が
手元と相手側にエージェント置けばいい・・・いや、自分はMIPv6?だから
相手側にだけホーム置ければ完了？
あれ、でもホームアドレスはIPv4だけど中身はIPv6なMobileIPって
どういう構成・動作になるんだ？
む、たしかに。
経路最適化はともかくとして、トンネリング相当だったら自分が
手元と相手側にエージェント置けばいい・・・いや、自分はMIPv6?だから
相手側にだけホーム置ければ完了？
あれ、でもホームアドレスはIPv4だけど中身はIPv6なMobileIPって
どういう構成・動作になるんだ？
i-d 書くのは実装してから、ね。
>>881
いや、IDが先でいい。
ただし、WG採用までには実装し、
最終的には運用実験による諸問題を明らかにしてから標準化トラックへ。
これらをきちんと経ずにRFCにしてしまった問題プロトコルが今まで多すぎた。
いや、IDが先でいい。
ただし、WG採用までには実装し、
最終的には運用実験による諸問題を明らかにしてから標準化トラックへ。
これらをきちんと経ずにRFCにしてしまった問題プロトコルが今まで多すぎた。
>861
音声はRTP/RTCPだろ。
SIPはB2BUAで終端すれば良い。RTPもB2BUAで扱えるものは有るが、メディアボックスを内蔵しているだけ。
音声はRTP/RTCPだろ。
SIPはB2BUAで終端すれば良い。RTPもB2BUAで扱えるものは有るが、メディアボックスを内蔵しているだけ。
啓蒙がんばってるitojunさんに素直に敬服。
ところでRH0問題ってもう安心していいの？
仕様が直ったからそれでいいって問題じゃないでしょう。
絶滅への啓蒙がんばらなきゃいけませんね。
ところでRH0問題ってもう安心していいの？
仕様が直ったからそれでいいって問題じゃないでしょう。
絶滅への啓蒙がんばらなきゃいけませんね。
>>876
それはわかるが、3G以上の複数のアンテナつかんで高速ハンドオーバーを
実現する技術との相性がわるそうだが、議論が活発とも思えない。
あとキャリアが携帯端末について公開するのは生IPではなくPARLAYなり
SLEEなりのAPIになりそうな気がしない？
まあ
それはわかるが、3G以上の複数のアンテナつかんで高速ハンドオーバーを
実現する技術との相性がわるそうだが、議論が活発とも思えない。
あとキャリアが携帯端末について公開するのは生IPではなくPARLAYなり
SLEEなりのAPIになりそうな気がしない？
まあ
盛り上がってて素直に勉強になります。SIPはまだまだ未知の領域だなあ。精進精進。
>>884
rthdr0ですが、各実装patchが出ていますが、世界の最後の1台までpatchをあててくれないとヤバいです。
あ、正確には最後の最後の1台はあてなくていいのか。
4/末に「最後の1台patchあたるまで寝れません」とか投稿したけど、いまは寝てますからねー。
インパクトとしてはいっちゃんまずいのがMacOS X(2200万台)とAirPort/AirMac Extreme(IPv6 onにすると一発で6to4/台数不明)です。
ただ、patchなしでもいくつか止める方法があります。どれもISP solutionですね。
- routing headerつきのIPv6パケットはどこのルータもforwarding性能が遅いから、
帯域埋め尽くし攻撃は成立しづらい
- ip6_hlimは255まで
- ip6_srcだけ見てuRPFしていればrouting header(というかsource routing一般)は使えない
いっこめはどこのルータ実装にも言えるんですが、中にはCPU forwardingしたあげくCPUが落ちて
DoSになる実装とか、rthdr0対策diffにバグはいってたとかいうのもあって、ちょっとなんだかなあです。
>>884
rthdr0ですが、各実装patchが出ていますが、世界の最後の1台までpatchをあててくれないとヤバいです。
あ、正確には最後の最後の1台はあてなくていいのか。
4/末に「最後の1台patchあたるまで寝れません」とか投稿したけど、いまは寝てますからねー。
インパクトとしてはいっちゃんまずいのがMacOS X(2200万台)とAirPort/AirMac Extreme(IPv6 onにすると一発で6to4/台数不明)です。
ただ、patchなしでもいくつか止める方法があります。どれもISP solutionですね。
- routing headerつきのIPv6パケットはどこのルータもforwarding性能が遅いから、
帯域埋め尽くし攻撃は成立しづらい
- ip6_hlimは255まで
- ip6_srcだけ見てuRPFしていればrouting header(というかsource routing一般)は使えない
いっこめはどこのルータ実装にも言えるんですが、中にはCPU forwardingしたあげくCPUが落ちて
DoSになる実装とか、rthdr0対策diffにバグはいってたとかいうのもあって、ちょっとなんだかなあです。