書きなぐったメモを吐き出し。
これもちょっとずつリライトする予定。
2日目の午後は眠かったのであんまりメモれてないっす。
○前説
開始10分前の橘さんのトーク。定番。
○BGPの更新情報による障害検出
経路更新情報の通知は1日に20万回
BGPルータから得られる情報のみを使って運用上有用な情報を抽出してみる
Peer に着目
ツールには BGPView を使用。
経路情報を2次元テーブルに落として、その2次元テーブルを
時系列に沿って比較することで、経路の変化を見る。
インパクトの高いASやPeerから大きい影響を受けた
BGPの経路図が作られる。
場所がわかれば回避が可能になるかもしれない
[課題]
更に多くの具体例の解析が必要
リアルタイム性が欲しい
パケットの遅延情報を指標に加えてみる
[Q&A、コメント]
指標は面白い。
オペレータ的には実トラフィックに目が行きがち。
NANOGとかでもやっていることとの違いは？
3回に1回ぐらいはそういう発表がある
スラマーのときのデータは解析すると面白いかもしれない。
停電のときの解析は始めてきいた。
なんで自分達でやっていなかったのか、と思った。
リアルタイム性ということだが、
今はどのぐらい時間がかかるのか？
--> その日の情報を読みこんで、、、、
半日ぐらいかけてまとめて計算する。
--> 1日分をまとめて、なので細かく計算すればもうちょっと速いかも。
パケットの遅延は、ランディがハッピーパケット、とかで調べてた。
ウイルスネタで。
影響がある場合もない場合もある、とか。
--> ランディがハッピーパケットでは、
あんまり影響ないって言ってるけど実は結構変動する
ASがリルートするときの影響かな。
ASの持っているネットワークの大きさ、というのも指標になるかもしれない。
ちなみに持っているネットワークとトラフィックの相関はない。
直近では経路変動による負荷が処理に与える影響もある。
ASの重み付けを単純に prefix の数で見るだけでも良いかも。
アドレスの数ではなく、経路情報の数がインパクトに与えているのかな、
と思った。
ベスト経路への切り替わりという例もあるので、
切り替わった ＝ インパクトでもない。
経路情報は他のところのデータもあるので、活用してみれば？
観測点を増やすと精度が上がるか？
--> もっと多くする予定だったが、進行の都合で2点になってしまった。
エンドユーザーへのインパクトという視点も必要かもしれない。
重み付けに工夫をするのも面白いかも。
Google とかは重くするとか
DNSが動いているところとかを重みを付けるのも良いのかな。
--> Mとかなら重みを付けるのはできる。
--> 今回の研究では重みはあまり考えていない。
--> 現実的には重み付けはすぐできそうなのでやっていこうね
BGP anycast をやっているところとかは見えるのか？
--> 多分見えないんじゃないか？
--> 1つの観測点でしか見ていない
--> AS Path が変わらないと検知できない。Path が変われば見えてくる
BGP anycast がほんとうに動いているか気になっている。
解析してみると面白いのかな、と。
○Ethernet LAN の憂鬱
Ethernet で作るといろいろ問題が起きる。
VLANを使う大規模LAN
VPI(Vlan Port Instance)の上限が以外と厳しい
Cisco だと必ず考慮する
VPI = Trunkポート数× Trunk内のVLAN数 + Non-Trunkポート数
MSTIの割り当ては十分に検討する
IEEE802.1sでは64MSTIまで
機器によっては、16程度になってるのもある
エッジポートの挙動などが規格と違っていたり
MSTIに対するVLANの割り当てを後から変更するのは大変
ハートビート用VLANに注意
MSTIを分けないとモジュールフェールオーバーで
MSTI内VLAN全体のトポロジーチェンジが起こる
インスタンスを食うのはやめて欲しい
MST以外のベンダー独自多重化プロトコルの問題、仕様に注意
リンクアグリゲーションの問題
スイッチ以外も考えないといけない。LACPを実装していない機器とか。
セッションテーブルを作る機器とか。
IPチェックサムなんかが問題になることもある。へぇー。
箱への要望
キャパシティ
CPUを高速化して欲しい
相互接続をもうちょっと
Ethernet への要望
誰かTTLをください
BPDU性善説というのもどうなのか？
いつまで STP なの？
IEEE802.1ah、ITU-T Y-17、etthoam?
早く Ethernet Ping が打ちたい
最近気になっているのは？
TRILL (Transparent Interconnection of Lots of Links)
IS-ISベース？でトポロジ管理をする
GMPLS for Ethernet
自由にパスが張れるようになると面白い
Ethernetは大変
考えないといけないことが多い
原因救命が大変
トラブルを避けるために冗長を止めようかな、みたいな
[Q&A、コメント]
TTLには大拍手
Ethernet の装置なのに L4 まで見る装置なんてものもある。
トラブルシュートのときにとても困る。
余分なところまで見ないで欲しいな、みたいな。
憂鬱プラス1、みたいな。
Ethernet Ping はやっぱり欲しいなあ。
--> どんなルータでも ICMP Ping が入っている。
--> 安いスイッチにも入るようになって欲しい。
パケットリオーダーの話を聞くたびに思うけど、
パケットリオーダーがどのぐらい必要？
あんまり気にしなくても良いんじゃないか？
--> テレビ会議システムの過去の例。突然落ちちゃうってことがあった
--> 世の中が TCP や UDP だけじゃない場合もある。
ポート何番だけとか
--> そういうのを見るとリオーダーありえないよね、とかなっちゃう。
IETFはL3の規格を作るところ。
そこが Ether に介入してくる動きなのかな。
変に上位層が介入するのは問題があるのか？
--> 憂鬱が解消されるならなんでも良い。
--> ステートフルにして欲しい
Ethernet の Plug & Play を考えないといけない。
そのために犠牲にしなきゃいけないことは多い。
IPはわけわかんないのは捨てられるけど、Ether は通さないといけない
IPでいいじゃん、とか言いたい
--> 現実的には Ethernet しかない。
--> iLink？ IP over IEEE1394。C社さん出してくれないかな。
○.JPアップデート
中国が100万ドメイン。
アジアのトップじゃなくなった。
大きく水をあけられた。
日本語ドメインも増えている。
JP DNS の更新間隔が大幅短縮
15〜30分間隔での更新へ変更
2006年4月頃開始目標
in-addr.arpa. の変更はなし
JP DNSは、すべて BIND 9 に変更
jp のみのシングルゾーン化
現在は、64ゾーン
BIND9化は3月中にやる。
そのときにシングルゾーン化も行なわれる
SOA を UNIX epoch からの秒数へ変更
YYYYMMDDNN の10桁 --> UNIX epoch
minimum値を900秒(＝15分)に短縮予定
現在は86400秒(＝1日)
実装の関係でそれほどインパクトはない
TTLは変更なし86400秒(＝1日)
BIND 9化の影響
JP DNSの XXX.in-addr.arpa が100% グルー無しになる
DNSサーバーの不適切な設定に対する措置
ドメインハイジャック問題
危険なDNSサーバを削除している
機械的に月1回やっている。
ただしJPドメイン名以外だと無力
すでに乗っとられているものとかも無力
Root DNS サーバ、いわゆる M を WIDE と共同運用することになった。
[Q&A、コメント]
SOAのタイムの短縮は大歓迎
現在は手遅れになってから相談されることも多い。
シングルゾーン化はどうありがたい？
--> BIND 8 と挙動を合わせるため
○インターネットガバナンスアップデート
[キーワード]
WSIS - World Summit on the Information Society
ITU管轄の国連世界サミット
WGIG - Working Group for Internet Governance
国連事務総長直轄の検討部会
[チュニス会合で何があったか？]
Issue Papers のとりまとめ
--> 良い整理ができた
IPv6アドレス管理
中国がRIRシステムに加えて、ITU-主権国家による管理の併用を主張
--> 特に何か起こる気配なし
ICANNの統治
米国商務省契約をどう変えるのか？
Zone ファイルの編集権を米国商務省が握っているのはどうするのか
外交カードとして使われる可能性がある
--> もつれた
Issue Papers
インターネット？というのものもある。
それだけ広範囲になっている。
チュニスサミットのコメントは総務省に和訳がある
国際連合管轄でインターネットガバナンスフォーラム(IGF)を設立し、
5年間維持。
--> WGIGの発展的延長
ICANNは当面現状のまま維持する。
決議日の前日までもつれていた。
チュニスアジェンダ35項
技術的側面、公共政策的側面がある
ブレイクダウンして良くかけている
[10年ぐらい前と比較してみる]
10年前
名著「インターネット参加の手引き」
作り手 ＝ 動かし手 ＝ 使い手、の名残を噛み締めながら
ユーザーが当事者意識を持って動かしていた。
現在
インターネットは縁の下の力持ち。
つながってあたりまえ。
[チュニス会合の意味]
インターネットが政策課題、外交カードの一つになった
政府には政府の「インターネットの意味」
国際的な公共政策議論にはまだ時間がかかる
米国支配体制をどうするか
発展途上国に理解してもらうまでにはもっと時間が必要
技術課題、技術政策は民間セクターに託された
○プロバイダーエッジ2重化
構成2パターン
VLAN + VRRP
BGP2セッション
2重化のモチベーション
- 故障交換
- バージョンアップ
- 他者(メーカー)のせいにしない
よくなかったことは机上では出てこないけどやるといろいろ出てくる。
技術的な問題もそれなりに。
対外的な問題もある
まあいろいろ。
2重化すると、、
運用性、運用レベルは上がる。
でもコストも上がる。
市場の評価は上がる。多分上がっている。
[Q&A、コメント]
metric は Type2 でやっている？
--> 2でやっている
static が消えない問題。銀色の箱で問題があった。
トポロジによってはルーティングの問題になる可能性がある。
--> PE1とPE2のリンクがない場合にループになるかもしれない
メイン側を再起動しているときに OSPF が安定せずに、
問題が起きることがある。
どうやっているのか？
--> 壊れるときはどうしようもない
--> メンテナンスのときは、寄せてからやっているので大丈夫
/29で余ってしまう、という問題があったけど、
お客さん側でルータを2台用意する、というケースもある。
--> そういうお客さんもいる。ただし個別相談。
VRRPではなくHSRPで提供していたときに、
keep-alive が別のソリューションとぶつかって流れずに、
うまく動かなかったことがあった。
ユーザーさんも2重化すれば良いんじゃないかという話は
ああそうだなあ、と思う。
ただしキャリアだけが嬉しいのはアンフェアな気がする。
お客さんから見て嬉しくなるように見せないと。
まとめる箱をどこが用意するのか？。
キャリアが用意するのは大変だし、まとめるとシングルポイントになるし。
static が消えない問題だが、
インターフェイスで指定すれば消えるのではないか、と。
destination を IP address と Interface にすれば良い。
メンテナンスの時は、戻すのか？
倒しっぱなし、というのもありでは？
--> 戻している
PE1とPE2は同じラックにあるのか？
--> 地域分散はしていない。
--> 要望があったらもう1つソリューションをかぶせている
2重化したので、24時間保守を止めたりするようなことはあったか？
--> あったりなかったり
狙っているのは顧客満足。かなり上がっていると思う。
客観的にも結果が出ている。見習っていこうと思っている。
--> お声をいただければ検討する
○NSP-SEC-JP
メンバー
現在 25名
Vender 3社
Team Cymru 1名
bogon route-server を東京に設置、世界で5台目
IRCで発表者と雑談をしながら聞いていたので、
このセッションはちゃんとメモをしてない。
でもまあこのセッションは仕方ないよね。
かなりゆるーくやってる感じなのに、予定どおり進むのは、すごいわ。
さすがだよなあ。
[Q&A、コメント]
bogon route-server に誰が登録しているのか？
--> 5台あるので、IANA が登録するときのタイミングで登録される。
bogon のフィルターは世界的にはやる方向なのか？
--> まだ現実的にはそういう段階ではない
--> スタティック等、それぞれでフィルターをかけている。
--> みんな困っているので、ダイナミックにやりたい、
という思いはみんな共通
アドレスが止められてるときに、ベンダーさんの
サンプルコンフィグを見て、過去の情報が
流通するようなことがある。それへの対応は？
確認する方法は？
--> 情報をなるべく早く公開することは考えている。
uRPFのVRFモードというのを検討している。
uRPF 対応はアクセスライン業者のほうでも対応をお願いしたい。
[まとめ]
エッジでフィルターをやっていきたいと思っているので、
ベンダーへの対応をお願いしたい。
どういうパケットがドロップしているか、等も取得したい。
○JPIRR、IRRセキュリティ
吉田さんとICカードをランディにかざしていた木村さんのセッション。
登録オブジェクト数は着実に増えている。
大手ISPが登録したので昨年末に一気に増えた。
個人情報保護対応をした
Mail-From 認証を廃止
CRYPT-PW または PGPKEY の利用に移行
inet6num オブジェクトの登録を2/1に開始予定
CRISPのRFC化にむけた提案活動
どこかのWHOISを1つ叩くと、そこから再帰的に検索して結果を出力
ごみオブジェクト問題
オブジェクトに有効期限を設ける
更新期限日移行、一定期間を経過したオブジェクトは
IRRデータベースから除去
経路情報が存在していれば、更新されていると
見なされるような仕様はどうか
正式サービスへの移行を検討中(2006年7月予定)
信頼性の高いIRRへ向けた取り組みを続けていく
日本の経路台帳としての役割を担うようにしていく
route authorization
IP指定事業者が管理下のprefixの経路広告をAS管理者に対して認可すること
なにが嬉しいのか？
フィルターが正確に書ける
経路ジャックの検出・防止ができる
Secure BGP の実現
IP指定業者の証明書利用「認証強化実験」を実施中
ICカードで認証
普段は見えないメニューも見えるようになる。
[Q&A、コメント]
JPNICから割り当てられたアドレスについては、
指定事業者が許可しないと世の中に出ていかない。
正確には IRR に登録できない。
マーケットが納得するかどうか。
ごみオブジェクトの本質的な問題は、権限を持っている人の
問題のような気がする。
--> 忘れないようにリマインダを送るという意味もある
あまり縛りをきびしくするとビジネスをする人と
技術の人でやりあいが発生するんじゃないか、という気がする。
--> なるべく縛りをゆるくするために、この範囲内で、
というふうにしている
--> 担当者が違うという問題はたしかにある。
他から発行してもらった認証局の鍵を使いたい。そういうことは可能か？
--> 今のところ JPNICの鍵を使う
IRRが完全でない場合は、ORIGINのチェックに使えない、
とすると効用がない。
ニワトリと卵になりそうなんだけど。
--> すべてやろうではなく、この仕組みをうまく使って
経路情報を作れれば、と思っている。
--> JPNICで作っていく情報はいろいろ使えると思う。
--> 日本で経路情報をきちんとまとめていくことをしたい。
有償化、という動きはどうなっているか？
有償になった場合には参加するモチベーションは低くなりそう。
登録ではなく、見るために利用するわけだし。
--> JPIRR の有償化は、JPIRRに登録すればOKってことなら
なんとかなるけどそんなことはないので、、、、
そのラインではあきらめた。
--> IRRもちゃんとしなきゃいけないしユーザーも
ちゃんとやらなきゃいけない。
--> JPIRR の活動は、高機能化というのと、
ユーザーへのフィードバックという方向で
やっていこうかと思っている。
○高速ネットワーク切り替え
最近のインターネット
- リアルタイムトラフィックの増加
- ミッションクリティカルなサービス
いかに切断を検知するか。
IGPやBGPの正常性確認機能が使える。
Hello とか Keepalive とか
デフォルトだと時間が長い
短くして試してみました。
最短時間
Cisco : インターバル 1秒、ホールド 3秒
Juniper : インターバル 2秒、ホールド 6秒
※20秒以下だとフラップするから良くないよ、とか言われる
相互接続の問題はあるがそれなりにうまく機能した。
1秒以下の切り替わりってできない？
--> BFDというのがある
Bidirectional Forwarding Detection
障害を検知することのみを目指したもの
IPレイヤ上で動作する
かなりうまく機能した。
[Q&A、コメント]
update が来たときに CISCO と Juniper で実装が違う。
keepalive を短くしたときに悪影響はないか？
-->正直わからない。ご存知のかたは？
BFDにグっときた。
実環境でやったときに問題になることは？。予測とか。
-->ラボの中ではちゃんと動きました。
BFDで障害を検知したときに BGP のセッションを
切るというけどインターフェイスは上がっている。
reconnect とかの変なことにならないのか？
--> retry は行なっている。装置によって違う。
○高速光切替素子による信頼性向上
今の JPNAP のトラフィック。--> 100Gbits/sec!!
Layer1 による切り替えをする
MTTRに焦点。平均回復時間。
Layer2 以上は頑張ってるけど Layer1 はいまいち。
光スイッチで切り替えると障害が早く回復できる。
802.1abでトランクする装置が欲しくなった
2ch は作ったけど 4ch、8ch は密度的にきびしいかも。
[Q&A、コメント]
サブ側に光が出てなかったら切り替わらないの？
--> そうなっている。光が出てなかったらトラップが出るので修理に行く
組み合わせたときにどうなるか。たとえばさっきの BFD とか
--> 調べてみたところ 50ms 以下であれば link-down を検知しない。
光のレベルはなんともないのにリンクダウンするということが
多発している。
光のレベルを見ているということだけどそういう事故はどうなるか。
--> レベルは変更できるけど波形は見ていない。
--> その場合はスイッチで検知
NTT-ATさんのものはそんなに安くない気がする。ペイできてるの？
--> 10Gならコストに見合う
--> G でも2、3年で償却ならなんとかなる。
--> 簡単なスイッチは今は実は意外と簡単に作れてしまう。
産総研あたりは良いスイッチが作っている
--> 箱にしてください。それならうれしい。
この手のスイッチでメタル対応のものはあるか？
--> メタルのソリューションは聞いたことはない
--> メタルは一社だけある。実は試してない。
光のデバイスを作ってるの後で相談させてください。
切り替わったときのリスクはあるか？
--> MACアドレスを忘れてしまうので若干fludする。
--> ただ IX の場合はトラフィックがすごいのですぐに学習する
JANOGでは WG という仕組みがある。
こういう実験ネタがありましたらよろしくお願いします。
光スイッチのIX以外での使い方。他の用途とかは？
--> ヨーロッパのアムジックスでグリマーグラスという
3DMEMSのスイッチを使っている。
3DMEMSは遅いけど複雑な制御ができる。
光スイッチがシングルポイントになるのが気になる。2重化との葛藤は？
--> IXのトラフィックは多いので、10Gの機器を2個買ってください、
とは言えない。
同時に切り替えたときに問題はないか？
--> シャシーごとに切り替える機能はある。特に問題はない
シングルポイントフェイラーになる、という話があるけど、
そういう話が出るのは日本だけじゃないか？
アメリカ人なんかは、うちが壊れたら隣がある、とか平気で言う。
リングが2つあるから同時に繋げ、とか、
自助努力を大切にするのが世界的な流れ。
-->回線が高いのでは？
-->機器も高い
-->民族性だと思う
○クロージング
参加率が異常に高い。
次回は東京開催。
パナソニック石油ファンヒーターを持ってたら型番を調べてね。
書きなぐったメモを吐き出し。
ちょっとずつリライトする予定。
○JANOG Update
内容盛り沢山
- 年齢層が上がっている。みんな年をとった？
- サーバーが新しくなった
- JANOG Comment が増えた
- 個人情報保護法対応のドネーションプログラムへの
協力ありがとうごいました。
- JANOG 20 のスポンサー募集。18、19は決まってる。
○ランディネタ
ISPの視点で「ルーティングセキュリティ」について考える
IRR だけでは不十分。
なんらかのベリファイ手段が必要。
X.509 を利用するのはどうか？
アドレスの割り当てではうまく機能している。
問題は、計算が大変なこと。
更新時、障害時に大変なことになるかも。
でもムーアの法則があるから大丈夫
[Q&A、コメント]
IRR でもいけるのでは？
--> 登録しない ISP、具体的には Sprint とか UUNet とかがねえ
JPNICのカードが証明書になるかも。
RFC3779に対応する予定。
○IPアドレス設計
IPv4をどう効率的に使うか？
どういう風に使っていくか？
IPv6とのデュアルスタック環境を考えたときに、
どういう風に使っていくのが良いか？
以下私的なまとめ。
要はIPアドレスというリソースをどう効率的に使うか、
で、どううまくデフラグするか、という話っぽい。
ファイルシステム等であれば、OSがうまくケアするんだけど、
IPアドレス空間を管理するOSっていうのはないしなあ。
なんとか手作業でできる範囲でもあるし。
IPv6になったら多分アドレス管理を効率的に行なうための
OSみたいなものが必要かも。
なんでアドレスの使い方を綺麗にしなきゃいけないか、
というと、以下のような理由。
- アドレスを一見してわかるようにしたい
- 効率的に使わないとアドレスのおかわりができない
- フィルター設定を簡単にしたい
オペレーション上の問題は多分以下。
- リナンバーが面倒
- チェックが面倒
これがうまく自動化できれば良い気がする。
以下のように管理するのが良いんじゃないかなあ。
- /24 とかのぐらいの小さめのブロックでアドレス空間をわける
- リナンバが勝手にできるアドレスと、ユーザーに配っている
リナンバが勝手にできないアドレスの空間はちゃんと分けておく
- アドレスが足りなくなったら、小さめのブロックをその都度追加で配る
- 配り方は、リーフ構造のような配置で配ってみるとか、
追加で配布したときになるべく綺麗になるような配り方をする
- 必要になったら柔軟にリナンバリングする
- アドレスのデータベースをちゃんと作って、使用用途等が
すぐわかるようにする
- リナンバの支援ツールを充実させて、ある程度自動化させる
- チェックももちろん自動化する。
- アドレス空間の使用状況等を可視化したり統計を取るツールを充実させる
本当はアドレス空間の管理なんかは、OS？にやってもらえれば
良い気がするんだけど。
CISCOが頑張ってくれることを期待してれば良いのかしら。
ちなみに IPv6 はリナンバしやすいような設計になっていて、
リナンバに関しては RFC4192 に定義されている。
○歴史的PI
かなり昔に配布されたアドレス(歴史的PIアドレス)をどうするか？
使っていないなら返却して欲しい
経路広告をしていない ＝ 使われていない、わけではない
JPNIC だけの問題じゃないよね？
--> APNIC とかでもあるけど、JPNIC は古くからやっているので
問題は大きい
お金の話が一切出てないけど、連絡するとお金が発生するのか？
--> 連絡を受けてすぐ、来年度すぐ、課金するという話はないけど、
将来的には課金したい。
公平にしたいために。
正直な人が損をしないようにしたいと思っている。
○IPv4/IPv6フォールバックの現状
IPv6の通信ができないときに、IPv4に切り替わってしまう --> フォールバック
フォールバックの原因
- タイムアウト
- ICMPエラー
ソフトエラー --> 再接続
ハードエラー --> 即座に失敗
ICMPエラーは RFC1122 で定義(IPv4 だけ)
IPv6 は今のところ draft
検証実験をしてみた。
Windows では IPv6 から IPv4 にフォールバックするまで
どのエラーケースでも20秒ほどかかる!!!!
ソフトエラーでもハードエラーでも一緒。
FedoraCora、FreeBSD 等でも実験。
早くフォールバックする場合もあるし、再送を繰り返す場合もある。
20秒の問題はユーザー利便性的に問題があるかもしれない。
ICMPv6 のソフトエラー、ハードウェアの場合の動作はどうあるべきか。
ICMPはアドレスが複数持つことを想定しているのか？
[Q&A、コメント]
Vista が来たときに、いきなり遅くなる、という苦情が来るかもしれない。
そうなったときにどうするか？という話か？
v6で繋がらなかったら、さっさとフォールバックしてくれれば
良いのになあ、とかも思う。
接続の状況は、OSによってもアプリケーションによっても変わる。
知見を詳細に教えて欲しい。
--> ここに出した以上は残念ながら言えないが、
たしかにアプリケーションで変わるのは事実。
Firefox と IE では挙動が違う。
.NET、光プレミアムあたりでは影響は大きいはず。
クローズドなところは返すエラーで工夫するので対応できるのでは？
--> それはあくまで暫定的な解だと思う
オペレーターが、ICMP を変にフィルターしないでちゃんと
通すということも必要かと。
IRSのほうでも知見をフィードバックして欲しい
retry はカーネルでやっているはず。
待つからいけないのでは？
4 と 6 を同時に投げて、とかすれば良いのでは？
--> サーバー側がいやがるのでは？
--> 今は、どういう風にフォールバックするかは、
アプリケーション側で決めている。
--> そのやり方を変えるのは結構大変。
実装として、ブロードバンドルータで適当に入れる、というも手かな、と。
○ドメインサーチオーダーとIPv6
クライアント側での名前解決に関する話
DNSには変なクエリが沢山来る
- Worm による大量クエリ
- しょぼい、ハード、ソフトによる大量にクエリ
クライアントのドメイン自動補完により、
1つの名前解決が、複数のクエリに展開される
Windows Vista は初期状態で IPv6 Enable --> クエリ2倍
自動補完により、解決できないと沢山引く。
まずは AAAA から引くので、解決するまでかなり遅くなる。
今は AAAA のクエリは2%〜5%だけど、Vista が来ると、
AAAAのクエリが増えるはずなので、いきなりクエリ全体が2倍になる!!
[Q&A、コメント]
実は2倍じゃなくて、20倍じゃなかったりしない？
この症状をマイクロソフトにフィードバックしている？
--> どうしましょう
--> プロバイダさんが受けとめてくれれば良いんだけど
--> まだβ版ですが
ドメインの指定を . で終わらせるとどうなる？
--> 基本的には挙動は変わらない
v6がちゃんと使えれば良いんじゃないか、ということで
Vista はこういう実装になっているのではないか？。
意味はあるんじゃないかなあ。
今この状態で Vista が発売されたときに
どの程度キャッシュサーバを増強すれば良いのか？
--> 相手の挙動によって違う。
中間管理職みたいなもので、上の問題でも下の問題でも
こけるのがキャッシュサーバ
AAAA に対して沈黙してしまう、Timeout してしまう
サーバーの場合はどうか？
--> その Timeout の分時間を待たされるのでは？
○IPv4が残り少なくなったときのことを考える
IPv6 の話はしない
IPv4 の枯渇問題は問題提起されから久しいけど何がおきるのか？
枯渇の時期の予測は行なわない
各会社・団体の問題については参考にしても掘り下げない
枯渇予想時期は、様々な予想では 2010年頃。
でもね、アドレスの需要がなくなるまでいろんなことが
起こりそうな気がしない？
外山さん
--> 枯渇する前の数年についての分析
藤本さん
--> 米国の動き
鶴巻さん
--> サービス提供の立場から
--> アドレス予測
[IPv4アドレスが枯渇する頃に何が起きるか？]
IPv4 のネットワークは半永久的になくならない
インターネット利用者も当面 IPv4 に体重を置く
IPv6 が普及するのは IPv4 が枯渇することが実感されてから
IANAプール --> RIRプール、の順番で枯渇する。
今後のフェーズ
1.枯渇に実感なし(今からしばらく)
2.枯渇のカウントダウン
3.IANAプール枯渇
4.RIRプール枯渇
5.枯渇後
トレンドに影響を与える要因
- Windows Vista
- プロバイダのIPv6対応
- 新しいサービス、ネットワーク、(FMC、NGNとか)の影響
- JP、APNIC地域だけじゃなく他の地域の話
- 使っていないアドレス
[ビジネスの動向からみたIPv4アドレス]
アドレスの確保加速
アドレス保有企業のM&Aとか
アドレスの価値の評価が始まる
アドレス売買市場形成
市場原理がアドレスの有効利用を促進する
IPv4アドレスは無くなるの？
なくならないと思う
無くなるとしたら
何億人もいる国にインフラを作ったり
新しいサービスができたり
[サービスから満たIPアドレスの需要予想]
日本の世帯の50%程度はインターネットを利用している。
日本のアドレスはざっくり /8 が7個ぐらい --> 1.1億個ぐらい
現在の1.5倍ぐらいのアドレスがあればサービスは
継続できそうな気がする
/8 が4つぐらい。
IANA では60個ぐらい残っている。
そのうち4つを拾ってくればOK？
新規サービスはサービスというよりフレームワーク、NGNとか、FMCとか
音声系を Full IP にすると、単純に 1.4億個必要、
でも会社の数があるからもっと多く必要。
新規サービスも IPv4 にすると /8が12個ぐらい欲しい。
でも他の国もあるから無茶。
好むと好まざるにかかわらず IPv6 でのサービス提供を考えるべき？
[Q&A、コメント]
かけこみ需要に対応するためにレジストリ側でも制限を考えたりするよね。
NGNとかいう恐しいキーワードもあるので、
IPアドレスはすぐ沢山必要になるかも。
IPv6 の技術開発を急がなきゃいけない。案外できてない。
IPv6の安心したプラットフォームができないとシフトできない。
お客さん的にはプロトコルはどうでも良い。
サービスのどれを入れようかな、とかいうのが普通。
6のテクノロジーを開発する、ではなく、
6から4へのNATみたいなテクノロジー、を開発する必要があると思う。
プライベートアドレスみたいな変な提案が出ないと良いと思う。
アドレスも国単位で閉じちゃう、とかそんなことがないと良いなあ。
新しい技術を移行するときに今まで使えてることができなくなる、
というのが問題。
v6のアドレスルールはビジネス的に首を締めてしまう気がする。
v6のアドレスはプロバイダでもアドレスを取りにくい
もっと敷居を低くして欲しい
欲しい人に出ていかない、というルールは誰も作りたくないと思うけど、
うまく調整できていないのかもしれない。
ポリシーも変わっていくはず。
特殊用途の PI のアドレスは v4 では出るけど v6 では出ない。
v6のサービスが始まってからポリシーが変わるのは困る。
悠長なことを言われても、ビジネス的には困る。
ポリシー作成にはスピード感を持って欲しい。
-->JPNIC的にはコミュニティが決めてくれればOK。
-->事務局ももちろん推進しないといけない。
--> ポリシーワーキンググループで推進しようとしている。
--> すり合わせに時間がかかる。これはテクニック。
NGNやらFMCはキラーアプリになるのか？
--> コンセプトがまだあるだけ。
--> 長いスパンで考えないといけない。
--> 4か6かについても考えないと
IPv4が1970年から2010年。40年ちょっと。
2010年に枯渇することにしちゃえば本気になる？
IPv6 fix とか。
同時に使う端末はそれほど多くない。
みんなが常時使うというモデルはネットワーク的にどうなのか。
常時待ち受けに使いたい、という人が増えてきているんじゃないか。
そうなるとプロバイダはますます儲からないなあ、と。
4じゃ駄目なら6で良いじゃん、が一番良いけど、
4が枯渇したときに6が駄目だったらつらい
アドレスがなくなったときにどうなるか？
規制、ブラックマーケット、、、、、
なにをやるにしてもコストがかかってしまう。
インターネットが社会的インフラだとすると、その上に
ビジネスが乗るはず。
アドレスに価値が出てくる、というのは悪いシナリオになるのかもしれない。
--> ブラックマーケットになるからいけない。
正当にやれば良いんじゃないか
国が規制をかける？かけて欲しくないよね。
なんでもインターネットというわけではない。
携帯はインターネットではないのにみんな使っているし、
お金にもなっている。
いろいろなやり方がある。
インターネットの隆盛は料金定額によるところが大きい。
ひょっとするとネットワークへの制約条件は、アドレス枯渇より
パケットの増大のほうが先に来るかもしれない。
6は6で世界ができてきている。
6はもらえたんだけど、4はもらえないんだよね、
というケースも出てきそう。
橋渡し的なプロトコルはあるのか？
--> 議論としてはないわけではない。
--> 今のアドレスルールのままいってしまう、ルールを変えていく、
という議論は誰もしていない。
スローランディングと言ってもランディングはランディング
4がなくなったから6に行こう、じゃなくて4でいけるなら4で、
ということもあるのでは？
v4がなくなる頃は僕らが信じているインターネットは
インターネットじゃなくなるんじゃないか。
アドレスはユニークだ、とかそういう常識が通じなくなる。
アドレスが使えなくなると、各国が勝手にネットワークを作っていって、
世界が割れちゃうんじゃないか、という気がしている。
アドレスが外交問題になるかも。
すでに南北問題というのがある。
アドレスを取れるときに取ってしまえ、という話はあるけど、
今のポリシーなら取れてしまう。
以下私見。
多分ユーザ的にはそんなに心配する必要はないんじゃないかなあ。
6と4のゲートウェイはマイクロソフトや Google がちゃんと
用意してくれると思うんですわ。
ただ裏側の人は頑張らないとね〜。
赤坂にて。
久しぶりに Pub になった。
業務内容の "publicity chair" が "public chair" と
誤記されててなごむ。
ん、デジャブ？
1年前と一緒じゃん。。。 --> [2004-09-10-2]
誰か直せよ。。。
http://www.janog.gr.jp/meeting/janog17/
届いた。
今回は強く強く推したいネタはまだないんだけど、
素敵なネタ持ってる人誰かおらんかのう。
- やっぱりプログラム担当は面白いね。
それなりに大変だけど、裏方は楽しいわ。
- タイムキープ、スタッフ間での連絡に IRC を
使ってるけど、やっぱり便利。
- ソフトバンクすごすぎ。それとも担当者がすごいのか？。
スポンサーをきっちり集めてがっつりまとめ上げてた。
- プログラムはネタに走りすぎかもね。
でも面白かったのでOKでしょ。
- 担当プログラムが1日目に終わると、2日目気楽で良い良い。
- ただ担当プログラムが4つ連続で続いたのはさすがに
つらかったかも。
- でも担当したプログラムはどれも安心できたね。
発表者に大々感謝。
- 個人的なベスト3は、野球、箱、ランディ。
- 前夜祭に参加できなかったのがとにかく残念。
やっぱり前日入りして観光しないと駄目だね。
http://www.janog.gr.jp/meeting/janog16/
○HRO話
JANOG13の続き。
資料は上司の説得に使えるぞ。
○IRR話
RADB から情報を消されちゃうと酷いことになる。
JPIRR に登録すると RADB にミラーされるので、
安心かと思いきや、直接 RADB に登録してないと、
駄目という ISP もあったりする。
そもそも IRR には、ミラーのミラーは行なわない、
という致命的な問題がある。
○IRR話 その2
経路のハイジャックを防ぐためには IRR は有効。
JPNIC で正式にサービスするよ、という話。
○UPDATE ライトニングトーク
JP* 等のインターネット団体からの UPDATE を、
持ち時間5分で発表。この形式良いかも。
JPNIC
JPNIC理事長変わりました。
どうでも良いですけど。(って言うなよw)
JPRS
汎用JPドメインの数が属性JPの数を2月に超えた。
日本語ドメインは毎年減ってたけど最近使えるように
なったので伸びてる。
検索エンジン対策とかに良いかも。
JPCERT/CC
TCP/1433 パケット増加中。
JANOG IRS Workshop
「読んできてくださっていると信じて、、、」
使えるな。
○IPv6話
アドレス割り当ての話とか。
良い復習になったかも。
IPv6は避けてきたんだけど諸事情により、
避けられない可能性があるのよね。
○個人情報保護話
JANOG での方針を作るときに、総務省のではなく、
経済産業省のを採用したのは、経済産業省のもののほうが、
わかりやすかったかららしい。
後で比較してみよ。
○NSP-SEC-JP話
この発表者達はさすがに安心感がある。
でも IRC でニコニコしながら遊ぶのはもうちょっと控えてね。
○100ギガビット話
夢のある話は楽しい。
でも数年後には夢じゃなくなっちゃうんだろうなあ。
で、その数年後には一般化しちゃう。
半導体にはムーアの法則、という名前付きの法則があるけど、
通信速度にも名前はあるかしら。
○DNSの逆引き話
BIND8 は捨てよう、グルーレコードもちゃんと書こうね、という話。
○野球中継話
やるぞ、と言って 1.5 ヶ月で作っちゃうってのはすごすぎる。
権利関係はやっぱり大変なのね。
○クロージング
次回は仙台。