ニュースレターNo.46/2010年11月発行

第78回IETF報告（2010.7.25～7.30）　IPv6関連WG報告

2010年7月25日（日）から30日（金）まで、オランダのマーストリヒトにて第78回IETFミーティングが開催されました。同時期、日本は酷暑でしたが、現地は最高気温が摂氏25度程度で、カラっとした過ごしやすい陽気の中でのミーティングでした。今回の参加者は、267人の新規参加者を含み、合計1,153名でした。また、参加者の内訳は、米国からが最も多く、続いて中国、日本、ドイツ、といった様子だったようです（プレナリにおけるIETFチェア発表より）。

本稿では、会期中における、IPv6に特化した内容を議論するワーキンググループ（WG）での議論内容を中心に紹介します。

6man WG（IPv6 Maintenance WG）

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回は、7月27日（火）の午後最後のコマと、28日（水）午前2コマ目の、合計2コマ開催されています。

最初にいつもの通り、6man WGで取り組み中である以下の文書について、ステータス確認が行われました。

IPv6拡張ヘッダの統一フォーマット（WGドラフトの初版発行）
IPv6サブネットモデル（RFC5942として発行）
IANA経路制御ヘッダ（RFC5871として発行）
IPv6推奨アドレス表記（RFCエディタ発行待ち）
※ミーティング後、メーリングリスト（ML）上で議論あり
DNS RA（Router Advertisement）オプション（IESG（Internet Engineering Steering Group）評価、AD（Area Director）フォローアップ中）

今回のミーティングでは、以下のアイテム/テーマについて議論されました。

2010年7月27日（火）：

ノード要求仕様の更新
draft-ietf-6man-node-req-bis
IPv6アドレス選択
draft-ietf-6man-addr-select-considerations
draft-arifumi-6man-rfc3484-revise
P2Pリンク上におけるIPv6プリフィクス長/127の利用
draft-kohno-ipv6-prefixlen-p2p

2010年7月28日（水）：

UDPゼロチェックサムの検討
draft-ietf-6man-udpzero
IPv6フローラベル仕様の更新
draft-carpenter-6man-flow-update
IPv6フローラベルを用いたECMP（Equal-Cost Multi-Path）
draft-carpenter-flow-ecmp
RPL（IPv6 Routing Protocol for Low power and Lossy Networks）でのIPv6経路制御ヘッダの利用
draft-hui-6man-rpl-routing-header
データプレーンデータグラムでのRPL情報運搬のためのRPLオプション
draft-hui-6man-rpl-option

これらのアジェンダの中から、以下にいくつかのトピックについてご紹介します。

・ノード要求仕様の更新
IPv6ノードが実装すべき仕様（RFC）を定義する文書の更新に関する議論です。最新ドラフトでの変更点についての説明、および以下の点に関する議論が実施されました。

- 設定方法：RAとDHCP
設定方法の柔軟性を上げるために両方で同じ項目を設定できた方がよい、という意見と、両方が使用された場合に、ホストが得た情報に矛盾があった場合の対処の困難性が指摘されました。

- DNS設定
RAによるDNS設定の配布方法が標準（Standards Track）になることを受け、RAによる配布を必須とすべきかについて議論されました。RAも必須とすべきという意見が多く、MLで確認することとなっています。

- アドレス設定
現在のRFCでは、DHCPによるアドレス配布の実装は「MAY」となっています。企業等はRAよりDHCPを使うだろうという意見もあり、これを「SHOULD」とする方向になりました。

- IPsecとIKEv2に関する記述
現在のRFCでは、IPsecの実装は「MUST」となっています。IKEv2と合わせ、これを「SHOULD」とする方向になりました（会場では、“strong SHOULD”と言われていました）。

・IPv6アドレス選択
IPv6ノードが複数のアドレスを持った場合のアドレス選択手法について、6man WGではデザインチーム（DT）を構成して議論を続けてきました。今回、DTから、議論となっていたアドレス選択ポリシーの配布方法としてはDHCPが適していること、複数の矛盾するアドレス選択ポリシーを受信した場合の扱いについては、別途検討を進めるべきであること等の、議論結果の報告がありました。この報告を受け、アドレス選択手法を定義しているRFC3484の改版提案およびDHCPによるアドレス選択機構の提案について、前者はWGドラフトとして進めていくこと、後者については、さらにMLで議論を実施することとなっています。

・UDPゼロチェックサムの検討
現状「MUST」となっているIPv6のUDPにおけるチェックサム計算について、UDPをトンネルのトランスポートとして利用する場合には、これを不要とする提案です。前回のIETFにて、WGとしてこの問題に取り組むこととなり、今回、WGアイテムとして議論されました。UDPチェックサムが'0'となった場合の影響について、中間ノード（ルータ等）や、エンドノードの観点でどうなるかに関する調査の必要性や、そもそもチェックサムが'0'でよい場合かどうかの区別ができるのか、という問題が提起されており、MLで継続議論となっています。

・IPv6フローラベル仕様の更新
IPv6の特徴の一つとしてあげられることの多い、フローラベルの仕様更改に関し、前回のIETFに引き続き議論が行われています。今回は、フローラベルを経路の途中で変更可能とするかどうかが、主な議論になりました。現在の仕様では、フローラベルは経路途中で変更してはいけないことになっていますが、これを変更可能とすることで、AS内等でローカルに利用できるようになります。しかしながら、フローラベル値は変更されたかどうか検知ができないため、情報として信用できるのか、という問題があります（IPsecでもフローラベルは保護されていません）。会場では、変更可能とすべき、という意見の方がやや多かったものの、結論は出ませんでした。

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

savi WG（Source Address Validation Improvements WG）

savi WGは、LAN環境において、始点アドレスの詐称を防ぐ機構について検討するWGです。今回は、7月26日（月）朝一番のコマにて、開催されました。参加者は20～30名と、それほど多くない人数での議論となっています。今回は、主にsaviの解としてのステートレスアドレス自動設定（SLACC）における詐称防止（IPv6）、DHCP環境における詐称防止（IPv4/IPv6）について、議論が実施されました。ポイントとしては、

SLACCにおける、savi機構のライフタイムの扱い
savi装置のポートにおいて扱わなければならないIPv6アドレス数
SLACCとDHCPv6が同時に使われた場合の扱いの問題

等が、特に時間を割いて議論されていました。

saviの機構はスイッチ、またはルータに実装されることになりますが、既に多くのベンダー（主に中国ベンダー）にて実装されており、運用実験等が進んでいる、という報告もありました。

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

v6ops WG（IPv6 Operations WG）

v6opsは、IPv6に関するオペレーション技術や、移行技術に関する議論を実施するWGです。今回は、7月26日（月）と30日（金）に2時間ずつ、合計2コマにて議論が実施されていました。今回も、数々の新提案があり、内容も多岐にわたっていました。いくつかのトピックについて、簡単に紹介します。

・NATを用いないIPv6マルチホーミング方式
（draft-troan-multihoming-without-nat66）
従来IPv4で行われてきた、NATを用いた複数サイト帰属（マルチホーミング）を、IPv6においてNATを用いずに実現する方法について提案したものです。そもそも、家庭ユーザーなど小規模サイトでの複数サイト帰属は、複数のISPに接続するケースや、ISP接続とVPN接続の併用といった場合にNATを用いて行われています。IPv6のend-to-end原理を実現するためには、NATを使わずにこういった複数サイト帰属を実現する必要があります。その方法として、それぞれの上流ネットワークから付与されたIPv6アドレスを、サイト内の端末に付与し、その結果ユーザー端末に複数のアドレスを付与するマルチプリフィクス環境を構築し、そこで経路選択情報とDNSサーバ選択情報、アドレス選択情報の三つの情報を、ホームゲートウェイやユーザー端末に配布する必要がある、という発表がなされました。また、この提案については、BBF（Broad Band Forum）において既に必要であるという合意がなされ、今回IETFへのリエゾン文書が送付されています。

・IPv6対応ISPのリスト化についての基本ガイドライン
（draft-kawamura-ipv6-isp-listings）
ユーザーがIPv6対応のISPを選定する際に、IPv6対応をうたっていてもISPごとに対応度合いがまちまちであり、明確な基準がなくユーザーに混乱をもたらす、といった問題への対処方法として、明確なIPv6対応項目リストを提示したものです。現在のドラフトでは、既存のIPv6対応ISPリストの情報を収集し、それらのチェック項目の詳細内容についてまとめ、新たなチェックを行う場合の判断基準について提案しています。今回のセッションでは、判断基準の妥当性や、Basic、Advancedといった判断基準をクラス分けする際のネーミングについて、活発な議論が行われました。

・IPv6でのCIDRによるアドレス集約（draft-azinger-cidrv6）
IPv6における将来的な経路表爆発問題が発生するという可能性を示唆し、その対策についての提案を行ったものです。近年IPv6のDFZ（Default Free Zone）において、IPv6 PIアドレスをはじめとした小さなアドレスブロックが広告されており、それによって将来IPv6もIPv4と同様に経路表爆発の問題が発生するとし、その推移の予想などを行っています。

またその対策として、できる限り集約した経路を広告するなどの手法がまとめられたRFC4692を遵守することを提案し、さらにアドレスを配布するIR（Internet Registry）に対しては、/32以上の大きなアドレスブロックを極力配布し、/48などの現在IPv6 PIとして配布している小さいアドレスブロックの配布は制限するか廃止することを推奨する、としています。セッションでは、RFC4692で述べられた手法の有効性や、IETFがアドレス配布といったIRの役割について踏み込むことの是非などについて議論が行われ、今後はIRと一緒に議論すべきであるなどの提案がなされました。

・エンドサイトへのIPv6アドレス割り当て
（draft-narten-ipv6-3177bis-48boundary）
既存のRFC3177に記述された、/48をエンドサイトに割り当てるという推奨文章を更新する件について提案がなされました。現在のIRでの、エンドサイトへのアドレス配布ポリシーでは、家庭ユーザーなどのエンドサイトに対して/56を割り当てることを想定した、割り振りアドレスサイズの検討が行われており、既にRFC3177に記述された状況との乖離が発生しています。このためRFC3177をアップデートすることで、乖離の解消を目的とした提案になっており、/64から/48の間に明確な境界を設けないこと、また/128単位でのアドレス配布は推奨されないことなどが盛り込まれています。セッションでの議論としては、そもそもエンドサイトに対して複数の/64を割り当てることの必要性など、基本的な部分の議論から行われ、必要以上にアドレスを付与してもかえって有害であるだとか、IPv6版NATの必要性を排除するためにも、潤沢なアドレスを付与することが必要だといった意見が出され、継続して議論を行うことになっています。

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

softwire WG（Softwires WG）

softwire WGでは、トンネルを用いてIPv4 over IPv6、またはIPv6 over IPv4通信の実現方式を検討するWGです。IPv4 over IPv6やIPv6 over IPv4の汎用的なトンネル方式以外に、昨今さまざまなISPで導入が検討されている、DS-Lite（Dual Stack Lite）や6rd（IPv6 Rapid Deployment）といった、新しいIPv4とIPv6の共存環境を構築する方式が検討されています。

6rdはつい先日RFC5969として公開されました。DS-Liteは現在ADによるレビューが行われています。

6rd+（draft-despres-softwire-6rdplus）
6rd over UDP（draft-lee-softwire-6rd-udp）

今回のセッションでは6rdやDS-Liteへの拡張提案が主に議論され、まず6rdの拡張方式として、6rdをUDPでカプセリングすることで、CPEなどのNAT装置が6rdに対応していない環境において、ホストが6rdを終端し、IPv6アドレスを取得して利用する方式が提案されました。しかし、IPv4ネットワークを介して、ユーザーにIPv6接続性を提供する方法としては、既にTeredoやL2TPといった複数の方式が確立されており、既存の方式でカバーされていない部分は何なのかといった部分を詰める必要がある、という議論が行われました。

DS-Lite RADIUSアトリビュート（draft-maglione-softwiredslite-radius-ext）
DS-Liteでのフローラベル利用（draft-donley-softwiredslite-flowlabel）

また、DS-Liteの拡張提案も複数議論され、DS-LiteにおけるトンネルアドレスのRADIUSアトリビュートについての提案や、DS-LiteのトンネルについてIPv6ヘッダのフローラベルを用いたQoS制御の提案などがありました。前者の必要性については賛同者多数でしたが、後者については、やはりフローラベルの仕様変更を含む提案であり、問題提起と要件定義というフレームワークを築いた上で議論を慎重に進めるべきである、という意見が多数ありました。