18th JPNIC Open Policy Meeting Minutes

第18回JPNICオープンポリシーミーティング議事録
日時：     2010年6月29日(火)10:00-17:00
場所：     ベルサール九段
出席者：   38名

[■議事録について]
  - プレゼンテーション資料は別途掲載しております．こちらよりご参照ください．
  - ご参加いただいた方： 38名

[■議題]
  1. JPOPM18 オープニング(I)

  2. JPOPMフォローアップ
    2.1 Action Item 確認(I)
    2.2 JPNICにおけるポリシー施行ステータス(I)

  3. APNIC29レポート(I)

  4. [提案]「Abuse contact information」(P)

  5. DNSSECの理想と現実　－そのIPアドレス管理への影響－(I)

  6. JPNICの逆引きDNSに関するお知らせ(I)

  7. [提案]6rd 用アドレス割り振りポリシーの提案(P)

  8. 最近のインターネットガバナンスに関するホットトピック（ITU IPv6グループを中心に）(I)

  9. RIPE ミーティングレポート(I)

 10. コンセンサス確認/まとめ

  (P) 提案事項
  (I) 情報共有を目的とした発表 



[■ 発表および質疑応答 (以下、Q. 質問、A. 回答、C. コメント)]



1. JPOPM18 オープニング (藤崎智宏/ポリシーWG)
[質疑応答]
    なし


2. JPOPMフォローアップ 
2.1 Action Item 確認 (藤崎 智宏/ポリシーWG) 
[質疑応答]
    なし


2.2 JPNICにおけるポリシー施行ステータス(奥谷 泉/JPNIC)
[質疑応答]
 Q. 発表資料3ページ目の「実装が十分に進んでおらず」とは、「ISPでの実装
   が進んでいない」という意味なのか。ルータの実装は進んでいると思うが。
 A. 機器の実装は進んでいると思うが、運用レベルでの実装がまだまだ進んで
   いないという意味である。(JPNIC 奥谷)

 Q. 発表資料4ページ目の「/48のIPv6PI割り当て」とは、パンチングホールの
   ことを指しているのか。
 A. パンチングホールを指しているわけではない。このPIアドレスの割り当て
   先として、マルチホーム運用を行う組織を対象としている。(JPNIC 奥谷)

 Q. /48程度であれば、グローバルルーティングテーブルの増大に歯止めがか
   けられると考えられているという理解でいいか。
 A. その点は、APNICでポリシーが検討された際には、あまり考慮されていな
   かったようだ。(JPNIC 奥谷)
 C. 経路広告のサイズについては、以前IPv6オペレーションズフォーラムで意
   見を聞いたときには、/64でフィルタをしている人が国内では多かった。
   一方海外では、/48でフィルタをしている人が多かった印象がある。IPv6
   の経路広告サイズについては、まだ標準が出来ていないように感じる。

 Q. 資料中の「IPアドレスコミュニティ」が何を指しているのかを具体的に教
   えてほしい。
 A. 「IPアドレスコミュニティ」とは、IPアドレスの管理・利用に関心がある
   方たちを想定している。具体的には、JPOPMに参加している方や、IP-USERS
   のメーリングリストに参加している方など。(JPNIC 奥谷)

 Q. アドレス移転について理事会で検討中とのことだが、具体的にどのような
   内容が検討されているのか。
 A. アドレスの管理の観点以外にも、アドレスの取引や規制などを考慮した議
   論が行われている。たとえば、まったく規制をせずに移転を実施してもい
いのかという点は、多くの時間を使って議論が行われている。また、もう
   少し踏み込んで、移転に伴いトラブルや混乱が発生したときのことを想定
   して議論をすべきという理事もおり、現在も慎重な議論が行われている。
   (JPNIC 奥谷)

 Q. アドレス移転については、約2年前(2008年頃)から、議論が行われている
   と思う。議論に多くの時間をかけているにも関わらず、あまり具体的な案
   が出ていないように感じるが。
 A. アドレス管理以外の領域の専門家として、税理士や弁護士から意見をうか
   がっている。アドレス管理以外の領域に対し、どの程度JPNICが関わって
   いくのかを現在検討しており、その点が明確になれば、もう少し具体的な
   案が出せると思われる。また、もし検討をすすめるにあたり、考慮したほ
   うがいい点などがあれば、お知らせいただきたい。(JPNIC 奥谷)
 C. JAIPAやIAJapanなど、JPNICがカバーする範囲外の人たちにの意見を聞く
   必要があるのではないか。また、TCP/IPのコミュニティだけではなく、流
   通業など、その他のコミュニティとも意見交換が必要だと思う。
 C. MLやJPOPMでの議論だけではなく、JPNICのWebページなどでも広くアドレ
   ス移転に関する情報を公開していく必要があるのではないか。JPNICは特
   定の人たちとの意見交換、議論になる傾向が強いとに思う。
 C. いただいたコメントは今後の検討の参考にさせていただく。アドレス移転
   については、外部の方の意見をうかがうことも検討している。(JPNIC 奥谷)
 C. 多くの人が関わるというよりも、IPv4アドレス空間を拡張するなど、技術
   的な解決を模索した方ががいいのではないかと思う。

 C. 今回実装されるIPv6申請手続きの簡素化だが、一足先に実装されたAPNIC
   では、IPv6の割り振りが大幅に増加したという実績がある。まだIPv6を保
   有していないが興味がある指定事業者の方は、これを機にIPv6の取得をご
   検討いただければと思う。(ポリシーWG 藤崎)


3. APNIC29アップデート (奥谷 泉/JPNIC)
[質疑応答]
 Q. 逆引きにDNSSECを適用する意義について、APNICミーティングではどのよ
   うな説明が行われたのか。また、異議は出なかったのか。
 A. ミーティングの場で議論は行われなかった。ミーティングの前にMLで
   APNICからアナウンスがあったが、1名反応した程度で、あまり大きな議論
   にはならなかった。正引きで実施しているため、レジストリとしては逆引
   きでも対応する必要があるという説明がAPNICからはあった。(JPNIC 奥谷)

 Q. RPKIについて、APNICではどのよう認識されていたのか。
 A. 現状、アドレスは勝手に経路広告できてしまう潜在的なリスクがある。
   IPv4アドレス在庫枯渇後、新規にアドレスの割り振りを受けられない状況
   で、どうしてもIPv4を利用して通信したい人が、勝手に経路広告を行う可
   能性がある。そのような行為を防ぐためのチェック機構の1つとして、
   RPKIが考えられている。(JPNIC 奥谷)
 C. APNICはアドレスの割り振り先を証明することが第一義と考えている。ま
   たIETF SIDRでは、ルーティングセキュリティにフォーカスして検討が行
われている。[チャットより補足]

 Q. IRRでも、勝手に経路広告されるリスクは防げるように思うが。
 A. もちろんIRRも1つの手段だと思うが、誰でも登録が可能である。それを補
   完する1つの手段として、RPKIを検討しているということだと思う。

 Q. RPKIがなくても、他人のアドレスを自分のASに引き込むことができる、
   という点は認識の上、議論が行われているのか。
 A. APNICではそこまで認識されていない。一方IETFでは、その点も認識して
   議論が行われているようだ。
 C. IRRの登録は現状誰でもできてしまうので、その登録を制限する(認証する)
   ような仕組みを入れたほうがよいと思う。

 C. APNICとしては、今後発生しうるリスクに対して有効と考えられる技術は
   まずは実装して検証しようという考えなのではないか。(JPNIC 奥谷)
 C. あとで何かの役に立つだろうから、というスタンスで検討をするのはよく
   ないと思う。技術的な議論の動向も考慮しながら判断してほしい。
 C. AS Pathは今後の課題である。IETF SIDRでも、IRRはデータの正しさが疑
   われており、JPNICが提供するJPIRRとは状況が異なる。[チャットより補足]

 Q. RPKIでは、IANAをルートにすることになると考えられるが、APNICをルー
   トのままにしたいと言った考えはなかったのか。
 A. APNICでは、IABでの検討に沿って実装を進めることになると思うが、特に
   APNICとしてのコメントはなかったように思う。(JPNIC 奥谷)
 C. APNICをはじめとしたRIRも、シンプルな仕組みを作るために主体的に調整
   を行っている。5RIRをルートとする形が現行提案であるが、たとえばシン
グルルートにすることでRIR間の移転も可能にすることなどが検討されて
   いる。[チャットより補足]

 Q. ガバナンスについてだが、かなり政治的な内容を含んでいるように感じた。
   このような提案が出された経緯、今後の動向予測、今後政府が出てくるこ
   とが予想されるがそれに対する認識、議論の雰囲気などを教えてほしい。
 A. 現在は、ボトムアッププロセスでIPアドレスの管理が行われているが、今
   後進め方が変わってしまうのではないかという警戒感が強かったように思
   う。(JPNIC 奥谷)



4. [提案]「Abuse contact information」(橘 俊男/ポリシーWG)
■abuse contactに関する現状の問題点
 C. abuse contactとして登録する場合は、必ず連絡の取れるメールアドレス
   を記入してほしいと思う。

 C. 過去の経験からいうと、アドレス管理用とAbuse受付用のメールアドレス
   は別にした方がよい。アドレス管理とAbuseの担当が分かれている場合も
   あるためである。また、連絡先はできるだけ多く、様々な箇所に登録で
   きるようにしてほしい。

 C. 複数のコンタクトがあると、至急の場合は検索結果として表示されたすべ
   てのメールアドレスに連絡が行くことがほとんどではないか。データベー
   ス上の多くの箇所に、Abuse担当の連絡先を登録すればいいというもので
   はないように思う。

 C. abuse関連のメールには、機械的に送られたものが多く見受けられる。そ
   のような送信ツールでも連絡先が読み取れる形式で記述(登録)してもらう
   ようにすれば、役に立つかもしれない。

 C. 現在のJPNICデータベースでは、割り振り情報には[Abuse]という項目があ
   るが、割り振りの情報まで遡って確認する人はあまりいないと思う。割り
   当て情報を確認すると、最近は管理者連絡窓口にグループハンドルが登録
   され、abuse担当ではなく総合案内窓口と思われる連絡先が登録されてい
   るケースも多い。グループハンドルにabuse担当の電子メールアドレスを
   登録するための項目を設けるなど、グループハンドルの扱いについても、
   検討してほしい。

 C. ISPのネットワーク運用部門の連絡窓口としての[Abuse]とエンドユーザか
   らSPAMなどの問い合わせ窓口としての[Abuse]、[Abuse]には2つの意味が
   あるように感じる。現在1つになっているこの2つの窓口を分離しようとい
   うのが今回の提案ではないかと感じている。(ポリシーWG 橘)

 C. RIPE Database WG では、 同じ使われ方がある2つのフィールド(abuse-c
   とIRT-contact)が存在することが、触らざるべき話題となっていた。国内
   でも、他の連絡先情報（技術連絡担当者など）との関係を明らかにするよ
   うな議論を、導入勧告の前に行うべきだと思う。

■採決について(1)
 Q. コンセンサス確認だが、2点に分けて実施したいと思っている。まずは、
   APNICと同じ実装をJPNICでも行うことについての是非。適切な連絡先の登
   録の促進する活動も必要と考えるのであれば、ここでは反対を表明すれば
   いい。1回目の採決で反対多数であれば、次にabuse contactの追加の是非
   について確認を行いたい。ここでで賛成多数であれば、具体的な実装方法
   について、JPNICへ検討を依頼する。(ポリシーWG 橘)

 Q. 現在のJPNICデータベースでは、割り振り情報にのみ[Abuse]という項目が
   あるようだが、APNICの提案は、割り当て情報にもabuse contactを登録す
   るというものなのか。
 A. これから新たに作成するオブジェクトには、IRTオブジェクトを登録させ
   るというものである。(IRTオブジェクトを別途登録して、そのハンドル
   (識別名)を登録させる形態になる。JPNICでは、現在[Abuse]には電子メー
   ルアドレスを登録させている)(ポリシーWG 橘)

-----------------------------------------------------
採決[1回目]：(母数：39)
* APNICと提案内容と同一の内容をJPNICで実装することに
 - 賛成 ・・・7
 - 反対 ・・・14
-----------------------------------------------------

■APNICでの施行状況と次回JPOPMでの議論
 Q. APNICでは2010年11月頃に実装される。その実装状況を参考に、次回の
   JPOPM(2010年11月を予定)で議論を行えばいいのではないか。
 A. APNICで実装された内容を議論のトピックとして扱うのも、1つの進め方だ
   と思う。ただしその場合、次回のJPOPMで誰が提案するのかを考える必要
   がある。(ポリシーWG 橘)
 C. APNICから具体的な内容が出るのを待っても、提案に記載されている以上
   の情報は出ないように思う。施行後、どの程度効果があったかは参考にな
   ると思うが、次回JPOPMが開催される2010年11月の時点では施行間もない
   ため、あまり情報が揃わないように思う。(ポリシーWG 藤崎)

 Q. 次回のJPOPMで議論するのが妥当であると思う。その前にJPNICで実装方法
   を検討し、その結果を元に議論するのはどうだろうか。
 A. それが理想的だと思うが、コンセンサスとなっていないものについて、
   JPNICへ検討を依頼することは、PDP上難しい。次回のJPOPMまでにJPNICに
   実装案の検討を求めるのであれば、今回何らかのコンセンサスが必要。
   (ポリシーWG 橘)
 C. それでは今回は、APNICの提案どおりに実装するか否かではなく、abuse
   contactを追加するか否かで採決を取り、JPNICに検討するよう勧告すれば
   いいのではないか。

 C. JPNICで想定するAbuseの考え方と、コミュニティの考えるAbuseの考え方
   があると思う。ぜひともコミュニティとしての考え方を聞きたいと考えて
   いる。(ポリシーWG 藤崎)

 C. 話を聞いていると、実装することに対する反対はないようだが、実装方法
   については議論が尽くされていないように思う。実装される場合、データ
   ベース改造費用がかかり、慎重に検討をすすめるという意味では、次回の
   JPOPMで議論するのがいいのかもしれない。

■JPNICでの実装内容について
 C. Abuse担当専門の情報が必要かどうか、登録の対象となる情報(割り振り情
   報、割り当て情報、AS情報)は何か、登録する情報はメールアドレスのみ
   か、それ以外の情報がほしいかの3点を提示していただければ、JPNICで実
   装検討することは可能。(JPNIC 奥谷)

 C. フォーマットは世界共通であれば良いと思う。管理者連絡窓口は、以前は
   運用責任者であり、そのアドレスの運用に責任を持つ人を登録する項目で
   あった。誰にどの情報が届くべきものであるのかを、しっかり検討した上
   で、議論を行ってほしいと思う。
 C. 管理者連絡窓口はそのアドレスの運用に責任を持つ方の連絡先を、技術連
   絡担当者は、技術的に対応可能な担当者の連絡先を登録してもらうように
   お願いをしている。(JPNIC 奥谷)

 Q. 以前個人情報保護の関係で、責任者に連絡が取れる者であれば、必ずしも
   責任者を登録しなくてもいいことになったと記憶しているが。
 A. 技術連絡担当者についてはその通りだが、運用責任者(※)はその組織に所
   属する方から選任していただくので、代理でISPの担当者を登録すること
   はできない。(JPNIC 奥谷)
※ 現在は[管理者連絡窓口]として正当な理由があれば代行は可能。
      (事後補足)

 C. 割り振りを受けた組織は、アドレスを責任を持って管理する義務がある。
   そのため管理者連絡窓口は割り振りを受けた組織から選任するが、技術連
   絡担当者はそのような責任はない。ネットワークの運用をアウトソーシン
   グしている場合もあると思うので、別の組織の担当者を登録してもいいこ
   とになったと記憶している。

 C. 管理者連絡窓口は台帳管理上の責任者。IPアドレスを実運用している組織
   ではない。実質的な運用責任者に直接連絡が取れる内容を登録すべきだと
   思う。まずはその点についてはっきりした上で、abuse contactを入れる
   かどうかについて議論すべきではないか。

 C. AbuseとIPアドレス管理の担当は別なので、別途項目を作りたいというの
   が今回の提案である。適切な連絡先が登録されているかどうか、誰を登録
   するのが適切かという議論はまた別なのでは。(ポリシーWG 藤崎)

 C. abuse contactを作っても受信するメールはほとんどがSPAMであり、運用
   が難しい部分がある。お金や時間をかけて対応をするよりも、[管理者連
   絡窓口]や[技術連絡担当者]の定義や何を登録すべきかを明確に決め、そ
   れを周知すれば、わざわざ新たに項目を設けなくてもいいと思う。

■採決について(2)
 C. まずAPNICと同じレベルの実装をするかどうかについて、採決を取っては
   どうか。賛成も反対もしない人は第3の案を提案するべきだと思う。

 Q. 1回目の採決で、APNICと同じレベルの実装の希望する人は少なかったはず。
   今回は、abuse contactを追加するか否かについて採決を取り、実装等の
   詳細は次回以降に議論を行うという理解でいいか。
 A. その通り。(ポリシーWG 橘)

 Q. 「abuse contactは新設しない。ただし、各項目には実効性のある内容を
   登録する」という選択肢を採決に加えることを提案したいのだが。
 A. その選択肢を加える場合、「現在の登録内容は実効性がない」ということ
   を説明する必要があるのでは。(ポリシーWG 橘)

 C. 実体験から言うと、管理者連絡窓口や技術連絡窓口として登録されている
   メールアドレスへ連絡しても、到達しないことが多い。これを是正する取
   り組みを含めて検討していくということではないか。

 C. 以前、担当から外れたにもかかわらずJPNICデータベースに登録が残って
   いたため、警察から問い合わせが来たことが何回かあった。もちろん、
   担当を外れる前にデータベースを更新すべきだったとは思うが、このよう
   なケースは他にもあるのではないか。

 C. 実際に連絡が取れない登録情報の件数については、統計は取っていない。
   ただし、データベースに登録されていない情報では連絡が取れない旨の
   電話が週に1回程度ある。電子メールについても、特に統計は取っていな
   い。(JPNIC 奥谷)

 C. 今回はabuse contactを追加するか否かについて採決を取り、担当者に連
   絡が取れる情報の登録を促す取り組みのについては、別途誰かが提案して
   はどうか。

 Q. [Abuse]には何を登録するのか。abuse contactとは何なのか。採決を取る
   前にもう一度確認させてほしい。
 A. 現提案では「Abuse Departmentに入れる」とある。その内容の判断は、各
   自で行ってほしい。(ポリシーWG 橘)

-----------------------------------------------------
採決[2回目]：(母数：39)
* abuse-cの新設に
 - 賛成 ・・・13
 - 反対 ・・・16
-----------------------------------------------------

[結論]
JPNICではabuse contactの設置については対応しない。



5. DNSSECの理想と現実　－そのIPアドレス管理への影響－ (太田 昌孝/東京工業大学)

[質疑応答]
 C. 次に何かを標準化する際は、ぜひいいものを作ってください。

 C. 発表資料18ページ目のCDNの問題についてだが、しっかり実装を行えば、
   そのような問題はないように思うが。DNSSECは大変だが、きちんと運用す
   れば利用できるように作られている。たとえば、安全ではないゾーンから
   応答が返ってきた場合もその旨の検知は可能であり、エラーとして処理す
   るように実装すればいい。まずは、安全にすべきところや、単純なところ
   から徐々に導入するのがいいと思う。DNNSECはまだ問題はあるが、段々よ
   くなっていると思う。
 C. 安全にすべきゾーンが存在するのであれば、むしろDNSSECが使える環境か
   らは参照できないようにする必要があると思うが。もちろん安全にすべき
   ところからDNSSECを導入するのは理想的だと思うが、現実はどうか。現在
   DNSは、DNSSECが検討されていた当時より問題は減っているので、運用し
   ているISPが信頼できるのであれば、問題ないはず。(発表者 太田氏)

 Q. IP-USERS等のMLで、DNSSECを使用する意義を以前問うたことがあるが、今
   回の発表者である太田氏より「導入する意味がないことをJPOPM18で発表
   する」という回答があるのみであった。「DNSSECはしっかり運用すれば安
   全」というコメントがあったが、逆に言うと、「いい加減な運用をすると
   安全ではない」ということか。DNSSECを導入した場合はどの程度安全で、
   導入しなかった場合はどの程度危険なのかを教えてほしい。また、現在の
   DNSが安全であるならば、DNSが安全に運用されるために時間や費用をかけ
   るほうがいいように思うが。
 A. ツリー構造で考えたときに、1つでも安全ではない部分があると、他が安
   全であっても安全ではなくなってしまう。また、DNSSECの運用がいい加減
   であった場合、基本的には検証されないか、検証エラーとなる。検証エラー
   となった場合は、名前解決ができずインターネットに到達できないことに
   なる。

 Q. 時刻同期がいい加減な場合は、検証エラーは返らないはず。その他にも、
   サーバ側やリゾルバ側の運用がいい加減で、エラーにならないケースもあ
   る。必ずエラーが返るわけではないと思うが。(発表者 太田氏)
 A. もちろんまだDNSSECには不十分な面があることは認識している。

 Q. 資料16ページについて、TCPでも通らないケースがあるようだが、これは
   どのようなケースなのか。
 A. 出典の文書を確認したが、詳細は記載されていなかったので不明である。
   (発表者 太田氏)

 Q. 仮にDNSSECが完璧だったとしても、逆引きを詐称しようとする人の動機は、
   逆引きがきちんとできて通信可能なDOS攻撃の標的をこと見つけるくらい
   ではないか。また、逆引きの委譲は正しいことが証明されても、設定値に
   は何も入れてもよいので、アドレスのなりすましは可能。パラメータのチ
   ェックをするならば正引きで行えばよく、逆引きにDNSSECが必要な理由が
   分からない。
 A. 逆引きにおいてDNSSECが機能するケースだが、強いて1つ挙げるとすれば、
   上位から来た委譲が正しいことが確認できるということではないか。
 C. 委譲が正しいことを証明できるが、値が正しいがどうかは性善説で上位
   を信じるしかない。


6. JPNICの逆引きDNSに関するお知らせ （小山 祐司/JPNIC）
[質疑応答]
 Q. 現在のlame率が1％ということだが、これはJPNICから直接委譲されている
   全てのゾーンに対する割合という理解でいいか。その理解で正しい場合、
   JPNICから直接委譲されていないゾーンのlame率はどれくらいか。
 A. 1％とは、JPNICから直接委譲されているゾーンにおける割合という理解で
   問題ない。また、直接委譲していないゾーンのlame率については、JPNIC
   では把握していない。(JPNIC 小山)
 C. ぜひ直接委譲していない部分についても、しっかりと調べてほしい。
   DNSSECの導入を検討する前に、JPNICはまずそちらを優先して検証してほ
   しいと思う。

 Q. JPNICデータベースにはネームサーバを複数登録する必要があるが、きち
   んと設定されたネームサーバが1つあれば十分ではないか。
 A. 1つのネームサーバが24時間365日動きつづければ問題ないが、停止したと
   きのことを想定して、2つ登録していただくようお願いしている。(JPNIC 小山)
 C. JPNICから見た場合は対象が広いため、確かに複数ネームサーバを立てる
   必要があるかもしれない。ただし、たとえばサーバが1台しかないところ
   にネームサーバを複数立てるのは不自然であり、一般的ではないことは誤
   解のないようにしてほしい。

 Q. 2010年4月18日以前、指定事業者は自社が管理するlameと判定されている
   レコードのリストを確認することができた。これが突然廃止されてしまっ
   たのだが、lame解消の対応をすすめる上で役に立っていたので、ぜひ復活
   させてほしい。
 A. 2010年4月19日より、JPNICは指定事業者向けにWeb申請システムの認証を
   強化した。lameチェックシステムはこれとは別のシステムであり、同レ
   ベルの認証強化ができない都合上、廃止させていただいた。容量は大きく
   なるがメールでリストをお送りすることは可能なので、今後対応を検討す
   る。(JPNIC 小山)



7. [提案]「6rd 用アドレス割り振りポリシーの提案」(藤崎 智宏/慶応義塾大学大学院)
[質疑応答]
■料金について
 Q. 提案内容に「料金を考慮してほしい」とあるその意図は。
 A. 現在の料金体系に当てはめた場合、料金がかなり高くなるため、6rd用の
   割引を適用されることを想定している。(提案者 藤崎)

 Q. 実装された場合、JPNICに料金を考慮してほしいとのことだが、アドレス
   の料金についてはポリシー議論ではないと聞いている。今回の提案につい
   ては問題ないのか、確認させてほしい。
 A. ポリシー提案の一部であれば問題ないと考えている。(提案者 藤崎)

■6rdの現状
 Q. このような提案を必要としている組織があるのか。具体的な事例があれば
   教えてほしい。
 A. 具体的な事例は把握していないが、ARINでは提案が提出されているようだ。
   (提案者 藤崎)
 C. ARINでは今回の提案とは異なり、割り振りサイズは指定されていない。
   また、それほど大きな議論にはなっていないようだ。一方RIPEでは、議論
   は起こっているが、ポリシー提案には至っていない。RFCで標準化される
   前であり、大きなアドレス空間を使うことにもなるため、慎重な議論が行
   われている。(JPNIC 奥谷)

 Q. 6rdの技術が広く普及していて、多くの要望があって提案されるのであれ
   ばいいと思うが、一部の技術のためにポリシーを考慮するのは望ましくな
   いのではないか。個々の技術単位で考慮するポリシーを設けることは適切
   ではないと思う。現在6rdはどれくらい利用されているのか。
 A. 6rdは6to4技術をベースにしており、広く使われている。ステートレスプ
   ロトコルとして、変換も不要。主観も入るが、今後主要になるのではない
   かと考えている。一方で、様子を見てからとのご意見も理解できる。個々
   のプロトコル単位でアドレスポリシーが必要であれば、その単位で対応し
   てもよいと考えている。(提案者 藤崎)

 Q. 通常のアドレスの割り振りを受けても、工夫すれば対応できなくはないと
   思う。もう少し6rdが普及するまで、この提案は保留してもよいのではな
   いか。
 A. その点は理解しているが、IPv4アドレス在庫枯渇が来年に迫っている現状
   を考えると、早めに議論を行ったほうがいいと考え、今回提案を行った次
   第である。(提案者 藤崎)

■現在のポリシーと本提案の必要性
 Q. 本当に必要であるならば、現在のポリシーにおいても/32を超えて必要な
   アドレスの分配を受けられるのではないか。
 A. 6rd用に必要なアドレスは、通常の顧客数ベースで需要を算出した場合よ
   りも大きな数になるため、希望している数の割り振りを受けることは難し
   いと思う。(提案者 藤崎)

 Q. 割り振りサイズを/28としたのはなぜか。IPv6のネットワークを本当に実
   装しようと思った場合、技術的にはもう少し大きなサイズでもいいように
   思えるが。
 A. 現在のポリシーでは、必要なアドレスを必要な分だけ割り当てるように定
   められている。今回は、6rdの導入に最低限必要なサイズとして、/28とし
   た。(提案者 藤崎)

 C. 実装のために必要なアドレスは認めるべきとの考えも理解できるが、一部
 の用途のために、特別なアドレスの分配を認めることには賛成できない。

 Q. 現在のポリシーでも、IPv4で運用しているネットワークのIPv6対応用のア
   ドレスとして申請すれば、分配を受けることはそれほど難しくはないので
   はないか。そうであるにも関わらず、申請面や料金面で優遇されるのは受
   け入れ難い。
 A. 現在のポリシーで簡単に取得可能とは思わないが、ご意見として了解した。
   (提案者 藤崎)

 Q. 6rdのメリットは、手軽にすぐにIPv6を実装できるところだと考えている。
   たとえば、6rdを用いてネットワーク運用を開始したいという小規模のISP
   がいる場合、現状のポリシーでは必要なアドレスは取得できないとの認識
   でいいか。
 A. 2年以内の一定の割り当て数(数値)の予定を提示できれば可能。最近の申
   請内容を見ていると、1000ユーザ以上の利用予定があるケースはまれで、
   試験サービスとして200ユーザ程度の利用を見込んでいることが多く、大
   部分が/32の割り振りを行っている。約25万ユーザをIPv6へ移行するケー
   スでは、/32を超える割り振りを行ったことがある。(JPNIC 川端)

 C. 地方のプロバイダの場合、それだけのユーザ数を満たすのは難しいと思う。

 C. 規模の小さなプロバイダほど、保有するアドレスが少ないため、大きなサ
   イズではなく/32で対応できるのではないか。

 Q. 6rdはプライベートアドレスでも対応可能か。
 A. 対応は可能なので、NATも利用できる。(提案者 藤崎)

 Q. NATを利用しなくても、6rdをルーティングするためにプライベートアドレ
   スを使い、IPv4はこれまで通りグローバルアドレスで提供すればいいので
   はないか。
 A. ユーザに割り当てているアドレスをそのまま利用できることが、6rdを利
   用するメリット。プライベートアドレスとグローバルアドレスの2種類の
   IPv4を割り当てればそのようなことも実現可能だが、それではガラパゴス
   状態のルータを作ってしまうことになり、あまり望ましくないのでは。
   現在ユーザにグローバルアドレスを割り当てているのであれば、6rd用に
   もグローバルアドレスを利用するほうがいいと思う。(提案者 藤崎)

■用途を限定した割り振りについて
 Q. 6rd用に利用するアドレスかどうかの判断は、どのように行うのか。
 A. 指定事業者からの申請内容に基づいて判断する。これは他のポリシーでも
   同じ。(提案者 藤崎)

 Q. 6rd用として割り振りを受けて、その後、他の目的で使っていることが判
   明した場合はどうするのか。JPNICは返却を求めるのか。
 A. 規約上可能であれば、目的外使用として返却を求めるべきではないか。
(提案者 藤崎)
 C. 目的外使用についての罰則が規約に盛り込まれた方が、個人的には受け入
   れやすい。

 C. 発表資料11ページに「6rdからネイティブ等に移行する場合には、この空
   間は返却し、顧客数に応じたサイズの別アドレスにリナンバする」とある
   が、IPv4でも難しいことを、IPv6で実現するのは難しいのではないか。
   一部でも顧客が利用している空間があれば返却は難しく、リナンバリング
   は限りなく不可能に近く、多くのアドレスが死蔵されるのでは。

 C. 特定のプロトコルに対して、ポリシーを作ってアドレス空間の無駄使いを
   することは適切ではないと思うし、あまりなじまないと思う。性善説に基
   づいて大きな空間の割り振りを行うと、IPv4と同じような問題を生み出す
   可能性があることを懸念している。

 Q. JPNICが、6rdに対応した機器を販売している組織を支援しているように見
   える可能性もあると思うが。
 A. 実態は別にして、そのような印象を与えるとの意見は理解した。(提案者 藤崎)

■その他
 Q. 採決の際、「今回は棚上げ」という選択肢を追加してはどうか。
 A. その場合は、「反対」に挙手すればいいのではないか。(提案者 藤崎)

-----------------------------------------------------
採決：(母数：36)
* 6rdに特化したアドレス割り振りポリシーを制定することに
 - 賛成 ・・・3
 - 反対 ・・・25
-----------------------------------------------------

[結論]
  反対多数のため、コンセンサスに至らず。




8. 最近のインターネットガバナンスに関するホットトピック（ITU IPv6グループを中心に）(前村 昌紀/JPNIC)
[質疑応答]
   なし



9. RIPE ミーティングレポート (橘 俊男/楽天)
[質疑応答]
   なし


10. コンセンサス確認/まとめ (藤崎 智宏/ポリシーWG)
[質疑応答]
   なし
Contact: contact@jpopf.net