NTT情報流通プラットフォーム研究所 藤崎 智宏／松本存史
1. 第68回IETF概要
2007年3月18日（日）から23日（金）までチェコ共和国プラハにて第68回IETFが開催された。今回は世界45カ国から1,129名が集まったとのことである。前回の米国サンディエゴで開催された第67回IETFは36カ国、1,264名の参加があった。人数的には減少している一方で、参加国数は増加している。図1に参加者の変遷を示す。また、参加者の国別割合（図2）については、米国外での開催ということもあり、米国の参加者割合が減っていることがわかる（前回は、米国の参加者が過半数を占めていた）。
２．v6ops WG（IPv6 Operations Working Group）の動向
v6opsワーキンググループ（WG）では、IPv6/IPv4の共存時における運用や、セキュリティに関する話題を主に扱っている。今回のIETFでは、当初、v6ops WGは2コマ時間を確保していたが、最終的にはミーティング本番初日である、3月19日（月）の朝一番のコマ（9:00～11:30）のみが実施された。参加者は150名程度であり、かなり盛況であった。
IETFでの標準化に関する議論は、WG単位で実施されている。各WGは、技術分野ごとに、特定のエリアに属している。各エリアには、担当のエリアディレクタがおり、エリアに属するWGの議論の方向性に関する調整、WG間、およびエリア間の調整を実施している。現在、Applications、Geenral、Internet、Operations and Management、Real-time Applications and Infrastructure、Routing、Security、Transportの8エリアが存在する（エリア、およびエリアに属するWGの一覧は＜http://www.ietf.org/html.charters/wg-dir.html＞に掲載されている）。
v6opsのミーティングのはじめに、v6ops WGの属するOperations and Managementエリアのエリアディレクタが変わったことが紹介された。今までは、インターネットレジストリの一つであるRIPE-NCC IPv6 WGのチェアである、David Kessens氏が ADをつとめていたが、今回からccamp WGやl3vpn WGのチェアをつとめていたJuniper NetworksのRonald Bonica氏に替っている。
今回のミーティングでは、前回のミーティング後にWGラストコール（WGLC）（※注1）がかかったWGドラフトの状況確認、それ以外のWGアイテムに関する議論、および、IPv6ファイアウォール等の運用紹介が実施された。
チェアのFred Baker氏による議題確認の後、WGLCがかかった以下のドラフトに関して、それぞれの著者より状況の報告が実施された。
- IPv6におけるポートスキャン
（draft-ietf-v6ops-scanning-implications） - IPv6ユニキャストアドレス割り当て
（draft-ietf-v6ops-addcon） - 802.16ネットワーク（WiMAX等）におけるIPv6デプロイメントシナリオ
（draft-ietf-v6ops-802-16-deployment-scenarios） - キャンパスネットワークにおけるIPv6移行シナリオ
（draft-ietf-v6ops-campus-transition）
「IPv6におけるポートスキャン」「802.16ネットワーク（WiMAX等）におけるIPv6デプロイメントシナリオ」に関しては、著者より現状の方向はあったが、メーリングリスト（ML）においても、また会場においてもコメントや意見が少なく、標準化を進めていくことに対しての懸念も表明されたが、そのコメントを反映して改版したドラフトに対して、再度WGLCをかけることとなった。
「IPv6ユニキャストアドレス割り当て」のドラフトに対しては、ML上でも割り当てアドレスサイズに関する議論等があり、また、ミーティング時にも、IPv6 プロバイダ非依存アドレス（PIアドレス）についての記述を追加すべき、アドレスプレフィックス /126 を利用することはRFC違反であることを明記すべき、RFC3306 で定義されているUnicast-Prefix-based IPv6 Multicastアドレスの使用法について記述すべき、などの意見が出された。本ドキュメントについても、コメント反映後、WGLCをかけることとなったを実施することとなっている。
「キャンパスネットワークにおけるIPv6移行シナリオ」に関しては、MLでのコメントが少ないこと、また、有用であるがIETFのRFCとして記述すべきものかどうか、という意見が表明され、今後の方向性についてMLで議論することとなった。
それ以外のWGアイテムに関する議論では、最近JANOGのMLでも話題になった、ルーティングフィルタ記述のガイドライン（draft-ietf-v6ops-routing-guidelines）、および、IPv6における複数アドレス選択の問題提起（draft-ietf-v6ops-addr-select-ps）と解決案の要求仕様（draft-ietf-v6ops-addr-select-req） に関する議論が実施された。
「ルーティングフィルタのガイドライン」に関する議論では、“ルーティングフィルタ”と題しているものの、IPv6の特殊用途アドレスの記述が主であり、フィルタの例に関しても、ガイドラインと言うには情報が少なすぎる、このようなフィルタの例示は、インターネットレジストリやオペレーションコミュニティで実施すべきであり、既にIPv6に関するフィルタの記述例が存在する、フィルタについての情報は変更が多く、将来にわたってメンテナンスが必要であるためRFCに適さない、といった意見が出された。結論として、IPv4では既にRFC3330（Special-Use IPv4 Addresses）として出版されている、特殊用途アドレス記述についてのIPv6版を作成する方向に変更することになった。
「IPv6における複数アドレス選択」に関する議論では、MLでの意見を要求条件ドラフトに反映したことの報告、および、アドレス選択についての解に関する議論が実施された。問題提起ドラフトについては、WGLCをかけることになり、また、アドレス選択の解法については多くの意見が出され、それを反映したドラフトを執筆し、次回のIETFで議論することとなった。
最後に、IPv6ファイアウォール等の運用状況についての報告があった。報告対象ネットワークは、ノード数約1,000台、ユーザ数2,000人程度のIPv6/IPv4デュアル接続の学術サイトであり、このサイトにおける、ファイアウォールでのフィルタリング状況、IDSの運用状況などが報告された。IPv4と同等のフィルタをIPv6でも実施していること、ファイアウォールのログ出力は、IPv4に比べてかなり少ないが、公開IPv6サーバへの probe パケット等が確認されたこと、特定のサービスポートに対する攻撃や、不正フォーマットのIPv6パケットが観測されたことなどが言及され、IPv6に対応した攻撃ツール等もそろってきているように思われること、対策ツール群はそろい始めているが、IPv4の焼き直しであり、IPv6に特化した攻撃への対処はできないことといった問題が提起された。
□第68回 IETF v6ops WG のアジェンダ
http://www3.ietf.org/proceedings/07mar/agenda/v6ops.txt
3. shim6 （Site Multihoming by IPv6 Intermediation） WG の動向
shim6 WGについては、今回、オンサイトのミーティングは開催されていないが、メーリングリストにて、エンドサイトに手を入れないで shim プロトコルを実現する shim6 proxy について議論されている。また、次章で紹介するように、shim6 とは別アプローチのマルチホーム実現手法に関する議論が始まっている。
4. ROAP（Routing And Addressing Problem BOF）
IETF以外にも現在様々なところで取沙汰されている、BGPルーティングにおけるスケーラビリティ問題について検討するBOFが開かれた。現在IPv4のグローバルルーティングテーブルは20万経路にも達すると言われており、現行のルータでは処理負荷が高く対応しきれない例も出て来ている。IPv6のグローバルルーティングテーブルには現在それほど多くの経路は存在しないが、今後IPv6が普及するに従って問題が顕在化してくることは自明であり、さらにIPv6のアドレス長やアドレス空間の広さから、この問題はより深刻になると予想されている。
この問題に対する解決方針としては、大別してルーティングプロトコルを拡張する、経路集約をより積極的に行うというルーティングに基づく方針と、エンドサイトまたはエンドホストに拡張を加えることによってマルチホームを実現し、現在のBGPルーティングによって実現されるマルチホームへの依存度を軽減するというホスト/サイトベースの方針とがある。このROAP BOFでは、Routing エリアではなく Internet エリアという、IPv6などのプロトコルを策定するエリアで開かれたBOFということもあり、ルーティングベースの解決策を検討するのではなく、ID/Loc分割と呼ばれるIPアドレスの個体識別子（IDentifier）と位置識別子（LOCator）の2つの役割を分けることによってホスト／サイトベースのマルチホームを実現し、現在のルーティングベースのマルチホームによって生じている経路表の増大を防ぐことが検討された。
これまでにIETFで検討されてきたID/Loc分割に基づく方式としてはShim6やHIPがあるが、HIPはそもそもマルチホームを主目的として策定されたプロトコルではなく、またIRTFに属していることからもまだ研究の域を出ていないと言える。またShim6はルーティングスケーラビリティの問題を解決することを目的として仕様策定が行われている方式であるものの、現在多くのISPで実施されているようなトラフィックエンジニアリングが困難である、またサーバへの負荷が過剰になる等の現場からの意見もあり、普及が容易ではないと見込まれている。そこで、今回のセッションでは、普及のコストとメリットのバランスを第一に考慮し、これまで行われた議論を最初からやり直すことを目標に掲げた上で、新しいWG設立に向けたアーキテクチャ設計に関する議論が行われた。
今回のセッションでは、解決方式に求められる要求条件を列挙し、どのような方式が考えられるかというデザインスペースに関する議論、そしてこれまで検討された方式がどのようなデザインでありどの要求条件を満たしていたかについての確認が行われた。個別の解決方式についての議論は今回は行われていないが、現在 ML上で既にいくつかの新しい方式が提案されている。それらの方式を見てみると、ホストの手前にMiddleboxと呼ばれる装置を設置し、ホストに変更を加えずMiddlebox間でのやり取りによって、通信経路の冗長化やトラフィックエンジニアリングを実現する方式が多数提案されている。
例えば、LISP（Locator/ID Separation Protocol）という方式では、図3に示すように、エンドサイト内ではPIアドレスを用い、ISPがエンドサイトに対して割り当てたPA（プロバイダ集約）アドレスはエンドサイト出口に設置されたTR（Tunnel Router）のみで用いるモデルが提案されている。通信のシーケンスは、ホストが相手ホストのアドレス（PI）を知り通信を開始した後、経路中に存在するTRがDNS等のデータベースにアクセスして相手サイトのTRのアドレス（PA）を知り、トンネルを生成する。TRはパケットをカプセル化して相手サイトに送信し、相手サイトのTRがデカプセル化してホストに届ける、という具合である。以上により、エンドサイトはPIアドレスをグローバルルーティングテーブルに広告すること無く、マルチホームを実現できる。
現在もML各方式についての議論が盛んに行われている。次回のIETFミーティングは7月であるが、5月に一度中間ミーティングが開催されることが決定されている。ルーティングスケーラビリティの問題は、今後のインターネットを占う重要なトピックであり要注目である。
□第68回 IETF ROAP BOF のアジェンダ
http://www3.ietf.org/proceedings/07mar/agenda/intarea.txt
■第68回IETFミーティングの各種情報
全体プログラム
https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=68
WGアジェンダ、発表資料
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68
※1 ラストコール
IETFでは、RFC化に向けてドラフトの段階を進める際に公式にコメント募集期間を設ける。この際のコメント募集のアナウンスをラストコールと呼ぶ。WCラストコール、IESGラストコールが実施される。
