1999/12/14(水)

←はじめに   1999/12/15(木)→
★Internet Week 99 私的レポート - 目次   ◎ほーむ


朝食は,横浜駅のドトールで.エスプレッソとサンドイッチ. 根岸線に乗り,桜木町駅で降りて会場のパシフィコ横浜へ.初日の今日は JANOG(日本ネットワークオペレーターズグループ)の主催するミーティング,JANOG5 に出席.

会場のパシフィコ横浜は埋め立てで造成した「みなとみらい21」地区にある. 昼,出歩いてみたところ, 輸入品を中心とした専門店が多数入居する「横浜ワールドポーターズ」を近くに発見した. ここの 1F ではワインの品揃えが豊富で,珍しいことに,250ml の小びんもたくさんあった.例をあげると,Rose d'Anjou, Medoc, George-Duboeuf の Beaujolais・Macon Villages.Bordeaux AC の Beau Rivages の 250ml ワインを1びん買った.380円.

パシフィコ横浜から駅へ歩くと,クイーンズタワー,ランドマークタワーの順に, オフィスビルが続く.一昨年と同様,クリスマスの飾りつけがされていたし, ランドマークタワー吹抜けではピアノの生演奏をやっていた.

新横浜駅前の商街「ASTY」を通ると,"Italian Quartier" という看板が見えた.そのまま通り過ぎたが, 変な名前なのに気づいて引き返してみると,実は "Italian Quarter" だったことが判明.このレストランで夕食.

新横浜プリンスホテルに宿泊.ここには4連泊した. プリンスという名前はついていても,ビジネスホテルの色合いが濃い. 部屋が広いのはよかった.

■JANOG5

JANOG と同様の北米の団体である NANOG のミーティングに参加した橘さんによれば,NANOG ミーティングでは Peering BOF と題する「お見合いパーティー」が開かれていたという. ピアリングを希望する ISP の人は名札に赤いシールを貼っておいて, 同じような人を探して,個人的に話してピアリングするというイベント.JANOG と違ってこのようなイベントが成り立つということは, 一次プロバイダがそれだけ多いということを意味するわけで, さすがインターネット先進国である.

マルチホームのパネルディスカッションが開かれた.ここでは, マルチホームを,アプリケーション層でのそれも含め, 「1ネットワークがインターネットへ二つ以上の到達可能性を持つこと」と広く定義した上で, その種々の方法について活発な討論がされた.

IP 層のマルチホームの方法としては,

  1. 二つのプロバイダからもらった PA (provider aggregatable) アドレスを一つのホストに両方付ける
  2. 片方の ISP の PA なアドレスブロックをもう一方の ISP にも広報してもらう
  3. PI (provider independent) アドレスブロックを両方の ISP で広報 (advertise) してもらい,IGP を使って経路をもらう
  4. PI アドレスブロックを両方の ISP で広報してもらい,private AS 番号を使って BGP4 で経路をもらう
  5. PI アドレスブロックを使い,global AS 番号を取得して BGP4 で経路をもらい,広報する
というものが紹介されたが,どれも欠点は多い.

一番スマートなのはもちろん (5) だ.が,この解には,どうやってプレフィクスの短い PI アドレスを取得するかという大きな問題がある./20 より短いプレフィクスでないと,アメリカの一部の ISP が経路をフィルターしてしまうという,嘘のようなほんとの話がある. 普通の組織が 4,096 もの IP アドレスを必要とするわけはないので, 取得は難しい.

ISP を立ち上げて,JPNIC の業務委任会員になることができれば, 最初から /22 のアドレスブロックが割り振られて (allocated),それを含む /19 がリザーブされるので, それを広報すればいいのだが,それも簡単ではない.

Historical に割り当てられた (assigned) クラス B を持っている組織は問題ないので,不公平感はぬぐえない.ただ, これらの PI アドレスがずっと使えるかという点は不透明である.

一方 (5) で必要になる AS 番号は,マルチホームするのであれば比較的簡単に APNIC から手に入れられる.不思議なことに,韓国は年間 AS 番号取得数が日本より多いそうだ.IP アドレスは,消費を節約する技術が広く普及したおかげでずいぶん余っているけれど, AS 番号にはそのような技術はない.先に枯渇してしまいはしないかと心配になる.

CIDR (classless inter-domain routing) はネットワークを木構造のものにしてしまうもので, ネットワーク層のマルチホーム技術とは相性が悪いことこの上ない. ネットワークそのものとしてはマルチホームが可能である以上, プロバイダでなくても可用性・接続性などの面からマルチホームがしたくなるのは成り行きだろう. 5, 6年ほど前,「これからは CIDR だ」と,JPNIC のポリシーを始め, 世の中の流れが大きく変化していくのを見ていて, その点をどう解決するのか不思議だったものだ. おそらく解は「場所によって経路表の見え方が全く異なる」という状態を積極的に作り出し, 活用するというアイディアを使うのだろうけれど,早く実現してほしいものである.

また,IIJ の山口さんからは, アプリケーション層の技術でマルチホームを実現するさまざまな手法が紹介された. NAT やアプリケーション層のプロクシなどを使ってトラフィックを分散させるという, 従来からある方法もあったが, 「銀行型」として紹介された方法は目新しかった.これは,DNS のゾーンファイルを

$ORIGIN ○×銀
www IN CNAME www.net
net IN SOA ほげ〜
    IN NS ns.isp1
    IN NS ns.isp2
として,それぞれの ISP に置いた HTTP サーバをそれぞれの ISP に置いたネームサーバで www.net.○×銀として見せるというもの.障害時には TTL だけ経てばもう一方にトラフィックが 100% 流れる.ただ,Windows などの DNS をちゃんと実装していないクライアントは, リブートまで古いアドレスでアクセスしてしまうという(私はテストしていないが). DNS を abuse しているようにも感じられるが, 現実的な解としてはきれいな方かもしれない.NAT を使ってぐちゃぐちゃになるのだけはやめたい.

ネットワーク界では古くから有名な mohta さんが, 大略「みんな『IP アドレスを節約しなきゃ』とお題目ばかり並べるが, そんなことは本当は誰も思っていない. 世界では経路表のサイズがどんどん増えているのだから, 我々もどんどんマルチホームすべきだ.それなのに NAT とか使ってマルチホームでもインターネットでもないような方法を提案するのは恥ずかしくないのか」と, いくぶん激しい言葉で批判していた. しかし,そういう方法でも仮に要求仕様を満たせるとすればそれでよいはずで, 当たらない批判だろう.

マルチホームはメリットはあるけれど,監視などにかかるコストも大きくなり, それを認識した上で導入すべきかどうか検討する必要がある. それでやると決意したならばぜひやるべきだというパネラーの中川さんの発言には, 全面的に賛成したい.

昼食後,Crayfish の南さんから, マイクロソフトのサーバ製品を運用する上での情報提供があった.

MS の製品はいろいろ言われるけれども,Solaris より Windows NT の方が素人には使いやすいし,認知度も高いのではないかという指摘.

発表者によれば,NT 3原則,すなわち

  1. 十分すぎる,むしろ過剰なメモリを積む
  2. 十分すぎる,むしろ過剰なディスクを積む
  3. 十分すぎる,むしろ過剰な CPU を載せる
さえ守れば NT でも平気で,コストパフォーマンスも高いという.

なおセキュリティホールは必ずふさぎ,チューニングをするとよいという.

会場から,「月一回のリブートはした方がいいのか?」と質問があった. 答えは,「週一回くらいでリブートした方がいいという人もいる.しかし,msn では1年止めていないという話」とのこと.大丈夫なのかなあ.

Fastnet の荻野さんからは,ウェブアクセスが快適な経路が欲しいとき, AS_PATH の段数,RTT, traceroute の段数のどれの大小を調べれば,TCP のコネクションの継続時間の大小を予測できるかという問題意識に基づいた発表があった.

よくアクセスされるウェブページに同じ大きさの二つの画像を置き, それぞれ日本と米国に置いて,世界中からアクセスされる様子を調べたところ, AS_PATH の段数の大小は TCP のコネクションの継続時間の大小と 53% 一致するのに対し, ルータ段数の大小は同じく 49% しか一致しないが,RTT の大小は同じく 71% 一致することがわかったとのこと.

なかなか快適なウェブアクセスを実現するのは難しいようだ.

Sendmail Inc. の Eric Allman からメールの標準化動向についての報告.IETF の DRUMS (Detailed Revision and Update of Messaging Standards) が RFC 821, 822 を改定する作業を進めているという話.確かにこの二つの RFC は用語や内容に問題が多いので,必要なことだと思う.

UPS の小包と同様,メールを追跡できるようにするという, メッセージトラッキングというサービスの提案があるという.もちろん MTA がみなヒストリデータベースを持たなければならないという欠点がある.


←はじめに   1999/12/15(木)→
★Internet Week 99 私的レポート - 目次   ◎ほーむ