JPNIIC

活動報告のように変遷してきたのか、
現状のIPアドレス管理構造と費用構造とし、2010年12月10日の総会にて、その旨をご報告させていただいがどうなっているかなどを整理し、歴史的PIアドレス割り当て組織

た次第です。

の内容を検討してまとめていく作業も行ってきました。
また、この資料をもとに、2010年9月末頃から順次機会を設けて、説明会とご意見聴取を進めてまいりました。
歴史的PIアドレス割り当て組織の方々全体に呼びかけて実施し2010.8.24 8.27▲の方々に、費用負担についてご理解をいただけるような説明資料

インターネット・
トピックス 〜関連団体の動向〜

第42回総会
資料1-1「『IPアドレス等料金体系改定の件』
検討状況の報告」
http://www.nic.ad.jp/ja/materials/general-meeting/20101210/shiryou1.pdf◆今後の進め方／取り組みについて
2011年度からの料金体系改定は見送らせていただきましたが、

APNIC30ミーティング報告■ 全体報告今回のAPNICミーティングは、日本人も多く訪れるオーストラリ
ア最大の観光保養地、
ゴールドコーストで開催されました。

た説明会は、2010年10月に2回開催いたしましたが、それ以外にも今後も料金体系改定実施は必要であると考えております。
そのた

地域の情報基盤センターや学術系ネットワーク団体の会合の機会

め、
これまでいただいたご意見を踏まえながら、今後より一層の広・開催期間：2010年8月24日〜8月27日などを利用し、意見交換をさせていただきました。

報、広聴活動を実施し、皆様にご理解をいただいた上での改定を

・開催地 ：オーストラリア、
ゴールドコースト

実現していきます。

・会場：サーファースパラダイス・マリオットリゾートアンドスパ

・参加者 ：オンサイト

このような機会を通じて、前述したように、利用用途による料金の区別は難しいという点をご説明させていただいたものの、
やはり学

今後の広報、
広聴活動においては、
これまで説明会等にご参加い術組織等に対する何らかの割引措置などを検討して欲しいというただけていない組織の方々への広報とご意見聴取を網羅的に行う一ご要望をあらためていただきました。

方で、必要に応じて個別的なヒアリング活動も実施していく予定です。

リモート会場

183名
24名

リモート参加 165名

また、
2011年度からの課金開始とした場合、2010年12月に金額がそのため、まずは2011年1月中に、すべての歴史的PIアドレス割り

反政府デモで政情が不安定なことから、開催の3ヶ月前に急遽決定するのは予算策定、確保スケジュールの都合上非常に厳しく、当て組織に対して、書面による料金改定に関するご説明を送付さ

APNICオフィスから1時間程度でアクセスできる、本開催地にこの段階で請求方式や細かな契約手続きが未確定なのであれば、せていただくとともに、ご担当者様の連絡先の再確認、また今後の変更したという経緯があります。当初の想定外ではありました

IPアドレスの利用継続意向などについてお伺いをする予定です。
まが、2000年のブリスベンでの開催以来、ちょうど10年ぶりにた、
その中で、現在の料金改定案についてのご意見も積極的におAPNICの地元での開催となりました。

◆2011年度からの実施見送りの理由

また、ミーティング最終日のAPNIC総会には、距離的に近いこともあって、普段はカンファレンスに参加しないバックオフィスのAPNICス

実は当初開催地としてバンコクが予定されていたのですが、実施時期をずらして欲しい、というご意見も多数いただきました。

Gold Coast, Australia

タッフも顔を出しており、私自身も普段メールだけでやりとりを行っている担当者に直接会って話をすることができました。
◆Member Petition BoF
Member Petition BoFで議論されたAPNIC組織運営に関する改善については、
前回のAPNIC29ミーティング以来、ECの選出方法の改定や政府関係者の関与の必要性を主張するインドのコミュニティメン

伺いしたいと考えています。

アドレスポリシーについては、今回議論の対象となった5点の新たな料金体系案についてのご意見聴取を進めていく中で、
歴

バーと、
その他メンバーとの間でメーリングリストでの議論が白熱してい史的PIアドレス割り当て組織の方々からもIPアドレス事業費用の一並行して、料金改定に関する説明と手続きを詳細に示した文

うち、提案者の意思により今回の提案としては取り下げられ次回た経緯もあり、
どのようなかたちで決着させるのかが注目されていました。

部を負担いただくことについては、
徐々にご理解をいただけるように書、規約案、合意確認を行うための書面等の整備、請求方法、お持ち越しとなった1点を除き、残り4点の提案はすべて継続議論

また、
アドレスポリシーと料金改定以外のテーマで、コミュニティメンバー

なってきていると考えております。

支払い方法の詳細など、各組織において、よりお支払いしやすい方となり、APNICミーティング後、施行するポリシーがないという珍から提案が行われたことはフォーラム上初めてのことでもあります。

法の詳細を、関連各位と連携しながら検討を進めます。
そして、上しい結果で終了しました。

しかし、
歴史的PIアドレス割り当て組織全体から見ると、
まだ十分

記の活動、
検討を実施した上で、最終的な料金体系案をまとめて、なご意見聴取ができていない状況にあります。前述したように、情2011年6月のJPNIC総会にてお諮りできるように取り組んでいく予

報基盤センターや学術系ネットワーク団体の会合の機会などを利定です。

用させていただいたこともあり、大学関係組織に対するアプローチ
は比較的進んできたと思われますが、地方自治体関係組織や、数

これまでJPNICは、
日本のインターネットの安定運用のため、適切として最も多い一般企業の方々に対しては、アプローチできているなIPアドレス管理業務に努めてきました。今後もIPアドレスの適切な割合が、比較的低いと認識しています。

管理体制を継続的に維持していくためには、
IPアドレスを利用している皆様からのご協力が不可欠です。

組織運営上のルールはAPNICの定款で定められており、全会員票数の2/3以上の賛成をもってしか変更することができません。
そのため、
BoFでは

プログラム構成は従来同様、初日にトレーニング・チュートリアル、
最終

冒頭で、
定款変更などに必要な請願（petition）
プロセスについて、説明が日にAPNIC総会を行い、
APOPS、ポリシーSIGを主な軸として、その他行われた後、ポリシーSIGに提出された三つの改定案が発表されました。

の時間にPlenaryや各種BoF等が割り当てられていました。
今回、議論の行方が一番注目されていたセッションは、新たに設けられたプログラム“Member Petition BoF”です。
これは、
APNICのフォー
ラム運営会則の改定を求める提案が、インドのコミュニティメンバーか

また、請求方式に関する要望や返却手続きの明確化など、いた
だいたご意見に対応するための事務手続き等の準備、検討を進

そのため、今回の料金体系改定の検討についても、皆様からのめていくためにもまだ時間がかかるといった状況もあり、理事会により多くのご意見を伺いながら進めてまいりたいと考えておりますのおける検討の結果、
このまま2010年12月の総会に議案として諮り、で、ぜひとも引き続き、
ご理解とご協力をお願いしたいと思います。

らポリシーSIGに提出されたことに対応したものです。
提案では、APNIC EC
（Executive Council）
選出方法の変更等、
APNICフォーラムの組織運営に関する改善を求めており、
ポリシー

2011年度からの実施とするのは困難であるとの判断に至りました。
（JPNIC IP事業部 佐藤晋）
そのため、2011年度については現行の料金体系を継続すること◆プログラムSIGで取り扱うテーマではないとSIGチェアが判断したため、
ECで協議
の結果、
専用のBoFを設けて議論を行う運びとなりました。

■ APNIC30はオーストラリア最大の観光地ゴールドコーストで開催されました

Activity Report
20 JPNIC Newsletter No.47 March 2011

JPNIC Newsletter No.47 March 201121

インターネット・
トピックス 〜関連団体の動向〜

インターネット・
トピックス 〜関連団体の動向〜

・EC選挙における投票権を1会員1票に限定する
・再選されたECの就任期間に上限を設ける

prop-087については、6rd（IPv6 rapid deployment）の実装

・在庫枯渇後に返却されたアドレスの管理に向けたIPv6アドレスポリシーを定義することを目的として、国内のセッションでは明確な結論が出ずその後、
APNICにおける在庫枯渇

アドレスポリシーフォーラムで議論を行い、そこでは支持の得られな後に返却されたIPv4アドレスはすべて最後の/8の分配ポリシーを適かった提案を改めたものです。APNICフォーラムでは、提案の意図

用するよう、
APNIC31に向けてコミュニティメンバーが提案※4を提出

・政 府 機 関の意 見を取り入れられるGA C（Go v e r n m e n t a l

自体は支持できるとのコメントも表明されていた一方、運用を工夫

Advisory Committee; 政府諮問委員会）の新設を求めるすることで必要とするアドレスサイズを小さくしながら、6rdの実装を・APNIC管理下のIPv4 /8における最小プリフィクスの変更実現できないのかとの確認が議論の焦点となり、継続議論となりま

最小移転単位に合わせてAPNIC管理下の全/8における最小分した。

配プリフィクスの表記を/24とし、文中に最小割り振り単位を記述

このうち、EC選挙における投票権を1会員1票に限定する提案と、政府機関の意見を取り入れられるGACの新設を求める提案の2点については、改定の必要性を検討していくことが合意され、ワーキンググ

それぞれの提案概要については、
下記URLよりご参照ください。

ループも設立されることになりました。

ip-address-trends/minimum-allocations
http://www.apnic.net/community/policy/proposals

メーリングリストでの議論の流れからは、
こうした合意に達することが難しいように見えましたが、共通の現状認識に基づいて今後議論を進める土台はできたと考えられます。
今回のようにAPNICフォーラムにおいて、政府が議論できる場を設ける必要性について公式に議論され◆選挙の結果今回のミーティングでは、以下三つのポジションに対する選挙が行われました。

＜次回持ち越しとなった提案＞＜次回持ち越しとなった提案＞
prop-083：IPv6追加割り振りにおける別要件の新設＜次回持ち越しとなった提案＞＜継続議論となった提案＞
prop-084 ：定期的なWHOIS情報の更新要請
prop-085 ： APNIC最後の/8在庫からのクリティカルインフ
ラへの割り当てprop-086 ：IANA在庫枯渇後のIPv4割り振りに関する
グローバルポリシー
prop-087 ：IPv6の実装実現のためのIPv6アドレスの割り振り◆ミーティングを振り返って※2 SIG Chair/Co-Chair
SIG（Special Interest Group）
セッションの議長を務め、提案事項があった場
合はコンセンサスの判断を行います。
※3 最後の/8ポリシー
APNICにおける通常在庫枯渇後は、別途リザーブしている当該/8空間からの分配に切り替えます。
この空間からの分配は1組織一律/22（1,024ホスト）に限定されます。
※4 prop-088: Distribution of IPv4 addresses once the final /8 period starts
http://www.apnic.net/policy/proposals/prop-088※5 JPNIC News&Views vol.731「APNIC29ミーティング報告 [第1弾] 全体報告」
http://www.nic.ad.jp/ja/mailmagazine/backnumber/2010/vol731.html

ここ最近のミーティングの傾向としては、
これまで中心に進めてきた
ネットワーク運用やアドレスポリシーに関する議論に加え、前回のミー
今回はEC選挙のプ
ティング※5ではITUにおけるIPv6アドレスの管理、■ APOPSレポート

ロセス、
および地域内の国や経済圏の意見をどうAPNICフォーラムにたことは初めてです。
◆アドレスポリシー提案の結果

http://www.apnic.net/publications/research-and-insights/※1 NC（Number Council）
各RIRの地域ポリシーフォーラムから選出された2名と、各RIRの理事会から指名された1名の計15名からなる組織で、グローバルポリシーに関する判断などを行っています。

http://meetings.apnic.net/30/elections

反映していくのかといった、
ガバナンスの話にテーマが拡張しつつある

報告します。APOPSは、アジア太平洋地域のインターネット・オ

・NRO NC※1
Naresh Ajwani氏（再選）
前回のEC選挙プロセスについて問題提起が行われたこともあり、
こ

APNIC30ミーティング内の1セッションとして開催された、
APOPS（The Asia Pacific OperatorS Forum）
についてごことを感じました。
実際、今回もアドレスポリシー提案よりも、EC選挙プロセスをはじめペレーターを対象とした技術的な話題を扱うフォーラムです。

としたAPNICフォーラム運営方針の改定について、活発な議論が行

APNIC30では、2010年8月25日（水）10時から15時30分

われていたことが印象的でした。

にかけて、九つのプレゼンテーションが発表されました。

れまでにないほど丁寧にプロセスの説明が行われていました。
票カウントにあたっても細かい点まで状況が共有され、コミュニティへの確認が行われていたことも印象的でした。

アドレス管理面では、
IPv4アドレス在庫枯渇に向けて必要となる大本稿では、紹介されたプレゼンテーションのうち、ネットワーク

枠のポリシーは施行されているため、個々の未対応のケースはまだの調査・計測に関する三つのアジェンダについてご報告します。

提案されてはいるものの、ポリシー以外の現在フォーラムを取り巻く課
・SIG Chair/Co-Chair ※2

題に関心がシフトしてきているのかもしれません。

Policy SIG Chair:Gaurab Raj Upadhaya氏（旧Chair：Randy Bush氏）◆Measuring traffic in 1/8, 14/8, and 223/8
APNICのGeorge Michaelson氏から、
1/8、
14/8、
223/8といった各ア

なお、
今回議論されたアドレスポリシー提案は、
基本的にすべて継ドレスブロックにおけるトラフィック量の調査について紹介がありました。

NIR SIG Co-Chair:Ji-Young Lee氏

続議論となったため、次回香港で開催されるAPNIC31ミーティング

1/8、
14/8、
223/8は、今年になって新規にAPNICへ割り振られたアドレ（旧Co-Chair：Ching-Heng Ku氏）

で再度議論が行われます。

スブロックで、それぞれのブロックには以下のような特徴があります。

◆その他：IPv4 Tomorrow?

◆次回のミーティング-

1/8 “1”
で始まる特徴的な数字を持ったアドレスブロック

このうち、
prop-086は、在庫枯渇後にRIRに返却されたアドレスの管

このPlenaryセッションでは、
APNICのIPv4アドレス在庫枯渇に向け

次回のAPNICミーティングはAPRICOT 2011と併せて、2011年2月に- 14/8 X.25との接続のために使用されていたアドレスブロック

理方法を定義したものです。
現在の提案内容は、
RIRからIANAへのたアドレス管理に関する3点の課題への対応について、
APNIC事務香港で開催される予定で、この号が発行される頃にはミーティングの結- 223/8 プライベートや実験目的のアドレスとして使用されやすい

返却が任意であるために実効性が薄く、必要性が理解できない等の局からコミュニティに問いかけが行われ、それぞれ以下の結論となりま果を以下のURLからご覧いただけるようになっているかと思います。

理由から支持されませんでした。

した。
□APNIC31

ただし、
現在はIANAからRIRへの最小分配単位が/8という大きな・最後のIPv4 /8在庫空間の特定ブロックであるため、在庫枯渇に向けて、
より小さな単位での未割り振り

どの/8プリフィクスから最後の/8ポリシー※3を適用するべきかは、

アドレスも分配可能とする必要があるのではとのコメントはありました。

運用上の課題としてAPNIC事務局の判断に一任

22 JPNIC Newsletter No.47 March 2011

アドレスブロック2010年1月に、
RIPE NCCが1/8のうち一部のアドレスブロックを経

http://meetings.apnic.net/31

路広告したところ、
10Mbpsのトラフィックが流れたことや、
また、
Merit
Network社が1/8のアドレスブロックを経路広告したところ、1週間で（JPNIC IP事業部 奥谷泉）

7.9TBのパケットが捕捉でき、瞬間的には860Mbpsのトラフィックを観JPNIC Newsletter No.47 March 201123

インターネット・
トピックス 〜関連団体の動向〜

測したことなどが紹介されました。

・IPv4のみ果をBGPルータで使うための設定、IRRのようなWHOISサービ■ リソースPKI関連報告

・IPv6のみ
14/8や223/8のアドレスブロックと比較して、1/8では数倍のトラ・IPv4/IPv6デュアルスタック（IPv6優先）

フィックが流れていること、1.1.1.0/24のアドレスを持つパケットが全体

・IPv4/IPv6デュアルスタック（IPv4優先）スなどが実装されました。
このプログラムは、以下のURLから入手可能です。

本稿では、APNICにおけるリソースPKI（以下、RPKI）の動
向や、RIRにおけるデータベースの動向について報告します。

の44.5%を占めることも紹介されました。
また、宛先ポート番号も調査

Resource PKI Software: http://www.rpki.net/

され、TCP445番ポート宛のパケットが多数を占めていることから、ウイと分類されますが、これらがどの程度使用されているか調査されたそ

ルスやワームによるトラフィックも無視できないほど存在することが述うです。方法としては、
APNICのWebサイトに、
IPv4/IPv6アドレスそ

前回のAPNIC29ミーティングで行われたRPKI BoFにべられました。

れぞれでアクセスできる画像ファイルを置き、どのくらいアクセスがあっ

続き、今 回はR P K Iセミナーと呼ばれるセッションが行われ◆Route Filtering: Handle with Care

たのかを調べたとのことです。
その結果、デュアルスタックのクライアン

ました。RPKIに関する話題は、3日目（2010年8月26日）

R I P E N C CのレジストリシステムであるL I R P o r t a lの、
リ

トはIPv4優先のクライアントが多く、IPv6のみのクライアントは1%以に行われたライトニングトークやR I R の 活 動 報 告 、A P N I C

ソース証 明 書 関 連 の ユ ー ザ ーインタフェースの 紹 介 で す 。

下だったことが分かったそうです。

のメンバーミーティングでも挙がりました。

L I R P o r t a lは、J P N I C の W e b申請システムにあたります 。

APNICのFrank Salanitri氏、
NTTコミュニケーションズ株式会社の吉田友哉氏の両氏から、経路情報のフィルタリングについて紹介◆RPKIセミナーで行われたプレゼンテーションの内容がありました。

（3）RIPE NCC Certification Software

Webインタフェースでリソース証明書やROA（Route Origin
Authorizations）の生成や管理を行うことができます。2年程

RPKIセミナーでは、RPKIツールの開発状況やRIRの取り組

前にご紹介したことのある※2 certtestというプロトタイプシステム

初めに、
Salanitri氏から、古くなったブラックリスト、
Bogon※1リストにみ状況が報告され、ディスカッションが行われました。セミナーとと基本的な機能は変わっていませんが、当時RIPE NCCのメン

よる通信障害が発生しているため、フィルタに使用する各種のリストいう名 前ではありますが、チュートリアルではなく活 動 紹 介を集バーでなくても試すことができたものが、今は実際の割り振り/割は、最新の状態に保つことが重要であることが紹介されました。
また、めたようなセッションでした。おのおのが興 味 深いプレゼンテー

り当ての通りに提供されるようになり、RIPE NCCのメンバーの

APNICでも、広報活動やトレーニングを行って啓発に努めていること

ションでしたので、内容を紹介します。

みが利用できるようになっています。

が紹介されました。
またRIPE NCCでは、RIPE NCC Validatorと呼ばれるリ（1）BBN's RPKI Relying Party Software
続いて、吉田氏から、debogon projectについて紹介がありました。新しい/8のアドレスブロックからその一部を顧客に割り当てたとこ
ろ、Webサイトを見ることができないという苦情があり、その原因を調べてみると、古いBogonリストがWebサイトに到達するまでの途中経

ソース証明書の検証ツールがJavaを使って開発されました。
こ
R P K Iの証 明 書 検 証プログラムの設 計と開 発を行っている■ 会議の様子◇◇◇です。IETF SIDR（Secure Inter-Domain Routing）WGで※1

新たに提案されたRPKI/Router Protocol を実装していま路で使われていた、というエピソードが紹介されました。
今 回のA P N I Cミーティングでは、アドレス割り振り時のネット
また、
27/8、
14/8、
223/8のネットワーク到達性の調査について報告

ワーク到達性について、
また、IPv6の実装や普及状況について処理するサーバとルータの間で使われるプロトコルで、キャッシュのプレゼンテーションが多かったように思います。
これには、IPv4と呼ばれる、
リソース証明書の検証結果を含んだデータをBGP

性が無いことが報告されました。

アドレス在庫枯渇も目前に迫ってきており、それに対する備えをルータに送ることができます。今後ソースコードが公開される予喚起する意味があったようにも感じられました。

定です。

（JPNIC 技術部 小山祐司）（2）RPKI Tools from Soup to Nuts

□The Asia Pacific OperatorS Forum
http://www.apops.net/

よるアクセスがどれくらいあるのかが述べられました。2008年の中頃2%程度になったことが紹介されました。

（4）Using RPKI tools in MyAPNICAPNICのMyAPNICにおける、RPKIの実装に関する紹介です。新たに、ROAをグループ単位で管理できるインタフェース
R O Aを、一 度にグループ全 体で更 新することなどができるようになりました。
また、
リソース証 明 書の検 証を行うための公 開用が紹介されました。

までは、割合として1%にも満たない程度だったのが、それ以降は1〜

validator-for-resource-certification

が加わりました。
これにより、数多く発行されることが予測される

APNICのGeorge Michaelson氏から、IPv6に関する調査結果

まず初めに、
IPv6の普及状況として、
www.apnic.netへのIPv6に

http://labs.ripe.net/Members/agowland/ripe-ncc-

す。
このプロトコルは、RPKIサーバと呼ばれるリソース証明書をがあり、割り振られた直後では、
20〜30%のネットワークに対して到達◆A second look at measuring IPv6のプログラムも、RPKI/Routerプロトコルを実装しています。

BBNテクノロジーズ社のStephen Kent氏によるツールの紹介□Program / Agenda - APNIC 30
http://meetings.apnic.net/30/program/

ISC（Internet Systems Consortium）
で、RPKIのツール開

Webページの準備が進められているようです。

発を行っているRob Austein氏による開発状況の報告です。ISCのRPKIツールは、IPアドレスのリストからリソース証明書を発行し

質 疑 応 答の時 間には、R I Rで提 供されているR P K Iのツーたり、
リソース証明書が格納された複数のリポジトリの間で、
リソー

ルにおける、秘 密 鍵 の 管 理 方 法 につ いて 議 論されました 。

ス証明書の交換を行ったりする機能を持っています。

L I R P o r t a lとM y A P N I C は 、ユ ーザ ーの 秘 密 鍵 が W e b
サーバ 側で保 管されています 。W e b サーバ 側で保 管されてまた、
IPv4およびIPv6プロトコルスタックが、クライアントにどのように実装されているかについての調査発表がありました。
プロトコルスタックの実装としては、

24 JPNIC Newsletter No.47 March 2011

※1 Bogon
インターネットの経路制御において、広告可能アドレスとして登録されていない
アドレスブロックやAS番号を指します。

2 0 0 9 年 1 1月に広 島で開 催された第 7 6 回 I E T Fの時には、いることについて、A R I N のチェアであるJ o h n K a r r e n 氏

既に一 連の動 作をするまでに開 発されていましたが、その後、は、多くのユーザーの秘 密 鍵 が 同 時に漏 洩してしまう構 造でRPKIサーバとルータの間の通信や、リソース証明書の検証結ある点を指 摘しました。これに対して、現 在はW e b サーバ 側

JPNIC Newsletter No.47 March 201125

インターネット・
トピックス 〜関連団体の動向〜

2010.11.7 11.12

げていく活動を行っているようです。

▲

であるが 、将 来はユーザー側で管 理 することが 考えられるという意 見 が 挙 がったり、それには鍵 の 生 成と安 全な切り替えを行う必 要 があるといったりした議 論 が 行われました。

A P N I CとR I P E N C Cでは既にメンバーにリソース証 明 書を提 供しており、A R I Nでも試 験 的に、メンバーのうち希 望 者に対しては提 供されています。今 後 A f r i N I Cで提 供されると、四つの地 域でリソース証 明 書が使えることになります。

第79回IETF報告■ 全体会議報告◆概要

しかし、N I Rからアドレスの割り振りを受けている事 業 者は、

第79回IETFミーティングは、
中国の北京で行われました。会場とリソース証 明 書を技 術 的に試 すこともできません。今 後 、アジなったホテルは、
北京の中心部から少し外れていますが、付近に大型

ア太 平 洋 地 域でどのように取り組んでいくべきなのかを考えるの商店やカフェがあり、参加者にとって快適な会場であったようです。

段 階に入っていくと考えられます。

Beijing, China

第79回IETFミーティングの開催概要：◇◇◇

開催期間： 2010年11月7日
（日）
〜12日
（金）

行うまでに発展したことは意義深いと思われます。

会場： Shangri-La Hotel Beijing
A M M の 活 動 報 告 に 関 するプレゼンテーションの 中 で 、
D N S S E C 対 応が完了し、M y A P N I CでD Sレコードが登 録で■ 会場となったSurfers Paradise Marriott Resort & Spa◆ライトニングトークにおけるRPKIの話題
A P N I Cミーティングの3日目に行われたライトニングトークでは、R P K Iを導 入 することの経 路ハイジャックに対 する効 果にきるようになったことが 報 告されました。ある技 術 がどの 程 度

して、R P K Iがどの程 度 有 効なのかをR I S ※ 3のデータを使って試算しています。
経 路 ハイジャックが 成 功しうる経 路 情 報 の 組 み 合わ せは、
今 回 対 象とした8 0 程 度のA Sにおける経 路 数の3 4 . 2 %ありま

実装に貢献したBjoern A. Zeeb氏に贈られました。
Itojun Service

ホスト： 清華大学（Tsinghua University）

Awardは、萩野純一郎氏にちなんで2009年に設立された賞で、IPv6の開発や運用などについて技術的貢献を行った人に贈られ役に立つのかを議 論し、綿 密に検 証していくことは大 事なこと
IETFチェアの発表によると、国別の内訳は、第1位が中国取り組みのように、短 期 間で実 装し、試 験 利用を通じて効 果や（33%）、第2位が米国（29%）、第3位が日本（8%）、第4

FirewallやSeND（Secure Neighbor Discovery）などの実装にお利 便 性を考えていくというアプローチには興 味 深いものがあり

位がフランス（4%）でした。

いて貢献しました。

ます。受賞者のZeeb氏は、FreeBSDにおけるIPv6、IPsec、IPv6のます。
（JPNIC 技術部／インターネット推進部 木村泰司）のように、Origin ASが本来とは異なり、かつASパス長が短くなるような経 路 情 報 が 流されるタイプの経 路ハイジャックに対2回目となるItojun Service Awardは、FreeBSDにおけるIPv6の参加国数： 52ヶ国

ではありますが、R I P E L a b sやA P N I CのD N S S E Cに対 する

ついて、R I P E N C CのM a r k D r a n s e 氏 が 紹 介していました。2 0 0 8 年 2月に起こったY o u T u b eの経 路ハイジャック事 件

参加者数：1,177名※1“The RPKI/Router Protocol”, Randy Bush, Rob Austin
http://tools.ietf.org/id/draft-ietf-sidr-rpki-rtr-02.txt※2 JPNIC News & Views vol.592「第57回RIPEミーティング報告」
http://www.nic.ad.jp/ja/mailmagazine/backnumber/2008/vol592.html※3 Information Services（RIPE NCC）
http://is-portal.ripe.net/

す。
しかしR P K Iを導 入 すると、これを1 3 . 6 %に下 げることが初日の11月7日（日）に、チュートリアルとレセプションが開か

IETFチェアのRuss Housley氏からは、
第78回IETFミーティング

れ、2日目から最終日にかけて、IETFの全体会議である二つのプ以降の全体の活動状況が報告されました。現在WGは124あり、108

レナリ、各ワーキンググループ（WG）のミーティング、BoFが開かのRFCが作成されました。IETFチェアの報告内容は以下のWebれました。本号では、二つのプレナリの模様を中心に報告します。

ページで公開されています。

◆Operations and Administration Plenary□Plenary report（IASA）

本プレナリはI E T Fの運 営 等に関する全 体 会 議で、1 1月1 0

http://iaoc.ietf.org/plenary_reports.html

日（ 水 ）1 6 : 3 0から行われました。初めに清 華 大 学のホストプレ
ゼンテーションがあり、次にISOCのItojun Service Award受
賞者の発表、IETFチェアの活動報告が行われました。

できるとのことです 。当 然 のことながら、この 数 値はA Sによっオープンマイクロホンでは、I E T Fの資 料を載 せるW e bペー
ジに資 料 があまりアップロードされていない状 況を改 善してほしいという要 望が挙げられたり、I E T FチェアのH o u s l e y 氏がて違いがあり、7 %〜2 2 %と幅があります 。
またこれは、O r i g i n

今回のホストは中国の国立大学である清華大学です。中国

検 討しているB o F 枠の割り当ての考え方について、参 加 人 数

A Sの確 認が1 0 0 % 行われ、必 ずA Sパス長が最も短い経 路がの大学間ネットワークであるCERNET（China Education andを考慮してほしいといった要望が挙げられたりしていました。

優 先される、といったシンプルかつ有 利に働く条 件で試 算されResearch Network）
は、清華大学が中心となり構築と運用が行わています。

れています。1988年当初は、X.25をバックボーンに使った小規模な◆IAB Technical Plenary

ものでしたが、CERNETはいまや中国の主要な大学間を10Gbps

こちらのプレナリは技 術 的な議 論を行う全 体 会 議で、1 1月のリンクで結ぶまでに発展しています。後述するIADの活動報告

8日（月）に行われました。IRTF（Internet Research Task

A P N I Cメンバーミーティング（ A M M ）での 報 告によると、

で、Bob Hinden氏が、1991年にビデオ会議システムのCUSeeMeでForce）の活動報告とIABの活動報告が行われた後に“IPv6

APNICではAfriNICでのRPKIの導入に協力し、現在のテス“Hello from Beijing”という文字列を見てから、
ちょうど20年経った

Operations Transitional Issues”と題してパネルディスカッションと述べています。
ネットワークの相互接続のみならずIETFのホストをが行われました。

◆RIRにおけるRPKIの取り組み

ト段階からAfriNICメンバーへの提供ができる段階まで引き上

26 JPNIC Newsletter No.47 March 2011■“10minutes talks”の様子

JPNIC Newsletter No.47 March 201127

インターネット・
トピックス 〜関連団体の動向〜

IRTFチェアのAaron Falk氏によると、IRTFでは“Machine

まり、
ルーティングやDNSなど、
インターネットの運用や研究に

Learning & Communication Systems”と“Internet of Things”

関連した話題が議論される会議です。参加は無料で、毎回という二つの新しいリサーチトピックを扱おうとしているそうです。特IETFの直前の日曜日（今回は初日の11月7日）に行われます。

に前者は、
irtf-discuss@irtf.org メーリングリスト
（ML）
で議論が行

今回は、IPv4とIPv6のトランスレーターの性能比較や、DNSとわれることになっています。
なお、Falk氏は2011年3月に引退し、次DNSSECの性能比較に関する発表が行われました。

のIETFで次期IRTFチェアが決まることになっています。

第80回IETFミーティングは、2011年3月27日〜4月1日、チェコのプラハで行われる予定です。

draft-ietf-6man-prefixlen-p2p・重複アドレス選択プロキシ■ IPv6関連WG報告

draft-costa-6man-dad-proxy・アドレス登録に関する要求条件□IEPG
http://www.iepg.org/

・P2Pリンク上におけるIPv6プリフィクス長 /127の利用

本稿では、会期中における、IPv6に特化した内容を議論する

draft-jiang-6man-addr-registration-req

ワーキンググループ（WG）での議論内容を中心に紹介します。
- ISOCパネル
第76回IETFミーティング以降、ランチの時間に行われている◆6man WG（IPv6 Maintenance WG）

ISOC主催のパネルディスカッション“ISOC Panel”
は、3日目の6man WGは、
IPv6のプロトコル自体のメンテナンスを実施するWG

11月9日に行われました。今回のテーマは“Mobility”
、
ワイヤレ

です。
今回は、
11月9日
（火）
の午後最初に1コマにて開催されました。

の資料や会場の録音データは、以下のページで入手できます。
■ IAB Technical Plenaryでパネルとして登壇する株式会社インターネットイニシア
ティブ
（IIJ）
の松崎吉伸氏IABでは、
これまでにプレナリで議論されてきた話題をドキュメン

・IPv6フローラベルに関するセキュリティ評価

セッション開始後、チェアより6man WGで取り組み中である、以下の文書についてステータス報告がありました。

・Teredo ループ攻撃の緩和
draft-gont-6man-teredo-loops□Internet Society Mobility Panel @ IETF 79
http://www.isoc.org/isoc/conferences/mobility/

・IPv6推奨アドレス表記（RFC5952として発行済み）（・エンドポイント識別子（EID）
オプションの廃止 draft-gont-6man-

・DNS RAオプション（IESG承認、RFCエディタ発行準備中）

obsolete-eid-option）→ 時間切れで議論できず。

※2010年11月末に、RFC 6106（Standard Track）
として発行

ト化する作業を進める一方で、ワークショップを開催しています。

これらのアジェンダの中から、いくつかのトピックについてご紹- CNNICツアー
CNNICは中国のNIR（National Internet Registry）
で、
IPアドレ

・ルータ要請メッセージでの回線識別（draft-krishnan-6man-

Plane OAM”
（2010年10月12日〜14日開催）

スやAS番号の他にドメイン名のレジストリでもあります。
IETF期間rs-mark-08）: WGドラフトとして登録

http://trac.tools.ietf.org/area/ops/trac/wiki/oamJDS

中の11月7日と9日にCNNICの見学ツアーが行われました。
CNNIC□IESG/IAB workshop“Architectural Oversight Forwarding

draft-carpenter-6man-flow-update、
draft-carpenter-flow-ecmp

draft-gont-6man-flowlabel-security

スのモバイル機器に広がってきたインターネットについてディス
カッションが行われました。
モデレーターであるLeslie Daigle氏

・IPv6フローラベル仕様の更新

介します。
・IPv6拡張ヘッダの統一フォーマット

ではDNSSECの実験の他に、
DNSトラフィックデータに基づいて最後の回線識別ドラフトに関しては、「技術的問題が多く、WGドラフトと□How can Technology help to Improve Privacy on the Internet

DNSルートサーバ等に関する研究が行われており、技術的にこだ

する合意に達していないのでは」という指摘がありましたが、「まずはWG（2010年12月8日〜9日開催）

わりのあるIETF参加者からも注目されて、好評を得ていました。

ドラフトにしてから技術的課題を検討するのであって、RFCとして発行す

IPv6拡張ヘッダの標準フォーマットを決めよう、という提案です。

ることとは別」というフォローがありました（WGドラフト化は、
IETF79前に、現在定義されている拡張ヘッダでは、
フォーマットに統一性はありま

WGドラフトとするかどうかの合意確認がMLで実施された結果です）。

せん。
今後新たに拡張ヘッダを追加定義する際、新しい拡張ヘッダを今回、以下のテーマが議論されています。時間の割には議題がよう、ヘッダの長さ情報等のフィールドを規定するなど、
フォーマットに

http://www.iab.org/about/workshops/privacy/
最後に、第2部としてRFC Series Editorモデルについて議論が行

draft-ietf-6man-exthdr

認識できない古い機器がそのヘッダ部分をスキップすることができる

われました。2年前の組織構造の見直しで、
RFC5620: RFC Editor

非常に多いという印象でした。

Model（Version 1）が作成されましたが、このモデルに合うRFC
Series Editorを雇うことに失敗、再度モデルの見直しを行うことになっ統一性を持たせることを提議しています。
会場から、中間ノードが知らない拡張ヘッダに遭遇した場合に取るアクション（そのまま通過させる

・IPv6拡張ヘッダの統一フォーマット

ています。
そのためのVersion 2のたたき台についての議論です。
しdraft-ietf-6man-exthdr

かし、会場からはVersion 2の案がこれまでの議論を反映しておら/パケットを落とす）
を定めるビットを設けるべき、という意見があり、
このビット追加を反映後、WGラストコールを実施することとなりました。

ず、意味がないという指摘が挙がりました。結局、コメントを再度集め
・UDPゼロチェックサムの検討てディスカッションをし直すことになりました。
◆IETFミーティングに合わせて行われたイベント- IEPGミーティング
IEPG（Internet Engineering and Planning Group）
は、
IETF参加者に加えてRIRやISPにおける技術者などが集28 JPNIC Newsletter No.47 March 2011

■ 中国開催ということでCNNICの見学ツアーが行われました□CNNIC
http://www.cnnic.net.cn/en/index/index.htm

draft-ietf-6man-udpzero、draft-eubanks-chimento-6man
・RFC3848 IPv6デフォルトアドレス選択の更新
draft-ietf-6man-RFC3484-revise

・UDPゼロチェックサムの検討
draft-ietf-6man-udpzero、
draft-eubanks-chimento-6man
IPv6では必須となっているUDPでのチェックサムについて、IPv4と同様に、計算の省略を可能にしようという、
ここ数回議論が続いている提案です。計算しない場合に関する考察である文書（draft-

JPNIC Newsletter No.47 March 201129

インターネット・
トピックス 〜関連団体の動向〜

ietf-6man-udpzero）
は、WGラストコールを実施することになり、実がWGドラフトとして採用の方向、際の適用手法に関する提案（draft-eubanks-chimento-6man）
が議初に通信できたセッションを利用する、といった解が提案されています。

は実際にこの仕組みを使い、IPv6の接続性が良い相手からのみ、

SCTPでの実装例や、
アプリケーションとの関連に関するコメントが出され

IPv6接続を利用可能とするような制御を実施しています。DNSの名論となりました。適用を特定の場合のみに限定することについてはお・Teredoループ攻撃の緩和ました。
提案名が漠然とし過ぎていてすぐに提案内容を想像できないた

前空間を分断することになり問題だ、DNS関連WGでも情報共有しおむね賛同を得ましたが、IPv6の基本文書であるRFC2460の改変

draft-gont-6man-teredo-loops

め、
もっとわかりやすいものに変更すべき、という意見もありました。

議論をしてほしい、という意見が出されました。

が必要という意見も挙がっています。後者の文書についても、
WGドラ
フトとして引き続き検討をすることに反対はありませんでした。

が適切なWGにて議論を継続、となっています。

ミーティング後に公表された投票の結果、それぞれ78.8%、
63.2%がWGドラフトとして扱うべき、ということになり、
特にHappy Eyeballs につ・RFC3484 IPv6デフォルトアドレス選択の更新□6man WG

いては、
出版ステータスの確認（InformationalかBCP（Best Current

draft-ietf-6man-RFC3484-revise

https://datatracker.ietf.org/wg/6man/

Practice）
か）が、ML上で実施されています。

投票の結果では、67.9%が、WGドラフトとして議論をすべきという意見でした。
アジェンダにはありませんでしたが、ミーティングの最 後に、
opsareaミーティングで話題に上がった、IPv4プライベートアドレ

IPv6ノードおよび通信相手が複数のアドレスを持つ場合に、通信に使うアドレスペアを選択する必要があります。
この選択方法については、
RFC3484に記載されていますが、デフォルトのルールに最新のアドレス情報（ULA; Unique Local IPv6 Unicast Addresses（RFC4193）
等）
が□第79回 IETF 6man WGのアジェンダ

・IPv6カスタマーエッジルータの高度要求仕様

ス（RFC1918）の拡張に関する議論がありました（draft-weil-

http://www.ietf.org/proceedings/79/agenda/6man.html

draft-wbeebee-v6ops-ipv6-cpe-router-bis

shared-transition-space-request）。
こちらは、ISP共有アドレス空◆v6ops WG（IPv6 Operations WG）

記載されていない問題等があるため、
RFC3484を改版しようという提案

v6opsは、IPv6に関するオペレーション技術および共存・移行技です。
本提案には、
アドレスペアを選択する際の優先度に関して、ULA術に関する議論を実施するWGです。今回は、11月10日
（水）
と12日

空間の優先度を引き下げるという提案が含まれていましたが、
これに対

（金）
の2コマにて議論が実施されました。

して「自分が使っているULA空間は優先すべき」等の意見があり、検討間として、2段NATの中間に使うための空間として利用したい、と・IPv6普及におけるCPEに関する考察
draft-herbst-v6ops-cpeenhancements

いうものです。
この用途として、IPv4の/10程度をリザーブしたい、という提案でしたが、賛成・反対共に多数の非常に激しい議論となりました。結果として、IETFではコンセンサスに至りませんでしたが、間もなくRFCとなる予定の、IPv6カスタマーエッジルータ基本仕様
文書（draft-ietf-v6ops-ipv6-cpe-router）
に対する、追加仕様の提案

IPv4アドレス空間のIANA在庫が枯渇直前となり、このような空間を用意することは既に困難な状況になっていると思われます。

を継続することになりました。
関連して、
デフォルトルールをDHCPv6で配

IPv6の導入加速の世相を反映してか、今回も数多くの新提案が布し、変更できるようにするという提案（draft-fujisaki-6man-addr-select-

ありました。チェアの方でも、議論時間を極力短縮するため、おのお書として検討しています。
また今回は同時に、
スマートメーター等で利

opt）
について、
WGドラフトとして扱うことに対するコンセンサス確認が実のの発表では合意の確認を実施せず、
インターネット上に用意した用される省電力無線デバイス（IEEE802.15.4（Zigbee）
等を利用した施され、WGドラフトとして議論することになりました。

サイトにて、賛同、不賛同を後ほど入力するような形式を取ることにデバイス）と家庭用ルータの接続に関する提案も実施されています。

・NATを用いないIPv6マルチホーミング方式

する、という周知が事前にありました。

CPE追加仕様については、
6rd、
DS-liteといった移行プロトコルの記

draft-troan-multihoming-without-nat66

・P2Pリンク上におけるIPv6プリフィクス長 /127の利用
draft-ietf-6man-prefixlen-p2p
前回WGドラフトとなった、ルータ間のリンクに付与するアドレスとして、127ビットのプリフィクスを用いることを可能としよう、
という提

ここでも、
いくつかのトピックについて、簡単に紹介します。
・Happy Eyeballs: デュアルスタックホストにおいて通信を成功させるために
draft-wing-v6ops-happy-eyeballs-ipv6

案についての議論です。
この文書中に挙げられている問題の一部を考慮するか）、ULAの利用方法などについて言及され、後者ではについて、ステータスレポートが実施されました。
こちらについては、IEEE802.15.4の接続方法、
ULAでの通信の必要性等が例として挙76%がWGドラフトとして議論をすべきという結果になっています。

げられました。
議論としては、マルチキャストDNSの利用の是非、
まずはトポロジーは単一ルータ環境に限定すべきである、といった点が挙げられています。
今後、継続して議論していくこととなりました。

・複雑な環境でのTCPセッションの開始出されました。
ミーティング後に、WGラストコールを実施し、より広い

draft-baker-v6ops-session-start-time

意見を集めることになりました（2010年12月6日までの期限でラスト

今回の議論で、
上記以外に、

投票の結果では、前者は65.2%、
後者は36.8%が、WGドラフトとして議論をすべきという意見でした。

IPv6/IPv4デュアルスタック環境では、通信相手がIPv4/IPv6両方のアドレスを持っている場合、ノードは、最初に選んだ通信プロトコルでの・IPv6 AAAA DNSホワイトリスティングの影響

通信に支障が発生した場合に、もう一方の通信プロトコルに切り替える

draft-livingood-dns-whitelisting-implicationsという、いわゆるフォールバック、と呼ばれる動作をすることが一般的で・重複アドレス選択プロキシ
draft-costa-6man-dad-proxy

す。
昨今の多くのデュアルスタック実装では、
IPv6がIPv4よりも優先され□v6ops WG
http://datatracker.ietf.org/wg/v6ops/charter/□第79回 IETF v6ops WGのアジェンダ
http://www.ietf.org/proceedings/79/agenda/v6ops.html◆softwire WG（Softwires WG）
softwire WGは、トンネルを用いたIPv4 over IPv6、またはIPv6
over IPv4通信の実現方式を検討するWGです。
昨今、さまざまなISP

キャッシュサーバからのクエリパケットのアドレスに基づき、DNS権で導入が検討されている、
DS-lite（Dual Stack Lite）
や6rd（IPv6

るため、
IPv6通信に支障があった場合にIPv4で再度試す、という動作

威サーバにて、
AAAAレコードを応答するかどうかを制御する、
DNS

Rapid Deployment）
といった、新しいIPv4とIPv6の共存環境を構築をしますが、
この切り替えに時間がかかり、ユーザーの利便性が損なわ

ホワイトリスティングに関する提案です。上記Happy Eyeballsのドラする方式も併せて検討されています。
今回は、開始早々の月曜朝一のコマにも関わらず、100名を超える参加者を集めて開催されました。

・IPv6フローラベル仕様の更新れる、という問題が発生しています。
このようにデュアルスタック環境で発フトにも関連しますが、この仕組みにより、クライアント（正確には、クラ

draft-carpenter-6man-flow-update、

生する問題を、ユーザーの観点からいかに解決するかについて提案がイアントの利用するキャッシュサーバ）のIPv6アドレスごとに、
自サイト

draft-carpenter-flow-ecmp

あり、議論が行われました。
複数のTCPセッションを同時にスタートし、最にIPv6を利用してアクセスするかどうかを制御できます。Googleで30 JPNIC Newsletter No.47 March 2011

その他、前回のレポートでご紹介した、述追加、家庭でのCPEのトポロジーに関する考察（多段ルータ環境

は、より広い範囲でも検討する必要があるのでは、といった意見がコールが実施されていました）。

です。従来、
基本仕様と同時に議論されていたものを、分離して別文

10件以上の新規提案があるなど議論アイテムも非常に多く、
新規

JPNIC Newsletter No.47 March 201131

インターネット・
トピックス 〜関連団体の動向〜

アイテムの提案については、「 技術の説明で1スライド、問題点や必http://tools.ietf.org/agenda/79/

要性等で1スライド程度で説明することを話者に連絡済み」「なるべ
く時間を短く」とチェアより念押しがありました。
このためか、
ほとんど（NTT情報流通プラットフォーム研究所 藤崎智宏）の新規アイテムで議論も質問もありませんでした。
この後、チェアからDS-liteのステータスに関する説明がありました。
DS-liteは、本体プロトコルと、必要なパラメータをDHCPで配布する■ DNS関連WG報告

DHCPオプション定義の二つの文書に分けられ、それぞれ個別に標準化が進められています。本体となるDS-lite（draft-ietf-softwiredual-stack-lite）
ですが、AD（Area Director）のレビューは終了し、そのコメント対応中となっています。
DHCPオプションのドラフト（draft-ietfsoftwire-ds-lite-tunnel-option）
では、
IESGレビューでコメントが付き、時に問い合わせる手法を提案した、draft-kitamura-ipv6-simple-

Requirementsに関するドラフトがIETF Last Callを通過した

Projectに関する発表がありました。
この発表はdnsop WGでも行

ため、次にそのプロトコルに関して定義しようというものです。具

われたため、以下のdnsop WG報告にて説明します。

体的には、draft-kong-dns-conf-auto-sync、draft-dickinson-◆dnsop WG（Domain Name System Operations WG）

す。主にNETCONFの枠組みを利用して、DNSサーバの設定やdnsop WGの会合では、
まずWG draftの確認がありました。
draftietf-dnsop-name-server-management-reqsがIETF Last Callを通

本稿では、DNSに関連した内容を議論するワーキンググ
ループ（WG）で議論された概要をご紹介します。
◆dnsext WG（DNS Extensions WG）

制御を行うという提案です。会場での活発な議論が行われ、引き続きMLで議論を行うことが確認されました。

報告されました。
また、
draft-ietf-dnsop-default-local-zones、
draft-ietf-（JPNIC DNS運用健全化タスクフォースメンバー／

dnsop-as112-ops、draft-ietf-dnsop-as112-under-attack-help-helpの東京大学 情報基盤センター 関谷勇司）

三つのdraftは、
早めにAD（Area Director）
レビューに回すことが確

dnsext WGでは、会合のまず初めに、dnsext WGのメーリン認されました。
また、
draft-ietf-dnsop-resolver-primingならびにdraft-

全に限定されたドメイン名）とIPアドレスの両方ではなく、どちらか片方グリスト（ML）が、今までのnamedroppers@ops.ietf.orgから

ietf-dnsop-respsizeはExpireしているのですが、著者が更新に向けのみ指定することが議論され、その結果、最終的にはFQDNのみを指dnsext@ietf.orgへと変更になるとアナウンスがありました。現在て作業をしているとの報告がありました。

定するよう変更することになりました。
こちらはドラフト修正後、WGラスト

登録されている人はそのまま新しいMLに引き継がれます。
次に、DNSSEC History Projectに関する発表がありまし今回の会合での主な議題は、draft-yao-dnsext-identical-

dnsop-nameserver-controlといったドラフトが提案されていま過したため、
Informational RFCとして発行される予定であることがトンネル終点の指定に、
FQDN（Fully Qualified Domain Name; 完

コール、
IESGにレビューを再依頼の予定となっています。

トコルを定めようという試みです。Nameserver Management

dns-queryに関する発表がありました。最後に、DNSSEC History※ 参考：第78回IETF報告 [第2弾] DNS関連WG報告
http://www.nic.ad.jp/ja/mailmagazine/backnumber/2010/vol774.html■ セキュリティ関連WG報告た。
これはDNSSECが実運用段階に入ったこと、
ならびにDNSSEC

resolutionとdraft-vixie-dnsext-resimproveでした。
どちらもWG

提案から20周年であることを記念して、DNSSEC標準化と実運用

IETFにはセキュリティ関連WGが14存在しており、今回は11WG

draftではありませんが、前者はIETF77から話題になっている、までの記録を残すというプロジェクトです。https://wiki.tools.isoc.

による13のセッションに加えて、BoFが二つ（KIDNS（Keys in the・今回のIETFよりWG化されたPCP（Port Control Protocol）WG

Zone Aliasing ※に関するドラフトです。後者は、上位ゾーンと下位

org/DNSSEC_History_Project に情報が集められています。

DNS）
とSCAP
（Security Content Automation Protocol）
）
で、

より、
PCPのプロトコルトランスポートとしてIPv6とIPv4のどちらを利ゾーンのNSセットが同期していない場合の、リゾルバサーバの挙動

用すべきか、という問いかけがありました。
特にDS-liteでの利用のに関する改善を提案しています。

その他、
以下のようなポイントが議論されています。

場合を想定しているとのことです。
チェアからの双方ともに得失が合計15のセッションが開催されました。
他には、draft-ietf-dnsop-dnssec-key-timingに関する報告がありました。現状では、Algorithm RolloverやCSK Rollover

セキュリティ関連のWGに関するこれらのミーティングは、領

前者のdraft-yao-dnsext-identical-resolutionは、Zoneといった項目に関して述べていないが、これらを盛り込んでから域および範囲が広いため、すべてのミーティング内容を把握する

A l i a s i n gに関しての目的と提 案されている方 式 、問 題 点をま

WG Last Callを行うべきか、
これらの追加の項目に関しては別ドことが困難な状況です。そこで本稿では、会期中に議論されたセ・draft-ietf-softwire-dslite-radius-ext

とめたドラフトです。Zone Aliasingの方式として、BNAMEとラフトとして発行すべきか、という議論がなされました。結論としてキュリティ関連セッションの中から、認証やセキュア通信に特化しdraft-guo-softwire-6rd-radius-attrib

CNAME+DNAMEという二つの提案が出ていましたが、IETF78

は、別ドラフトとして執筆し、現状のドラフトはWG LastCallに向けた内容を議論する二つのWGの動向について報告します。

の後、特に進展はありませんでした。
そのため、期限を区切って本ドて更新を行うことが確認されました。

softwireのチャーター内のアイテムとして6rdやDS-liteのradius属

ラフトを更新することが提案され、Suzanne Woolf氏を中心としてあるとの説明通り、その後の議論でも意見が分かれました。

性定義の提案がありました。
それぞれ、
WGドラフトとして議論していく作業が行われることとなりました。

ことになっています。ISPでこれらのプロトコルを使用するには必須な部分であり、
実導入に向けて検討が進んでいることがうかがえます。
□softwire WG
http://datatracker.ietf.org/wg/softwire/charter/□第79回 IETF softwire WGのアジェンダ
http://www.ietf.org/proceedings/79/agenda/softwire.txt◆IPSECME WG（IP Security Maintenance and Extensions WG）

WG draft以外では、draft-livingood-dns-whitelisting-

IPSEC WGの後継として、2005年に同WGがクローズした後、implicationsに関する発表がありました。
これは、DNSクエリの送必要になった拡張や既存ドキュメントの明確化などの議論を行うた

後 者のd r a f t - v i x i e - d n s e x t - r e s i m p r o v eに関しては、N S

信元IPアドレスによって、応答にAAAAを返すかどうかを決定する

めのWGです。今回このミーティングは、2010年11月10日の午後1

R RのT T Lに応じて、ゾーンの委 譲を再 検 証し、検 証においてという仕組みです。
これによって、IPv6接続性が無い組織のDNS

時から2時間程度開催されました。参加者は、40名程度でした。

NXDOMAINが返ってきた場合には、そのゾーンに関してそれ以サーバからDNS問い合わせが来た場合に、不要なAAAAを返さ降の検索を止める、という提案です。
リゾルバDNSサーバの挙動をないことによって、IPv6接続タイムアウトの発生を回避することがで

IPSECME WGにおいて、前回のマーストリヒトでのIETFか変えるものであるため、いくつか否定的な意見が出ました。発表のきるという提案です。
これに関しては、
いくつかの質問とコメントが出

ら今回までにR F Cとして発 行されたドキュメントや、R F Cとして後、WG draftにするかの挙手による意思確認が行われましたが、されましたが、dnsop WGとしては好ましくない手法であるとの意見発行される直前のドキュメントを示します。

ほとんど手は上がらず、議論はMLに引き継がれました。

が大勢を占めました。
＜RFCとして発行されたドキュメント＞

IETFミーティングのすべての資料、Jabberログ、
オーディオ録音
等は、次のページより参照可能です。

32 JPNIC Newsletter No.47 March 2011

その他には、DNSのリソースレコードとしてURI RRを追加する提最後に、Name Server Control Protocolに関する議論が案である、draft-faltstrom-uriや、AAAAレコードとAレコードを同行われました。
これは、DNSサーバを制御するための共通のプロ

・RFC5996 Internet Key Exchange Protocol Version 2（IKEv2）

JPNIC Newsletter No.47 March 201133

インターネット・
トピックス 〜関連団体の動向〜

IKEv2について記述するドキュメントです。
このI-D（Internet-

Security Document Roadmap）は廃止されます。

D r a f t ）が R F C 化されたことで、以 前 発 行されたR F C 4 3 0 6（Internet Key Exchange（ IKEv2） Protocol）とRFC4718

http://www.ietf.org/dyn/wg/charter/ipsecme-charter.html
また、今回議論された検討項目は、以下の通りです。
□第79回IETF IPSECME WGのアジェンダ（IKEv2 Clarifications and Implementation Guidelines）
を廃
止（Obsoletes）
しました。
なお、
このRFCは、
インターネット標準化過程（Standards Track）
として発行されました。

□IPSECME WG

・A Quick Crash Detection Method for IKE

http://www.ietf.org/proceedings/79/agenda/ipsecme.txt

・Deprecate DES support for Kerberos（draft-lha-des-die-die-die）
きたい

危 殆化した暗号アルゴリズムであるDESに関してKerberosでのサポート停止をアナウンスするためのDraftです。
このドキュメントのステータスとしては、WG Last Callは完了しており、著者によるdraft-ietf-ipsecme-failure-detection-02

IESGへの対応待ちの状況です。
この仕様は、暗号の危殆化（暗URL:http://tools.ietf.org/html/rfc5996

号の世代交代）の観点から重要なものであると考えられています。

・Protocol Support for High Availability of IKEv2/IPsec
draft-ietf-ipsecme-ipsecha-protocol-02

・RFC5998 An Extension for EAP-Only Authentication in IKEv2

・Kerberos Options for DHCPv6（draft-sakane-dhc-dhcpv6-kdc-option）

このミーティングでは、主に“A Quick Crash Detection
IKEv2において、拡張可能な応答者認証を提供するための相互認証（mutual authentication）
や鍵合意（key agreement）
を提Method for IKE”と“Protocol Support for High Availability
Dynamic Host Configuration Protocol for IPv6
（DHCPv6）
において、of IKEv2/IPsec”
に関する議論に時間を費やしました。

供するEAP（Extensible Authentication Protocol）
を仕様化する
ドキュメントです。
なお、
このRFCは、Standards Trackのドキュメン
トとして発行され、RFC5996を更新（Updates）
しています。

Kerberosプロトコルに関係する設定情報を利用するために、四つのオプションを定義する仕様です。
このドキュメントのステータスは、修正版の投

上 記 以 外のトピックとして、以 下の三つの話 題が会 議で取り上げられ議論されました。
この中から二つに注目して、議論内容のポイントを報告します。

URL:http://tools.ietf.org/html/rfc5998
・IKEv2 Re-authentication■ 今回のIETFには中国国内から多くの技術者が参加しました◆KRB WG（Kerberos WG）
KRB WGは、マサチューセッツ工科大学（MIT）が考案した、・RFC6027 IPsec Cluster Problem Statement
IKEv2bisとして議論され、RFC5996として発行された仕様にお稿待ちでしたが、ミーティング中に、著者から更新版が投稿されました。
＜技術的な議論＞・KerberosにおけるCamelliaに関する議論

認証方式の一つであるKerberosプロトコルに関する新規仕様やクラスタ上でのIKEやIPsecを実装するための要求条件や問題

いて、Re-authenticationにいくつかの問題が存在しているという機能拡張について、検討を行うWGです。
このミーティングは、最終

現在、KRB WGのスコープに暗号アルゴリズムの追加は含まれの提示、および専門用語について定義しているドキュメントです。
ま指摘がありました。
それらの問題に対して、いくつかの解決策はある日である2010年11月12日の午後1時から2時間半程度開催されまていないため、WGとして議論するトピックとしてコンセンサスを取る

た、異なるクラスタ間の相互運用を可能にするピアを許可するためが、現在思いつくような解決策ではなく、異なる方法による解決が必した。
なお、参加者は、20名程度でした。

ための議題でした。議論の概要としては、技術的な議論が主な目の、仕様と実装のギャップも記述しています。
なお、
このRFCは、情報要であるという議論になりました。今後のIPSECMEでの議論に注目（Informational）に分類されるドキュメントとして発行されました。

する必要があると考えます。

ミーティングの構成として、以下のような議題で進行されました。

URL:http://tools.ietf.org/html/rfc6027

・IKEv2--（IKEv2“minus minus”）

・ドキュメントステータスおよび議論的だったため、Camellia-CCMを利用した際のKerberosに対する影響などについて活発な議論が行われました。
議論を行う際に、KRB WGのチェアから送られたメールを参照しました。
そのメールの詳細については、以下のURLをご覧ください。

＜RFCとして発行される直前のドキュメント＞「デバイスによる高い制約を受ける状況などでIKEv2を実装す・技術的な議論る人などに向けて、最小構成のIKEv2を規定する必要はあるの- KerberosにおけるCamelliaに関する議論

・IP Security（IPsec）and Internet Key Exchange（ IKE）

ではないか？」という議論が行われました。IKEv2という仕様は複- IANAに関する議論

Document Roadmap（draft-ietf-ipsecme-roadmap-10）

雑であり比較的大きなものなので、IKEv2を利用するIPSECME- PAC（Privilege Attribute Certificate）
に関する議論どが複雑化しており、そのドキュメントの背景や要約を記述することます。
この議論の結果としては、最小実装として満たさなければな・Mesh wireless network through Kerberosに関する提案

らない仕様は、RFC5996で規定されている仕様となりました。

（draft-moustafa-krb-wg-mesh-nw）

・IKEv2 with CGA（CGA: Cryptographically Generated Addresses［RFC3972］）

このミーティングについて、ドキュメントステータス、
技術的な議論および今回の3提案の中から、いくつかのトピックスに関して報告します。

る状態（RFC Ed Queue）
です。本I-Dは、Informationalのドキュメントとして発行される予定です。

なお、IPSECME WGの詳細情報および今回のアジェンダについては、次のURLをご参照ください。

このI - DがR F C 化されると、以 前 発 行されたR F C 2 4 1 1（ I P

34 JPNIC Newsletter No.47 March 2011

□KRB WG
http://www.ietf.org/dyn/wg/charter/krb-wg-charter.html

でそれらの関係を整理することを目的としたドキュメントです。
なお、
I-Dのステータスは、RFC Editorの 編集待ちリストに掲載されていなお、KRB WGの詳細情報および今回のアジェンダについては、以下のURLをご参照ください。

WG以外の人に対して、最小構成仕様の必要性は高いと考えられ
IPsecやIKEに関係するRFCが多く発行され、それぞれの関係な

https://lists.anl.gov/pipermail/ietf-krb-wg/2010-November/008770.html□第79回IETF KRB WGのアジェンダ
http://www.ietf.org/proceedings/79/agenda/krb-wg.txt＜ドキュメントステータスおよび議論＞（NTTソフトウェア株式会社 菅野哲）

JPNIC Newsletter No.47 March 201135

インターネット・
トピックス 〜関連団体の動向〜

インターネット・
トピックス 〜関連団体の動向〜■ICANN関連トピックス

申し立て後30日以内に、レジストリは申し立てに対する答弁書を紛争処理機関に提出します。紛争処理機関は申し立て者に対し、答ICANNが検討しているコミュニティベース新gTLD向けの紛争解決手続き
レジストリ制限事項に関する紛争解決手続き（Registry Restriction Dispute Resolution Procedure; RRDRP）について弁書を送付します。紛争処理機関が答弁書を受領してから10日以
内に、レジストリは紛争処理機関に対し申請費用を支払います。
紛争処理機関は、1名の専門家パネルを、答弁書受領より21日以内に選定および指名します。申し立て者もしくはレジストリから◆本稿執筆の背景

RRDRPは、新gTLD申請者ガイドブック案（本稿執筆時は第4の要望があったときは、3名パネルとなることもあります。その後、紛RRDRP（レジストリ制限事項に関する紛争解決手続き）に版）がICANN理事会により正式に承認された段階で確定するこ争処理機関は手続きに要する費用を見積もった上で、申し立て

ついては、ICANN報告会などにおいても、今まで明示には取とになります。RRDRPでは他のDRPと同様、独立した外部の専門者およびレジストリの両方に費用の全額を請求します。
これら費り上げてきませんでした。というのもこの仕組みが「コミュニ家に紛争処理の判断を任せることが想定されます。その理由は、用については、紛争に勝った方が支払った分については後で返

ティベースgTLD」を対象としたもので、影響の範囲も比較的ICANNが登録者レベルでのドメイン名の内容について判断する

却されます。迅速に紛争処理を行うため、および費用を抑えるた

限定的されていると考えられたためです。しかしながら、取りことは、“ 技術的なことの委任”を受けるという、ICANNの使命を逸め、申し立て書および答弁書の内容に基づいた書類による審理

上げずにいれば、今後も本手続きに関する情報が十分提供さ脱するためとされています。※3のみで、通常は証拠開示や聴聞は行われません。

れないままとなってしまうため、今回、テーマとして取り上げる
こととしました。

◆RRDRPの想定例
RRDRPの想定利用例として、次のようなものが考えられます。

◆RRDRPとは

RRDRPを定めた文書において、裁定の期限については、裁定書が専門家パネルの指名から45日以内に提出されるよう努力する※7
2009年10月2日には、申請者ガイドブック案第3版（DAGv3）が発行され、その中の「Module 5: 委任への移行」という項目には、レジストリ契約書案※8およびRRDRP手続き文書案※9が付属しました。
2010年2月15日にはICANNが手続き文書案を公開し、4月1日まで意見募集を行った後、コメントのまとめと分析※10が5月31日に公開されました。

ICANNナイロビ会議会期中の2010年3月12日には、ICANN
理事会にて、RRDRP最終案を申請者ガイドブック案第4版
これを（DAGv4）で公開するよう求めた決議※11がなされました。
受け、2010年5月31日にはRRDRP最終案を含める形で、DAGv4※
12が発行されました。
DAGv4に含まれるRRDRP最終案※3は、2月15日から4月1日までの間に寄せられたコメントを受けて変更されていますが、変更はそれほど大規模なものではありません。

こと、および正当な理由なしに60日を越えないようにすることとなっ次のgTLD募集ラウンドで募集されることになる、いわゆる新ペット（ 動 物 ）愛 好 家 団 体 が . p e tというg T L Dを申請し、ドています。
また、専門家パネルはレジストリに対して、当該gTLDで

gTLDの申請受け付け開始が、スケジュールは確定していない

メイン名 の 登 録 要 件にペット愛 好 家 団 体であることを定 めての新規ドメイン名登録の停止、
レジストリ契約への改善措置の追ものの、近づいてきていると見られています。

ICANNの審査・評価を通過しサービスを開始した後、ペットボ

加、
レジストリ契約の終了などを勧告することができます。

トル製 造 業 界 団 体がb o t t l e . p e tというドメイン名を申請して登RRDRPとは、新gTLDのうちコミュニティベースgTLDを対象

録が認められた場合に、正しく要件を満たして申請・登録していとしたサービス開始後の紛争解決メカニズムです。コミュニティ

る、その他のペット（動物）愛好家団体が不服を申し立てるケー

ベースg T L Dとは、特 定のコミュニティにおいて利用されることス等です。

を前提とするgTLDのことで、既存のTLD では、.museum、.
aero、.proなどのスポンサ＜次回持ち越しとなった提案＞
がRRDRP導入の背景と詳細について記載された、単独の説明文書※6を公開しました。

※1※2付きgTLD（sTLD） が、これに類似したものと言えます。

◆RRDRPにおける手続きの流れ※1 スポンサ組織
トップレベルドメイン（TLD）の登録・運用ポリシーを策定する組織。

◆まとめ
コミュニティベースgTLDは、
gTLDの文字列がコミュニティのアイ
デンティティを示すことから、そのドメイン名をインターネット上で利用する登録者が、そのコミュニティを構成する者としての要件を満たしていることが担保されることは重要です。

当該TLDレジストリへのTLD委任開始後、個人もしくは組織が申し立てを行います。ICANNは紛争の当事者になれないの

既にサービスが開始されているsTLDでも、いくつか類似の紛で、ICANN自身による申し立てはできません。申し立ての際には、争解決手続きが用意されていますが、今回新たなgTLD募集ラ

てプロセスにおいて、「申請者の要件合致についての判断に関WHOISの苦情申し立てフォームに類似したオンラインフォームがウンドの施行にあたり、統一した手続きがRRDRPとしてまとめらする事後紛争解決手段が必要」という考えに基づき導入される用意されるので、それを利用します。
申し立てにあたって利用する

れ実装されることは、
コミュニティベースgTLDの価値を高める観ものです。

言語は英語となり、RRDRP紛争処理機関（以下、紛争処理機関）

点で、意義深いものだと考えられます。

RRDRPは、コミュニティベースgTLDにおけるドメイン名割り当とのやり取りはメールなどにより電子的に行います。申し立て時にコミュニティベースgTLDは、
誰でも自由に登録できる通常のgTLDとは違い、レジストリ制限事項（Registry Restriction）と呼ばれる、レ

は、紛争処理機関が定める登録費用を申し立てから10日以内に、紛争処理機関に対して支払う必要があります。

ジストリによってドメイン名登録希望者に要求される、登録要件などの制限事項が存在します。
コミュニティベースgTLDのレジストリがサー申し立て後5営業日以内に、裁定を行う主体である紛争処理

ビスを開始した後に、この制限事項が適切に遵守されていない場合機関が指名するパネリストにより事前審査が行われた後、紛争処に、RRDRPを利用して登録者などから異議申し立てを行うことが可理機関からレジストリに対して申し立てがあったことと、申し立て

能となります。

内容について通知されます。

36 JPNIC Newsletter No.47 March 2011（JPNIC インターネット推進部 山崎信）

［参考］導入検討の経緯
2009年2月18日に発行された（新gTLD）
申請者ガイドブック案
同日付公開のレジストリ契約書案※5では、第2版（DAGv2）※4と、
RRDRPという名称こそ使われませんでしたが、初めて「コミュニ
ティベースTLD運営者の義務」という条項が追加され、登録ポリシー遵守についての紛争解決手段の制定も、レジストリが守るべ
き義務の一つとなっています。
続いて2009年5月30日には、
ICANN※2 JsTLD（sponsored Top-Level Domain; スポンサ付きトップレベルドメイン）
特定の業界・分野内に運用が制限されたTLDで、当該業界を代表する組織がスポンサ組織として登録ポリシー等を決定します。
※3 REGISTRY RESTRICTIONS DISPUTE RESOLUTION PROCEDURE（RRDRP）REVISED - MAY 2010
http://www.icann.org/en/topics/new-gtlds/rrdrp-clean-28may10-en.pdf※4 New gTLD Draft Applicant Guidebook（DAGv2）
http://www.icann.org/en/topics/new-gtlds/draft-rfp-clean-18feb09※5 New gTLD Agreement Proposed Draft（v2）
http://www.icann.org/en/topics/new-gtlds/draft-agreement-clean-18feb09-en.pdf※6 Proposed ICANN Registry Restrictions Dispute Resolution Procedure（RRDRP）
http://www.icann.org/en/topics/new-gtlds/rrdrp-30may09-en.pdf※7 Draft Applicant Guidebook, version 3（DAGv3）
http://www.icann.org/en/topics/new-gtlds/draft-rfp-clean-04oct09-en.pdf※8 New gTLD Agreement Proposed Draft（v.3）
http://www.icann.org/en/topics/new-gtlds/draft-agreement-specs-clean-04oct09-en.pdf※9 REGISTRY RESTRICTIONS DISPUTE RESOLUTION PROCEDURE（RRDRP）
http://www.icann.org/en/topics/new-gtlds/draft-rrdrp-04oct09-en.pdf※10 NEW gTLD DRAFT APPLICANT GUIDEBOOK VERSION 3 PUBLIC COMMENTS SUMMARY AND ANALYSIS
http://www.icann.org/en/topics/new-gtlds/summary-analysis-agv3-15feb10-en.pdf※11 Adopted Board Resolutions | Nairobi - 12 March 2010
http://www.icann.org/en/minutes/resolutions-12mar10-en.htm#8※12 Draft Applicant Guidebook, version 4（DAGv4）
http://www.icann.org/en/topics/new-gtlds/draft-rfp-clean-28may10-en.pdf

JPNIC Newsletter No.47 March 201137