第 6部

WIDE Internet の経路制御

195

第 1章WIDE Backbone の概要
WIDE Project では、その研究基盤として WIDE Internet を運用している。このうち、北東から順に、札幌・仙台・東京・藤沢・京都・奈良・大阪・広島・福岡の９箇所の NOC| Network Operation Center | とそれぞれを結ぶリンクは WIDE Internet の幹線として位置付けられており、WIDE Backbone とも呼ばれる。なお、1994 年度に開設が予定されている NOC として、八王子および浜松が計画されている。
NORTH

TOPIC

SapporoSendai

WNOC-SPK

TISN
JAIN
64k
JPNIC
Tokyo
TRAIN
SINET
WNOC-TYO
384k
JOIN
IIJ
NSI
SPIN
InfoWeb

CSI
Osaka

WNOC-SNDWNOC-OSA

64k

64k

Hiroshima
WNOC-HIJ
64k

Fujisawa

WNOC-SFC

Kyoto

Fukuoka

WNOC-KYO

WNOC-FUK
512k

192k
192k

Nara

768k

768k
WNOC-NAR

TISN
NCA5

KARRN

ORIONS

図 1.1: WIDE Backbone の構成

WIDE Backbone は 768kbps  64kbps の帯域のディジタル専用線を用いており、最近のマルチメディアアプリケーションに対して十分な帯域があるということはできないものの、WIDE Project を始めとする各種の研究活動になくてはならないものになっている。WIDE Backbone の各ルータは WIDE Project のメンバ有志によってその管理が行われており、障害時などの対応に若干問題があるものの、概ね良好に動作している。

WIDE Backbone のルータは共同研究の一環として相手側から提供して頂いているものが多く、種類が多いのが特徴である。単にルータの種類というだけではなく、ベンダの種類も、Sun, Proteon, Cisco, Well eet, NetBlazer などと多岐に渡っており、相互運用性が大きなキーポイントになっている。現在は IP データグラムの転送に関しては、相互運用上の問題はほとんど 生じていないが、経路制御に関しては若干問題がある。これに関

197

198

1993 年度 WIDE 報告書

しては後で述べる。
多くの NOC は WIDE Project のメンバが比較的速やかにアクセスできるが 、東京
NOC に関しては管理メンバの所属が若干離れた場所にあるため、遠隔である程度の診断ができることが重要になっている。そこで、ターミナルサーバである ANNEX を逆向きに利用し 、Sun などの break 信号で OS がストップしてしまうものを除いて、主なルータのコンソールポートを接続している。そのため、障害発生時にはコンソールにおけるメッセージ出力などを遠隔モニタすることができ、ベンダに対応を依頼してから NOC に駆けつけることができるなど 、大きな効果がある。また、経路制御上の問題等でアクセスできなくなっている場合でも、コンソールポートからコマンド を発行することによって、これらの問題を解決することも行われている。
NOC のルータの監視はそれほど厳密には行われていない。これは WIDE Project のメンバが常時インターネットを利用しており、障害発生時にはユーザとしてのメンバがこれを発見、通報されるため、多くの障害は比較的速やかに検出されている。無論、管理ツール等を用いて監視を定常的に行うことが望ましが 、WIDE Backbone の管理を生業として行っている者はいないため、常時監視を行う体制は直ちに実現することはできない。ただし 、一部の NOC では ping などによって定期的に polling を行い、障害が検出された場合には担当者の pager を鳴らし 、障害内容の概要を示すメッセージを伝えることも行われている。この機構により、担当者が飲み屋で一杯やっている間の障害も検出することが可能になっている1 。

1 統計を取っていないが、飲み屋で pager が鳴る割合はいわゆるオフィスタイムに比べて有意に高いのではないかと担当者は感じているとのことである。

第 2章
経路制御について

2.1

歴史

我が国のインターネットは、大学のキャンパスネットワークが相互に接続される形で、1987 年ごろから発達を始めた。これはすなわち WIDE Project の始まりであるが、東京
大学（大型計算機センター）−東京工業大学（情報工学科）の 64kbps のリンクが同年７月に運用を開始し 、引き続き東京大学（大型計算機センター）−慶應義塾大学（数理科学科）のリンクが設置された。それぞれのキャンパスネットワーク内部における経路制
御は、4BSD UNIX で実装されていた routed を用いて、RIP によって行われていた。
このため、組織を跨った場合の経路制御でも、この routed をそのまま使用し、RIP に
よって全体の経路制御を行っていた。Class B ネットワークアドレスと subnet を使用していたものの、接続されている subnet 数は全体でも 10 程度であった。
わずかに遅れて、TISN や学術情報センターの X.25 網である学術情報網を利用したJAIN などのネットワークも運用を開始し 、東京大学などで相互に接続されるようになったが、ネットワーク相互間の経路制御も依然として RIP が用いられていた。すなわち、日本のインターネット全体が単一の routing domain として稼動していたことになる。
海外との接続も早くから行われていたが、当時全世界で 2000 程度のネットワークが接続されていた。これだけの経路を RIP で輸入することは不経済であるため、default 経路で代用することが行われてきた。すなわち、

default は海外を表現するということが経路制御上の前提となっており、今日でも一部を除いてそのように取り扱われている。

WIDE Internet が各地に延びるに従って、経路の選択という問題が発生してきた。つまり、X.25 網は単一の 48kbps あるいは 64kbps の物理インターフェース上に複数の論
理回路（ Vircutal Call) が存在していたため、各 VC は物理インターフェースの帯域をお互いに奪いあう形になる。そのため、64kbps の専用線を利用していた WIDE に比べて、X.25 網を用いていた JAIN では十分なパフォーマンスが選られなかった。そのため、２点間に JAIN・WIDE 両方のリンクが存在する場合には、WIDE 経由の経路が好まれるようになった。これはホップ数を経路の質の評価に用いていた RIP ではそのままでは実
199

200

1993 年度 WIDE 報告書

現することができず、JAIN 経由の経路では、1 ホップについて metric を 3 程度わざと増やすという、ポリシに基づいた経路制御が実装されていた。
ところで、その後のインターネットの発展に伴い、接続される組織数も増加し 、RIP による経路制御には問題が発生するようになった。国内インターネットが成長し 、特にキャンパスネットワークの端では経路情報が到達しない問題が発生していた。これは RIP では metric が 16 になったら到達不能であると解釈することによるもので、キャンパスの入り口で default 経路を生成ということも行われていた。

2.2

IP アドレス事情

IP アドレスはインターネットが始まる前までは、それぞれの組織で勝手なアドレスが振られていた。ところが各組織が相互に接続されるようになってくると、アドレスの重複が問題になってくる。さらに国内では独立したアドレスであっても国際的にそうである保証は全くないわけで、DDN NIC から正規の IP アドレスを取得するようになった。
当初は IP アドレスは直接 DDN NIC に電子メールを書いてリクエストしていたが、その後現在の JPNIC の前身ともいうべき IP アドレス割り当て調整委員会がスタートし 、
英語で申請書を書かずとも正規のアドレスが取得できるようになった。
このころは、世界的には Class C ではなく Class B アドレスの取得が勧められていた。
これは 、Class C アドレスで経路制御を行う場合、経路数 n のとき、Class B であれば
2n オクテットの経路情報交換が必要になるのに対して、3n オクテットの情報交換が必要になるからである。また、Class C アドレスはアドレス空間としては小さすぎ 、サブ
ネットに分割して利用することが困難な場合がある。そのため、小さな組織でホスト数が数十という場合にすら、Class B アドレスの割り当てが行われていた。
ところが、ワークステーションの普及や ARPANET 以外のネットワークの出現などの影響で、インターネットは急激に発展してきた。そのため、全体でも 16384 個しかない
Class B アドレスが半分以上割り当て済みとなり、Class B アドレスが枯渇することが現実的になってきた。Class B アドレスは 6 万を越えるホストを接続することができるが、実際には高々数千個、少ない場合で数十個のホストしか接続されておらず、アドレス空間の利用効率が低いということも問題になってきた。
そこで、IANA | Internet Assigned Numbers Authority | では、従来の Classs B を推奨する方針を変更し 、よほどの規模がない限り Class B アドレスの割り当ては行わな
いことになった。その代わり、必要な場合には複数の Class C アドレスの割り当てが行
われるようになった。
このような状況と近年のインターネットおよび TCP/IP 技術の急激な普及により、32bitの IP アドレス空間が不足することが予想されるようになった。このため、64bit あるいはそれ以上のアドレス空間を持つ次世代 IP （ IPng ）を開発し 、現行の IPv4 を置き換える必要がでてきた。IPng には幾つかの候補が提案されており、マルチキャストや移動ホ
ストサポートなどの従来の IP では十分にカバーされていない点の実現性などの観点か
ら、実装・評価が勧められており、次回の IETF でどの候補にするかという決定に向け第 6部

WIDE Internet の経路制御

201て大きく動きだすことになっている。
一方現行のアドレス空間があとどのぐらいの時間大丈夫なのかということを予測することは、IPng の開発・移行スケジュールに大きく影響を与える。IETF では ALE | Address
Lifetime Estimation | BOF によってアドレス空間が使い尽くされるのにはどのぐらいの時間が必要かという見積もりを行っている。現在のアドレス割り当て率を外挿することによる予想では、CIDR ベースのアドレス割り当てによって 2008 年ごろまで、またClass A/Class B アドレス空間の再割当てを行う事によって 2013 年ごろまで大丈夫であるとのことである 2.1。

Assigned and Allocated Network Numbers

1e+006Class B: actual
Estimated
Max Class B nets
Class C: actual
Estimated
Max Class C nets

Fri Mar 25 23:09:47 1994

100000

10000

1000

1989

1990

1991

1992

1993

1994

1995

1996

図 2.1: IP アドレス割り当ての予想（ IETF ALE-WG による）
ところで、インターネットに直接接続されない部分に対してまで世界的にユニークなアドレスを割り振る必要性に関しては長い間議論が行われてきたが、一つの解決法として、あるアドレス空間はプライベート専用とし 、インターネット上のホストには割り振らない方法がある。この方法では、プライベートアドレスを持っているホストは自社内にあるということが仮定でき、インターネット上のホストとは異なったアドレスを持っていることが保証される。
このような目的で発表された RFC1597 では、以下のようなアドレスはプライベートとして一般の割り当てから保留されている：

1993 年度 WIDE 報告書

20210.0.0.0{ 10.255.255.255
172.16.0.0 { 172.32.255.255
192.168.0.0 { 192.168.255.255

RFC1597 はまだ発表されて日が浅いため、WIDE Internet に接続されている組織で採用しているところはまだないが、今後はプライベートアドレス空間を使用することによって、正規に取得したアドレスの何倍も広い空間が、JPNIC などへの申請なしに使用する事ができるため、今後は多く採用されるものと思われる。

2.3

経路制御の問題

さて、アドレス空間はしばらく大丈夫であるという予想が立ったわけであるが、実際のインターネットにおいて、経路制御が可能かど うかということがもう一つの重要な問題である。実際、近年のインターネットの急速な普及および CIDR 方式を想定した複数の Class C アドレス割り当てによって、default 経路の無いルータにおける経路数は急激に増加している。また、OSPF 、BGP などの最近の経路制御プロトコルでは、パケットの転送に用いる経路表以外に、それぞれのプロトコル毎に経路表を管理する必要がある。
このため、経路表を管理するためには非常に大きなメモリが必要になってくる。
1994 年 3 月には、インターネットから到達できるネットワーク数が 20,000 を越えた。
そして、16MB のメモリを持つルータの一部では、メモリが不足する事態が発生している。この増加率を外挿すると、経路が管理できなくなる限界と考えられる 2,000,000 に達するのは 1998 年と予想される。従って、結論からいえば 、IP アドレスの枯渇の問題
よりも経路表の膨張の方が深刻な問題であるということができる。
この事態を回避するため、かねてから複数のネットワークを単一経路で表現する、いわゆる経路の集成（ aggregate ）が可能である経路制御プロトコル BGP version 4 が検討され、各社で実装が行われてきたが、1993 年末ごろからソフトウェアが入手可能になってきた。このため、トンネリングを用いた BGP4 テストネットが世界的に構成され、日本からは IIJ のルータが参加した。そして、ソフトウェアのバグフィックス等が行われ、1994 年 2 月ごろから実際のインターネットにおける経路制御では、従来の BGP3 から
BGP4 への移行が開始され、経路の集成も可能になってきた。
単一の組織からの複数の経路のうち、集成が可能な場合は極力集成を行う、いわゆるキャンパスレベルの経路集成によって経路表の膨張は図 2.2 に示すように抑えることができ、さらにプロバイダに IP アドレスブロックを委譲（ delegate ）し、その空間からクライ
アントに割り当てることが始まっているが、この場合にはプロバイダ単位での経路の集成が可能になる。これを実施すれば 、経路表の成長は更に抑制することができる（図 2.2 ）。
実際、一部のルータがメモリ不足で動作しなくなったため、1994 年 3 月末に開催された第 29 回 IETF の CIDRD WG（旧 BGPD WG ）では、速やかに経路の集成を行うことが各プロバイダに要請されることが決議された。これに基づき、各所でキャンパスレ
ベルの集成が行われるようになったため、インターネットの経路表の大きさは 1994 年 3第 6部

WIDE Internet の経路制御

203

NSFNet Policy Routing Database
1e+0081e+007

1e+006Fri Mar 25 23:09:47 1994

10000010000
PRDB entries, actualClassful PRDB entries, est.
Campus-level CIDR, est.
Provider-level CIDR, est.
Max IPv4 nets

1000

100
1990

1992

1994

1996

1998

2000

2002

2004

図 2.2: 経路表の増加の予想（ IETF ALE-WG による）
月の約 22,000 を最高に徐々に減少を始めており、1994 年 5 月末現在で経路表の大きさは約 18,000 となっている。

第 3章

WIDE BB の経路制御の実際
3.1

RIP の問題点

我が国のインターネットでは、一部のルータを除いて default 経路によって海外経路を代表している。従って実際にルータ間で交換される経路情報は、国内の経路のみとなっている。この経路数は、1993 年 5 月には約 350 であったのに対し 、一年後の 1994 年 5月には約 700 とほぼ倍増している。これはインターネットの普及と複数の Class C アド
レス割り当てによるものである。
ところで、伝統的に我が国のインターネットでは、経路制御に RIP が用いられ、全体として単一経路制御ド メインを形成していた。RIP は Distance-Vector 型の経路制御プ
ロトコルで、比較的容易に実装されるため、多くのルータがサポートしているという特徴がある。しかし RIP は、30 秒に一回各ルータが持っている経路表をブロード キャス
トするというプロトコル体系であり、経路の増加に従ってオーバヘッド の増加が目立つようになってきた。
経路情報を RIP で交換するとした場合、１エントリ当たりおおよそ 20byte であるか
ら、全体のメッセージは 14kbyte となる。64kbps リンク上では、およそ 2.3 秒程度が必要になる。これが 30 秒毎に発生するわけであるから、平均トラフィックとしては、帯域の 8% 程度しか消費していない勘定ではあるが、telnet などのインターラクティブなア
プリケーションを使用している場合には、この 30 秒毎に 2.3 秒のブロックは非常に気に触るものになってしまう。そして、インターネットの普及に伴う経路数の増加は、直ちにブロックされる時間の増加につながる。
そこで、WIDE Internet では、バックボーン上の経路制御プロトコルを RIP から OSPFに、また WIDE 以外のネットワークとの経路情報交換には BGP を用いるように移行を行ってきた。以下、現在の WIDE Internet の経路制御方式について述べる。

3.2

現在の経路制御方式

WIDE Backbone における経路制御は主に OSPF が使用されれいる。これは、WIDE
Backbone を形成する主なルータで OSPF がサポートされてきたということに大きく依存している。

204

第 6部

WIDE Internet の経路制御

205

 Proteon では 、古くから OSPF をサポートしてきたが 、10.0 になって現行のバージョンである OSPF version 2 になった。

 Cisco では OSPF のサポートはなかなか始まらなかったが、9.1 になって OSPF をサポートするようになった。

 Cornell 大学で開発されている経路制御プログラム gated では、3.0 から OSPF がサポートされている。
具体的にどのルータが OSPF に参加しているかについては、付録のルータ一覧を参照して頂きたい。
gated は、WIDE Backbone で多く使用されている Sun WS + Sunlink/IR で稼動するため、WIDE Internet の運用に関して非常に重要である。特に OSPF や BGP などの最近の経路制御プロトコルを使用する場合、バグフィックスなどの点や開発グループの視点などを考慮しなければならないが、実験ネットワークとしての性格も併せ持っている
WIDE Internet では、バグが十分に取り除かれるのを待っていることはできない。
gated に関しては、バージョン 3.0 リリースの時代から WIDE Internet の一部で運転を行っており、幾つかのバグフィックスと数多くのバグレポートを Cornell 大学に送っている。開発グループとより密接な関係が必要になってきたため、1994 年 3 月から WIDE
Project は gated の開発母体である GateDaemon Consortium のアカデミックメンバとなっている。

1994 年 3 月時点で、WIDE Backbone に属すほとんどの Sun と、9.1 が稼動している
Cisco は経路制御を OSPF に移行している。OSPF では、それ以外の経路制御プロトコ
ルからの経路は、たとえそれが IGP によるものであっても、AS-external 経路として取り扱われる。AS-external 経路には、AS 内部の経路におけるコストも評価する type 1 とAS 間のコストだけを評価する type 2 の二つの種類があるが、回線速度が十分ではない部分もあり、目的地まで冗長な経路を通らないような努力が必要であるため、原則として type 1 の AS-external 経路として表現されている。
OSPF をサポートしていないルータでは、経路制御方式は従来の通り、RIP で学習した経路を各組織に送り、一方各組織から供給される経路を RIP で WIDE Backbone 上にアナウンスしている。これに対して、OSPF をサポートしているルータでは、OSPF の
経路情報交換を行う他、RIP 経路を OSPF type 1 AS-external 経路に、あるいは OSPF
経路を RIP 経路に変換する作業を行っている。
このうち、RIP
OSPF では、同一 Ethernet 上に接続されている OSPF ルータ総てでこの変換を行う必要はない。これは、OSPF 経路には NextHop 情報が付加されており、別なルータで変換が行われても、経路としてはそのルータを経由することなく、RIP 経路
をアナウンスしたルータに向くことによる。しかしながら、逆方向の OSPF
RIP で
1
は、RIP には NextHop 属性がないので 経路が冗長になってしまう場合があるが、ICMP

0!

0!

1 RIP version 2 には NextHop 情報も付加されているが、RIP version 2 をサポートは gated のみであり、OSPF も同時にサポートされているので、RIP version 2 は使用されていない。

1993 年度 WIDE 報告書

206

redirect によって動的に経路が修正されるので、パフォーマンス上大きな問題にはなっていない。

WIDE Internet で流通している経路は次のようになっている：
ネットワーク経路
サマリ経路
External 経路
OSPF ルータ数

28
13
606
32

WIDE Internet 以外のプロバイダとの間の経路制御も、伝統的には RIP が用いられてきたが、経路制御のオーバヘッド の増加およびプロバイダ単位での経路選択の必要性という理由で BGP への移行が進められている。当面、国内の経路数が非常に大きく（ 2000程度以上）なるまでは BGP version 3 で十分であり、BGP3 から BGP4 への移行は経路の集成方式をその時点でのトポロジに対応して検討する必要があることから、当面 BGP3が用いられることになっている。

JPNIC ではこのため InterNIC より 32 個の AS 番号の割り当てを受けており、現在次の様に AS 番号が割り振られ、WIDE Internet との間の経路制御が BGP に移行して
いる：

AS 番号
2497
2498
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2907
2915
3.3

プロバイダ

移行状況

IIJ
JOIN
WIDE
TISN
TRAIN
TOPIC
NCA5
KEK
CSI
RIC-TSUKUBAKARRNIIJ2INFOWEB
SINET
SPIN

BGP3
1994 年 7 月
我々
計画中
計画中

BGP3
BGP3
計画中

BGP3
計画中

BGP3
BGP4（海外向き）
BGP3
BGP3
BGP3

経路の供給方式

現在、一部を除いて WIDE Backbone に接続されている各組織には、国内の経路全部を供給しているが 、この方式は前述のようにオーバヘッドが大きく、不必要に回線の帯第 6部

WIDE Internet の経路制御

207

域やルータの CPU を消費している。そこで、マルチホームになっているなどの理由がある場合を除き、次のような経路制御方式への移行が検討されている：

 各組織には、default 経路と WIDE Backbone のアドレスである 133.4.0.0/16 のみを RIP で供給する。

 各組織はそれぞれの経路に対する経路情報を RIP で WIDE Backbone に向けてアナウンスする。
この方式によって、オーバヘッドが飛躍的に軽減できるほか、経路が徐々に増加したことによるオーバヘッドの増加や、経路の漏れなどの事故による影響を伝搬しないなどの利点がある。ただし問題点として、WIDE の国際リンクに障害が発生し 、WIDE Backbone
側からの default 経路が消失した場合に、海外はもとより国内とも通信ができなくなってしまうことが挙げられている。この問題の解決として、

 各組織側で default 経路を WIDE Backbone に向けて設定する
 default 経路を WIDE Backbone の各ルータで生成し 、各組織に供給するなどの案が現在検討されている。
一方 WIDE Internet 以外にも接続を持つ、いわゆるマルチホーム組織の場合には、リンクの使い分けが必要な場合がある。この場合には、それぞれの状況に応じて経路情報を供給する必要があるが、RIP では大きなオーバヘッドが発生するので、別な経路制御
プロトコルを用いなければならない。一つの案は OSPF を用いることであるが、OSPF
は link-state 型の経路制御プロトコルであり、本質的に経路のフィルタリングを行うことができない。そのため、複数の接続間で経路情報の漏洩が発生しやすく、OSPF を用いることは得策ではないと考えられる。
そこで例えば 、WIDE Internet からは default 経路を含まない、アカデミック経路を供給し 、商用ネットワークに対しては default 経路を設定するという方法も考えられる。
この場合には、両方の接続に対して OSPF による経路情報交換を実施する必要がないた
め、WIDE Internet 側からの経路の供給に関しては OSPF を用いることも可能である。
これについても現在検討が進められている。
それ以上に複雑な経路選択が必要な場合には、その組織が独立した AS となり、WIDE
Internet およびその他のプロバイダから BGP で経路の供給を受ける方式が考えられる。
この方法は、経路選択に関してはもっとも効果が高い方法であるが、AS 番号空間は 16bitしかないため、慎重に実施しないと AS 番号を使い尽くす可能性もある。ただ、一部のIAB メンバは、個人的意見ではあるが、日本国内で 1000 程度の AS 番号を使う事は問題はないとコメントしており、この方式についても検討が行われている。プロバイダ間
および組織内部の調整が必要であるが、近日中に幾つかの WIDE メンバのところで実験的な運用を開始したいと考えている。

208
3.4

1993 年度 WIDE 報告書

経路の集成について

経路表の爆発問題に関しては、国際的にも深刻な問題となっており、経路の集成を行うことが急務となっている。ところが 、WIDE Project は早くからインターネットに接続し 、IP アドレスの割り当てを受けてきたため、関連する多くの経路は集成可能な連続アドレスではない。もし最大限の集成を行った場合にどの程度経路数が減少するかという調査が NSFNET に接続されているプロバイダ単位で行われているが、WIDE Internetの国際接続の受け手である NASA の運営する NSI では、僅かに 27% しか経路数を減らすことができないことが報告されている。これは、大学などのアカデミック組織が多く、CIDR 方式に基づいたアドレス割り当て以前に割り当てられたアドレスを使用している
こと、大学ではインターネットにどこからも到達できるようにすることが多く、 rewallを設定している企業のようにインターネット到達部分のアドレス変更を行うことが非常に困難であることが起因していると考えられる。
ところで 、WIDE Project では約 50 の企業等が共同研究を行っており、その多くでrewall を介して WIDE Internet に接続している。そこで、WIDE Project である ClassC のアドレスブロックの委譲を JPNIC から受け、 rewall 部分のアドレスの再割当てを行うことが計画されている。1994 年 5 月に 202.249.0.0 | 202.249.254.0 のアドレ
スブロックの委譲を受けており、各組織と相談しながら、可能な場合にはアドレスの移行をお願いすることになる。
この場合、JPNIC のアドレス割り当て基準に従うと、従来持っている Class B や Class
C アドレスをインターネットにアナウンスしない場合には、プロバイダに委譲された空間から１個を限度としてさらに Class C アドレスの割り当てを受けることが可能である。
このアドレスは、割り当てを行ったプロバイダとの接続が切れた場合には、速やかにそのプロバイダに返却することが必要になる。
このようにすることによって、複数のプロバイダに直接接続されている場合でも、各プロバイダから Class C アドレスを一つづつ取得することができ、複数の rewall と対応した選択技術を用いることによって、同一目的ホストに対して異なった経路を使用することも実現可能になる。
WIDE Project では、この方針に積極的な管理者がいる組織に対して、Firewall WG とも調整しながら、効率的な IP アドレスの変更方法およびチェックリストの作成をしていきたいと考えている。
また、WIDE Project のすべての非大学系の組織がこの方式に移行した場合には、WIDE
Project それ自身で実験的に使用されているアドレスを含めて、50 60 程度の経路の集成が可能になる。



第 4章
まとめ
WIDE Internet は、その目的が運用ベースのネットワークに要求される高い信頼性ではなく、いろいろな技術開発の基盤として運用されている。しかしながら、研究者相互の円滑な通信をサポートすることも必要であり、実験等で必要な場合を除き、極力他の通信に影響を与えないようにする努力も必要である。また、新しい経路制御の導入や、移動
ホストサポート、マルチキャスト、IPng の導入など 新規の技術を評価し 、他の運用ベースのネットワークに対して技術移転を行うことも、WIDE Project に課された重要な使命である。
この二つの、しばしば矛盾する目的のため、各 NOC の管理者は時には寝食を忘れて障害の復旧に当たっているが、何分限られた人数で作業を行っているため、気付かない
問題が発生していることも少なくない。そのため、関係者の一層のご協力がぜひとも必要になる。次のことを特にお願いしたい： 障害に気がついた場合で、その現象が 10 分程度以上継続した場合には、担当者に連絡を頂きたい。

 その際、障害原因の発見や切りわけ、対策が可能になるように、障害の報告には 、「刺さる」「繋がらない」のような口語的表現ではなく、xxx に ping すると応答がなく、traceroute すると yyy までは正常であり、zzz に対しても同様の症状がある、というような具体的な情報を含めて頂きたい。

担当者は WIDE Internet の管理・運用が本業ではないため、ルータ等に速やかにアクセスすることが困難な場合がある。そのため、より具体的な症状の報告は、障害の早期復旧には非常に重要になってくる。関係各位のご理解をお願いしたい。
今後は集成された経路を取り扱う必要も生じるので、WIDE Backbone の CIDR 対応化が急務であり、メモリなどの資源の見直しも必要になると考えられている。

209

第 5章
付録 : WIDE Backbone のルータ一覧
以下に WIDE Backbone に含まれるルータの機種、ソフトウェア、インターフェースの状況、経路制御プロトコルについて示す。このデータは 1994 年 5 月下旬のもので、特にソフトウェアや経路制御プロトコルに関しては随時変更される可能性があることをお断りしておきたい。
endo

Sun4/470 (32MB)
SunOS 4.1.3 + MC, gated-R3 0
proto: RIP, OSPF
ie0
133.4.27.2
ie1
133.4.11.2

jp-entry

Proteon CNX-500 (8MB)V13.0d[]proto: RIP
Eth/0
133.4.1.2
SL/0132.160.251.2/132.160.251.2 (hawaii.net)
SL/1(unused)SL/2(unused)SL/3(unused)jp-gateSun SparcStation-2 (32MB)
SunOS 4.1.2 + MC, gated-R3 5Alpha 5
proto: RIP, OSPF, BGP3
le0
133.4.11.1
le1
133.4.1.1
le2
133.27.48.5 (keio.ac.jp)
ptp0
133.4.2.1/133.4.2.2 (wnoc-tyo)
ptp1
133.4.7.1/133.4.7.2 (wnoc-kyo)
ptp2
133.4.4.1/133.4.4.2 (wnoc-snd)
ptp3(unused)ptp4
133.4.1.1/133.107.1.2 (hitachi-sk.co.jp)
ptp5
133.4.1.1/133.196.1.11 (toshiba.co.jp)
ptp6
133.4.1.1/133.152.1.1 (ascii.co.jp)
ptp7
133.4.1.1/133.160.28.1 (fujitsu.co.jp)
ptp8
133.4.1.1/133.179.213.31 (nsc.co.jp)
ptp9(unused)ptp10(unused)ptp11(unused)

210

第 6部

WIDE Internet の経路制御

jp-tapSun SparcStation-1+ (16MB)
SunOS 4.1
proto: RIP
le0
133.4.11.9
le1
133.4.1.3

jun-cisco

Cisco IGS (1MB)
8.2(8)
proto: Staic
Ether0133.4.15.20
Serial0133.4.26.2

nakasuSun SparcStation-2 (32MB)
SunOS 4.1.2 + MC, gated-R3 5Alpha 4
proto: RIP, OSPF, BGP3
le0
133.5.19.3 (kyushu-u.ac.jp)
ptp0
133.4.19.2/133.4.19.1 (wnoc-kyo-ss5)
ptp1
133.4.20.1/133.4.20.2 (wnoc-fuk)ptp2(unused)ptp3(unused)dummy0133.4.13.1

shSun SparcStation-1+ (40MB)
SunOS 4.1.3, in.routed
proto: RIP
le0
133.4.11.11

wide-ccp-iij

cisco 3000 (16MB)
9.21(5362)
proto: OSPF, BGP3
Ether0133.4.32.2
Serial0192.244.176.206/192.244.176.205 (iij.ad.jp)

wide-ccp-relay

IBM 6611/140 (16MB)
AIX 3.2, gated-R3-IBM
proto: RIP, OSPF
te0
133.4.3.20
te1
133.4.32.4
to0(unused)to1(unused)to2(unused)to3(unused)wide-ccp-spin

cisco 3000 (16MB)
9.21(5558)
proto: OSPF, BGP3
Ether0133.4.32.3
Serial0
unnumbered/165.76.4.8 (spin.ad.jp)

wnoc-fujisawa-cisco

cisco IGS (1MB)
8.2(3)
proto: RIP
Ether0133.4.11.5
Serial0
unnumbered/133.229.1.1 (melco.co.jp)2111993 年度 WIDE 報告書

212
wnoc-fujisawa-cisco2

cisco 4000 (4MB)
9.21(4302)
proto: RIP, OSPF
Ether0133.4.11.10
Serial0
192.47.168.33/192.47.168.34 (ntt.jp)
Serial1(unused)wnoc-fujisawa-cisco3

cisco 3000 (4MB)
9.1(6)
proto: RIP, OSPF
Ether0133.4.11.14
Serial0192.83.157.66/192.83.157.65 (nttdata.jp)

wnoc-fujisawa-dec90

DECBrouter90 (1MB)
9.14(1)
proto: RIP
Ether0133.4.11.18
Serial0
unnumbered/202.34.226.7 (dec-j.co.jp)

wnoc-fujisawa-dnx

Proteon DNX300 (1MB)
13.0a [[]]
proto: RIP
Eth/0
133.4.11.27
SL/0150.52.136.20/150.52.136.10 (sanno.ac.jp)
SL/1(unused)wnoc-fujisawa-netblazer

Telebit NetBlazer (2MB)
1.51x12-test
proto: RIP
en0
133.4.11.7
line01133.4.11.7/192.50.240.1 (ysc.go.jp)

wnoc-fujisawa-proteon

Proteon P4100 (1MB)V8.1
proto: RIP
Eth/0
133.4.11.3
SL/0
unnumbered/129.249.88.1 (fujixerox.co.jp)

wnoc-fujisawa-proteon2

Proteon P4100+ (2MB)V12.1Z [8]proto: RIP
Eth/0
133.4.11.8
SL/0
unnumbered/150.61.5.1 (canon.co.jp)

wnoc-fuk

Sun SparcStation-1 (16MB?)
SunOS 4.1.2 + MC, gated-R3 0 3
proto: RIP, OSPF
le0
133.4.14.3
ptp0
133.4.20.2/133.4.20.1 (nakasu)
ptp1
133.4.14.3/163.44.224.1 (just.co.jp)
ptp2
133.4.14.3/133.37.56.121 (oita-u.ac.jp)
ptp3
133.4.14.3/202.26.211.3 (kyushu-id.ad.jp)

第 6部

WIDE Internet の経路制御

wnoc-fukuoka-proteon

Proteon P4100+ (2MB?)
V12.1Z [8]proto: RIP
Eth/0
133.4.14.1
Eth/1
133.125.1.1 (systemsoft.co.jp)
SL/0(unused)SL/1
131.206.18.1/131.206.18.2 (kyutech.ac.jp)

wnoc-fukuoka-proteon2

Proteon P4100+ (2MB?)
V12.0e [ ]proto: RIP
Eth/0
133.4.14.6
SL/0
unnumbered/133.94.1.252 (kurume-it.ac.jp)
SL/1
unnumbered/133.17.6.2 (kyusan-u.ac.jp)
SL/2
unnumbered/150.43.2.3 ( t.ac.jp)

wnoc-fukuoka-sparc

Sun SparcStaion-1/IPC (28MB)
SunOS 4.1.1 + MC, gated-R2 1
proto: RIP
le0
133.4.14.2

wnoc-hij

Sun Sun4/110 (16MB)
SunOS 4.1.3 + MC, gated-R3 0 2
proto: RIP, OSPF, BGP3
ie0
157.7.254.3 (rerf.or.jp)
ptp0
133.4.17.2/133.4.17.1 (wnoc-kyo)
ptp1
133.4.18.1/202.15.112.33 (csi.ad.jp)
ptp2(unused)ptp3(unused)wnoc-kyo-ss2

Sun SparcStation-2 (32MB)
SunOS 4.1.2 + MC, gated-R3 5Alpha 4
proto: RIP, OSPF, BGP3
le0
133.4.8.2
le1
133.18.64.2 (astem.or.jp)
ptp0
133.4.7.2/133.4.7.1 (jp-gate)
ptp1
133.4.17.1/133.4.17.2 (wnoc-hij)
ptp2(unused)ptp3
133.4.8.2/192.50.8.7 (nca5.ad.jp)
ptp4
133.4.8.2/133.83.1.2 (ryukoku.ac.jp)
ptp5
133.4.8.2/160.250.1.1 (shiga-pc.ac.jp)
ptp6
133.4.8.2/133.186.1.1 (atr.co.jp)
ptp7
133.4.8.2/192.51.37.14 (kaba.or.jp)

wnoc-kyo-ss5

Sun SparcStation-2 (32MB)
SunOS 4.1.3 + MC, gated-R3 5Alpha 4
proto: RIP, OSPF
le0
133.4.8.5
ptp0
133.4.19.1/133.4.19.2 (nakasu)
ptp1(unused)ptp2(unused)ptp3(unused)213

1993 年度 WIDE 報告書

214
wnoc-kyoto-cisco

cisco IGS (4MB)
9.1(3)
proto: OSPF
Ether0133.4.8.4
Serial0133.4.22.1 (wnoc-nara-cisco)wnoc-kyoto-cisco2

cisco 4000 (16MB)
9.21(5558)
proto: OSPF, RIP
Ether0133.4.8.6
Serial0133.4.35.1 (hiroshima-cu.ac.jp)
Serial1(unused)wnoc-kyoto-proteon

Proteon CNX-500 (8MB)V13.0d[]proto: RIP
Eth/0
133.4.8.1
SL/0133.4.9.1/133.4.9.2 (wnoc-osaka-proteon)
SL/1(unused)SL/2
133.210.3.1/133.210.3.2 (omron.co.jp)
SL/3(unused)wnoc-nara-cisco

cisco AGS4+ (16MB)
9.1(8)
proto: RIP, OSPF
Ether0133.4.23.1
Ether1(unused)Serial0133.4.21.2/133.4.21.1 (wnoc-tokyo-cisco2)
Serial1
133.4.22.2/133.4.22.1 (wnoc-nara-cisco)
Serial2
192.218.128.2/192.218.128.1 (osaka-u.ac.jp)
Serial3(unused)Fddi0
163.221.24.2 (aist-nara.ac.jp)

wnoc-nara-ss2

Sun SparcStation-2 (32MB)
SunOS 4.1.3 + MC, gated-R3 5Alpha 4
proto: OSPF
le0
133.4.23.2
ptp0
133.4.23.2/192.47.241.1 (sharp.co.jp)
ptp1(unused)ptp2(unused)ptp3(unused)wnoc-osaka-proteon

Proteon CNX500 (2MB)V13.0c[]proto: RIP
Eth/0
133.155.192.1 (senri-i.or.jp)
SL/0133.4.9.2/133.4.9.1 (wnoc-kyoto-proteon)
SL/1(unused)SL/2(unused)SL/3(unused)SL/4
unnumbered/133.243.25.241 (crl.go.jp)
SL/5202.13.88.66/202.13.88.65 (mei.co.jp)
SL/6133.30.248.1/133.30.248.2 (kobe-u.ac.jp)
SL/7(unused)第 6部

WIDE Internet の経路制御

wnoc-sfc-ipc

Sun SparcStation-1/IPC (12MB)
SunOS4.1.3 + MC, gated-R3 0 1
proto: RIP, OSPF
le0
133.4.11.13
ptp0
133.4.11.13/136.198.200.250 (jvc-victor.co.jp)
ptp1
133.4.11.13/202.16.229.134 (shonan-it.ac.jp)
ptp2
133.4.11.13/133.139.209.1 (ricoh.co.jp)
ptp3(unused)wnoc-snd

Sun Sun4/330 (24MB)
SunOS 4.1.1 + MC, gated-R3 0 3
proto: RIP, OSPF, BGP3
le0
133.4.5.1
ptp0
133.4.4.2/133.4.4.1 (jp-gate)
ptp1
133.4.5.1/130.34.10.10 (tohoku.ac.jp)
ptp2(unused)ptp3(unused)wnoc-snd-ss2

Sun SparcStation-2 (32MB)
SunOS 4.1.1 + MC, gated-R3 0Alpha 6
proto:
le0
133.4.5.2
le1
150.80.254.2 (aic.co.jp)

wnoc-spk

Sun SparcStation-2 (32MB)
SunOS 4.1.3 + MC, gated-R3 0 3
proto: RIP, OSPF
le0
133.4.25.1
ptp0
133.4.24.2/133.4.24.1 (wnoc-tyo)
ptp1
133.4.25.1/133.50.16.70 (hokudai.ac.jp)
ptp2
133.4.25.1/192.51.252.1 (bridge.co.jp)
ptp3(unused)wnoc-tokyo-cisco

Cisco AGS+ (4MB)
9.1(9)
proto: RIP, OSPF
Ether0133.4.3.9
Ether1133.235.64.1 (iwanami.co.jp)
Serial0
unnumbered/130.153.8.50 (uec.ac.jp)
Serial1(unused)Serial2
unnumbered/133.72.1.252 (kanagawa-u.ac.jp)
Serial3
unnumbered/133.43.98.32 (nihon-u.ac.jp)
Serial4
unnumbered/192.47.52.66 (glocom.ac.jp)
Serial5
unnumbered/163.142.60.1 (jcsat.co.jp)
Serial6163.213.101.2/163.213.101.1 (cisco.co.jp)
Serial7(unused)Serial8192.218.88.161/192.218.88.162 (ipa.go.jp)
Serial9
unnumbered/157.2.61.252 (netone.co.jp)215

1993 年度 WIDE 報告書

216
wnoc-tokyo-cisco2

Cisco AGS+ (16MB)
9.21(5192)
proto: RIP, OSPF, BGP
Ether0133.4.32.1
Ether1133.4.3.16
Serial0157.20.9.2/157.20.9.1 (join.ad.jp)
Serial1
133.4.21.1/133.4.21.2 (wnoc-nara-cisco)
Serial2
133.4.28.1/133.4.28.2 (wnoc-tokyo-otemachi)
Serial3
133.4.26.1/133.4.26.2 (jun-cisco)
Serial4(unused)Serial5(unused)Serial6
150.65.10.2/150.65.10.1 (jaist.ac.jp)
Serial7133.4.6.1/133.4.6.2

wnoc-tokyo-cisco3

Cisco 4000 (16MB)
9.21(5558)
proto: RIP, OSPF
Ether0133.4.3.22
Serial0
unnumbered/133.2.90.254 (aoyama.ac.jp)
Serial1(unused)Serial2
unnumbered/133.9.1.2 (waseda.ac.jp)
Serial3(unused)wnoc-tokyo-cnx

Proteon CNX-500 (2MB)V15.0a[X8-Akira-1]
proto: RIP, OSPF, BGP
Eth/0
133.4.3.21
SL/0(unused)SL/1(unused)SL/2
133.4.12.1/133.4.12.2 (etl.go.jp)
SL/3
133.4.10.1/133.4.10.2 (sra.co.jp)
SL/4(unused)SL/5
unnumbered/133.140.83.2 (yokogawa.co.jp)
SL/6
unnumbered/133.143.1.254 (dcl.co.jp)
SL/7
unnumbered/133.20.1.110 (dendai.ac.jp)

wnoc-tokyo-igs

Cisco IGS (4MB)
9.0(5)
proto: RIP
Ether0133.4.3.8
Serial0
unnumbered/192.135.93.0 (nec.co.jp)

wnoc-tokyo-igs2

Cisco IGS (1MB)
8.2(5)
proto: RIP
Ether0133.4.3.13
Serial0
unnumbered/192.26.9.23 (icot.or.jp)

wnoc-tokyo-ins3000

Cisco 3000 (4MB)
9.1(6)
proto: OSPF
Ether0133.4.3.18
BRI0
157.10.50.194/157.10.50.193 (takenaka.co.jp)

第 6部

WIDE Internet の経路制御

wnoc-tokyo-netblazer

Telebit NetBlazer (2MB)
1.51x12-test
proto: RIP
en0
133.4.3.7
sl0(unused)sl1(unused)sl2
unnumbered/192.50.188.1 (jus.or.jp)
sl3
unnumbered/192.50.17.50 (tsukuba.ac.jp)
sl4(unused)sl5(unused)sl6
unnumbered/133.99.1.32 (tsuda.ac.jp)
sl7(unused)wnoc-tokyo-news1

Sony NWS-3470 (16MB)
NEWS-OS 4.2R, gated-R2
proto: RIP
en0
133.4.3.17
dl0
133.4.3.17/133.227.11.1 (jip.co.jp)

wnoc-tokyo-nss

IBM 6611/170 (16MB)
AIX 3.2, gated-R3-IBM
proto: RIP, OSPF
te0
133.4.3.15
to0(unused)to1
192.156.220.34/192.156.220/33 (ibm.co.jp)
to2(unused)to3(unused)to4(unused)to5(unused)wnoc-tokyo-otemachi

Cisco 4000 (16MB)
9.21(5362)
proto: RIP, OSPF, BGP3
Ether0192.244.178.2
Ether1133.4.33.1
Serial0133.4.28.2 (wnoc-tokyo-cisco2)

wnoc-tokyo-wellfleet

Well eet (?)
1.19
proto: RIP???
133.4.3.19

wnoc-tyo

Sun SparcStation-2 (32MB)
SunOS 4.1.2 + MC, gated-R3 5Alpha 5
proto: RIP, OSPF, BGP3
le0
133.4.3.2
ptp0
133.4.2.2/133.4.2.1 (jp-gate)
ptp1
133.4.3.2/150.100.1.250 (sinet.ad.jp)
ptp2(unused)ptp3
192.31.117.1/192.31.117.2 (titech.co.jp)
ptp4(unused)ptp5
133.4.3.2/133.156.1.1 (dit.co.jp)
ptp6
133.4.3.2/133.123.1.1 (foretune.co.jp)
ptp7
133.4.24.1/133.4.24.2 (wnoc-spk)

217

1993 年度 WIDE 報告書

218
wnoc-tyo-news

Sony IKX-536 (128MB)
NEWS-OS 6.0.2, gated-R3 0 2
proto: RIP, OSPF
lance0133.4.3.3
dl0
133.4.3.3/133.128.199.2 (sony.co.jp)

wnoc-tyo-ss2

Sun SparcStation-2 (32MB)
SunOS 4.1.2 + MC, gated-R3 5Alpha 4
proto: RIP, OSPF
le0
133.4.3.12
ptp0
133.4.3.12/133.112.1.1 (soum.co.jp)
ptp1
133.4.3.12/157.18.128.1 (unisys.co.jp)
ptp2
133.4.3.12/133.26.136.4 (meiji.ac.jp)
ptp3
133.4.3.12/133.12.30.1 (sophia.ac.jp)
ptp4
133.4.3.12/133.144.224.2 (hitachi.co.jp)
ptp5
133.4.3.12/133.194.10.3 (recruit.co.jp)
ptp6
133.4.3.12/133.147.2.254 (astec.co.jp)
ptp7(unused)ptp8
133.4.3.12/133.166.10.1 (csk.co.jp)
ptp9
133.4.3.12/150.88.208.1 (hitachi-cable.co.jp)
ptp10
133.4.3.12/133.25.16.6 (hosei.ac.jp)
ptp11
133.4.3.12/192.51.48.1 (ipsj.ac.jp)
ptp15
133.4.3.12/202.17.180.1 (ieice.or.jp)