第3回JPIRR BoF 議事録
■ 本議事録について
- 質疑応答ではJPNIC関係者および発表者の発言のみ、発言者を明記していま
す。発言者の記名が無いものは参加者からの発言となります
----------------------------------------------------------------------
[はじめに]
+ これまでのBoFでいろいろと意見をいただいてきていて、JPIRRにもその意見
をフィードバックして、新しい機能として取り入れてきている。
+ JPNICでも、JPIRR試験サービスの正式化にむけた準備を進めている。
+ 今回についても、新しい取り組みをいろいろとやってきているので、その取
り組みについてご紹介して、みなさんと議論をしていきたいと考えている。
----------------------------------------------------------------------
■JPIRR Update(川端宏生(社団法人日本ネットワークインフォメーションセンター))
[補足]
+ 11/15にMail-Fromの認証を廃止したが、Mail-From認証のみのメンテナーオ
ブジェクトについては、すぐに利用できるように準備を行っている。該当す
る組織の方は、問い合わせ窓口までコンタクトして欲しい。
■IPv6 IRR(外山勝保 (JPNIC IRR企画策定専門家チーム/日本電信電話株式会社))
[質疑応答]
+ レジストリが登録するベータベースだと、/48とか/64のinet6numオブジェク
トはあってはならないものではないか。(近藤)
- IPv6については、レジストリに登録された内容とIRRのオブジェクトの内
容がほぼ同じになってくると想像している。登録してはいけないものか
どうかについては調べる必要があると思う。(外山)
+ /48のオブジェクトがあるということは、レジストリからの/48の割り振りが
あるということではないのか。/48はともかくとして、IPv6のポリシー上、
/40とか/42の割り振りは聞いたことはない。もしもこれが正しいものとする
と、レジストリの登録が間違っているのではないか。(近藤)
- /48はCritical Infrastructureとして割り振りをされていることがあるか
確かに、/40とか/42の割り振りは聞いたことはないので、この登録が正し
いかは調べてみる(外山)
■ゴミオブジェクト問題への取り組みついて(衛藤将史 (JPNIC IRR企画策定専門家チーム/独立行政法人情報通信研究機構))
[質疑応答]
+ BGPで利用されているフルルートとJPIRRに登録されているオブジェクトとの
比較を行ったとのことだが、フルルート内で見つからなかったRouteオブジェ
クトについては、Routeオブジェクトが登録されているが、経路広告されて
いない経路のことになると思うが、そのRouteオブジェクトを管理するメン
テナに、オブジェクトを削除するように通知のメールを流すのか？(近藤)
- 意図的に経路広告していないケースもあるので、このRouteオブジェクト
が必ずしも問題になるとはいえないと考えている。(衛藤)
- 情報がかけ離れていなければ、正しいのではないかとも思う。逆にユーザ
の立場からすれば、経路は流れているけど、Routeオブジェクトが登録さ
れていないケースの方が、メールで通知する/されるモチベーションは上
がると思う。ただ、その場合には、どこに通知するか、という問題点は
ある。(近藤)
- as-setオブジェクトに登録されている、AS番号をoriginとするrouteを検
索する等、逆の検索をしないといけない。自分が登録したことを忘れて
いる場合に通知してくれると嬉しいと思う。(吉田)
- 上記のようなケースを機械的に見つけ出す方法が思い浮かばなかったので、
その方法は書いていなかったが、確かに必要な機能だと思う。(衛藤)
+ 一時的に、または万が一の時のために、フルルート内にないRouteオブジェ
クトを登録している場合も想定されるので、オブジェクト内に一定の文字列
が記述されていれば、メールで通知しないような仕組みにしてはどうか(近藤)
- 例えば、descriptionにそのような文字列を記入すれば、メールによる通
知を行わないようなしくみがあると思う(衛藤)
+ その人に直接通知をする必要はなくて、1週間とか3日に1回ぐらいの間隔で、
経路情報とデータベースに登録されたRouteオブジェクトの情報を、ある
メーリングリストに投げるようなしくみにするというのもある。その情報
を見たい人だけがMLに登録することになるので、必要な人だけに情報が届
くしくみになる。あるいはWebページなどで公開する形もあると思う。(近藤)
- 他の人の目にさらされる方が、効果が上がるかもしれない(近藤)
+ 本当に経路広告元が正しいのかについて調べて、通知を行うことも考えてい
る。(衛藤)
- その場合には、通知が送られることになるので、良いと思う(近藤)
+ 視点として考えた時に、元々、JPNICでは、(1)割り振りの情報と(2)IRRの情
報との整合性について考えてきていたので、RIR/NIRがIRRをやる、と考えて
きていたと思う。このプレゼンでは、(2)IRRと(3)実際に経路広告されてい
る情報が一致するかについてみていると思う。この3者のどこをチェックす
るか、ということをもっと明確にしたほうが良いと思う。先ほどの質問も
この点を明確にしないと答えが出にくいと思う。
- IRRの登録情報を神であり、IRRの情報が絶対だと思っている。割り振りを
受けた人がそのアドレスレンジで経路広告を行うわけなので、割り振られ
たアドレスが正しくIRRに登録されている、逆に、割り振りを受けたアド
レスレンジ以外が登録できないようにしてしまうのが良いと思っている。
その関係は正しく保つべきものである。(近藤)
- IRRの情報は、経路情報のReferenceとして参照されるべきものと考えてい
る。IRRに登録されようとする情報を、インターネットレジストリの持つ
情報と比較されていて、間違った情報を登録できないようになっている。
登録されたものを、さらに細かな単位で登録する時に、誰に登録を許可さ
せるかをはっきりとして、管理者を明確にしていく。それが、インター
ネットに流れる経路のReferenceである、と考えている。ここまでは以前
と何ら変わっていない。(近藤)
- 一番大きな情報は割り振り情報になるのではないかと考えている。例えば、
/16の割り振りを受けた時に、/16が一番大きな単位になる。そのアドレス
を誰が管理するか、インターネットの経路のReferenceとして、誰が管理
するかと言えば、メンテナである。
メンテナは、/16のブロックを管理することができて、その管理者は、
/16に含まれる/18を管理できる人を決めて、その人に/18の管理を委譲す
る。その人は/18のオブジェクトを登録することが可能になる。結果とし
て、インターネット上に/18の経路が、この人の管理の元で広告されます、
という参照データベースにIRRはなっていく。(近藤)
- 経路情報とつき合わせていて、IRRに登録されていないのに広告されてい
る経路は、不正利用の可能性があるかもしれない。IRRが神であれば、
登録がないのに経路広告がある場合には、(あまり強くはいえないが)不正
利用であると言えると思う。
IRRに登録されているのにもかかわらず、経路広告が行われていない場
合は、その/16を管理している人が、なにかあった時に/17*2や/18のオブ
ジェクトを使うという意思を(何らかの形で)表していると理解している。
(近藤)
+ IRRは神であり、IRRに登録されている情報が正しいとすると、実際の経路情
報に対して正しいかどうかを判断する。もう一つの話は、RIRのデータ登録
の時に、IRR(神)はどうする、という話があると思う。
- 具体的な例でみると、IPv6では経路広告をしないアドレスの割り振りが認
められている。レジストリデータベース上では割り当て情報が存在するが、
経路広告は行われていない。その場合に、IRRはどうするのか？「私は経
路広告を行いません」と言うことを宣言するのか。
- 仕組み上は、レジストリが割り振りをする。メンテナーを作成する際に
どのブロックを登録可能かというDBにアドレスの範囲を登録する。Route
オブジェクトの登録の際にその情報を参照するようなしくみを想定して
いる。(近藤)
+ 近藤さんの説明だと、やはりレジストリデータベースが神になると思う。
誰が神で何と比較をしてどのようなアラートをあげるかについて、明確にし
ないとユーザが混乱とすると思う。
- どちらかが悪いので、登録情報を確かめてください、という感じではな
く、Aが正しくてBが間違っているのでBを直してください、ということを
第1義的にやらないといけないということで理解した。(衛藤)
----------------------------------------------------------------------
■ISPにおけるIRRの利用について(河野誠 (ソフトバンクBB株式会社))
[質疑応答]
+ スライド中にフォーマットの統一とあるが、どの部分のフォーマットのこと
を指しているのか？(近藤)
- 電子メールでオブジェクト登録を行う際のフォームのことか？現在、IRRd
でもRIPEのソフトウェアでも、現在使われているフォーマットは定義され
ており、中に記入するものは統一されているので違いはない。(近藤)
+ スライド中に、オブジェクトのsource記述が柔軟に対応ができないかという
内容があるが、これの意味を教えて欲しい。(近藤)
- 例えば、RADBとJPIRRの2箇所登録したい場合、JPIRRにメールを送ると
RADBにも登録される、という内容をイメージしている(河野)
- しくみ的な問題よりも、登録をして良いのか悪いのか、という問題になる
と思う。RADBの更新権限をJPIRRに誰に持たせるか、という問題になるの
で、まだまだ議論の余地はあると思う。構造的には、EPPを利用すれば実
現できるのかもしれない(近藤)
+ 以前に、把握できるすべてのIRRにコンタクトを取ってミラーをしようとし
たことがある。IRRの中には、自組織とのpeerとIRRを共有してフィルタを作
成するためだけの目的で、RADBとミラーを行っているところもあることがわ
かった。Peerするのであればミラーを受け入れるという組織が多かった。
一部でプライベートな用途にIRRがあることは事実で、グローバルなオブ
ジェクトとプライベートなオブジェクトが世の中にあるのかもしれない。
プライベートなオブジェクトをIRRに登録することで、内部のネットワーク
の管理が楽になることもまた事実である。IRRにはそのような力も持ってい
るので、そのような用途のIRRをいっしょにして考えるのではなくて、ある
程度分離して考えるようになると、違う世界があるのかもしれないと考えて
いる。そうすれば、IRRの使い道も広がるかもしれない(近藤)
+ IRRの目的には2つあるようなので、確認をしたい。経路情報データベースと
してIRRを利用しているケースと、自分が割り振りを受けた情報を全て登録
して、自分が割り振りを受けたアドレスブロックはこれだけあることを、他
の人に参照させるような使い方をしている場合もあると思う。
この2つの用途が混在していて、どちらの使い方を優先させるのかは難し
い状況にあると思う。本来であれば、経路広告を行わないアドレスブロック
登録しないべき(したくない)であると考えている人も多いと思う。
現状では、割り振りを受けていることを主張できるのはIRRしかないと考
えている人もいるため、インターネットレジストリが持っているアドレス割
り振り/割り当て情報を確認して、通知を上げる機能があれば、IRRに経路広
告を行わないアドレスブロックを登録をしなくても良いという風にも思える。
天使が天使として活動するのであれば、神の情報を参照する(できる)よう
にしたほうが良いと思う。APNICでは、天使と神がほぼ一緒になっているが、
JPNICでは天使と神が独立して活動を行っている。(松本)
+ IRRが利用されているのに、IRRのデータが正しく整備されていないことが
現在の問題だと思う。
+ 登録情報を正確に保つための具体的な良いアイデアがあれば教えて欲しい
- ISPとしてもレジストリとしても大変な労力を割く必要があるとは思うが
具体的には何かアイデアがあるというわけではない。
----------------------------------------------------------------------
■CRISP for IRR ?(吉田友哉 (JPNIC IRR企画策定専門家チーム/NTTコミュニケーションズ株式会社))
(近藤邦昭 (JPNIC IRR企画策定専門家チーム/株式会社インテック・ネットコア))
[補足]
+ CRISPというのは、もともと、レジストリ間のデータを相互参照するプロト
コルとして考えられているので、ミラーリングとは違う構造になっている。
このプロトコルの良い点は、各レジストリにデータが残らない点、情報を持
たないレジストリに問い合わせがあった場合に、上位のレジストリに参照を
行う仕組みになっているところである。(近藤)
- 一時期、RWHOIS というのがあったと思うが、それをイメージしていただ
ければよいと思う(近藤)
- 登録関係は全くない、あくまでも参照系の話になる。登録と言うことにな
ると、現在、検討対象外となっているEPPを使うことになる。(近藤)
- 下のレイヤーにはIRISというのがあって、その上のレイヤーには、EPPと
CRISPが乗っている、という関係である。基本的には、同じカテゴリーの
ものであると考えてもらえればよい。EPPとCRISPはそれぞれ別々に検討
されているのが現状である。(近藤)
+ IRRでCRISPを利用する際にデメリットと思われる点は、CRISPではrootとい
う概念が必要になっていて、最上位を定義しないと検索が始まらないという
プロトコルであるところだと考えている。rootが特定できないところが現在
の大きな問題点である。したがって、どういう検索Pathを作るかについては、
まだ検討されている。DNSで逆引きの検索ができるぐらいなので、CRISPにつ
いてもできるのではないかと考えている。(近藤)
[質疑応答]
+ フィルタリングの情報はどこか特定のIRRの情報を見るか、ローカルの情報
を見るかといわれれば、特定のIRRを使って欲しいところだが、実際にフィ
ルタを書こうとすると、IRRを見ているだけで時間がかかるので、ローカル
の情報を見たい、と考えている。(近藤)
- そういう意味で、ローカルに何らかのChashみたいなに、すばらしく早く
検索できるようなものがあって欲しいと考えている。ミラーリングだと、
自分の手元に全てデータが残るので、検索を行うととても早い点がとても
よい。CRISPを使うとそのメリットが失われる。運用に落ちてきた時に、
そこをどういう風にクリアしていくのかが、いま気になるところである。
(近藤)
+ どこまで情報が正確である必要があるのか、フィルタリングの情報を作る時
に、1時間おきにきちんと正確な情報を出して欲しい等について、ぜひISPの
オペレータの方に意見を聞きたい。(吉田)
- 1日1回位更新されるものであるということが理解できれば、その更新頻度
でも問題ないと思うが、別の視点で、フィルタを緊急で開けたい場合の対
応などが考えられていれば良いと思う。
また、IRRから情報が引けるから良いというものでもなくて、名前空間
は一意でないので、正しいものが引けているかどうかの検証が大変である。
as-setオブジェクトに他のas-setオブジェトの情報が書かれている時に、
どこのIRRを見に行けばよいのか、同じsourceと仮定してよいのか、まだ、
表記の自由度が大きいところが逆に悩みどころである。現在は、このオブ
ジェクトはどのIRRに登録されたものなのかを聞いて、そのIRRの内容を参
照するようにしている
- 1日1回位更新されるものでも問題ないと思う。緊急の場合には、手動で
ルータの設定を直接いじれば良いかもしれない
- 自組織の経路が届かない場合に何とかして欲しい、というのがあると思う
が、自分が設定しても何とかならない場合もあると思う。お互いの緊急度
の考え方が重要になると思う。(近藤)
- フィルタリングはExact Matchで行っているので、IRRに/22のRouteオブ
ジェクトが登録されている場合、/23の経路を受け入れないような運用を
している(吉田)
----------------------------------------------------------------------
■IRR Security(木村泰司 (社団法人日本ネットワークインフォメーションセンター))
[補足]
+ 1月に開催されるJANOG17でも、IRRのセキュリティに関する議論を行う予定
である。そこでも詳しい話をしてもらう予定にしている。
[質疑応答]
+ なし
----------------------------------------------------------------------
■最後に(吉田)
+ メンテナーオブジェクトもRouteオブジェクト数も以前に比べてだいぶ登録
数が増えてきているので、IRRがどのように利用されているかについても把
握していきたいと考えている。
+ 来年度以降、JPIRRサービスも正式サービス化を予定しているので、IPアド
レスのレジストリのデータベースとの相互参照より、信頼度の高い情報を
登録できるなどの機能を考えている。
+ ミラーリング先の追加についても議論を行う機会を設けたいと考えている。
+ 複数のIRRにオブジェクトを登録することについては、なるべくやりたくな
い人が多いと思うが。情報の冗長化を図っている人も多いのではないかと
考えられる。
+ 1月に開催されるJANOG17でも、今回のトピックのようなことを議論できれば
良いと考えている。
以上
----------------------------------------------------------------------
