/home/pochi/ChangeLog / 2006-01-19
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
2006-01-19 Thu
■ ガンダムバー、Zion と 連邦軍 [食事][ネタ][ガンダム]
http://www.geocities.jp/riped_sin/gundam_shotbar_zion.html
「ガンダムバー」でYahoo!検索
先日の前夜祭で行けなかったので([2006-01-18-4])、
4人で連れだって行ってきた。
最初は「Zion」。
店に入るとプラモデルがいっぱい。
ジオラマもいっぱい。
最初に、「上等兵」階級章が貰える。
スタンプを3つ溜めると、次に来たときに昇進するらしい。
半年来ないと降格する。
でも仙台なんて通えないよね。
オリジナルドリンク「ガルマ様の仇」を飲む。
甘かった。中身は軍事機密らしい。
黒い三連星はちゃんと3ドリンクだった。
馬鹿すぎる。大笑い。
お金持ち向けのメニューとして、デギン様のドンペリがあって、
なんと15万円。飲む人いるのか？
ついでに近所にある「連邦軍」へ。
JANOGの参加者が沢山。
連邦軍の最初の階級章は「三等兵」。
ドリンクメニューは Zion とほぼ一緒。
Zion でのビールは「シャア専用○○」という名前が付いてたけど、
連邦軍でのビールは「ガンダム○○」という名前が付いていた。
連邦軍はモビルスーツの数が少ないのでジム重装型とか、
わりと無理矢理名前を付けていた。
「白いやつ」というオリジナルドリンクはやっぱり白かった。
こっちも中身は軍事機密。
連邦軍にもお金持ち向けのメニューがあって、
レビル将軍のドンペリがやっぱり 15万円。
いやー、楽しかった。
こういうコンセプトのバーは他にも結構作れるかもしれんなあ。
- 北斗の拳バー
- 仮面ライダーカフェ
このへんならいけるか？
誰か東京に作ってよ!
■ JANOG 17 懇親会 [JANOG]
ご飯あまりすぎ。
牛タンも売れ残ってしまった。
年齢層が高くなったせいかみんな思ったほど食べない。
昔はみんな食いまくってたので、炭水化物を多めに〜、
とか業者に頼んでいたのが嘘のようだ。
■ TSR-MS4R MPEG-4 ネットワークビデオサーバ [道具]
TSR-MS4R MPEG-4 ネットワークビデオサーバ
控え室で会場の様子を見るために設置してあった。
内蔵のカメラはしょぼいけど、ビデオカメラと組み合わせて
使うのはかなり良さげ。
職場の総会の中継のときはIEEE塔載のノートPCで
エンコードしたんだけど、(-->[2004-10-24-1])、
このビデオサーバがあればノートPCが不要だよな。
いいかも。
■ JANOG 17 1日目 [JANOG]
書きなぐったメモを吐き出し。
ちょっとずつリライトする予定。
○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 がちゃんと
用意してくれると思うんですわ。
ただ裏側の人は頑張らないとね〜。
2021 : 01 02 03 04 05 06 07 08 09 10 11 12
2020 : 01 02 03 04 05 06 07 08 09 10 11 12
2019 : 01 02 03 04 05 06 07 08 09 10 11 12
2018 : 01 02 03 04 05 06 07 08 09 10 11 12
2017 : 01 02 03 04 05 06 07 08 09 10 11 12
2016 : 01 02 03 04 05 06 07 08 09 10 11 12
2015 : 01 02 03 04 05 06 07 08 09 10 11 12
2014 : 01 02 03 04 05 06 07 08 09 10 11 12
2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12
2004 : 01 02 03 04 05 06 07 08 09 10 11 12
最終更新時間: 2021-03-02 14:20