ニュースレターNo.45/2010年7月発行

第77回IETF報告　IPv6関連WG報告

2010年3月20日から26日まで、米国アナハイムにて第77回のIETFミーティングが開催されました。春先の温暖なカリフォルニア、また、景気の回復基調を反映してか、初めての参加者173名を含む1,192名の参加がありました。参加者の内訳では、米国からの参加者数が過半数を占め第1位、続いて日本、中国がほぼ同数で続いています。

本稿では、会期中に議論されたIPv6に関連したトピックスのうち、IPv6に特化した内容を議論するワーキンググループ（WG）での話題を中心に紹介します。余談ですが今回、IPv6関連のWGは、mif WGとv6ops WG、6man WGとsoftwire WG等、セッションが並列で同時に実施され、参加者も戸惑っていました。

v6ops WG（IPv6 Operations WG）

v6opsはIPv6に関するオペレーション技術や、移行技術に関する議論を実施するWGです。今回は、3月22日（月）、26日（金）の朝一番のコマにて実施されました。v6ops WGでは、IPv6とIPv4の相互変換技術に関する議論を他WG（behave WG）に移行した後、議論内容が少なくなるのかと思ったのですが、昨今のIPv4アドレス在庫枯渇、IPv6導入の流れを受けてか、継続議論のみでなく、数々の新提案もあり、内容も多岐にわたりました。特に、2010年3月上旬に、サンフランシスコにて開催された3GPPとIETFのジョイントミーティングにおいて、IETFが3GPPでのIPv6利用について、プロトコル制定の面でサポートをする方向になったことを受けてか、3GPPでのIPv6利用に関する提案、議論もいくつか実施されています。

今回、次の議論がアジェンダとして挙げられていました。

〈3月22日（月）〉

RFC5006（DNS設定のためのRAオプション）の実装と普及に関する議論
家庭向けIPv6インターネットサービス提供用CPEにおける簡易セキュリティ推奨機能
draft-ietf-v6ops-cpe-simple-security
IPトンネリングにおけるセキュリティの懸念
draft-ietf-v6ops-tunnel-security-concerns
IPv6 CPEに関する高機能セキュリティ
draft-vyncke-advanced-ipv6-security
3G拡張パケットシステムでのIPv6
draft-korhonen-v6ops-3gpp-eps
モバイルネットワークでのIPv6導入検討
draft-koodli-ipv6-in-mobile-networks
ステートレスIPv6プリフィクス委譲
draft-savolainen-stateless-pd
ISATAPと6to4における経路ループ: 問題提起と解決案
draft-nakibly-v6ops-tunnel-loops

〈3月26日（金）〉

IPv6ディプロイメントに関するサービスプロバイダシナリオ
draft-carpenter-v6ops-isp-scenarios
IPv6移行技術の利用に関するガイドライン
draft-arkko-ipv6-transition-guidelines
IPv6マルチキャストメッセージのユニキャスト転送
draft-gundavelli-v6ops-l2-unicast
近隣探索プロトコルにおける近隣キャッシュの保護
draft-jiang-v6ops-nc-protection
セルラーネットワークにおけるIPv6移行ツールとしてのDHCPv6プリフィクス委譲
draft-sarikaya-v6ops-prefix-delegation
ステートレス自動IPv6 over IPv4トンネル: 仕様
draft-matsuhira-sa46t-spec
IPv6 CPEルータ拡張推奨機能
draft-wbeebee-v6ops-ipv6-cpe-router-bis
Softwire-liteのためのステートレスアドレスマッピング（SAM）
draft-despres-softwire-sam

以下より、いくつかの内容について、簡単に紹介します。

RFC5006（DNS設定のためのRAオプション）の実装と普及に関する議論

当初、この項目はアジェンダにはありませんでしたが、v6opsメーリングリストで大きな議論を呼び、進め方についての確認を実施するために急遽追加されました。IPv6ではPC等の端末にDNSサーバのアドレスを配布する方法がかなり議論され（RFC4339に議論がまとめられています）、その結果、DHCPv6を利用した方法（RFC3646）が標準となり、一般的に利用されています。当時、ルータ広告（RA）を利用した方法も検討されましたが、“Experimental”（実験的）のステータスとして、RFC5006が出版されるにとどまっており、実装もあまりされませんでした。これに対し、RAでの配布も標準にして欲しい、という要望があがり、RFC5006を“Standard”（標準）のステータスにするかどうか再議論となりました。事前のメーリングリストでの議論で、標準とする方向で議論はほぼ固まっており、ミーティングでも、現在のスペックをほぼそのまま標準とすべきである、という意見があった程度で反対はありませんでした。ドラフトを6man WGに提出、標準化を進めていくことになりました。

IPv6ディプロイメントに関するサービスプロバイダシナリオ

世界的に、IPv6の導入は徐々に進んでおり、対応を進めているサービスプロバイダも増えてきました。このドラフトでは、実際に導入を進めているISPに導入方法、導入時に発生した問題、必要だと思う機能等のアンケートを実施し、その結果をまとめています（JANOGでも昨年末に、アンケートの案内が流れています）。ミーティングでは、「これは中間報告であり、またISPの数もそれほど多くない（ミーティング時点では30程度）ため内容には偏りがある可能性がある」という前提のもと、現状の集計結果の報告がありました。

興味深い結果としては、IPv6サービスの導入時期について、もっとも遅いISPで2013年としていること、IPv6トラフィックが50%を占めるようになる時期は、「2015年」という回答が一番多かったこと、対応が不十分だと思われる機器としてCPEの指摘が多かったこと、ほとんどのISPでIPv4/IPv6のIP層での何らかの相互通信（トランスレーション、デュアルスタック等）が必要だと考えていること等があります。結果は、
http://www.ietf.org/proceedings/10mar/slides/v6ops-0.pdf
にまとめられています。このドラフトの今後ですが、RFCとして発行することに対する反対意見はあったものの、まずは文書としての構成を見直して整理する方向となっています。

近隣探索プロトコルにおける近隣キャッシュの保護

IPv4のARPキャッシュにあたる、近隣キャッシュの保護に関する提案です。近隣要請メッセージを多数送るというDoSアタックにより、ノードの近隣キャッシュが溢れてしまうという攻撃を防ぐために、近隣要請メッセージを送ってきたノードに対して、問い合わせを実施し、返答が得られた場合に近隣キャッシュに登録するとしています。これに対し、問題点は共有されたものの、提案されている解決手法に対しては、返答要求メッセージの処理でまた同じ問題が発生すること、問題の一部の解に過ぎないこと（遠隔からの問い合わせでも同じ問題は発生する可能性があるが、それには対応できない）等の指摘がありました。提起された近隣キャッシュを保護するという問題に対して、メーリングリスト上で議論を継続することになりました。

IPv6 CPEルータ拡張推奨機能

IPv6対応のCPEルータが持つべき機能に関する提案です。WANとLANの設定、基本的なルータ機能、基本セキュリティ機能のみを基本部分として分離した基本機能ドラフトは別途RFC化に向けて進んでいます。そのドラフトから切り出した検討事項が多い部分（マルチキャスト、DNS、プリフィクスの再委譲、IPv6移行機能、パケットフィルタ、QoS等）に関して、今後の進め方に関する議論がありました。現在、別のWGとしてホームルータの機能を議論するhomegate WGが構成されようとしており（2010年4月末に中間ミーティング実施予定）、棲み分けをどうするか、が主な論点でしたが、homegate WGとは連携をするが、現状まだhomegate WGでの議論動向がはっきりしないことおよび、homegate WGでカバーされない部分に取り組む必要があることから、v6ops WGで継続的に議論をしていくことになっています。

□v6ops WG: https://datatracker.ietf.org/wg/v6ops/
□第77回 IETF v6opsのアジェンダ: http://www.ietf.org/proceedings/77/agenda/v6ops

6man WG（IPv6 Maintenance WG）

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回のミーティングは、3月24日（水）の午後の2コマ（13:00-16:10）にて開催されました。途中、2コマ目はDS-Liteや6rdを扱っているWGとして最近注目を集めているsoftwire WGと時間帯が重なってしまったため、多くの参加者が途中退出する様子も見受けられました。

まず、6man WGで取り組み中である、以下の文書のステータス確認が行われました。

経路制御ヘッダー（RFC出版準備中）
IPv6サブネットモデル（IESGレビュー中）
IPv6推奨アドレス表記（IESGレビュー中）
フラグメント重複問題（RFCとして出版）

アジェンダには下記のアイテム/テーマが掲載されていました。

ノード要求仕様の更新
draft-ietf-6man-node-req-bis
RFC5006（RAでのDNS情報配布）をStandard Trackへ
UDPゼロチェックサム
draft-fairhurst-tsvwg-6man-udpzero
IPv6フローラベルの仕様法に関して
IPv6フローラベルを用いたECMP（Equal-Cost Multi-Path）
draft-carpenter-flow-ecmp
IPv6フローラベル仕様の更新
draft-carpenter-6man-flow-update
IPv6フローラベルを用いたトランスポート層シグナリング
draft-donley-6man-flowlabel-transport-sig
DHCPv6経路情報オプション
draft-dec-dhcpv6-route-option
ユニークIPv4射影アドレス
draft-thaler-6man-unique-v4mapped
ルータ間リンクでの127ビットプリフィクス
draft-kohno-ipv6-prefixlen-p2p
アドレス選択
draft-ietf-6man-addr-select-considerations
draft-ietf-6man-addr-select-sol
データプレーンデータグラムにおいてRPL情報を伝達するためのRPLオプション
draft-hui-6man-rpl-option
近隣探索ベンダー固有オプション
draft-gundavelli-6man-ipv6-nd-vendor-spec-options
RS（ルータ要請）のマーキング
draft-krishnan-6man-rs-mark

この中で、DHCPv6経路情報オプションについては、既に行われたmif WGのセッションにおいて、mif WGで扱われることがほぼ確定したため、本セッションでの発表はありませんでした。これらのアジェンダの中から、いくつかのトピックについてご紹介します。

RFC5006（RAでのDNS情報配布）をStandard Trackへ

RFC5006で定められた、RAを用いたDNS情報配布オプションを、これまでのExperimental（実験的）のステータスから、Standard Track（標準としての提案）に変更しようというテーマについての議論が行われました。このアイテムについては、月曜日に行われたv6ops WGのセッションや、v6ops WGのメーリングリスト上で、支持者が大勢を占めるという状況になっており、標準化を進めることについての合意はほぼ形成されていましたが、6man WGが実際のプロトコル策定を行うWGということもあり、ここでも再度発表が行われました。

このセッションでは、DNS関連のオプションとしてはDomain Search Pathオプション等も存在するが、これらは必要ではないのか、という疑問に対して、Domain Searh Pathは通信のために必須ではないが、DNSサーバアドレス情報は通信のために必須であるから、RAに含めるべきだ、といった意見が出されました。

また、他にもlifetimeオプションは有用ではないか、Domain Nameオプションはあった方がいい、といった意見は出されましたが、このアイテムについて標準化を進めることはほぼ合意が取れていることが確認されました。

IPv6フローラベルの使用法に関して

IPv6ヘッダー中にフローラベルという20ビットのフィールドがあり、RFC3697でこの使用法について規定されています。しかし、現在このフィールドは広く利用されているとは言えず、RFC3697で定められた、途中のルータでこのフィールドを変更してはならない、といった規定がその利用を制限しているため、これを緩和しようという提案がなされました。

提案内容としては、現在のフローラベルの1ビット目が1にセットされていた場合に、それ以降の19ビットはRFC3697の規定が適用されず、サイト等のローカルドメインで利用してよい、というものです。

また、フローラベルの具体的な利用法についても提案があり、ECMP（Equal-Cost Multi-Path）というトラフィックの負荷分散や、QoS（Quality of Service）の実現等が提案されました。これらの利用例は、上記のフローラベルの規定が変更されなければ実現が難しく、現在の規定の制限を受けているものとして説明されました。

この発表に関する議論としては、実際にフローラベルがどの程度、どのように利用されているのかという疑問が投げかけられ、それを調査してから仕様変更に着手するべきである、といった慎重な意見も出されました。また、実際にフローラベルが使われている例についても紹介がありました。仕様を変更することで、ローカルドメインにおける新たな使用法が可能になるため、ぜひ仕様を変更するべきであるという意見と、それによってこれまでの使用法が不可能になってしまうという意見があり、議論は平行線となりました。

ルータ間リンクでの127ビットプリフィクス

ルータ間に付与するアドレスとして、パケットのループ（pingpong）や、近隣探索キャッシュ溢れ等の問題の発生を防ぐために、127ビットのプリフィクスを用いることが有用です。しかし、IPv6ではサブネットエニーキャストアドレスが存在するため、これを利用することができないという問題が提起され、ルータ間リンクではこのアドレスを無効にしようという提案がなされました。

Point-to-Pointリンクが利用できるのではないか、また、ホームゲートウェイのWAN側でも利用できるようにするのか、といった議論が行われ、WGアイテムとしての採用はこれらの議論を行ってから、ということになりました。

アドレス選択

IPv6のアドレス選択方式については、複数の送信元アドレスと送信先アドレスのペアが存在するときに、短時間で一斉にこれらのペアについて通信を試みる、アグレッシブモードと呼ぶ方式と、従来方式との棲み分けについての提案がなされました。提案内容としては、どちらの方式を採用した場合でも、サイトのポリシーを適用することは必要であり、このポリシーを配布し適用する方法については、アグレッシブモードと従来方式とで、別々に分けて議論を行うことが可能であり、そのように進めようというものでした。

その後の議論では、アグレッシブモードの有用性が思ったほど大きくない研究結果の紹介があったり、アグレッシブモードについては後で検討を進めれば良いといった意見が出されたりしました。また実際のポリシー配布の方法については、実際の配布する情報の選定がまだ議論が十分し尽くされていないという意見があり、メーリングリストで引き続き検討を行うということになっています。

□6man WG: https://datatracker.ietf.org/wg/6man/
□第77回 IETF 6man WGのアジェンダ: http://www.ietf.org/proceedings/77/agenda/6man.html

behave WG(Behavior Engineering for Hindrance Avoidance WG）

behaveは主にNATの挙動に関して扱うWGですが、その技術的な関連性からIPv6-IPv4変換についての議論も行われています。今回は、3月25日（木）と26日（金）に合わせて5時間以上ものスロットを用いて、現在のWGアイテムのステータス紹介と、今後のアクションアイテムの選定が行われました。

IPv6-IPv4変換の基本方式については、以下の文書がIESG（Area Director）のレビュー段階となっており、Transport AreaのArea Directorである、Magnus Westerlund氏からいくつかのコメントや質問が行われました。なお、この基本方式では、IPv6ホストからIPv4ホストへの通信は1対多の変換、逆にIPv4ホストからIPv6ホストへの通信は1対1の変換について定めたものとなっています。

draft-ietf-behave-address-format-04
draft-ietf-behave-dns64-07
draft-ietf-behave-v6v4-framework-07
draft-ietf-behave-v6v4-xlate-stateful-09
draft-ietf-behave-v6v4-xlate-10

上位層のプロトコルの扱いに関して、トランスレータが上位層のプロトコルに対応していない場合に、そのパケット転送を必須（MUST）とするかどうかという質問が行われました。会場からの反応としては、ステートフルモードでは転送はできない、MUSTではなくSHOULDにするべきだ、等の意見がありました。またIPv4ヘッダーのIP IDフィールドの扱いについて明記することが必要であるとの意見が述べられました。

続いて、behave WGの今後のアクションアイテム選定と、マイルストーンの設定をするべく、さまざまな方式提案の発表が行われました。主に以下のテーマについて議論が行われました。

IPv4ネットワークから、IPv6インターネットへの通信（シナリオ3）
IPv4インターネットから、IPv6ネットワークへの通信（シナリオ4）
マルチキャストパケットのIPv6/IPv4変換
IPv6-onlyホストでのIPv4アドレスの扱い
デュアルスタックホストでのNAT64利用を避けるための方式
NATのハイアベイラビリティ、負荷分散方式
ラージスケールNAT

これらのうち、いくつかのトピックについて概況をご紹介します。

IPv4ネットワークから、IPv6インターネットへの通信（シナリオ3）

IPv4インターネットから、IPv6ネットワークへの通信（シナリオ4）

IPv4からIPv6への変換については、トランスレータをIPv6サーバ側に設置してIPv4クライアントからのIPv4での通信をIPv6に変換するシナリオ4と、IPv4クライアント側に設置してIPv4クライアントがIPv6インターネットに接続できるようにするシナリオ3とが既にチャーターに掲載されています。しかし、これらの方式はDNSへの依存度の高さ等、以前廃止されたNAT-PTでの問題点をクリアすることが難しく、WGでの標準化マイルストーンも設定されていないという状況になっています。

今回も中国勢をはじめ、両方のシナリオについてさまざまな提案がなされました。シナリオ4については、IPv4-IPv6変換にIPv4アドレスのポート部分を用いてアルゴリズミックに行うことでステートレスに近づけたもの、シナリオ3については、NAT-PTのIPv4-IPv6変換方式そのままのもの、BIS（Bump In the Stack）と呼ばれるホスト内で変換を行うもの、等が提案され活発な議論が行われました。

NAT-PTでの問題の多くが解決されていなかったとしても、移行にはトランスレータが必要であり、これらの技術が必要である等の肯定的な意見も複数あり、またこれらのシナリオは緊急性がそれほど高くはなく、必要になってから議論すべきだ、との意見も出されました。これらの議論を踏まえて、次のステップについてはチェアとAD（Area Director）との協議で決定することになりました。

NATのハイアベイラビリティ、負荷分散方式

NATのハイアベイラビリティや、負荷分散方式については、これまでの議論のサマリー等が提示され、これら方式の標準化の是非について、議論が行われました。ベンダーからの意見と利用者（キャリア）からの意見が大きく異なっており、マルチベンダー環境でも使えるようにすべく、標準化が必要だというキャリアからの意見と、L2スイッチ等でもベンダー独自方式でやっているように、こういった技術については標準化は難しくベンダーでの独自方式で進めるべきだとのベンダーの意見で対立した状況となりました。

ラージスケールNAT

ISP等においてNATを行う、ラージスケールNATについても発表がありました。ラージスケールNATに関連する各文書の位置づけや、改訂内容について説明があった後、数名から支持を表明するコメントがありました。特に反対意見や質問等は挙げられなかったため、今後behaveのWGアイテムとして標準化が進むものと思われます。

また、前述以外のトピックとして、今回IETF77の会場ネットワークで運用されていたNAT64トランスレータの実験について報告がありました。カナダのVIAGENIE社のオープンソース実装を用いた実験で、専用のSSIDを用いて実験が行われていました。実験の参加ホスト数は34と、あまり多くはなかったものの、いくつかのバグや、各種OSやソフトウェアの問題等が発見され、有意義な実験となったようです。