ニュースレターNo.47/2011年3月発行

IPv6関連WG報告

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

6man WG（IPv6 Maintenance WG）

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回は、11月9日（火）の午後最初に1コマにて開催されました。

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

IPv6推奨アドレス表記（RFC5952として発行済み）
DNS RAオプション（IESG承認、RFCエディタ発行準備中）
※2010年11月末に、RFC 6106（Standard Track）として発行
ルータ要請メッセージでの回線識別（draft-krishnan-6manrs-mark-08）：WGドラフトとして登録

最後の回線識別ドラフトに関しては、「技術的問題が多く、WGドラフトとする合意に達していないのでは」という指摘がありましたが、「まずはWGドラフトにしてから技術的課題を検討するのであって、RFCとして発行することとは別」というフォローがありました（WGドラフト化は、IETF79前に、WGドラフトとするかどうかの合意確認がMLで実施された結果です）。

今回、以下のテーマが議論されています。時間の割には議題が非常に多いという印象でした。

IPv6拡張ヘッダの統一フォーマット
draft-ietf-6man-exthdr
UDPゼロチェックサムの検討
draft-ietf-6man-udpzero、draft-eubanks-chimento-6man
RFC3848 IPv6デフォルトアドレス選択の更新
draft-ietf-6man-RFC3484-revise
P2Pリンク上におけるIPv6プリフィクス長/127の利用
draft-ietf-6man-prefixlen-p2p
重複アドレス選択プロキシ
draft-costa-6man-dad-proxy
アドレス登録に関する要求条件
draft-jiang-6man-addr-registration-req
IPv6フローラベル仕様の更新
draft-carpenter-6man-flow-update、draft-carpenter-flow-ecmp
IPv6フローラベルに関するセキュリティ評価
draft-gont-6man-flowlabel-security
Teredoループ攻撃の緩和
draft-gont-6man-teredo-loops
（・エンドポイント識別子（EID）オプションの廃止 draft-gont-6manobsolete-eid-option）→時間切れで議論できず。

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

IPv6拡張ヘッダの統一フォーマット
draft-ietf-6man-exthdr

IPv6拡張ヘッダの標準フォーマットを決めよう、という提案です。現在定義されている拡張ヘッダでは、フォーマットに統一性はありません。今後新たに拡張ヘッダを追加定義する際、新しい拡張ヘッダを認識できない古い機器がそのヘッダ部分をスキップすることができるよう、ヘッダの長さ情報等のフィールドを規定するなど、フォーマットに統一性を持たせることを提議しています。会場から、中間ノードが知らない拡張ヘッダに遭遇した場合に取るアクション（そのまま通過させる/パケットを落とす）を定めるビットを設けるべき、という意見があり、このビット追加を反映後、WGラストコールを実施することとなりました。

UDPゼロチェックサムの検討
draft-ietf-6man-udpzero、draft-eubanks-chimento-6man

IPv6では必須となっているUDPでのチェックサムについて、IPv4と同様に、計算の省略を可能にしようという、ここ数回議論が続いている提案です。計算しない場合に関する考察である文書（draft-ietf-6man-udpzero）は、WGラストコールを実施することになり、実際の適用手法に関する提案（draft-eubanks-chimento-6man）が議論となりました。適用を特定の場合のみに限定することについてはおおむね賛同を得ましたが、IPv6の基本文書であるRFC2460の改変が必要という意見も挙がっています。後者の文書についても、WGドラフトとして引き続き検討をすることに反対はありませんでした。

RFC3484 IPv6デフォルトアドレス選択の更新
draft-ietf-6man-RFC3484-revise

IPv6ノードおよび通信相手が複数のアドレスを持つ場合に、通信に使うアドレスペアを選択する必要があります。この選択方法については、RFC3484に記載されていますが、デフォルトのルールに最新のアドレス情報（ULA; Unique Local IPv6 Unicast Addresses（RFC4193）等）が記載されていない問題等があるため、RFC3484を改版しようという提案です。本提案には、アドレスペアを選択する際の優先度に関して、ULA空間の優先度を引き下げるという提案が含まれていましたが、これに対して「自分が使っているULA空間は優先すべき」等の意見があり、検討を継続することになりました。関連して、デフォルトルールをDHCPv6で配布し、変更できるようにするという提案（draft-fujisaki-6man-addr-selectopt）について、WGドラフトとして扱うことに対するコンセンサス確認が実施され、WGドラフトとして議論することになりました。

P2Pリンク上におけるIPv6プリフィクス長/127の利用
draft-ietf-6man-prefixlen-p2p

前回WGドラフトとなった、ルータ間のリンクに付与するアドレスとして、127ビットのプリフィクスを用いることを可能としよう、という提案についての議論です。この文書中に挙げられている問題の一部は、より広い範囲でも検討する必要があるのでは、といった意見が出されました。ミーティング後に、WGラストコールを実施し、より広い意見を集めることになりました（2010年12月6日までの期限でラストコールが実施されていました）。

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

重複アドレス選択プロキシ
draft-costa-6man-dad-proxy
IPv6フローラベル仕様の更新
draft-carpenter-6man-flow-update、
draft-carpenter-flow-ecmp

がWGドラフトとして採用の方向、

Teredoループ攻撃の緩和
draft-gont-6man-teredo-loops

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

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

v6ops WG（IPv6 Operations WG）

v6opsは、IPv6に関するオペレーション技術および共存・移行技術に関する議論を実施するWGです。今回は、11月10日（水）と12日（金）の2コマにて議論が実施されました。

IPv6の導入加速の世相を反映してか、今回も数多くの新提案がありました。チェアの方でも、議論時間を極力短縮するため、おのおのの発表では合意の確認を実施せず、インターネット上に用意したサイトにて、賛同、不賛同を後ほど入力するような形式を取ることにする、という周知が事前にありました。

　ここでも、いくつかのトピックについて、簡単に紹介します。

Happy Eyeballs：デュアルスタックホストにおいて通信を成功させるために
draft-wing-v6ops-happy-eyeballs-ipv6
複雑な環境でのTCPセッションの開始
draft-baker-v6ops-session-start-time

IPv6/IPv4デュアルスタック環境では、通信相手がIPv4/IPv6両方のアドレスを持っている場合、ノードは、最初に選んだ通信プロトコルでの通信に支障が発生した場合に、もう一方の通信プロトコルに切り替えるという、いわゆるフォールバック、と呼ばれる動作をすることが一般的です。昨今の多くのデュアルスタック実装では、IPv6がIPv4よりも優先されるため、IPv6通信に支障があった場合にIPv4で再度試す、という動作をしますが、この切り替えに時間がかかり、ユーザーの利便性が損なわれる、という問題が発生しています。このようにデュアルスタック環境で発生する問題を、ユーザーの観点からいかに解決するかについて提案があり、議論が行われました。複数のTCPセッションを同時にスタートし、最初に通信できたセッションを利用する、といった解が提案されています。SCTPでの実装例や、アプリケーションとの関連に関するコメントが出されました。提案名が漠然とし過ぎていてすぐに提案内容を想像できないため、もっとわかりやすいものに変更すべき、という意見もありました。

ミーティング後に公表された投票の結果、それぞれ78.8%、63.2%がWGドラフトとして扱うべき、ということになり、特にHappy Eyeballsについては、出版ステータスの確認（InformationalかBCP（Best Current Practice）か）が、ML上で実施されています。

IPv6カスタマーエッジルータの高度要求仕様
draft-wbeebee-v6ops-ipv6-cpe-router-bis
IPv6普及におけるCPEに関する考察
draft-herbst-v6ops-cpeenhancements

間もなくRFCとなる予定の、IPv6カスタマーエッジルータ基本仕様文書（draft-ietf-v6ops-ipv6-cpe-router）に対する、追加仕様の提案です。従来、基本仕様と同時に議論されていたものを、分離して別文書として検討しています。また今回は同時に、スマートメーター等で利用される省電力無線デバイス（IEEE802.15.4（Zigbee）等を利用したデバイス）と家庭用ルータの接続に関する提案も実施されています。CPE追加仕様については、6rd、DS-liteといった移行プロトコルの記述追加、家庭でのCPEのトポロジーに関する考察（多段ルータ環境を考慮するか）、ULAの利用方法などについて言及され、後者ではIEEE802.15.4の接続方法、ULAでの通信の必要性等が例として挙げられました。議論としては、マルチキャストDNSの利用の是非、まずはトポロジーは単一ルータ環境に限定すべきである、といった点が挙げられています。今後、継続して議論していくこととなりました。

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

IPv6 AAAA DNSホワイトリスティングの影響
draft-livingood-dns-whitelisting-implications

キャッシュサーバからのクエリパケットのアドレスに基づき、DNS権威サーバにて、AAAAレコードを応答するかどうかを制御する、DNSホワイトリスティングに関する提案です。上記Happy Eyeballsのドラフトにも関連しますが、この仕組みにより、クライアント（正確には、クライアントの利用するキャッシュサーバ）のIPv6アドレスごとに、自サイトにIPv6を利用してアクセスするかどうかを制御できます。Googleでは実際にこの仕組みを使い、IPv6の接続性が良い相手からのみ、IPv6接続を利用可能とするような制御を実施しています。DNSの名前空間を分断することになり問題だ、DNS関連WGでも情報共有し議論をしてほしい、という意見が出されました。

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

アジェンダにはありませんでしたが、ミーティングの最後に、opsareaミーティングで話題に上がった、IPv4プライベートアドレス（RFC1918）の拡張に関する議論がありました（draft-weilshared-transition-space-request）。こちらは、ISP共有アドレス空間として、2段NATの中間に使うための空間として利用したい、というものです。この用途として、IPv4の/10程度をリザーブしたい、という提案でしたが、賛成・反対共に多数の非常に激しい議論となりました。結果として、IETFではコンセンサスに至りませんでしたが、IPv4アドレス空間のIANA在庫が枯渇直前となり、このような空間を用意することは既に困難な状況になっていると思われます。

その他、前回のレポートでご紹介した、

NATを用いないIPv6マルチホーミング方式
draft-troan-multihoming-without-nat66

について、ステータスレポートが実施されました。こちらについては、76%がWGドラフトとして議論をすべきという結果になっています。

□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、またはIPv6over IPv4通信の実現方式を検討するWGです。昨今、さまざまなISPで導入が検討されている、DS-lite（Dual Stack Lite）や6rd（IPv6 Rapid Deployment）といった、新しいIPv4とIPv6の共存環境を構築する方式も併せて検討されています。今回は、開始早々の月曜朝一のコマにも関わらず、100名を超える参加者を集めて開催されました。

10件以上の新規提案があるなど議論アイテムも非常に多く、新規アイテムの提案については、「技術の説明で1スライド、問題点や必要性等で1スライド程度で説明することを話者に連絡済み」「なるべく時間を短く」とチェアより念押しがありました。このためか、ほとんどの新規アイテムで議論も質問もありませんでした。

この後、チェアからDS-liteのステータスに関する説明がありました。DS-liteは、本体プロトコルと、必要なパラメータをDHCPで配布するDHCPオプション定義の二つの文書に分けられ、それぞれ個別に標準化が進められています。本体となるDS-lite（draft-ietf-softwiredual-stack-lite）ですが、AD（Area Director）のレビューは終了し、そのコメント対応中となっています。DHCPオプションのドラフト（draft-ietfsoftwire-ds-lite-tunnel-option）では、IESGレビューでコメントが付き、トンネル終点の指定に、FQDN（Fully Qualified Domain Name;完全に限定されたドメイン名）とIPアドレスの両方ではなく、どちらか片方のみ指定することが議論され、その結果、最終的にはFQDNのみを指定するよう変更することになりました。こちらはドラフト修正後、WGラストコール、IESGにレビューを再依頼の予定となっています。

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

今回のIETFよりWG化されたPCP（Port Control Protocol）WGより、PCPのプロトコルトランスポートとしてIPv6とIPv4のどちらを利用すべきか、という問いかけがありました。特にDS-liteでの利用の場合を想定しているとのことです。チェアからの双方ともに得失があるとの説明通り、その後の議論でも意見が分かれました。
draft-ietf-softwire-dslite-radius-ext
draft-guo-softwire-6rd-radius-attrib

softwireのチャーター内のアイテムとして6rdやDS-liteのradius属性定義の提案がありました。それぞれ、WGドラフトとして議論していくことになっています。ISPでこれらのプロトコルを使用するには必須な部分であり、実導入に向けて検討が進んでいることがうかがえます。