IPv6スレ ver3
>>903
挙げられている問題は全部「IPv4だろうとIPv6だろうと難しい問題」です。
MIP4もMIP6も、結局は「大多数の計算機は固定で移動するやつは少ない、
だからbinding cacheは小さい」「IPアドレスを変えると通信に支障が出る」
という仮定にたっていますが、前者は多分今後は違うし(中国VoIP携帯10億台)、
後者はsession layer protocolで解決すべき問題です。
IP multicastは本質的に困難な問題を含んでいます。
全ルータがIGMP join/leaveを拾ってmulticast forwarding tableを持たないといけませんが、
これはmulticast listenerがどんどん送ってくるので、ルータに設定されてしまうtableのサイズに
上限がなく、さらに集約できません。ので、ルータに負担になる。
一部ISPでは運用してますが、なかなかいいアプリケーションがみあたらないというのが
実際のところではないかと思います。
もちろん、「みんなが同じ番組を観る」のなら多分うまく動くんですが、
普通TVのチャンネルはばしばし変えまくるでしょ?
IPsecの普及のためには、鍵交換というどうやっても解けない問題を解かないといけません。
opportunitistic IPsecみたいにDNS databaseにとりあえず突っ込んでおくとか、
sshみたいに初回は「こんなfingerprintだけど繋いでみるかね」みたいにして
認証のめんどくささを弱める方策を使わないとうまくいかないでしょう。
それから、IPsecはあまりに暗号化が普通のユーザの下の層でやれられるので、
「sshって打ったから暗号化されてるもんね」みたいな上手なUIがないとちょっと
難しいところもある。
あとはX.509みたいな階層構造よりはpgpのchain of trustをうまく作れる
方法があればいいんじゃないかと思います。
これはちょっと野望があるのですがどうナンパすればいいのか模索中。
IPv4延命策とIPv6と比べてどうかって? そんなのIPv6が勝つに決まってます。
なんぼ延命しようとも、中国のVoIP端末10億をうまく取り扱うには10.0.0.0/8では足りないので。
挙げられている問題は全部「IPv4だろうとIPv6だろうと難しい問題」です。
MIP4もMIP6も、結局は「大多数の計算機は固定で移動するやつは少ない、
だからbinding cacheは小さい」「IPアドレスを変えると通信に支障が出る」
という仮定にたっていますが、前者は多分今後は違うし(中国VoIP携帯10億台)、
後者はsession layer protocolで解決すべき問題です。
IP multicastは本質的に困難な問題を含んでいます。
全ルータがIGMP join/leaveを拾ってmulticast forwarding tableを持たないといけませんが、
これはmulticast listenerがどんどん送ってくるので、ルータに設定されてしまうtableのサイズに
上限がなく、さらに集約できません。ので、ルータに負担になる。
一部ISPでは運用してますが、なかなかいいアプリケーションがみあたらないというのが
実際のところではないかと思います。
もちろん、「みんなが同じ番組を観る」のなら多分うまく動くんですが、
普通TVのチャンネルはばしばし変えまくるでしょ?
IPsecの普及のためには、鍵交換というどうやっても解けない問題を解かないといけません。
opportunitistic IPsecみたいにDNS databaseにとりあえず突っ込んでおくとか、
sshみたいに初回は「こんなfingerprintだけど繋いでみるかね」みたいにして
認証のめんどくささを弱める方策を使わないとうまくいかないでしょう。
それから、IPsecはあまりに暗号化が普通のユーザの下の層でやれられるので、
「sshって打ったから暗号化されてるもんね」みたいな上手なUIがないとちょっと
難しいところもある。
あとはX.509みたいな階層構造よりはpgpのchain of trustをうまく作れる
方法があればいいんじゃないかと思います。
これはちょっと野望があるのですがどうナンパすればいいのか模索中。
IPv4延命策とIPv6と比べてどうかって? そんなのIPv6が勝つに決まってます。
なんぼ延命しようとも、中国のVoIP端末10億をうまく取り扱うには10.0.0.0/8では足りないので。
|
|
|