ニュースレターNo.44/2010年3月発行

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

本稿では、第76回IETFミーティングの会期中に議論されたIPv6に関連したトピックスのうち、IPv6に特化した内容を議論するWGでの話題を中心に紹介します。

6man WG（IPv6 Maintenance WG）

6manワーキンググループは、IPv6プロトコルのマイナーなメンテナンスを実施しているWGです。今回のミーティングは、11月10日（火）の午前最初のコマにて、開催されました。

会議は、前回と同様、チェアよりのミーティングの議題確認および、WGで取り組み中である文書のステータスについての報告から始まりました。現在、6man WGにて正式に取り組み中の文書（WGdocument）は、

フラグメント重複問題（IESG^※1review中）
ノード要求仕様（メーリングリストで議論中、アジェンダからは落ちました）
アドレス選択（今回、議論されました）
IPv6推奨アドレス表記（今回、議論されました）
IPv6サブネットモデル（ワーキンググループラストコール中：ラストコールは最終合意のこと。以下、Working Group Last Callを略してWGLCと表記。）※2009年11月14日に終了
経路制御ヘッダ（WGドラフト化）

の六つとなっています。

今回のミーティングの議題は、

IPv6アドレスのテキスト表記方法（draft-ietf-6man-text-addrrepresentation）
6LoWPANでの近隣探索（draft-ietf-6lowpan-nd）
アドレス選択に関する次へのステップ
- アドレス選択ポリシー間の矛盾解決（draft-arifumi-6manaddr-select-conflict）
- アドレス選択デザインチーム議論報告（draft-ietf-6man-addrselect-considerations）
近隣探索キャッシュの更新について（draft-kitamura-ipv6-neighbor-cache-update）
P2Pリンクでの/127プリフィクス長の利用（draft-kohno-ipv6-prefixlen-p2p）
ノード要求仕様文書に関する議論（draft-ietf-6man-node-reqbis）
IPv6のUDPチェックサムついて（draft-fairhurst-tsvwg-6manudpzero）

となっています（上記の通り、ノード要求仕様については簡単なコメントのみで議論されませんでした）。このうち、いくつかについて簡単に紹介します。

・IPv6アドレスのテキスト表記方法

前回のミーティング、およびその後のメーリングリスト（ML）での議論で、6man WGとして取り組んでいくことに合意し、今回のミーティングの前にWGLCが終わっていました。ミーティングでは、IETF75からの変更点について簡単に解説がありました。会場からのコメントも、文章表現についての簡単なもので、RFC化に向けて進めることになっています。

・アドレス選択問題について（アドレス選択ポリシー間の矛盾解決）

今回も引き続き、IPv6サイト/ホストがアドレスプリフィクスを複数持った場合の、アドレス選択のあり方の検討状況報告がありました。前回は、複数の上流から矛盾するアドレス選択ポリシーが配布された場合の、コンフリクトの解消（ポリシーのマージ）についての提案・議論がありましたが、今回は、主にポリシーを配布するプロトコルについての議論がありました。プロトコルとして、ルータ広告、DHCPv6、もしくは経路制御プロトコルのオプションを利用する場合の利点、欠点の検討紹介について、どれか一つに決めるべきである、DHCPv6でも情報をアップデートは可能、といったコメントがありました（その後、MLでも手法についての議論が延々と続いています）。提案文書について、より多くのコメントが欲しい、とのことです。

・P2Pリンクでの/127プリフィクス長の利用

現在、アドレスのプリフィクス長に/127を利用することはIPv6の仕様的に問題があるとされており、/127のプリフィクスを使用することの問題点を記述した文書（RFC3627）も出版されています。これに対して、特にオペレーションの観点から、P2Pリンクにて/127より短いプリフィクスを利用することの問題点を提示し、P2Pリンクでの/127の利用を明示的に可能とすることについての提案です。リンクローカルアドレスに関する問題等仕様上の注意点が指摘はされましたが、賛成も多く、今後WGとして継続して議論することになると思われます。

・IPv6のUDPチェックサムついて

ここしばらくIETFで議論されている、UDPにおけるチェックサム計算をしなくてもよいことにする提案に関する議論です。IPv6では、IPv6ヘッダにチェックサムがないため、IPv4と違ってUDPにおけるチェックサムの計算を必須としています。しかしながら、UDPを利用したトンネルの際に、トンネルの中を通るパケットレベルで相当のチェックをしている場合には、外側のUDPでのチェックサム計算が必要ない、途中のルータでトンネルリンクにパケットをフォワードする際に、UDPチェックサムを計算するコストが高くなってしまう、などが問題とされていました。今回は、計算コストに関する議論、チェックサムを廃止した場合の影響が検討され、ミーティング中の議論では、UDPのチェックサム処理への変更は実施しない方向となっています。

□6man WG: http://www.ietf.org/dyn/wg/charter/6man-charter.html
□第76回 IETF 6man WGのアジェンダ: http://www.ietf.org/proceedings/76/agenda/6man.html

v6ops WG（IPv6 Operations WG）

v6opsはIPv6に関するオペレーション技術や、移行技術に関する議論を実施するWGです。今回は、11月10日（火）、11月12日（木）午後最初の、合計2コマにて議論が実施されています。今回も、数々の新提案があり、内容も多岐にわたっていました。

議論内容は以下の通りです。

11月10日（火）

家庭向けIPv6インターネットサービス提供用CPEにおける簡易セキュリティ推奨機能（draft-ietf-v6ops-cpe-simple-asecurity）（アジェンダから消されました）
IPv6CPEに関する高機能セキュリティ（draft-vyncke-advanced-ipv6-security）
BitTorrentネットワークでのIPv6トラフィック測定（draft-defeche-ipv6-traffic-in-p2p-networks）
IPv6 CPEルータ推奨機能（draft-ietf-v6ops-ipv6-cpe-router）
IPv6 CPEルータ拡張推奨機能（draft-wbeebee-v6ops-ipv6-cpe-router-bis）
IPv4/IPv6共存フレームワーク（PET）（draft-cui-softwire-pet）
PETでのIPv6からIPv4への通信（draft-cui-softwire-pet64）
Internet Exchange（IXP）でのIPv6ディプロイメント（draft-ietfv6ops-v6inixp）

11月12日（木）

ICPに対するISPのIPv6移行サービスのプロビジョンに関する推奨
（draft-qin-v6ops-icp-transition）
IPv6ディプロイメントに関する新サービスプロバイダシナリオ
（draft-carpenter-v6ops-isp-scenarios）
IPv6移行のための段階的キャリアグレードNAT（CGN）導入
（draft-jiang-v6ops-incremental-cgn）
ISATAPと6to4における経路ループ：問題提起と解決案
（draft-nakibly-v6ops-tunnel-loops）
Teredoの拡張（draft-thaler-v6ops-teredo-extensions）
IPv4サーバにアクセスするIPv6アプリケーションの構築（draftwing-v6ops-v6app-v4server）

写真:ANAクラウンプラザホテル広島 — 会場となったANAクラウンプラザホテル広島

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

・IPv6 CPEに関する高機能セキュリティ

IPv6 CPEに関する高機能セキュリティは、現在議論中である「簡易セキュリティ推奨機能」（当初、議題には挙がっていましたが、議論はされませんでした）に対する、より高度なセキュリティモデルとしての提案です。IPv6ネットワークは、IPv4グローバルアドレスを内部にも使っている企業ネットワークと同等であり、セキュリティポリシーを考える際に、企業で利用しているポリシーが参考にできると考えて、七つのホームネットワーク用セキュリティポリシーを提案しています。特に、CPEデバイスを外部から動的にアップデートすることで、より強固なセキュリティを担保できるようにすることの必要性を強調していました。提案に対する賛成意見もありましたが、一方で、これはIPv6に特化したものであるのか、また、動的アップデートには標準等は必要ないため、IETFでなく、ブロードバンドフォーラム等で議論すべき内容ではないかとの反対意見もあり、提案に対する賛成、反対も含め、MLで継続議論となりました（火曜日のセッション終了後、継続議論されています）。

・IPv6 CPEルータ推奨機能、IPv6 CPEルータ拡張推奨機能

ここ数回のIETFで議論を続けている、IPv6対応のCPEルータが持つべき機能に関する提案です。今回から、検討事項が多い部分を拡張機能として別ドラフト（フェーズ2ドラフト）に切り出し、WANとLANの設定や、基本的なルータ機能、セキュリティ機能のみを基本部分として分離しています。基本部分のドラフトについては、MLにて意見を集め、それを反映後にWGLCを実施することとなりました。フェーズ2ドラフトの議論項目としては、マルチキャスト、DNS、プレフィックスの再委譲、IPv6移行機能、パケットフィルタ、QoS等が挙げられており、議論を継続していくこととなりました。

・Internet Exchange（IXP）でのIPv6ディプロイメント

IXPにおけるIPv6導入モデルは、3度目の発表となります。今回は、AMS-IXで導入されている、余計なARPトラフィックを減少させるための仕組みであるARPスポンジと同等の機能を、IPv6で実装する方法についての検討報告がありました。ARPスポンジは、多くのIXPで導入されているそうです。IPv6では、近隣探索プロトコルへの対応となりますが、アドレス長の違い、利用されていないアドレスが広大なことによる必要資源の増加等が問題となるようです。会場からは、この問題はIXPに特有でなく一般的な問題である、利用されていないアドレス対策が必要なら、/64より長いプリフィクスを使ったらどうか、といった質問がありました。コメントを反映して改版後、WGLCに進むことになりました。

・ICPに対するISPのIPv6移行サービスのプロビジョンに関する推奨

ICPをどのようにIPv6対応にしていくべきかをまとめようとしている提案です。利用できる移行機構（デュアルスタック、NAT64、IVI）を列挙し、利用できるツール等をまとめることを目的としています。会場からは、重要な観点であり、利用可能な技術を集めて情報共有をすることは意味がある、という意見や、重要ではあるが、多くのプロトコルは現状、標準化中であったり、どれがよい、と選べるものではなかったりと、まとめ方には注意が必要だ、といった意見がありました。今後デザインチームを作って、各機構、ツールの利点、欠点、ユースケース等を議論することになっています。

□v6ops WG: http://www.ietf.org/dyn/wg/charter/v6ops-charter.html
http://www.6bone.net/v6ops/
□第76回 IETF v6opsのアジェンダ: http://www.ietf.org/proceedings/76/agenda/v6ops

softwire WG（Softwires WG）

softwire WGは、トンネルを用いてIPv4 over IPv6、またはIPv6over IPv4通信を実現する方式を検討するWGです。現在扱っている方式は三つあります。一つはWGタイトルそのままのsoftwireと呼ばれる、IPv4 over IPv6またはIPv6over IPv4の汎用的なトンネル方式です。他にはDS-Lite（Dual Stack Lite）と呼ばれる、softwireのIPv4 over IPv6方式にCGN（Carrier Grade NAT）の機能を加味することで、IPv4アドレス在庫枯渇対策も含めたもの、そして6rd（IPv6 Rapid Deployment）と呼ばれる、IPv6アドレスの自動割り当ても含むIPv6 over IPv4トンネル方式があります。

これら三つの方式はいずれもまだ標準化が完了していませんが、それぞれが競合しているわけではなく、適用領域が異なっているとして、並行して標準化が進められています。

今回のセッションでは6rd、DS-Liteそれぞれについての標準化の進捗が報告され、いくつかの子細な部分に関する議論が行われました。6rdに関する議論では、Dave Thaler氏より6to4プロトコルで得られたNUD（Neighbor Unreachability Detection）の扱いや、routing loop問題への対策などの知見を盛り込むこと、また複数のBR（Border Router）を扱えるようにしてはどうか、といった提案がなされました。

DS-Lite方式の進捗に関しては、用語の変更などがあり、これまでCGNと呼ばれていたNAT装置を、AFTR（Address FamilyTranslation Router）と呼ぶとの説明がありました。DS-Liteでも6rdと同様に、トンネル終端装置であるAFTRを二重化する話が議論され、6rdと違ってDS-LiteではAFTRがクライアント装置毎にstateを持つ必要があるため、より実現が困難であり、引き続き検討が必要であるということになりました。

その他、6rd over UDPといった、6rdに対する拡張の提案などがありましたが、根本的な仕様変更を伴う提案であったため、まずはベースとなる6rdの標準化が完了してから検討すべきであるとの結論に至りました。

6rdは今回の議論を反映した改訂版を作成し、すぐにでもWGLCに進む予定になっています。DS-Liteに関しては、AFTRの二重化に関する議論が終わればWGLCに進むものと思われます。

□第76回 IETF softwire WGのアジェンダ: http://www.ietf.org/proceedings/09nov/agenda/softwire.txt
□softwire WG: http://www.ietf.org/dyn/wg/charter/softwire-charter.html

aplusp BoF

IETFではIPv4アドレス在庫枯渇の対策として、ISP内でNAT装置（CGN）を用いる方法と、ユーザーにグローバルIPv4アドレスを割り当てつつ、利用できるポート番号の範囲を限定する、というA+P方式の二つが主に議論されてきました。今回のBoF（WG設立前のミーティング）では、このA+P方式全般というよりはさらにフォーカスをしぼって、DS-Liteのトンネル上でこのA+Pを行うという方式についての議論が行われました。

A+P方式の利点としては、ポート範囲が限定されてはいるものの、ユーザーに直接グローバルIPv4アドレスを配布できるため、NATに阻害されずに通信が可能であるということが挙げられます。欠点としては、ホストやルータに対する影響が大きいことなどが挙げられます。このDS-Liteのトンネル上でA+Pを行うことで、トンネル終端装置以外の装置（中継ルータなど）への影響を最小限に留める、といった狙いがあると思われます。

今回のBoFのゴールは、IETFがこの方式を扱うかどうかを決定すること、ということで、新たなWGを設立するか、既存のWGのアイテムとなるかといった選択肢が示されました。

セッションでは、まずA+Pの概要説明後、モバイル環境への適用についての提案、そしてA+Pに関する懸念事項、そしてフリーディスカッションの後に、今後の方針について決定する、という流れで検討が行われました。

フリーディスカッションでは多くの意見が交わされましたが、結局Dave Thaler氏によるA+P方式のTCP/IPプロトコルスタックへの微小な修正が、多大な影響をもたらすものであり、またそれはNATの導入とは質の異なる根本的な変化であるとの指摘に同意する人が多かったのか、WGの設立はおろか、本提案についてIETFで取り組むべきではないと感じる聴衆が大半を占めるに至りました。これらの意見はIESGにインプットされ、A+P提案が他のWGで扱われるか、などの決定がなされることになっています。

□第76回 IETF aplups BoFのアジェンダ: http://www.ietf.org/proceedings/09nov/agenda/aplusp.html

behave WG（Behavior Engineering for Hindrance Avoidance WG）

behaveは主にNATの挙動に関して扱うWGですが、その技術的な関連性の高さからIPv6-IPv4変換についての議論も行われています。今回も、そのIPv6-IPv4変換の議論や、その他のNATに関する議論など、多数のトピックがありました。

まず、チェアからWGの状況についての報告があり、IPv6-IPv4変換に関する提案については、Interim Meeting（IETFミーティング期間以外での中間ミーティング）を経て、当初最重要であるとした問題ケースを解決する提案として、ほぼ仕様策定が完了したとの報告がありました。次の五つの提案について、2009年12月にはWGLCを行うとし、5人のレビュアーが必要であるということで、ボランティアを募りました。

- Address Format: draft-ietf-behave-address-format-01
- Framework for IPv4/IPv6 Translation: draft-ietf-behave-v6v4-framework-03
- IPv6/IPv4 Translation: draft-ietf-behave-v6v4-xlate-03
- Stateful IPv6/IPv4 Translation: draft-ietf-behave-v6v4-xlate-stateful-02
- DNS64: draft-ietf-behave-dns64-02

その後、これらのそれぞれの提案について、変更点の報告などが行われました。Address Formatの提案では、Well Known Prefixのフォーマットについての議論や、またTranslationの提案では、パケットのフラグメントの扱いに関する詳細議論が行われましたが、特に大きな変更が必要となるような意見は出ず、今後もInterim Meetingを行いながら迅速に標準化を進めていくということになりました。

また、これらの提案以外に、ホスト自身でIPv6-IPv4変換を行うといった提案や、A+Pの考え方をIPv4からIPv6への変換方式に組み込むことで、IPv6ホストにIPv4グローバルアドレスを付与するといった提案など、さまざまなIPv6-IPv4変換に関する変更や拡張の提案がなされました。しかしながら、これらの提案は、現在注力している上記の方式の標準化が終わってから着手するべきであるとか、また他のWGで進められている技術と同一目的であるのでそこで議論するべきである、という意見が多数となっていました。

IPv6-IPv4変換だけでなく、IPv4-IPv4変換の議論も行われ、CGN装置の信頼性向上のための冗長化の議論、また複数のユーザーで同一のIPv4アドレスを共有するという観点から問題点、対策をまとめた文書などの発表がありました。これらの議論も継続して進めることになっています。

□behave WG: http://www.ietf.org/dyn/wg/charter/behave-charter.html
□第76回 IETF behave WGのアジェンダ: http://www.ietf.org/proceedings/09nov/agenda/behave.html

（NTT情報流通プラットフォーム研究所藤崎智宏）
（NTT情報流通プラットフォーム研究所松本存史）

※1 Internet Engineering Steering Group（IESG）: IETFの活動と標準化プロセスの、技術的な側面についての責任を担っているグループです。IESGのメンバーは、IETFの複数のWGで文書のレビューを行ったり、WGの方向性について助言を行っているArea Directorで構成されています。IESGはInternet-Draftの標準化プロセスを進めるかどうかを決定し、IESGによって承認されるとRFC番号が割り振られ、RFCとしてIETFのサーバで公開されます。