IPv6スレ ver3

>>924
それはリンクローカル内しか全く見えていない
全体のアーキテクチャをちゃんと勉強したほうがいい

Dense ModeとSparse Modeでは影響を受けるルータの数が全く異なる
さらに(*,G)と(S,G)では状態の数がまるで異なる

>>925
話が通じてないようですが、
verisignを信用するかどうかはどうでもよくて、
証明書が何を証明するものなのかを明確にすることが重要。
これはPKIでもPGPでもあらゆる基本です。

「IIJに署名されたitojunの鍵」の例にしても、
『itojun』という名を持つ人を証明するものなのか、
『[email protected]』というメールアドレスを持つ人を証明するものなのか、
その二つは大きく違います。
どちらですか？

HTTP並に普及するポテンシャルのマルチキャストアプリかあったとして
それは現状じゃ運用できん。集約不可能な億の経路が仮に1/10に
削れたとしても全然だめだ。

>itojun
自分の体を大事にしてくれ、頼む。

かつてkameでMIP6をやっていました。

MIP6のspecをreviseしよう、という動きが一時期ありまして、その時には今のスペックを３つくらいに分割しようと言われていました。その後はどうなったのかな。
もっともそうなればなったで、読むべきRFCが多すぎる、とか言われかねないような気もしますが。

実装についてですが、確かにkameのmip6実装(今はshisaと呼んでいますが)のBSD mainstreamへのmergeは未だ完了していませんが、遅々としては進んでいます。いつになるか、というのはまだちょっとお約束はできませんが。
linuxではUSAGIのmip6実装のkernelに必要な拡張ははすでにmain treeに入ったと聞いています。利用するにはさらにmip6関係のデーモンをインストールする必要があります。
どちらにしても、実装があったとしても、現時点ではごく一部の研究室以外のでの需要はあまりなさそうです。

Home AgentサービスはNautilus6 projectというところでやっています。だれでも使えるはずです。(多分、もっと使ってー、というところだと思います)

https://op-ha.nautilus6.org/
http://www.wide.ad.jp/news/press/20070329-MobileIPv6-j.html
http://internet.watch.impress.co.jp/cda/news/2007/03/30/15255.html

>>933
そうすると、>>893 >>890 >>888 >>879 >>>876 >>875 >>873 にある、
IPv4とIPv6を組み合わせたMIP6によるIPv4/v6移行途中運用案は、いかがなものなのでしょう？

>> 934

こちらのスレで議論されていた運用案の具体的姿がよくわからないのですが、

1. Global IPv4 addressをHoAとして
1-1 IPv4 cloudに移動
1-2 IPv6 cloudに移動

2. IPv6 addressをHoAとして
2-1 IPv4 cloudに移動
2-2 IPv6 cloudに移動

とすると、1-2のようなケースでしょうか?
1-1はmip4だし、2-2はmip6なのでおいておくとすると、1-2, 2-1ともに一年ほど前のIETFでは議論されていたように思います。
現実にはIPv6 reachableな網がそこら中にあってそこでIPv4を使いたい、という状況はあまりないので、2-1のようなIPv6 HoAを通常のIPv4網で使えるようにしたい、という要求の方が多かったように思います。
その場合は、NATをどうtraverseをどうするか、というのが問題で、DSMIPには一応NAT detectionという機構が入っていました。

shisaではNAT traversalをサポートしない2-1タイプのDSMIPは一応入っています。動くのかどうかはよくわかりません。

また、DSMIPが首尾よくできたとしても、route optimizeするのは相当困難かと思われます。もしかしたら今IETFで検討/議論されているのかもしれません。

>>931
マルチキャストで必要な経路数を根本的に勘違いしてるぞ

例えば１００のＴＶ放送局を１億人が各局を選んで適当に見ているとすると
各ルータ上で必要になるマルチキャスト経路数は１億ではなくて１００だぞ

itojunも>>924で勘違いしているようだが
＞＞IGMPv3/MLDv2でjoinしたひとにちゃんとmulticast streamを流してあげないといけませんが、
＞＞そのときの流し先の情報(これを「状態」と呼んだ)はpim6sdなりなんなりが持ってるでしょ?

これにより１億の経路を各ルータが持つようになるわけではない
１００の放送局それぞれの分に対して転送するか否かの状態を各ルータが持つだけで
つまり各ルータ上のマルチキャスト経路数（状態）は１００に過ぎない

この効率性がＩＰマルチキャストの特徴ならびに設計された理由でなので
基本アーキテクチャぐらいは理解しておくべき

>>935
経路表の増大無しに、疎なアドレス空間のまったく別のところに残存する
IPv4アドレスを別の場所で転用したい、というのが移行過程でどれくらい
現実に起きるか、ということが問題になりますね。

まずはISPとしては端末側からIPv4を巻き取りつつサーバ・専用線向けに
転用するだろうから、上のような事態になるのはそれを消尽して、かつ、
L7的にリレーするのでは不可な場合になりますかね。少なくとも2010に
いきなりはならなさそう。

まずはmulticastネタ。

うーん、なんでmulticast routingでこんなに意見がずれるのだろう。
ほんとにoperationしたことありますか? わたしはありますが。kame FMとかやってた頃ね。

確かに100 channelを10億人だと、group数は100ですが、パケット配送のときのための
データ構造を考えると、unicast routing tableとは全く違うメモリの食い方をします。
ひとつのグループであっても、おおきく分岐するポイントでは、unicast routing tableでいうと
"gateway"にあたるところがたくさんになりますね。
しかもそれがrouting protocol(= ネットワーク管理者がいろいろ管理できる)ではなくて、
IGMP/MLD join/leave(= ユーザの挙動)で変わるので、provisioningが困難です。

つぎにcertificateネタ。

わたしはoppotunitistic IPsec好きでopenssh開発者なので、
鍵に対する署名自体にそんなに価値を見いだしていません。
どっちかというと、現在のX.509 certificateの普通の使われ方、
「Internet Explorerが知っているCAに署名されているからそのまま信用」というのが怖い。
bootstrap問題をOS出荷でごまかしているように見えます。
ていうかmicrosoftの出荷プロセスを信用していいのか?
対してopensshの「一度目はyes/noって聞いて、
できたらkey fingerprintを確認してもらう」はいい割り切りだと思います。
ここがsshのRFCのハイライトです。Tatu Ylonen偉い。
RFC4255していればもっと良。さらにDNSSECしてればばっちぐーです。
certificateネタはスレッド違うと思うのでこんくらいにしません? あとはメールください。

とても元気ですよ。医者のOKもあるし。ご心配いただいた方どうもです。

>>938
分岐するポイントで"gateway"にあたるところがたくさんになりますが、
それはinterfaceの数が上限で、forwardするか否かのみですね。
しかも、いくらinterfaceが多くてもそのルータ内のみの管理情報となります。
つまり、unicastと異なり各entryで持つinterace数が1からNへと唯一変わりますが、
100個のchannelであればtable上のentryは100個だけです。
したがって、全体で10億人であっても、backbone routerでも100のentryのみです。

linklocal上のIGMP/MLDの挙動だけでなく、
それによって他のルータへ伝播される情報とその枠組みは何か、
そして各ルータが持つことになる情報はどれだけかといったことを、
学習することをお勧めします。

>>939
> 分岐するポイントで"gateway"にあたるところがたくさんになりますが、
> それはinterfaceの数が上限で、forwardするか否かのみですね。
???
ちょっと意味がわからん。
IXのようにスイッチ経由で複数のルータに接続する場合、同じインターフェース上に
複数のルータが現われるんだけど。

operationしたことないので机上の意見だけど。
10億人で100chだったら上流のルータは常に全ch流しっぱなし
でtableに変化がなさそう。
でも中〜下流のルータでjoin/leaveを上に下にとやり取り
していたら100個のテーブルでlistenerが0〜8とかの間で
めまぐるしく変わったら結構な負荷になる気がする。

試しに簡単なシミュレーション書いてみたけど
パラメタ悪いせいか出た数字見てもピンとこない。
何ミスってるかわからん。

>itojun
この辺に関して詳しい話のURLとかって無いんすか？
"provisioning"は有料ですって言われたらそれまでだけど。

>>940
MLD/IGMPでそのインターフェース上に各マルチキャストグループを流すべきかどうか決まるので、
そのインタフェース方面に複数のルータやエンドホストが接続していても、一つでも要求があればforwardする。

スイッチがMLD/IGMP snoopingして最適化するかどうかはL2の問題で独立でどちらでもよい。
不要なマルチキャストグループが届いたルータやエンドホストは単に無視する。
運用上の問題はない。

今webサイト数は個人勝手サーバーを含めて1億をこえたとか。
マルチキャストサーバーは、ポテンシャルがあるアプリがあったとしても
全然そこまではいけないでしょ？といういみ。

>>941
軽くぐぐったけどみあたりませんでした。QoSがあるときに云々というのはあるんだけど。

あ、思い出したぞ。富士通研の今井さんがやっているXCASTの仕事の導入部分
(ASM/SSMの問題点みたいなの)を読んで頂くと、きもちを共有できると思います。

とりあえず、sys/netinet6/ip6_mroute.c:ip6_mdq()のケツのloop見て下さい。
あと、最近N+Iに置いてあるでっかい高いルータはラインカード一本でGbEが100本出たりして
ラック一本あたりのインタフェース本数はむちゃんこ上がってますんでそのへんも注意。

>>944
XCASTはあくまでも少人数メンバー向けで有意義ですが、対象分野が異なります。
例に出ているような、TV放送を大人数に行なう場合には、

　・multicast group addressを用いるIP multicastの方がコスト的に有利
　・そもそも長さ問題でXCASTを適用することが原理的に不可能

となり、優劣や問題点を比較するというよりも、適用分野が全く異なるわけです。
したがって、それをもってIP multicast否定には全く繋がりません。

>>945
そのloopは、基本的には、単に全てのifに対して必要ならforwardするというだけです。

このような分岐ルータにおける最小限のコピー転送処理は、
XCASTにおいても、L7でのmulticast類においても、発生する必然の処理ですので、
それをもってIP multicast否定には全く繋がりません。

本質をきちんと理解していないために、反論が的外れになってきていませんか？

民放連加盟は約200社。マルチキャストも免許制導入なら何とかなるだろうが・・

だからマルチキャスト*も*アクセスまわりにしか入らないってば。

なんだかかみ合っていないですねえ。わたしスルー力低いなあ…

IP multicastを全否定した覚えはないし、XCASTラヴでもありません。
どちらも領域によってはうまく使えるところがあると思います。
ただし、
- 普及させるにはいろいろと解決しづらい障壁があり
- それを原因としてPIM6を動かしたくないひとがいる
- だから、そこらじゅうでlink localより大きいスコープのmulticast routingが動いていると
仮定すると動くはずのものも動かなくなりますよ

ってくらいのつもりだったんですけど。なんか外してる?

>>949
具体的に問題点を指摘するなり技術的に説明するなりすべきですね
もちろん可能ならば解決案なり別の代案などを述べるとベター

それを言わずに曖昧に障壁があって動かしたくないというレベルだと
まるで現状のIPv6の状況と全く同じです

IPv6に乗り気でない人たちから同じ態度を取られた場合を想像してみて下さい

技術的問題点はいろいろ出したはずです。代替案はちょっと考えさせてくださいね。

いつのまにここが盛況に。

>>933
Mergeは指をくわえてみてることしかできませんが、完了を待ってます。

>>885
802.16系やFlash-OFDM改な802.20だとそんなに相性悪いとも思えないけど、キャリアが公開するのはAPIだけだと思います。
RNC以外もひらくの嫌うったらありゃしない。

>>952
MIPのFastHandOverへのアプローチはいかに早く送り先を切り替えるか。
それに大してITUのアプローチはとりあえず両方に送って、
受けた方で合成するなり、一個に絞るなりの処理をする。
この２つ方法って排他的で相性がわるいから、移動音声通信に限って言えば
無理してMIPを使わずに上下レイヤにお任せすればいいかと思いますた。
IEEEはごめんなさい、勉強不足です。韓国とかでは充分な実装実績あるはずなんですが。
ご存知でしたら教えてください。

>>ALL
マルチキャスト≒放送という既存概念で話を進めるならTVBANK社のgridvodが
ひとつの代替実装案としてありえるんじゃないですか？網に比べたら
端末のスペックの方が余ってるわけだし。こんな実験してる時点で
現場がマルチキャストの限界を感じてるとも取れる。

放送衛星：Broadcasting Satellite：BS
東京放送：Tokyo Broadcasting System：TBS

放送はブロードキャストじゃね？

>>955
言いたいことはあるんだけど、まあいいや。
じゃあ、どんなアプリで実装されると思う？
P2P(言葉としては破綻してるけど)やIM、ファイルシェア、テレカンで
実装したがってる人たちは居るみたいですが。

マルチキャストはブロードキャストではないから、IP放送は放送ではない。
ってのは結構重要な論点だ。事業者より役人のほうがここにはひっかかる。

　　　　　　　,ｒ::::::.... 　 ヽ:::, -── - ､:::ヽ::.ヽ ヽ
　　　　　 　 | 　　,' .: :, ‐' 　　　　　　　 ヽ::ヽ:｝i: l
　 　　 　 　 !:::...i/ .::/ 　　　　　　　 , -―ヽ:i::! !: !
　　　　　　│　 { ..:::| 　 ＿_　　　　'　　　　ﾘﾚ!| !l 　　　　さぁ、IPv6の議論を続けてくれさー。
　　　　　　 |　i .:ヽﾍゝ´　　 ｀ 　　 　イかﾘk|:: |:| !
　　　　　　 !| | {　|｀ｰ ,ｲ丞ﾃﾐ　　　　弋zｿ '|::: !i !
　　　　　　.!|.:|!::ヽ|　::|｀弋zｿ 　　　　　　 　 !:: |::|l
　　　　 　 l !::!..::::::|　::|.、　 　 t ― ｖ7　　　!::. !=' ﾆﾆ≠ ､
　　　　　 ,'//_,. -┤ ::l..＼ 　　｀ ‐ ‐' 　 ／.!::: !‐'´￣ へヽヽ__
　　　　　/／ ィ二.|　:::!:::...｀＞ｰ-　　 イ, .::!:　|｀!　　　　 ヾ=､､ヽ
　　　　.//／r'　 　|　:::l::::::::...＼　 　　 /.:: !::　|│　　 　 ,' 　, ヾ `
　　　 / ' ／丶:　　|　:::|　 　::....ヘ　　/ 　.!:::　| .|　　　 / ／
　　／‐'´　　 ＼:.　|　::::!　 　 ,, =､ > l〃~|::::　!.┘　　/ '

6LoWPANのRFCでも読めばいいじゃない

v6でライブの映像配信でも始めれば、それにつられてユーザが増えるかも…。
フレッツの動画配信もv6端末じゃないと見れないようにしようよ。

OCN IPv6つかっててコレガのCG-BARPRO6買おうか迷ってるけど
この機種2年も前のもので新製品が出るかもしれないと考えるとなかなか買う気が起きない
誰か使ってる人いる？

＞マルチキャストはブロードキャストではないから、IP放送は放送ではない。
確かにIP再配信問題、放送と通信の融合の方向性が見えんことにはな。
しかし既得益にしがみついてるとされてるのは民間放送事業者でないか？

>>954
わざわざそれだけのために>>954取らなくてもいいぞ。

今どきネットで垂れ流しの映像見るやつがどれだけいることか？
それこそスポーツやコンサートなどの生中継しかありえない
生中継以外はオンデマンドで見るよ普通

>>960
CG-BARPRO6をOCN IPv6で、たまに、使ってみてます。

普段は、RT-200NEでPPPoEやってて、IPv6
する時にRT-200NEと入れ替えというか、ケーブルを
抜き差ししてる（原始的だけど、問題が起きても対応
しやすく、安い）。

最初は、CG-BARPRO6でPPPoEやってたりも
したんだけど、設定が悪いのか？時間がたつと不調に
なるようだったし、構成によっては、電話が使えなくなるので、
こういう形にしてます。

CG-BARPRO6はDNSの代理？もやるようなんですが、
動作が変かも。Aレコード、AAAAレコードは
引けてもゾーン転送とか反応しないように見えるので、
IPv6パソコンではプロバイダのDNSを直接、参照するように
してます。

パソコン側は、IPv6が動けば、しばらくすると、
IPv6でつながるようです（localでないIPv6のアドレス取得に
時間がかかってるように見えます）。

Internet商用化のはじまった時代を思い出すというか、単なる
ユーザからみると、IPv6は、まだまだ、難しいのでしょうね。

持ってる方に質問。CG-BARPRO6のOSってなにベースですか? ほかの製品はLinuxだったような記憶があるんですが。

>>963
VODはユニキャストだね。なんか、どう利用されるか
という前提なしにマルチキャストの問題点は語れないと思う。

やっぱIPv6と言えば日立だよね！！

http://network.hitachi.co.jp/IPv6/index.html

http://www.iodata.jp/prod/network/wnlan/2006/wn-gdn_r-s/index.htm
この「IPv6ポート」って、単にBフレッツとかのPPPoEの口が見えるだけですか?
マーケティングに使ってくれるのは嬉しいけど、ちゃんとIPv6サポートしろよと言いたい。

>>968
「IPv6が使えるポート」というより「IPv4その他が全く使えないポート」という理解のほうが正しい。

>>964
プロバイダとの接続はほかのルータを使って
OCN IPv6への接続だけCG-BARPRO6使うことってできないの？

>>968
等価構成

　[IPv6対応ONU/CTU等]
　　　　　　　　｜
[IPv6対応3ポートL2スイッチ]-[IPv4ルータ]-[IPv4端末]
　　　　　　　　｜
　　　　　　　　└-(IPv6対応LANケーブル)--[IPv6端末]

>>971
ふふふ、思ったとおりだ(スネークマンショウ)
「IPv6対応LANケーブル」なところ芸が細かくていいです。嬉しい。

訂正! s/スネークマンショウ/S.E.T./

ONU/CTUとスイッチの間はv4/v6両対応のLANケーブルじゃないとまずいいだろ。

IPv6が流行語大賞に選ばれる頃には
LANケーブルのパッケージに「IPv6対応済」なんて文字が踊ってたりして。

実際、アナログ接続のヘッドホンに「デジタル対応」と書かれていたりするし。

IPv6対応LANケーブル（笑）

IPv6ではパケットサイズが増大するため、よりケーブルの品質などに配慮が
必要となります。

この度、弊社はIPv6時代に必要となる高品質ケーブルの開発を行い、世界に先駆けて
その実用化を達成いたしました。本ケーブル、Cat6v（仮称）は純度99.99999%の
高純度銅を信号線に利用し、外周のシールドは金沢の金箔師による技術指導を受けて
製造のアルミ箔により、ノイズ遮断率98.19%を達成しております。これにより
パケットの欠損率は従来の1/30と著しく低減させることに成功しております。

現在、IPv6評議会などを通して、本ケーブルを国際規格Cat6の拡張として
Cat6vとする提案活動を行っており、インターネットの新時代を切り開くための
重点分野として今後も積極的な製品開発を併せて進める所存であります。

・・・とか？

ただ「skype対応」と書いただけのヘッドセットが2倍以上の売れ行きだった
らしい。そしてそれがビジネスの本質だ。