第2回JPIRR BoF 議事録

■本議事録について
  - 開催概要、議題は別途公開しています
  - 議事録中ではIRR企画策定専門家チームを「IRR-Plan」と省略しています
  - 質疑応答ではJPNIC関係者および発表者の発言のみ、発言者を明記してい
    ます。発言者の記名が無いものは参加者からの発言となります

--------------------------------------------------------------------------
【１】開会のご挨拶 
【２】JPIRR Update
　吉田友哉(JPNIC IRR企画策定専門家チーム/NTTコミュニケーションズ株式会社) 
--------------------------------------------------------------------------
 + 資料に基づき、現在のJPIRRの説明と企画策定専門家チームの活動紹介を行った

[質疑応答]

 + JPIRRにlinuxを入れる前はどんなOSを使っていたのか？
   - soralisを使っていた。
   - その前はFreeBSDを使っていた
   - BSDはコンパイルがうまくいかなかったので、使わなくなってしまった。
     (以上、IRR-Plan 吉田)

 + パスワードはどこに保存されているのか(IRR-Plan 近藤)
   - 別のファイルとして保存されているわけではない
　　 (DBファイルに保存されている)

 + APNICはRIPEのデータベースソフトを使っている。APNIC経由でRADBのデータ
   を持ってくると、隠されたパスワードはどのように表示されるのか。
   - パスワードはやはり隠されるのか？(以上、IRR-Plan 近藤)
   - これについては、今後調査をする(IRR-Plan 吉田)

 + JPIRRに関するドキュメントは随時アップデートされている
   - しかし、まだアクセスは少ない(以上、IRR-Plan 吉田)

--------------------------------------------------------------------------
【３】JPIRRに関する統計情報のご紹介 
　長橋賢吾(JPNIC IRR企画策定専門家チーム/東京大学大学院) 
--------------------------------------------------------------------------
 + 資料に基づき、JPIRRに関する現在の統計情報の報告を行った

[はじめに]

 + 今回のBoFでは、JPNICから割り振りが行われたアドレスに関して、実際に経
   路広告されている情報と、RADBに登録されている情報の整合性に関しての調
   査結果を報告する。
　 　- RIPEでは割り振り情報とIRRに登録されている情報が同じになっている。
　 　- 現在、JPNICではRIPEのような運用をしていない。
　 　- このような状況を踏まえて、以下を目的として調査を実施した
        →・JPNICの管理するリソースが登録されている割合を把握する
          ・データが登録されている場合、その整合性を把握する

 + 元となるデータは、2003年11月27日現在のIPアドレス管理指定事業者リスト
　 から取得した
　 　- prefix 数は約1600、アドレス数に直すと約2200万アドレスであった。

[質疑応答]

 + JPNIC の最小割り振りサイズは/22だと思うが、/23や/24と言った単位では
　 JPNICから割り振りを行っていないのではないか。
　 　- 確実なことは言えないが、歴史的な経緯を含む古い情報であると思う。
       (IRR-Plan 長橋)

 + sourceは RADB だけか？
　 　- そうである(以上、IRR-Plan 長橋)

 + Best Match だと整合が取れているのに、Exact Match だとそれほどない、
   というのは問題ではないか。

　 　- /20でBest Matchされた、というのが、考察の結果である。

　 　- なぜ、Exact Match だとこのような結果になるのかは、JPNICの管理ポ
       リシーが関わっている。

　 　- 最小割り振りサイズが/22だった時代には、その/22を含む/20分を将来
       追加割り振りのためにリザーブをしていた、という経緯がある。

　 　- 割り振りを受けた/22を含む/20分を経路広告してよいことになっていた。
        →そのため/20で経路広告をしており、RADBにも登録をしていたと
          考えられる。(以上、IRR-Plan 長橋)

 + JPNIC では過去に、/22を最小割り振り単位として割り振りを行っていた。
   経路広告に関しては、リザーブ分を含めた/20を経路広告してよいというこ
   とになっていたと思う。解放割り振りに伴って、指定事業者にはそれぞれ
   /20単位で割り振られていると思っている。(IRR-Plan 近藤)

　 　- 指定事業者向けのリストには割り振りを行った単位で登録されている。
       現在のデータベースにも、割り振りを行った単位で登録するため、
       リザーブ分を登録することはしていない。(JPNIC)

 + 解放割り振りを行ったので、それぞれの指定事業者は/20単位でデータベー
　 スに登録されていると思う。だとすると、/22という情報はデータベース上
   に存在しないのではないか。この調査では、どのデータを参照するか、とい
   う問題があるのだが、JPNIC側のデータベースも実態に合わせてアップデー
   トした方がよいという問題もあると思う。(IRR-Plan 近藤)

　 　- 解放割り振りの前後で/20単位に書き換えをしたわけではなくて、リザ
       ーブ分のうち未割り振り分の空間を追加してデータベースに登録するこ
       とで対応を行った。そのため、実際は/20の空間を割り振られている指
       定事業者でも、データベース上は、/21と/22*2という形となっている。
       (JPNIC)


 + /16の割り振りを受けているISPが、追加で/16をの割り振りを受けており、
   複数回の割り振りをまとめれば/13程度の空間を持っているとする。BGP の
   ルーティング上で、ある回線は/16のprefixを割り当てて流したい、という
   ようなことを、割り振りを受けた段階でやってしまうと、まとめることは難
   しいと思う。このようなケースは結構あると思っている。(IRR-Plan 吉田)


　 　- 実際流れている情報と割り振りを受けた情報が一緒になっている、とい
       うこともあると思う。(IRR-Plan 吉田)

　 　- オペレーション上は、/13の割り振りを受けた場合、/13をIRR に登録し
       ているのではなく、分割したものを登録しているのか？(IRR-Plan 近藤)

　　　　→/13で登録している。(IRR-Plan 吉田)

 + /13という大きな単位ではなく、/20といった空間を/21*2に区切って使うよ
   うな場合、どこかのExit Pointでは/20で流しているというケースもあると
   思う。その場合、IRR には重複して登録することになると思うが、統計上、
   そのようなデータはどのように考えているか。

　 　- つまり、/20と/21*2 の３つのルートオブジェクトを重複して登録して
       いる場合、それはどのように見ていて、統計上、どのようにカウント
　　　 するのか、ということである。(以上、IRR-Plan 近藤)

　 　- Best Matchで見ている。Best Match では/20で/21以下をカバーするこ
       とでカウントしている。カテゴリとしてはBest MatchとExact Matchの
       andなのだが、それはBest Matchの定義に当てはめて考えることは可能
       なので、Best Matchで見ている。(IRR-Plan 長橋)

　 　- リクエストだが、どれぐらい重複しているケースがあるか調べて欲しい。
       (IRR-Plan 近藤)

　 　- できれば、アドレスブロックを見てみて、Best Match になっている原
       因を解析してみるともう少し考察を加えることができると思う。

       (以下のような点を検証してみればよいと思う)
　　　　・集約できるはずだが、分けて経路広告をしている
        ・JPNIC からは集約した状態で割り振られているか、あるいは、ばら
          ばらに割り振られたものだが、結果的に集約できる状態になっている。

　 　- JPNICのデータベースとの比較と言う意味では、その点を検証してみる
　　　 と、データとしての意味付けがもう少し変わってくるのではないかと
       思う。

 + 割り振りを受けているが、インターネット上に経路広告していないアドレ
   スブロックについては、どのように取り扱えばよいと思うか。VPNサービス
   などに使われていると、社内ではグローバルアドレスは使っているけど、
   経路広告はされていないケースがある。

　 　- プライベートアドレスを利用してJPNICに返却することも考えられるが、
       MPLS-VPNサービス等ではプライベートでの運用は難しい。

　 　- 逆にインターネット上のデータベースである、と考えているのであれ
       ば、経路情報を登録しない、というのが正しい姿なのかもしれない。
       あるいは、全体としては使っていないが、一部分(メールサーバなど)
       には使っている(しかし、経路広告はしていない)ので、登録すべきで
       あるかもしれない。

　 　- ここで扱う議題ではないかもしれないが、統計情報を考える上での参
       考にして欲しい(以上、IRR-Plan 松本)

　 　- ブロック単位で流しているのであれば経路広告をすべきだと思う。流
       しているものを登録するのがよい思う。そもそもIRRはその情報を元に
       フィルタを書いている人もいるので。内部で使っているものは登録し
       なくてもよいと思う。(IRR-Plan 近藤)

 + こういう統計情報を取った方がよいと言う意見はあるか(IRR-Plan 吉田)

　 　- 今回の項目に関して言えば、内容としては、以下の３パターンがある
       と思う。

        ・JPNICが割り振ったアドレスとIRRに登録されている情報との比較
        ・実際に世の中に流れている経路情報とIRRに登録されている情報と
          の比較
        ・実際に世の中に流れている経路とJPNICが割り振ったアドレスとの
          比較

　 　- JPNICが割り振りを行ったアドレスと、IRRに登録されている情報や実
       際に流れている経路との比較は、運用上あまり意味がないと思ってい
       る。

　 　- 実際に世の中に流れている経路情報とIRRに登録されている情報との比
       較は、運用上は有用な情報になるのではないかと思っている。

　 　- 以前にも問題になったと認識しているのだが、何をもって、どの情報
       を参照してインターネットの経路とするのか、まだクリアではない。

　 　- 2,3箇所のISPとpeerをしてフルルートをもらっているが、全ての経路
       数を把握できる、と言うわけではないと思っている。
       (以上、IRR-Plan 長橋)

　 　- それぞれ経路数は違うのだが、経路数の違いはなぜ起きるのか、調べ
       ていくのもよいと思う。(IRR-Plan 吉田)
        
　 　- 本質的に観測場所によって経路数は違う。１箇所だけでサンプリング
       しても、世の中の全体の雰囲気はわからないので、協力してもらって
       複数の観測点でサンプリングするとより参考になると思う。また、調
       査項目も大事だが、ある程度継続的に観測する必要があると思う。

 + IRだと自分が割り当てたアドレスをIRRに載せたがるのだが、IRRには実際
   に経路広告する情報を載せる方がよいと思っている。

　 　- RIPEのデータベースはinetnum(割り振り情報) とルートオブジェクト
       は一緒に扱える構造になっている。ルートオブジェクトは、任意で登
       録する項目となっているが、実際に経路広告する情報を載せましょう、
       という方針で運用をしている。それが一番よい方向なのかなと考えて
       いる。

　 　- IRRdにはその機能がなく、またwhois のデータベースと連携していな
       いという状況である。どのように連携させるかについても将来的に考
       えなければいけないと考えている。(以上、IRR-Plan 近藤)


--------------------------------------------------------------------------
【４】IPv6 IRRについて
　外山勝保(JPNIC IRR企画策定専門家チーム/日本電信電話株式会社) 
--------------------------------------------------------------------------
 + 資料に基づき、IPv6に対応したIRRについての報告を行った

[はじめに]

 + IPv6に対応したIRRの必要性、およびIPv6経路の安全性確保に関して意見交
　 換をしたいと考えている。

 + 今回は以下の内容について報告を予定している
　 　- IRR関係のIPv6対応状況
　 　- IPv6経路とRegistry情報の整合状況

[質疑応答]

 + inet6numオブジェクトで確認できるので、ルートオブジェクトを登録する
　 ことは必要なのか。

　 　- Origin-ASを確認するためだけであれば、inet6num オブジェクトにオ
       プショナルにそういうフィールドをつければ足りると考えている。

　 　- 割り振りを受けたブロックサイズをそのまま経路広告する、というこ
       とが今後もずっと続くのか、ということについては疑問を感じている。

　 　- なぜなら、今のルーティングシステムだと、prefixコントロールがで
       きないと考えている。

　 　- 普通に考えると、たぶんinet6numオブジェクトでは足りないかもれな
       い。経路として２つ目の大項目でどう守っていくか、と考えると、別
       の何らかのデータベースを持つ必要があると思う。今ある方法として
       はIRRでやるべきなのかと思う。(以上 IRR-Plan 近藤)

 + 現状では、割り振りを受けたアドレス空間を分割しないで経路広告してい
   るのか。

　 　- 調べた範囲の結果では、分けて流しているケースは少ない。

　 　- whois のデータと比較しても、割り振りを受けたアドレスブロックの
       サイズ同じ大きさの経路広告をしているものがほとんどである。
       (IRR-Plan 外山)

　 　- IPv6においては、まだマルチホームする余裕がない実態を表している
       のだと思う。

 + 「経路を流すべきでない」と書いてあったが、これは、レジストリなどか
　　ら指導されているものか。

　 　- 調べてみたところ、割り振りのポリシーによれば、「経路はできるだ
       け集成して広告しよう」という感じの記述があるが、割り振りを受け
       たサイズ以外で経路広告してはいけない、といった内容は、ポリシ以
       外にも特には見当たらなかった。(IRR-Plan 外山)

 + レジストリとしては、集成できるように考えた割り振りサイズとなってい
   るが、分割して経路広告したいという運用上の要望もあると思う。

　 　- 実際にIPv6が普及してくると、運用する側では、かなりそれなりの使
       い方が出てくると思う。もともとIPv6を設計した人々にも、経路表の
       増大を防ぐことが必要という認識はあったと思う。そのポリシーとど
       のように折り合わせていくのか、についても気になっている点である。
       (IRR-Plan 外山)

　 　- /48 でも相当大きいサイズであると認識している。このサイズで経路
　　　 広告したいと考えている人は多いと思う。(IRR-Plan 近藤)

 + 10枚目のスライドで、/35が28個との記述があるが、これは昔に/35で割り
   振りが行われていたもので/32に移行したものであると認識している。
   inet6numオブジェクトは/32だが、現在も/35で経路広告し続けているもの
　 が28個あるという意味か。それとも、敢えて/35で流しているものか。個
   人的には前者であると考えているのだが。(IRR-Plan 吉田)
 + 
　 　- そこに関しては、本来の意図に関しては判断できる材料が少ないが、
       descr:の欄に/35から/32に移行する旨のコメントが入っているものが
       多かったと思う。それが28個全部であったかどうかについてはわから
       ない。(IRR-Plan 外山)

   　- /35から/32への移行は申し込み制だが、その割には大部分が移行した
       ような印象をもっている。

   　- /35から/32への移行したときに、どこかのルータが調整がうまくいか
       ず、/35の経路を流しつづけるという現象が起きた。そのため、カウン
       ターを当てるという意味で、/35を流しつづけたということもある。

   　- 割り振りブロックだけを経路広告する、ということは少ないのではな
       いか。(IRR-Plan 近藤)

   　- ただやはり、今は必要ではなくても、なんらかの方法を考えていく必
       要があると考えている。どうせやるなら早いうちにやる必要があると
       考えている。(IRR-Plan 近藤)

     - どこがIRR をやるべきかという話にもなると思うが、IPv6の現在の状
       況もふまえて、私はレジストリがやるべきであると考えている。IRRと
       whoisを一緒に運用するかはさておき、レジストリがこれらを運用して、
       両方見てちゃんとチェックが入る機構が動いているのが望ましいと思
       う。(IRR-Plan 近藤)

     - ミラーについては、(IETFドラフト的には)CRISP 等が動いていると思
       うが、ちゃんと最初からワールドワイドでミラー出来るものを考えて、
       パブリックな経路情報とプライベートな経路情報を共存させていくよ
       うな仕組みを考えていかないと、IPv4と同じような状況になってしま
       うと思う。現在はまだクリーンな状態なので、検討していけば良いの
       ではないかと思っている。(IRR-Plan 近藤)



--------------------------------------------------------------------------
【５】ゴミオブジェクト問題について
　衛藤将史(JPNIC IRR企画策定専門家チーム/奈良先端科学技術大学院大学) 
--------------------------------------------------------------------------
 + 資料に基づき、ゴミオブジェクト問題についての報告を行った
   (ポリシーチェックサービスについては、時間の都合上、割愛となった)

[はじめに]

 + ごみオブジェクトとは、長期にわたって更新がなされず、現状の運用状態
　 と矛盾する形で登録されているオブジェクトと定義している

　 　- 前回の JPIRR BoF においても、指摘されており、RADB などでは数が
       結構あるのではないかと考えられている。

　 　- JPIRR ではどのような対策を考えているかを紹介して、みなさまから
       ご意見をいただきたい。

[質疑応答]

 + IRRの情報はエンドユーザが登録することが少なくて、ISP が登録している
   と思う。そうすると、ISPは登録するオブジェクトのリストを持っていると
   想像する。通知が来ると(あるいは来る前に)、changedを更新をしてしまう
   と思う。そうすると更新を促すメールはこなくなる、ということにならな
   いか。

　 　- この仕組みのそもそもの目的は、長期間更新されないのであれば、オ
　　　 ブジェクトを消してしまおうというところにある。ISP が持っている
       ファイルファイルを元にして、上のようなことがされていれば、それ
　　　 なりに更新されていれば、IRR の健全性は保てると考えている。
       (IRR-Plan 近藤)

　 　- 上の質問の意図は、オブジェクトの中身については全然更新せず、
       changedフィールドのみを機械的に更新してしまえば、このシステムを
　　　 すり抜けることはできるのではないか、という意図だと思う。
       (IRR-Plan 吉田)
　　　 
　 　- 例えば、100 個のルートオブジェクトのリストを持っていて、それを
       いちいち有効かについて調べたりすることはないと思う。
       (IRR-Plan 松本)

　 　- 本当は変更の必要のあるオブジェクトなのだが、情報変更が面倒なの
　　　 でchangedフィールドのみを書き換えるようなケースが当てはまると
       思う。確かに100 個もあれば面倒だと思うが、この仕組みを使うと更
       新されていないものだけが届くと思うので、５件ぐらいであれば調べ
　　　 ると思う。(IRR-Plan 松本)

　 　- 自動的に対応できるようにされてしまうと打つ手はないが、最初は多
       く通知が来るかもしれないが、こまめに情報が更新されていれば、通
       知も少なくなるだろうし、結構見てくれるかなと考えている。
       (IRR-Plan 松本)

　 　- 確かに、そのような状況になることは否めないが、期待として言えば、
       JPIRR 側でフォーマットや通知される情報を示しておくことが必要で
       あると思う。また、通知がきた時点で情報と照らし合わせて、欠けて
　　　 いる情報を埋めてくれるようなスクリプトを作ってもらえると嬉しい。
       ISP側でもちゃんと管理をして欲しいと考えている。(IRR-Plan 近藤)

　 　- しかし、効果については実装してみないとわからない面もある。
       (IRR-Plan 近藤)

　 　- 正しい日付で登録するのであるから、当然、登録に対して責任が生ず
　　　 ると考えている。なので、あまりいいかげんなことはできないと考え
       ている。ただし、顧客管理の部門と運用の部門は必ずしも同じという
       わけではなく、運用の部門が忙しかったりすると顧客管理まで手を回
       せないということもあると思う。

 + 実際の経路情報と比較して、異なっているものだけを取り上げて通知する、
　 といったこともできるのではないかと考えている。そうすると、日付だけ
   眺めていっせいに書き換える、ということもなく、実際に変更があったも
   のだけを書き換えるようになるのではないかとも考えている。
   (IRR-Plan 衛藤)

　 　- それも良い考え方だとは思うが、JPIRR では経路を全部見ているわけ
       ではないので、見えない経路についてはどうするか、ということを考
       えなければいけないと思う。

　 　- RIPEでは、RIS というのを使っていて、AS番号とルーティングテーブ
       ルを見てチェックしてメールを出してくれる仕組みがある。ある程度
　　　 の地域(例:JP)を区切ってみれば、ある程度できるのではないかと思う。

　 　- そのときに問題になるのが、先ほども出てきた、経路広告をしていな
　　　 いのにも関わらず、IRRに登録してしまっているケースである。IRRに
       は登録しない方が良い、というスタンスに立てば、そのオブジェクト
       自体を消してもらう方向を考えるのしかない、とも思う。
       (IRR-Plan 近藤)

　 　- ルーティングテーブルは、どこで見るかによって見え方が変わってく
       るので、(たまたま)見えていない経路情報に対して通知が行ってしま
       う、というケースも考えられる。(件数は多くないと考えている)

 + 長期間更新されないと、ステータスがExpireからDisposalへと変化してい
   くが、メンテナーオブジェクトの場合もこの方針で運用するのか。メンテ
   ナーオブジェクトがなくなってしまうとルートオブジェクトも何もなくな
   ってしまうのだが。(IRR-Plan 吉田)

　 　- まだ設計段階なので何ともいえないが、あるメンテナについて、ある
       メンテナが持っているオブジェクトを全部チェックするような仕組み
       にしようと思っている。なので、そこは対処の仕方があるのではない
       かと考えている。(IRR-Plan 衛藤)

　 　- 仕組みを実装する前に、ルーティングテーブルに載っていない経路と
       更新期間の相関については調べておいた方が良いと思う。

　 　- 今すぐはないかもしれないが、メンテナーオブジェクトに登録されて
       いるnotificationのアドレスと、受け取るべきメールアドレスが
　　　 Expireしている場合には、どう対処するか考えておいた方がよい。

　 　- IRR のオペレーション的な負担はできるだけ少なくしておきたい、と
       考えている。もし届かなければ、自己責任としても良いのだろうか。
       それについては、みなさまからの意見を聞きたいと考えている。
       メールが届かないときのことを考えて、住所や電話番号を聞くのであ
       れば、それだけ重たいものになってしまうし、運用する側のオペレー
       ションも煩雑になってしまう。(IRR-Plan 近藤)

　 　- メールが届かないのであれば届かないのでも良いと思う。
       しかし、メールが届かないのであれば、返事がないものとしてメンテ
　　　 ナーオブジェクトが消されてしまうことを、あらかじめ示されておく
       必要があると思う。

　 　- ルーティングテーブルに載っている情報は、最新の情報に更新してお
       かないと、パケットがはじかれるという意味で、アクティブな情報で
       あると考えている。しかし、IRR の情報に余計なものが載っていても
       基本的にネットワークの運用には悪さをしないので、どうして残して
       おいて悪いのかという疑問に突き当たる。もちろん不要なものは残さ
       ないという原則については異論はない。

　 　- ルーティングテーブルに余計な情報がある、ということを比較すると、
       常に緊急性は低くなってしまう。という根本的な性質があると思う。
       また、他人の経路(アドレス)を登録するときは、他人のものは自分の
       ものだと主張している面もあるので、若干見識を問われてしまう。
       そうでない限り、種類を多く登録してしまった結果、ごみが残る、と
       いったこともあると思う。なので、IRR の緊急性については個人的に
       は疑問に思っているところである。

　 　- 正直なところ、それほど緊急性は高くないと考えている。RIPEやRADB
　　　 等では、古いIRR の情報が残っており、しかも実在しない経路で、
       情報が他人のものであるというケースもあると聞いている。
　　　 データベースに新たな情報を追加してもらうようにお願いしたときに、
　　　 連絡が取れないオブジェクトが多くあり、そのオブジェクトを削除し
       てもよいのかもわからないという状態になっている。このような状況
       は古いIRRでは現実のものとなっている。古いIRRでは、そのような
       データも多く、データの総量もどんどん増えている。オペレーション
       上も現実問題として、どんどん煩雑になってきているらしい。
       (IRR-Plan 近藤)

　 　- JPIRR としては、それほどの緊急性はないと考えているが、あらかじ
       め考えておく必要はあると考えている。そこでポイントになるのが、
　　　 Expireまでの期間(t)である。１年なのか２年なのか、あるいは半年
       なのは考えどころだと思っている。(IRR-Plan 近藤)

　 　- ルーティングテーブルに載ってしまうということは、アクティブにな
       っているということである。本来なら流れてはいけない経路が流れて
       しまうということもあるかと思うが、そもそも、そういう状態を作ら
       ないようにしたいと運用側は考えていて、そのためにIRRというもの
       があって、IRRの情報を参照すれば、BGPのルーティングテーブルに載
       せない、ということもできると思っている。そういう意味では、デー
       タベースを正しいものに作っていくということが必要で、例えば、一
       つの解としてこれまで述べてきたような仕組みがあると思う。
       (IRR-Plan 吉田)

　 　- 緊急性と登録の方針というのは鶏卵問題と同じで、古いから使えない、
       使えないから登録しない、という感じで悪循環になっていると思う。
       情報をシャープにして使いやすい形に切り替えるとアクティブな使い
       方をする人も出てくると思っている。(IRR-Plan 衛藤)

　 　- IRRにゴミ情報を多く登録しておくと、IRRの信頼性を失うことになっ
       てしまう。ゴミ情報が入っているからIRRはだめだ、という人も多いの
       で、そういう意味で、努力をして示していかないと、IRRのブランドイ
       メージも落ちると思う。

　 　- そもそもこの活動を始めたのは、RADB(Merit)が有料化され、IRRを取
       り巻く情勢が変化してきた、というのがきっかけなのだが、いろいろ
       と調べているうちに、最初の頃はBest Matchを調べても100%にもなら
　　　 ないし、Exact Matchにしても4%ぐらいにしかならなかった。APNICが
       IRRサービスを開始した頃には、50%ぐらいがゴミデータであった。
       どこのIRRでも、ゴミ対策に力を入れていて、IRRの信頼性確保という
       のは非常に大事であると考えている。(IRR-Plan 近藤)

　 　- 2年前に比べれば、ゴミオブジェクトもかなり減ってきているので、
　　　 良い環境になりつつあると認識している。(IRR-Plan 近藤)

 + IRRを使っている人は、IRRに対するモチベーションは高くないように感じ
   ている。使っている人にとってわかりやすいメリットがあれば、もっと
   IRRが使われるだろうし、それについて何かアイデアがあれば教えて欲しい。
   (IRR-Plan 衛藤)

　 　- RADBに登録をしていないと、あるサイトに接続できないという話を聞
       いたことがある。そういうのよりは、JPIRR の価値が上がって、日本
       の人たちはJPIRRにさえ登録しておけばRADBに登録しなくてよい、とい
       う方向に進んでいけば、RADBを重視している人たちも自然にJPIRRを重
       視するようになると考えている。(IRR-Plan 松本)

　 　- ネガティブに、「JPIRRに登録していないとだめだ」という感じになら
       ないか。(IRR-Plan 外山)

　 　- 現実問題として、メリットを与えるのは非常に難しいと考えている。
      「適切にオペレーションする」ということもそれほどメリットではない
       と思う。日本人的な気質から考えると、登録することがルールである、
       といえば、登録してもらえるので、そこには期待している。日本でで
       きるだけで、モチベーションはあがってくるだろうと期待している。
       (IRR-Plan 近藤)

　 　- AS lookupみたいなIRRを積極的に利用するツールが増えてくると、正
　　　 しい情報が登録されていないと面白くないと思う。そのあたりにも、
       IRRにデータを正しく登録することによるメリットがあると思う。なの
       で、あのようなツールを普及させるのもよいと思う。

 + JPIRRに情報を登録したら、RADBには登録をしなくてもよいのか、という質
   問を良く受ける。明快な回答はないと思うのだが、明快な回答を作る、も
   しくは参考となるような情報を考えるとすれば、どのような候補(項目)が
   あるか。(IRR-Plan 松本)

　 　- サービスが確実に停止しない状況になれば、RADBなどへの登録が不要
       になるという見方をしてよいのか。(IRR-Plan 松本)

　 　- 例えば、CWなどではRADBのデータを参照しているが、RADBにあるJPIRR
       の情報を参照しているかどうかははっきりとわからない。情報を確実に
       参照できる等といった、「JPIRRで大丈夫である」といわれるための
       課題などがあれば教えて欲しい。(IRR-Plan 松本)

　 　- 私が運営しているIRRでは、ミラーした情報は提供するが、データベー
       ス自体を参照してもらっても、自分が持つ情報とRADBの情報ぐらいしか
       提供していない。基本的にも我々もRADBの情報を参照している。
         本来の分散データベースという意味では間違っているかもしれないが、
       全てのIRRをミラーリングすることは困難なので、RADBに頼っているの
       が現状である。

　 　- one-pathでそのサーバが持っている情報を渡すことを検討している、
　　　 ということを前回のBoFで話した。JPIRRとミラーをすれば、RADBが持
　　　 っているLIRの情報を参照できるような仕組みを作れば、先ほどの話の
       ような障害はなくなるのではないかと思っている。(IRR-Plan 松本)

　 　- いくつかのIRRとPeerを張って冗長性をもたせれば、自分の持つデータ
       ベースを参照できるようになれば文句ないと思う。ただ、ニュースグ
       ループのリストみたいに、IRRのリストはメンテナンスしなければいけ
       ないということになるのだろうか。

　 　- リストをメンテナンスする形式であれば、現在でも機能的に実現可能
       である。そうではなくて今考えているのは、ここのIRRから情報をもら
       うという設定をすると、全てのIRRの情報が参照できる、というもので
       ある。

　 　- ただし、いろいろなハードルがあって、まだ難しい状況にある。まず、
　　　 AUPの関係で、RIPEはAPNICを経由せずに直接ミラーリングすることを
       希望している。とりあえず、直接ミラーリングすることにして、今後
       我々が希望する形式でミラーリングが行えないかどうかを打診してい
       る。今後のRIPEのミーティングにおいて提案を行う予定をしている。
       (IRR-Plan 近藤)
       
　 　- ミラーリングの問題が解決すれば、実装の問題なので、うまく動くよ
       うにしたいと考えている。(IRR-Plan 近藤)

　 　- RIPEでは、ミラーリング先に情報を渡す際に、個人情報を削除して参
       照させる仕様を検討している。RIPEの考えは、データベースの個人情
       報の(責任から見た)重さを軽くして提供しようというものである。
       これが進めは、ハードルはだいぶ低くなると考えている
       (IRR-Plan 松本)

　 　- 現状は実験ベースなので、あまり考えていないが、IRRが正式サービス
       になれば、個人情報の公開については、JPNICの情報公開ポリシーに則
       って実装していきたいと考えている。(IRR-Plan 近藤)




--------------------------------------------------------------------------
【７】IRRのセキュリティについて
 　木村泰司　(JPNIC 技術部　セキュリティ事業担当) 
--------------------------------------------------------------------------
 + 資料に基づき、IRRに求められるセキュリティについての報告を行った

[はじめに]

 + IRRのセキュリティに関する考察やアイデアについて、今回報告する。

　 　- 実際のオペレーションに携わっていないので、現実の運用に即した
　　　 提案などがあれば聞かせて欲しいと考えている。

[質疑応答]

 + IRRにもセキュリティの概念は必要であると考えていて、何らかのアクショ
　 ンを起こさないといけないと考えている。まず、守らなければいけないのは、
   そのオブジェクトが正しいかどうかについてであると思う。正しい(資格を
   持つべき人)人によって登録されているかどうかである。提案の中では、認
　 証にどのような方式を使う予定であるか。(IRR-Plan 近藤)

　 　- X.509を利用する予定である。証明書を格納するkey-certオブジェクト
       を利用することを考えている。key-certオブジェクトのIDが、各オブ
       ジェクトのauth:フィールドに入っているとイメージしてもらえればよ
       い。(IRR-Plan 木村)

　 　- RIPEでは、契約時にLIRごとにパスワードが送付されるので、そのパス
       ワードを用いて、利用する証明書をsubmitしている。(IRR-Plan 木村)


 + 具体的にどのように適用して、我々はどうしなければいけないということ
   がはっきりと理解できていない。現状ではPGPが利用されているが、それを
   X.509にすることに何かメリットはあるのか。(IRR-Plan 近藤)

　 　- PGPを使うべきかPKIを使うべきかについては、議論の余地があるとこ
       ろだと思う。他人の登録した情報を検証するときに、PGPの場合は相手
       の鍵が必要になってくる。たくさん調べようと思うと、鍵をたくさん
       交換しておかなければならない。PKIであればCAの証明書があれば検証
　　　 できる。(IRR-Plan 木村)

　 　- X.509を利用することで、楽になり、かつセキュリティ的に強くなるの
　　　 であれば、それは良いと思う。(IRR-Plan 近藤)


 + セキュリティについては今後も検討を進めていく必要があると考えている。
   今後もBoFを開催したいと考えているので、その際に、このセキュリティの
   仕組みをJPIRRに適用するかどうかについて、時間をとってゆっくり議論し
   たいと思う。(IRR-Plan 近藤)

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上
-----------------------------------------------------------------------