第1回JPIRR BoF 議事録  [次第6-7]

■本議事録について
  - 開催概要、次第は別途公開しています
  - 次第1-5についての議事録は別途公開しています
  - 質疑応答ではJPNIC関係者および発表者の発言のみ、発言者を明記してい
    ます。発言者の記名が無いものは参加者からの発言となります

--------------------------------------------------------------------------
【６】ディスカッション:IRRの今後に関して 
      コーディネーター：近藤邦昭
            (JPNIC IRR企画策定専門家チーム/株式会社インテック・ネットコア) 
--------------------------------------------------------------------------
【はじめに】
　+ バックグラウンドの共有ということでプレゼンを行ってきたが、このバッ
　　クグラウンと専門家チームが行っていることの紹介を含めて、今後どのよ
　　うに進めていくかについてディスカッションの時間を設けた。
    (IRR企画策定専門家チーム 近藤)

　+ 最終的には、日本においてIRRを確立させたいと考えている。
      - 本当は世界的に確立させたいが、まずは日本で成功した例を作りたい
      - そのためには情報が信頼できるものにすることが必要
      - source JPIRR を参照すれば日本のISPが網羅されていて、一元的に情
        報管理がされていれば、ユーザにとっては幸せかな、と思っている。
      - JPIRRで情報管理ができていれば、RADBには登録する必要はない。
　　      - RADBにはデータベースの冗長化の意味で登録しておく
      - ピアリングにおいては、オペレーションとIRR のバインドができてい
        れば非常に有効になると考えている。(IRR企画策定専門家チーム 吉田)

　+ ８月に韓国でAPNIC Open Policy Meeting (APOPM) があるが、いままで紹
    介したプレゼンテーションに近いものを APOPMでも発表する。ミラーリン
    グモデルもポリシを含めて提案を行ってくる予定である。それにうまく重
　　ねて、今回の BoFで出た意見や日本からのリクエスト、運用例も伝えてい
    きたいと考えている。(近藤)



Q:JPNICが指定事業者に対してアドレスブロックの割り振りを行う際に、IRRに
  強制的に登録を行ってしまうと、一番効果的でパワフルであると思うのだが、
  強制的な登録を行わない理由はあるのか。行わないのはネガティブなインパ
  クトがあるからだと思っているのだが。

A:私も強力だと思っている。 RIPEやAPNICで利用されているwhois v3はそのモ
  デルに近い実装をしている。NANOG 22で私が提案してきたモデルに似ている。

  whois v3では、inetnumという割り振り情報にmnt-lower: と呼ばれるフィー
  ルドがある。このフィールドは、該当するレンジの中のメンテナンスをする
  権限がある人は誰かを表したものである。
    mnt-lower は、そのレンジの中のルートオブジェクトを登録することがで
  きる形になっていて、階層構造ができている。(近藤)

A:しかし、RIPEのデータベースでもルートオブジェクトを自動的に登録するこ
  とは行っていない。
    IRRができてきた経緯もあるが、IRRはルーティングの運用情報であり、
　whois のinetnum などはレジストリの管理情報である。レジストリとしては、
  基本的にはルーティングやオペレーションには口を挟まない、という立場が
  あるはずなので、そういう部分で「勝手に登録するのはいかがなものか」と
  いう意見もある。(近藤)

A:「自動的に登録してもよい」と運用側が言えば、割り振り時に登録をするか
  もしれないが、現実的には運用側の必要性を把握できていない状態であると
  思う。IRR を有効利用する上では、一気に登録すればよいと思っている。
    ちなみに、JPNIC をはじめとする各レジストリのIRRとwhoisは以下のよう
  な関係になっている(近藤)

      - JPNICの場合は、whoisとIRRが相互に連携していない。
      - APNICは、whoisとIRRのデータベースが一つになった。
      - ARINは、whoisとIRRは別の組織で運用を行っているので、相互に結び
       つけること自体が難しい


Q:JPNICという一つの傘の下でwhois とIRRの運用を行っていることから考えて、
  相互に連携していないのは単に縄張り争いの問題なのか。

A:そうではない。JPNIC では新しいレジストリシステムの検討を行っているの
  だが、IRR は今後どのような形で連携していくかということも含めて検討を
  行っている。
        
  吉田さんをはじめとするIRR の運用を行っている人にも、意見を聞きながら
  レジストリシステムとの連携についても検討をしていくつもりである。その
  あたりのことを検討する意味も含めて、専門家チームで行っていた運用を、
  JPNIC のIP事業部にやっていただく方向で移管を進めている。将来、JPNIC 
  としてIRRサービスを行う判断がなされれば、whoisと連携する、といったこ
  ともあると思う(近藤)

(コメントとして)
C:最終的には、情報が100%登録され、ごみオブジェクトがない状態が一番良い
  と考えている。それは共通認識と理解しているので、その目標に向かって頑
  張って欲しい。

Q:例えばJPNICから/16の割り振りが行われ、IRRに/16で登録されたとする。し
  かし、実際のルーティング情報は/17*2である場合、IRRに登録した内容と異
  なると思うのだが。そのあたりはどのように考えるか。

A:データベースの作り方の問題ではないか。どんどん細分化する仕組みを作っ
  ていけばよいと考えている。

A:JPNICから/16の割り振り後に、AS番号を参照してルートオブジェクトを登録
  する。JPNICからAS番号の割り当てが行われていれば、JPNICのデータベース
  を参照すればよいのだが、JPNIC 以外の他レジストリより割り当てを受けて
  いる場合には、どのデータベースを参照するのか、といった問題となってし
  まう。

　　例えば、アドレスブロックをJPNIC から割り振られ、AS番号をRIPEから割
　り当てられているケースなどが考えられる。(近藤)

　　APNIC では、ルートオブジェクトを登録する際に、AS番号まで参照してい
  るのかと聞いたところ、参照しているといわれた。他地域のレジストリから
  割り当てられたAS番号は参照するのか、と質問したところ、そのケースにつ
  いては、ルートオブジェクトの登録はできない、との返答をもらった。(近藤)


Q:日本国内で流れている全ての経路を管理するというゴールは難しいか

A:世界中がすべてミラーされれば、実現可能かもしれないモデルとしては考え
　ており、ぜひ実現したいと考えている。(近藤)



(コメントとして)
C:RADBがいつまで続くかみんな心配している。割と基盤がしっかりとしてきて
  いるNICがIRRを運営することが、ある意味正解であると思っている。その反
  面で、IRRという(お金儲けの)ビジネスとNICのビジネスとでは、やや異質な
  のではないかと思っている。

C:最近のIPアドレスの割り振り状況からすると、割り振りされたものがそのま
  まルートオブジェクトとして登録される可能性が高いと思われるので、自動
  的にルートオブジェクトが生成されることに対しても意味があるのかもしれ
  ないが、昔に割り振られたアドレスブロックは、分割されて経路広告される
  ことも多いし、どのASから経路広告されるのかわからない、ということもあ
  ると思う。

Q:IRRの中で一番信用できない情報が入っているのはAPNICであると思う。ルー
  ティングしないような情報についても、データベースに登録されている、と
  考えている。IPのレジストリのデータベースとしては正しい情報なのだが、
  ルーティングのデータベースとしては入っていて欲しくない情報が入ってい
　るように思える。IRRに対する考え方は違うのかな、と思っている。

A:APNIC も基本的にRIPEのデータベースを使っている。RIPEのドキュメントは
  よく整備されていて、RIPEのデータベースの運用ポリシについてもドキュメ
  ントがあるが、 as,route,route-setなどのIRRに関するオブジェクトについ
　ては、IRR のオブジェクトなので、レジストリの情報ではないと言い切って
  いる。

  そのように言い切っているので、自動的に登録は行わないし、mnt-lower に
  ついても inetnumオブジェクトぐらいしか運用していない。そこから下のポ
  リシーについても強化しているが、運用はユーザが勝手に行うようになって
  いる。(近藤)

(コメントとして)
C:RIPE はある程度順当に運用しているイメージがある。APNICもRIPEと同様に
  運用しているはずなのだが、アジアは厳密に管理する傾向があって、その影
  響をAPNICが受けているのではないだろうか。

  考えていることがあれば、APNICにメールを出してもよいと思う。APNICはIRR
　を実際に運用していても、ユーザからの声は聞こえてこないと思う。我々も
　声を上げていかなければいけないし、実際のユーザからも声を上げていかな
　ければならないと考えている。(近藤)



Q:基本的にcomprehensive な情報はRADBからしか取れないので、それが嫌な人
　は自分であらゆるIRR とミラーリングをする、という状況になっていること
　が個人的にはIRRの大きな問題として考えている。

　RADBに集中するという状況は、IRR が分散データベースであることから考え
　るとすると、理想が実現できていないことである。分散データベースのメリ
　ットを十分生かしきれていないので、何とかしないといけないと思う。

　JPIRR が考えていることは、必ずしも今考えていることの解になっていない
　とは思うのだが、JPIRR はRADBとも話し合いを持っているようなので、その
  あたりについてどのように考えているのか。

A:そもそもIRR は分散データベースではない。本来はスタンドアローンなのだ
  が、データベースのコピーを置いているだけである。今後、分散化がちゃん
  とした形で進むのではないかと考えている。JPIRR(JPNIC)としては、そのと
  きにあるモデルが提供できて、それがいい形になれば、と考えている。(近藤)



Q:"ごみオブジェクト"の問題は昔から延々と議論されているが、ごみオブジェ
　クトを削除するために、オブジェクトにExpireの概念を設ける方向にならな
  いのか。 JPIRRでは１年毎にExpirationするような仕組みを実装するように
  提案したい。

A:RADBが有料のサービスに移行したのがExpirationのよい契機になった。料金
  を払わないメンテナオブジェクトに関しては、オブジェクトを削除している。
  RADBの事例は参考になると思うのだが、JPNIC がIRRサービスに対して課金す
　るかどうかどうかは、IP事業部がサービスコストなどを計算して判断するこ
　となので、現時点ではわからない。

  ただ、Expirationはごみオブジェクトを削除することに対しての一つのよい
　対策なので、Expireの概念はうまく取り入れていきたいと考えている。

A:RSPLの実装として取り込んでしまえばよい、という考えか？新たにフィール
  ドを作る、もしくはchangedフィールドをみて1年間を経過したものをExpire
  する、などが考えられる。(吉田)

Q:最終更新日付に基づいて、ある一定期間経過後にメンテナのところにメール
  が飛んで、「一ヶ月以内に更新しないと削除される」というような警告が出
  る仕組みはどうだろうか。そうすれば、notifyをまじめに書き換えるプロセ
  スも起きる可能性もあるかと思う。
  
Q:全てのオブジェクトに対してこの概念を取り入れるのか。

A:重要なオブジェクトだけでよいと思う。

A:運用を始めて、100個のルートオブジェクトを登録した場合には、100個の
  notifyが届くのは問題があると思う。スプールしておいて、月末にまとめて
  送信するなど実装方法を考えなければいけない。(近藤)

A:人間が手作業で行うのは現実的ではないので、何らかの方法でサーマリーを
  する仕組みをシステム側に設ける必要があると思う。(JPIX 川上)

(コメントとして)
C:指定事業者に割り振られたアドレスブロックを、強制的にIRR に登録するこ
  とについて議論があったと思うが、割り振りを受けてからしばらくすれば、
  実際に聞こえてくる経路があると思うが、現在検討中の統計を取るシステム
  で経路が検出された場合は、人為的なプロセスを踏んでから登録するような
  流れにしてもよいのではと思う。
    しかし、ニワトリとタマゴ的な問題であり、ルーティングのフィルタリン
  グには使えなくなってしまう。

Q:アイデアはとてもよいと思う。ただし、JPNIC から割り振られたアドレスブ
  ロックを経路広告したとしても、 JPNICで経路広告が観測できるという保証
  はどこにもない。
    JPNIC で観測できないのであれば、登録を自ら行うことになるが、登録する
  気がない人は登録をしないので、延々と登録されないアドレスブロックが発
  生するのではないか。(近藤)

A:フルルートを観測していれば、いずれ観測できるという考え方がある。また、
  JPNICは主要なIXと接続しているのようなので、JPNICとピアすることをプロ
  モーションして、 JPNICのルータで聞いている経路に関しては、先ほど述べ
  た方式での登録を積極的に行うのも面白いのではないか。(JPIX 川上)


Q:JPNIC では割り振りを行った経路に関しては、経路広告をしているかどうか
  の確認を行っているのか。

A:確認は行っていない(JPNIC)

(コメントとして)
C:アイデアとしてはよいと思うが、現時点ではまだ実用的かどうかは判断でき
  ない(近藤)



Q:正確な情報を持つオブジェクトをたくさん登録した人にとっては、正確な情
  報を登録しているにもかからず、更新の作業が大変である。情報を更新する
  必要がない人にとっては、とても苦痛な作業ではないか。

    例えば、 BGPの経路と照合して、明らかに誤った情報を登録していると思
  われるオブジェクトに対してのみ、更新を促すメールを送るようにすればど
  うだろうか。

A:BGP の経路と照合する話がよく出ているが、例えば、JPIXで受ける経路数と、
  JPNAP で受ける経路数は必ずしも一致するものではない。経路を照合すると
  いうのは果たして現実的なのだろうか。(IRR企画策定専門家チーム 長橋)

A:長橋さんの質問の意図は、BGPの経路といっても10万,14万などいろいろある
  ので、何と確認すれば正しいのかわからない、ということである。(吉田)

Q:Best Matchで確認すればよいと思う。それぞれの経路数の差は、パンチング
  ホールや細かく分割された経路で、それらをフィルタしているかフィルタし
  ていないかの差であると思う。誤差の範囲で見積もることができると思う。
  可能であれば、経路の誤差の意味について調べてはどうだろうか。

A:一度データを取って調べてみる(近藤)

A:/24と/28では運用上のポリシーが違うような気がしている。その違いが、
  10万,14万といった差に出ているのではないか(長橋)



Q:RADBに登録されている情報で、我々に割り振られたcidrの一部を、我々の組
  織以外の人によって、違うoriginASで登録されているオブジェクトがある。
  パンチングホールではなく、たぶん間違って登録されたものだと思う。その
  ような場合には、mnt-low が実装されればだいぶ解決すると思う。

  このprefixに関しては、我々のものであることを主張できる。勝手に我々の
  originASでルートオブジェクトを登録されているケースが、我々の子ASであ
  ったが、その際に、このprefixは我々のものではない、ということが主張で
  きるような紛争解決の窓口があるとよいと思う。

A:紛争解決の窓口は難しいが、mnt-low の実装は松崎さんが述べたような問題
  の解決を目指している。(近藤)

Q:mnt-lowは自分のprefixは自分で管理できるが、他人の prefixについては管
  理できない。他人のprefixが意図しないoriginASで経路広告するという内容
  で登録されてしまう事は防げない。そのような場合に、このprefixに関して
  は、我々のものではないことを主張できるような場もしくは窓口があればよ
  いと思う。

A:窓口的には機能するが、紛争解決は難しい。Policy Checkerでは実装は難し
  いと思うが、機械的に発見することは実装次第で可能かもしれない。自動的
  な形で実装が可能であれば、発生するごとにnotifyを飛ばすことができるか
  もしれない。(近藤)

Q:登録内容に間違いがあることを相手方に連絡する時には、メンテナの間でや
  り取りをするが、その間に管理者権限みたいなものを設けて、双方の意見を
  聞いて、登録内容に明らかに間違いだとわかったら登録内容を変更するよう
  な機能を果たしてほしい。

A:両者が合意の上で意図的にやっているケースがあるのではないか。両者が合
  意の上だと、機械で発見しても削除できない。(近藤)

(コメントとして)
C:申告制でもよいのだが、この機能をぜひ実装して欲しい。



Q:ミラーリングのポリシーをはっきりさせて欲しい。 IRRだとミラーをすると、
  ミラー先の情報が検索できてしまう。ということは、ミラー先の情報をかな
  り信じてしまう状態にある。相手方の登録ポリシーがどうなのか等を開示し
  てくれないと、情報を検索することができても、その情報を信用することが
  できるのかチェックできない。ミラーをする以上は提示しておいて欲しい。

A:先ほどのミラーリングモデルでは、基本的にJPIRR は他レジストリとのミラ
  ーリングのみを考えている。レジストリとのミラーリングに集約して、レジ
  ストリの運用する IRRを信用してもらうべきであると考えている。(近藤)

A:集めたデータを分散させてしまっては意味がないので、データを分散させな
  いようにある程度、歯止めをかけようと考えている。 JPIRRで持っているデ
  ータは、LIR(Local Internet Registry)がミラーして持っていくことはでき
  るが、 LIRの内部利用のみに限定する、というポリシを考えている。
    データの分散を防ぐ狙いもあり、ミラーをしてデータを持っていってもよ
  いが、それをLIR 配下に対してはミラーリングさせないように考えている。
  (近藤)

A:RIPE はAUPを書かせてデータの分散を防いでいる。今回我々が提案しようと
  しているポリシは、我々の持つデータを変なところに分散しないように、と
  の考えがある。(近藤)

A:今回提案するポリシをうまく利用して、データの信頼性を高めることができ
  るのではないかと考えている。最終的にはデータベースの信頼性の問題にな
  るので、信頼性を上げる方向で行動を起こしているが、他に何かよい案があ
  れば、コメントが欲しい。(近藤)



Q:今回のディスカッションでは、実際のオペレーションでの利用という点と、
  データの正確性を向上させるという点について議論をしているのだと認識し
  ている。

  結果的に見て、データの正確性が低いので、運用に利用することができない
  という意見も正しいと思うが、ルートオブジェクトのそれぞれに対して正確
  性を求めることは、非現実的であるとまでは言わないが、まだ先のゴールで
  あると考えている。例えば、VPN 用に利用する場合などには、アドレスの割
  り振りを受けたとしても、経路広告をしないケースも多い。

  auto-numオブジェクトを利用したフィルタの交換などは、実際に行われてい
  るケースもあり、現実的な話ではないかと思う。現実的な話から考えて、オ
  ペレーション的にIRR を利用するモチベーションが上がるかどうか、につい
  て意見を聞きたいと考えている。

  例として、あるIX上でのas-pathの交換を行う際に、IRRの情報を利用するよ
  うにした場合に大きな障害があるかどうか、など。

A:JPIXでは、ローカルのルーティングレジストリを動かしているが、そこに直
  接オブジェクトを登録してもらうことはしていない。あくまでも経路確認が
  目的である。「全経路に関してはこのAS-macroを見て欲しい」という内容の
  メールを流す外国の顧客がいる。日本の顧客には、まだそのような事をして
  いる顧客はいない。(JPIX 川上)

A:JPNAP では、顧客に対して提供するだけの形ではあるが、RADBやその他のIRR
  の情報を提供するサービスを実施している。IRR サービスの提供を行ってい
  ることを顧客に対してアナウンスしているが、どのノードの顧客がどういっ
  たものを利用しているか、については把握していない。(JPNAP担当者)

A:フィルタをIRR から書こうとすると、現状ではprefixフィルタしか書けない。
  JANOG のメーリングリストでも議論になったが、as-macroの中に全てas-macro
  で含んでいくと、おそらく完全なas-path フィルタを書くことができるので
  はないかと考えている。これについては、近いうちにこの実験をしてみよう、
  という話になっている。

  日本の場合では、実際には人手でas-pathフィルタを書いている状態である。
  as-pathフィルタが実際に現実的かについては、現在流れているprefix数か
　ら考えても、どういうオペレーションになるか疑問である。(吉田)

A:IRR-USERS というメーリングリストがあるのだが、そのメーリングリストで
  有志を募り、IRRを利用したas-pathフィルタのアップデートを試験的に行う
  とすると、反対か賛成か意見を聞ければ、と考えたのだが。
　(IRR企画策定専門家チーム 松本)

A:as-pathを出したくない人のほうが多いのではないか(近藤)

A:IXにピアリングの希望を出したところ、RADBにas-macroを登録するように言
  われた。RADBのデータでフィルタを作っているので、as-macroを登録しない
  と経路を受け取らない方針であった。この方針を否定しないが、孤軍奮闘し
  てやってみるのも一つの方法ではないか。ピアリングの希望を受ける大きな
  ASだと特にそう思う。

A:Origin ASを登録するだけでも効果はあると思うが、as-pathも登録すると、
  いろいろなフィルタをかけることができる。過去にもas-path でフィルタリ
  ングを行っていたIXもあった。as-path でのフィルタリングをパブリックな
  IRR でやる、ということについてはいろいろ問題があると思う。as-path を
  出すか出さないかはISP に依存していると思うので、もしかすると個別にや
  った方がいいのかもしれない。(近藤)

A:昔みたいにうまく運用ができるレベルであればよいが、prefixで攻撃をして
  くる人もいるので、そういう人たちをブロックする必要性がある時代になっ
  てしまった。その点から考えても、as-path のフィルタでは不十分で、
  prefixフィルタを細かく書く方がよいと思う。
  
  prefix フィルタを細かく書くためにIRRを利用しないと、運用が厳しくなっ
  てしまうのではないか、と個人的には考えている。(近藤)



Q:登録されたオブジェクトの正確性を向上させるための技術的な面について、
　検討を重ねていると思うが、根本的な問題として、データベースの契約関係
  はどのようになっているのか。具体的には以下のような対策が必要ではない
  だろうか。

      - ユーザに対して正確な情報を登録してもらう
      - 変な利用をした場合にはペナルティを課す

  IRR間ではどのような契約関係になっているのかわからないが、JPIRRに精度
  の高い情報が集まったとすると、その情報はとても価値のあるものとなると
  考えられる。データベースに集まった情報について、誰が権利を持っている
  のか、といった問題も発生してくるようになると思う。

  まだ、ユーザを増やす段階にあると思うのだが、契約である程度縛ることも
  必要なのではないか。他のIRRではどのように運用しているのか。

A:まず、確かなモデルを構築するのにフォーカスを当てているので、専門家チ
  ームでも、その問題については議論がまだできていない。(近藤)

A:個人的に意見を言うと、重要な問題であると認識をしている。ある程度のデ
  ータが集まれば、価値のあるものになるとは考えている。その情報を勝手に
  持ち出されるようになるのも困るので、ある程度の契約関係が必要であると
  考えている。具体的には、JPNICのwhoisと同程度のレベルで考える必要があ
  るのかも、と考えている。(近藤)

A:今は誰でも登録を行うことができるのだが、当初は、JPNIC会員/IPアドレス
  管理指定事業者に限定することを考えていた。これはこれまで述べてきたよ
  うな問題があったためである。
 
  今はかなりルーズな運用をしているが、本運用に際してはかなり考えなけれ
  ばいけないと思っている。契約関係にするか既にある契約関係をベースにす
  るか、についてもポイントとなると思う。(近藤)



Q:RADBに登録をしないと経路を受け入れてもらえないケースもある。今後、
  JPIRR に登録をしないと経路を受け入れてもらえないケースも出てくるだろ
  うと考えられる。このような状況になった場合に、IRR 間の連携が行なわれ
  ないと、オブジェクトの登録やメンテナンスの手間が２倍かかってしまうの
  だが、できるだけ手間の少ないようにして欲しいと思う。

A:実際に、RADBに登録しないと受け入れない、というケースはあるのだが、２
  タイプのケースがあると思う。分類すると以下のようになる。

      - 実際にRADBに登録しないで、ミラーリングしてデータベースを引いて
        きているので受け入れられないケース
      - RADBを直接検索して、RADBから検索できないと受け入られないケース

  後者はJPIRRに登録を行えば、 RADBで検索を行っても情報を見ることができ
  るので、問題はないと思う。(近藤)

A:理想的な環境としては、どのデータベースで登録されているか判断されるの
  ではなく、レジストリ間のミラーリングの関係の中で、どこかに登録されて
  いればよいと言われるような環境に持っていきたい、と考えている。
  
  例としては、 JPIRRに登録されていなくてもRIPEから検索できるので、JPIRR
  に登録する必要はない、と言われるぐらいにしたいと考えている。ヨーロッ
  パの人なら、RIPEに登録をするだろうから、JPIRR には登録しようとは考え
  ないはずである。(近藤)

--------------------------------------------------------------------------
【７】閉会のご挨拶 
近藤邦昭(JPNIC IRR企画策定専門家チーム/株式会社インテック・ネットコア) 
--------------------------------------------------------------------------
　+ いろいろな意見を聞くことができたので、我々も非常に有用だったと思っ
    ている。

　+ 今回の議事録はIRR-USERS にまとめて流すので、今後もそれをベースにし
　　て、いろいろな意見を聞かせていただければと思う。

　+ 議論をメーリングリストでも行うので、今後ともよろしくお願いします。

--------------------------------------------------------------------------

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上