2000年08月08日
日本ネットワークインフォメーションセンター
IRR研究会
IRRに関する調査結果
1. 概要
本レポートは、日本ネットワークインフォメーションセンターが実施する
IRR研究会で行なっているIRR(Internet Routing Registry)に関する研究活動
に伴う調査結果の報告です。
IRR研究会では、IRRに関する研究活動として、調査、検討、提言の三つの
段階を定義し、それぞれの段階で得た結果をまとめてゆきます。この報告書
はその第一段となる、調査段階の報告書です。
2. 調査内容
IRR研究会では、IRRに関する現状調査という位置付けでいくつかの項目をあ
げ調査を行ないました。調査した項目を以下に示します。
- IRR登録情報の現状
- RIPE/NCC IRRについて
- JPNIC - RIPE181比較
- 事例によるIRRの実態
- IRRの利用例について
これらの項目について、IRR研究会で報告された調査資料を添付資料に示し
ます。IRR研究会では、この調査報告資料に基づき、それぞれの項目について
さらに分析しました。この結果を以降に記述します。
3. IRR登録情報の現状について
調査報告にもありますが、調査の基礎情報はIIJに設置してあるIRRサーバよ
り2000年6月27日時点で取得したものを利用しています。
この段階でミラー可能であったIRRサーバは28サーバでしたが、Meritにある
IRRサーバリストの全てをミラーできていませんでした。実際に存在するIRRサ
ーバは、NANOG19ミーティングでの報告によると75ものサーバがあるとの事で
した。
日本国内には、IIJのほかにARCSTRやSINETもIRRサーバを設置しているが、
ARCSTRの例によれば、必要に応じたいくつかのIRRサーバとしかミラーをして
おらず、28ものサーバとはミラーしていないとのことです。
このため、ここで挙げられる数字は、存在する75にも及ぶ全てのIRRサーバ
とミラーすることによってさらにわかることが十分に考えられます。
仮に28のIRRサーバの情報が現状を映し出していると仮定すれば以下のこと
がいえることになります。
- 登録はあるけれど使われてない経路 約82000経路
- 登録されていないAS番号 約1700AS番号
ただし、この数字には、実際にグローバルインターネットでは利用されるこ
とがないと思われる/32やmore specificな経路も含まれているため、より現実
的な数値を求めるためにはこれらの経路を除外する必要があるかもしれません。
また、添付資料にある「Routeオブジェクトと現実の差分」に示されるグラ
フにおいては、実際にグローバルインターネットに流れている経路とIRRに登
録されている経路を比較した結果が表されていますが、このグラフによると登
録されている経路の数の傾きより登録されていないが実際に流れている経路の
数の傾きのほうが急であり、IRRで検索可能な経路の率が日増しに高くなって
ゆく様が見て取れる。この傾きが一定の線形を描くのであれば、IRRへの実際
の経路の登録率が50%を下回る状況は数ヶ月以内に発生すると思われます。
4. RIPE/NCC IRRについて
まず、RIPE/NCCがアサインしているAS番号およびアドレス関して調査結果の
分析が行なわれました。
現状、RIPE/NCCがアサインしているASは3000程度であり、実際にグローバル
インターネットに対して広報されているのは2100程度とのことです。
一方、アドレスに関しては、APNICが観測しているIR(Internet Registry)ご
との調査情報から13000Prefixと結論付けた。しかし、RIPE/NCCの実際の割り
当て状況などから推測するにこの数値は少ないと見るほうが正しい。そこで、
情報元の文書等を詳しく分析したところ、正確には、RIPEが割り当てたASから
広報されている経路数を意味していることが判明しました。アドレスは、AS番
号に関係なく広報できることから、実際にはARINから割り当てを受けたアドレ
スをRIPE/NCCから割り当てられたAS番号から広報していることが十分に考えら
れ、このAPNICの数値にいくらかの誤差を含む必要があると認識しました。
とはいえ、13000Prefixという数値は少ない。米国が一番多くのPrefixを広
報していることは、否定できないが、それにしても少ないのは、RIPE/NCC地域
内での広報経路はきちんとaggregateされているからという理由に落ち着きま
した。これについては、今後の追加調査が必要になるところです。
次にRIPE/NCCで稼動しているIRRサーバに関する調査結果です。
RIPE/NCCで稼動しているIRRサーバで扱っているオブジェクトの種類は、全
部で12 Objectです。通常のIRRと比較してオブジェクトの数が多いのは、アド
レスやAS関係のオブジェクトのみを扱っているわけではないため。RIPE/NCCは、
レジストリという立場もあり、IRRでは、通常のIRRのオブジェクトに加え、ド
メインに関するオブジェクトやアドレスのアロケーションブロックを管理する
ためのオブジェクトも含まれています。
また、これらのレジストリとしての情報は、階層構造による更新保護がつい
ているなど、IRRとしても取り入れるべき要素は多い。
5. JPNIC - RIPE181比較
この調査は、現状JPNICが持つwhoisサービスの項目とRIPE181で定義される
IRRの項目との比較を行い、IRが実際にIRRを行なうといった場合にどのような
情報がないのか、または、どのような問題があるのかを明らかにするために行
なわれました。
添付資料の比較にもあるように、IRRとしてJPNICのwhoisサービスを見た場
合には、CIDRブロックやポリシ、セキュリティの面などからサポートされてい
ない機能、情報が多くあることが明らかとなりました。
機能面からJPNICのwhoisサービスを見るため、ASに関する情報とアドレスに
関する情報であるネットワーク情報およびプロジェクト情報への関連性につい
て分析を行ないました。しかし、JPNICのwhoisとしては、もともとAS情報は正
式サービスとはなっておらず、この関連性はないことがわかりました。
そもそも、JPNICはAPNICの下位層にある単純なIRであるため、IRの観点から
すれば、アドレスのリースされている組織と到達性の確保をしている組織が別、
つまり、JPNICで到達性に関する情報をもっていないことはごく自然な流れで
あるという結論となりました。
ここで一旦、JPNICの用語とDBレコードの整理を行ないます。
Member情報=会員情報:割り振られたCIDRの参照が可能
AS情報: 割り当てられたAS番号の参照が可能
ネットワーク情報: 割り当てられたIPアドレスの参照が可能
接続情報: ネームサーバの逆引き登録の承認の為に登録。
基本的にネットワーク情報の単位で登録。
- 割り振り=JPNICから会員への業務委任ブロックの割り振り
- 割り当て=エンドユーザもしくは会員インフラへの割り当て
- 割り振り(allocate) --> 割り当て(assign) --> とLIRに下ろされる
- Inetnumとネットワーク情報は割り当てに近いobject
- 会員情報にaloocateされている会員の業務委任CIDRは登録されている
- 接続情報にはCIDRからエンドユーザに割り当てされたネットワーク情
報が登録
この整理に基づき、JPNICにIRRを設置しwhoisサービスと融合することを考え
た場合の情報の整理を行なうことにし、route objectの扱いについて議論した
結果、route objectに近いものを作るとしたら会員情報の業務委任ブロックを
取ってきた方が適切であろうということになりました。しかし、さらに分析を
進めた結果、以下のような問題があることが判明しました。
- 複数サービスの提供や企業合併などの都合で会員情報とAS情報は一対
一で対応していない。
- 複数のAS番号を持つ場合もある。
- ただし、historical なPI(133.とか192とかのJPNICが直接割り当てし
てたもの）は、
1. 接続情報にあるが、会員情報にはない
2. 逆引きの必要がない場合は接続情報にもない
3. /24より小さいスペースの直接割り当てをJPNICはしてない
(APNICは2,3例があるらしい)
4. マルチホームの場合はJPNIC直接割り当てだったり、今はAPNIC直接
割り当てだったり。
- すごく古い(JNICとかWIDEでやってたとき)のはwhois引けるか?
→割当先不明になってるものもあるかもしれない→さらうのは困難
→ARINのDBにはNSIから引き継いだのがあるはず
この他、この分析ではさらに問題点などが挙げられましたが、JPNICがIRRと
whoisを融合したサービスを提供することを考えた場合、以下の点について、
さらに詳しい整理が必要であると言う結論となりました。
- JPNICのDBに足りない情報の整理が必要。
- JPNICの情報の相互のつながりを整理する必要がある。
6. 事例によるIRRの実態
ここでは、実際に活用されているIRRサーバの現状と問題点を分析し、今後
のIRRサーバの有り方に関するモデルを検証しました。
まず、現状のモデルとしてArcstarのIRRサーバを挙げ、現状と問題点を挙げ
たところ、以下のような結果となりました。
- RADBのバックアップサーバが3月くらいにあがった
- 相互ミラーしているのは、verio/RADB
- peerしているところ、upstreamはミラーするポリシーで運用
- IRRサーバフルメッシュしないとデータ集まらない
これを踏まえ、問題点の解消、運用のしやすさ、などの面から今後のモデル
をガンが得た場合、３つの運用方法が考えられると結論付けられました。
以下に、概要を示します。
Pattern1:level1〜3くらいの階層構造でIRRを分散させる
- トップレベルのRRにデータを集める。
- 登録は分散される。
- メリットは、advertiseとregisterの整合性をみたり管理が
できる。
- デメリットは、結局サーバが乱立。現状に対して、整理がさ
れただけ。
→階層化の定義とか、冗長構成とか必要
Pattern2:RIRで集中管理
- RIRでIRR機能を持つ。バックアップ、queryの負荷分散用に
バックアップを用意する。
- メリットは、サーバの乱立状態が解消される
- デメリットは、登録、登録についてのサポートが重要になる。
- 登録資格がないためにそのRIRのIRRに登録されず、filter条
件で特定RIRのIRRをsourceとした場合に破綻する
Pattern3:RFC2769(Routing Policy System Replication)のモデル
- Repositly Objectを設けて route object を階層的に管理す
るRR間の連携が取れる。
この３つのモデルを考察した結果、RFC2769に挙げられるモデルは、現在IRR
研究会でも、ひとつの案として考えられているIRのような管理組織にIRRを運用
するモデルに近く、この方向性を詰める方向で考えてゆくというコンセンサス
を得た。
7. IRRの利用例について
IRRの利用例に関する調査は、IRRが利用されている具体例をしらべることに
よって、IRRが正しく機能しなくなった場合の影響度合いを測るひとつの目安と
して行ないました。
調査の結果、IRRという経路に関する情報を蓄積しているデータベースをHTTP
の配送などの配送元サーバの選択に利用している例もあげられ、IRRに登録され
ている情報がすでに広範に利用されていることが明らかとなりました。
細かい利用例については、添付資料に記載されていますので参照して下さい。
以上
[関連資料]