ニュースレターNo.51/2012年8月発行

第83回IETF報告
IPv6関連WG報告～6man WG、v6ops WGについて～

本稿では、会期中において、IPv6に特化した内容を議論するワーキンググループ(WG)のうち、6man WGとv6ops WGの議論内容を中心に紹介します。

6man WG( IPv6 Maintenance WG)

6man WGは、IPv6のプロトコル自体について小規模なメンテナンスを実施するWGです。今回は、27日(火)の朝一のコマにて開催されています。ミーティング冒頭で、いつもと同様、チェアによるアジェンダ確認があり、6man WGで取り組み中である以下の文書についてステータス報告がありました。

・IPv6ノードの要求仕様改版: RFC6364として発行済み。
・RFC3627(ルータ間における/127のプリフィクス長の利用を非推奨とする文書)を歴史的ステータス(Historic)化: RFC6547として発行済み。
・RPL(低電力高損失ネットワーク用のIPv6ルーティングプロトコル)用のデータ転送オプション: RFCエディタでの発行待ち(本稿執筆時点では、RFC6553、RFC6554として発行済み)。
・IPv6拡張ヘッダの統一フォーマット: RFCエディタでの発行待ち(本稿執筆時点では、RFC6564として発行済み)。
・URL中でのZone IDの記法(draft-ietf-6man-uri-zoneid): WGラストコール終了。課題について今回議論。
・回線IDオプション(draft-ietf-6man-lineid): 1週間のWGラストコール準備完了(4月12日(金)～19日(金)までラストコール)。
・重複アドレス検索プロキシ(draft-ietf-6man-dad-proxy): 1週間のWGラストコール準備完了。
・UDPのチェックサム廃止(draft-ietf-6man-udpzero/draft-ietf-6man-udpchecksums): 1週間のWGラストコール準備完了。
・単一フラグメント(atomic fragments)の処理(draft-ietf-6man-ipv6-atomic-fragments): 1週間のWGラストコール準備完了。
・DADの拡張(draft-ietf-6man-enhanced-dad): WG文書として採択。
・アドレス選択関連文書(draft-ietf-6man-addr-selectconsiderations/draft-ietf-6man-addr-select-opt/draft-ietf-6man-rfc3484-revise): draft-ietf-6man-rfc3484bisと併せて議論(今回のミーティングで議論)。

文書のステータス報告後、WGの共同チェアの変更報告がありました。Brian Haberman 氏がインターネットエリアのエリアディレクタ(AD)に就任することに伴い、Ole Troan氏が今後、6man WGの共同チェアとなり、Robert Hinden氏とともに6man WGを運営していくこととなります(インターネットエリアのADだったYari Arkko氏は、IAB(Internet Architecture Board)メンバーとなります)。

今回議論されたテーマの中から、いくつかのトピックスを取り上げてご紹介します。

・RFC3848 IPv6デフォルトアドレス選択機構の改版 (draft-ietf-6man-rfc3484bis)

IPv6のアドレス選択機構について、現行仕様の変更に関する議論です。従来、元の文書であるRFC3484の一部をアップデートする方向で議論が進んでいましたが、元の文書をすべて置き換える方向になっており、従来の議論を取り込んだドラフトにて議論が実施されました。

議論の中で、「IPv6 SLACCのプライバシー拡張」(RFC4191)等で生成されるプライバシーアドレスの扱いが問題となりました。従来のRFC3484では、グローバルユニキャストアドレス等のパブリックアドレスと、プライバシーアドレスのような一時アドレスがある場合に、パブリックアドレスの使用を優先する、という規約になっています。この規約ですと、通信の際、プライバシーアドレスを発アドレスとして利用する場合が少なくなるため、Windows OS等では、逆の動作(プライバシーアドレスを優先)をします。改版に合わせ、この動作をどのようにするかが議論され、サイト外部と通信する際には、プライバシーアドレスを優先したいが、サイト内ではパブリックアドレスを優先したい、等の意見が出されました。

どちらが好ましいか、参加者に確認したところ、プライバシーアドレスを優先すべきという人が多く(比率にして3：1程度)、メーリングリスト(ML)にて引き続き意見を募集することとなりました。他に、IPv4共有アドレス空間をデフォルトテーブルに加えること等が意見として出され、ミーティング終了後、WGラストコールを実施することとなりました(本稿執筆時点で、4月26日締め切りのラストコールがかかっています)。

・URL中でのZone IDの記法(draft-ietf-6man-uri-zoneid): URL中における、IPv6のZone Index指定記法に関する議論です。IPv6では、アドレスの有効範囲(スコープ)を明確に規定しています(リンクローカルスコープ、グローバルスコープ)。範囲の指定には、Zone Indexという値を利用します。例えば、リンクローカルスコープの場合、Zone Indexにインタフェース名(en0、fxp0など)を用い、アドレスが属するスコープを指定します。アドレス表記的には、'％'を使用し「fe80：：1％en0」という形となります。しかしながら、URLでは'％'は特殊な意味を持つ文字であり、そのままでは使用できないため(RFC3986)、どのような形でZone Indexを指定すべきかの検討です。議論では、指定方法についていくつかの案が出されましたが、URL中にアドレスを記述する場には、'［' ', '］' でくくるため(ex. http://［ fe80：：1％en0］)、この中については特に気にする必要はないのでは、といった意見もあり、合意には至りませんでした。また利用頻度についても、家庭ネットワークでは、リンクローカルスコープの指定が多くなるので重要であり、早く決める必要がある、という意見もありましたが、逆に、そもそもIPアドレスをURLで直に指定することはまれである(リンクローカルアドレスなどを指定するのはIETFに来ているような人だけだ)という意見もあり、意見が分かれていました。

・Fernando Gont氏のセキュリティ関連連続プレゼンテーションより

(1)IPv6ステートレスアドレス自動設定(SLAAC)における静的なプライバシー拡張アドレス生成方法
(draft-gont-6man-stable-privacy-addresses)

IPv6のステートレスアドレス自動設定(SLAAC)において、アドレスの一部(インタフェース識別子)に、MACアドレスから生成されるEUI-64ではなく、ランダム値を使用する手法を提案しています。ランダム値は、プリフィクスやEUI-64の値等から生成するものとされています。実際、Windows OSではVista以降、このようなアドレスを生成して使用するようになっています(設定により変更可能)。議論では、適切なアドレス生成方法を検討するには、ドラフトが対応しようとしている脅威の明確化が必要、といった意見が出されました。プライバシー保護の観点からも、この問題については多くの参加者が興味を持っていることが確認され、WGとして引き続きこの問題に取り組んでいくこととなりました(4月26日期限で、WG文書としてこのドラフトを扱うかどうかのコメントが募集されました)。

(2)予測可能な断片化識別子値に関わるセキュリティ
(draft-gont-6man-predictable-fragment-id)

IPv6でパケットを断片化する際、断片の識別子に予測可能な値を用いていることに対する問題提起の提案です。予測された場合、断片化機構に対する攻撃に利用される可能性があります。実際にいくつかのOSでは、初期値0のカウンタを用いていたものや予測が容易な値を用いていたものがあり、著者の指摘によって変更された、ということも報告されました。議論では、このような事象を文書化しておくことは重要であるという意見が出され、WGで扱うかどうかをMLにて確認することとなりました。

ここまでで取り上げたトピック以外に、今回の6man WGミーティングでは、次のトピックが議論されました。

近隣到達不可能検知の再送ルールの変更(Neighbor Unreachability Detection is too impatient)
(draft-ietf-6man-impatient-nud)
MS/TPネットワーク上でのIPv6転送
(draft-ietf-6man-6lobac)
IPv6パケットの色付け(staining)
(draft-macaulay-6man-packet-stain)
CGAアドレスにおける複数ハッシュアルゴリズムの追加サポート
(draft-zhou-6man-mhash-cga)
DoSを緩和するための近隣探索機構の拡張
(draft-gashinsky-6man-v6nd-enhance)

それぞれの詳細については、発表資料等をご覧ください。

□ 6man WG
　 https://datatracker.ietf.org/wg/6man/

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

v6ops WG( IPv6 Operations WG)

IPv6に関するオペレーション技術および共存・移行技術に関する議論を実施するWGです。ミーティングは、会議最初の3月26日(月)午前の1コマおよび29日(木)午後1コマの、合計2コマで実施されました。参加者は相変わらず多く、広めの部屋がほぼいっぱいとなっていました。

会議の冒頭にチェアのFred Baker氏より、2012年9月にオランダのアムステルダムで開催されるRIPE 65ミーティングに併催して、IETFの複数WGでの中間ミーティングを開催する予定がある旨報告があり、v6ops WGとしての参加の是非についての確認がありました。特に反対は無かったのですが、賛成もそれほど多くなく、今後のアナウンスが待たれます。

v6ops WGについても、今回議論された項目の中からいくつかのトピックスを取り上げて、次に簡単にご紹介します。

・2012年春WIDEキャンプにおける、移行技術を用いたIPv6 onlyネットワーク実験からの経験 (draft-hazeyama-widecamp-ipv6-only-experience): 2012年3月初めのWIDEプロジェクトの春期キャンプにおいて、各種移行技術、トランスレーション技術をキャンプネットワークで実際に利用した、IPv6実験結果に関する報告です。前回のIETFでの発表に続き、2回目の報告となります。移行技術として、DNS64/NAT64、4rd、464XLAT、SA46Tを利用し、発生したトラブル等をまとめています。議論として、パケットの断片化周りで問題が発生するのは理解できるが、実際の利用としてフラグメントが本当に数多く発生するのか、発生する場合どのようなアプリケーションなのか、といった質問に対し、VPNアプリケーションでは問題になる可能性が高い、といったことや、ドラフトに対して、技術的条件を詳述してほしいという要望が出されました。興味を持っている参加者が多く、継続した報告をしてほしい、といった意見がありました。秋に開催される予定のキャンプでも、引き続き実験をして報告をするとのことです。

・NAT64運用の経験 (draft-chen-v6ops-nat64-experience): NAT64の運用時に発生する課題等の報告です。以前の発表以降に受けたコメント等に対する、対応状況等の説明が中心の報告でした。このドラフトは有効である、という意見が多かったのですが、トピックスとしてどこのWGが扱うか、が議論になり、設立が検討されているv4exit WGが成立すればそちらで、そうでなければv6opsで検討をしていくこととなりました。

・464XLAT：ステートフル・ステートレス変換の組み合わせ (draft-ietf-v6ops-464xlat): IPv6ネットワーク上で、IPv4をサービスする手法として、IPv4/IPv6変換とIPv6/IPv4変換を組み合わせる方式についての提案です。以前、softwire WGで議論されていましたが、v6ops WGに移り、WGアイテムとして扱われています。議論中、利用するIPv6プリフィクスを/96にすべきではない、という意見が出され、それに対応した新たなドラフトが既に出されています。今後の進め方として、チェアより、ドラフトをサービス的観点(BCPステータス)と実証による経験的な観点に分割してはどうか、といった意見が出されましたが、議論の結果、Informationalステータスの文書として進めていくこととなっています。

・IPv6カスタマーエッジ(CE)ルータに対する基本要求仕様 - マルチホームと移行 (draft-townsley-troan-ipv6-ce-transitioning): IPv6対応CEルータの、特に初期設定に関する部分の議論が実施されています。同じプレゼンテーションが、softwire WGでも実施されています。今後、プロバイダーの方式に依存しますが、CEルータが認識しなければならないIPv4/IPv6提供方式は、ds-lateや6rdなどを組み合わせるとかなりの数になってしまうこと、提供されているIPv4/IPv6方式を認識し、設定を自動で実施することは、CEルータベンダーとしては非常に困難であること等が議論されています。特定のプロバイダーが自社サービス向けに提供するような場合では、このような問題が発生する可能性は低いと思われますが、量販店で扱われ、複数の環境での動作が前提となるようなブロードバンドルータベンダーでは、かなり頭の痛い問題となりそうです。

・IPv6カスタマーエッジルータに対する基本要求仕様 (draft-ietf-v6ops-6204bis): RFC6204の改版を目的としたドラフト提案です。前回より引き続き議論されています。マルチホームの際に利用する始点アドレスベースのルーティングに関する記述の是非(記述賛成に多数)や、IPv6ネイティブリンクと6rdの並存に関する議論が実施されました。すぐにでもRFC化してほしいという意見もあり、ミーティングでの議論を反映した改版を実施後、WGラストコールを実施することとなりました。

また、今回のv6ops WGでは、ここまでご紹介したトピックス以外に、次のテーマについても議論が行われました。