ニュースレターNo.48/2011年7月発行

第80回IETF報告(2011.3.27～4.1)
IPv6関連WG報告

2011年3月27日(日)から4月1日(金)まで、チェコのプラハにて第80回IETFミーティングが開催されました。東欧の古都であるプラハでの開催は2007年春に続き、2回目となります。会期中のプラハは日本より暖かかったため、帰国後、日本がかなり寒く感じられました。参加人数については、49ヶ国より1,229名(新規参加173名)と発表されています。国別の参加人数内訳では、従来は日本からの参加者は人数の多い順で、2番目であることが多かったのですが、今回の震災の影響と、年度をまたがるという事情もあってか、日本からの参加者は減少し、米国、中国、ドイツに続いて日本、フランスという順番でした。

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

6man WG (IPv6 Maintenance WG)

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回は、会議開始直後の3月28日(月)の朝に開催されました。

議事録担当、アジェンダ確認等の後、6man WGで取り組み中である以下の文書のステータス報告がありました。

P2Pリンク上におけるIPv6プリフィクス長/127の利用
→ RFCエディタによる発行順番待ち(その後、RFC6164として発行済み)
RPL(低電力高損失ネットワーク用のIPv6ルーティングプロトコル)用の情報伝達オプション、RPL用経路制御ヘッダ
→ Proposed Standard(標準化への提唱)に向け、IESG(Internet Engineering Steering Group)に送付
IPv6ノードの要求仕様改版、トンネルにおけるECMPとリンクアグリゲーションでのIPv6フローラベルの利用
→ WGラストコール終了
IPv6フローラベル仕様、IPv6フローラベル仕様更新理由
→ WGラストコール中(現在は終了)

また、今回議論されたアジェンダの中から、いくつかのトピックについてご紹介します。

1. フローラベル仕様の更改について: draft-ietf-6man-flow-3697bis
draft-ietf-6man-flow-update
draft-ietf-6man-flow-ecmp

IPv6の特徴の一つとされているフローラベルの利用について、現在の仕様であるRFC3697を改版し、より使いやすいようにしようという提案です。IPv6トンネルを利用してECMP (Equal-Cost Multi-Path routing)やLAG (Link AGgregation) を実施する場合の、フローラベルフィールド利用方法も併せて提案しています。ドラフト中の文言の見直し、およびラストコールコメントを反映して改版をすることになりました。
2. IPv6拡張ヘッダの統一フォーマットについて: draft-ietf-6man-exthdr

議論が続いているIPv6拡張ヘッダの標準フォーマットを決めようという提案です(6年間も議論しているという紹介もありました)。前回からの差分として、文書としてはIPv6拡張ヘッダのフォーマットに関する記述のみに特化したこと、新しい拡張ヘッダを定義する際には、終点オプション(destination option)の利用を推奨し、そうでない場合には明確な理由を必要とするという規定を加えたとの説明がありました。これは、新しい拡張ヘッダの追加は既存実装へのインパクト(特に性能面)が大きいという意見があったため、この文書は新しい拡張ヘッダ定義の追加を推奨するものではなく、既存の拡張ヘッダの枠組み内で新規機能の追加を勧めるためです。特にコメントはなく、WGラストコールを実施することとなりました。
3. RFC3484 IPv6デフォルトアドレス選択の更新について: draft-ietf-6man-rfc3484-revise
draft-ietf-6man-addr-select-opt

Pv6ノード、および、通信相手が複数のアドレスを持つ場合に、通信に使うアドレスペアを選択する仕様であるRFC3484に関する改版提案です。前回の議論を受けた改版の後、ULA(ユニークローカルIPv6アドレス)とプライバシー拡張の扱いが残課題となっているとの説明があり、この2点が議論になりました。プライバシー拡張を制御しようとする場合にはセキュリティに十分気をつける必要があることや、ULAのプライオリティを制御する必要性などについてのコメントがありました。コメントを反映後、WGラストコールを実施することになりました。
4. IPv6ノードの要求仕様 RFC4294の改版について: draft-ietf-6man-node-req-bis

IPv6ノードが持つべき機能(実装が必要な機能)を定義した仕様であるRFC4294の改版です。WGラストコールを受けて修正した点の確認、MLD (Multicast Listener Discovery)に関して追加した部分に対する意見照会がありました。RFC化された文書のみ取り込むことにしていますが、現在取り組んでいるドラフトなどをどこまで取り込むかの議論がありました。しかし、ドラフトまで取り込むときりがないと判断され、現在RFC化された文書のみを取り込み、現時点で次のステップ(IESG送付、IETFラストコール)に進めることとなりました。
5. IPv6ステートレスアドレス自動設定におけるプライバシー拡張機能の管理について: draft-gont-6man-managing-privacy-extensions

提案者が不在で、急きょ、代理人(Tim Chown氏)によるプレゼンテーションが実施されました。現在、IPv6ステートレスアドレス自動設定(SLAAC)によりノードが自動生成するアドレスがまちまち(EUI64ベース、プライバシー拡張ベース、ランダム、その他)なため、それを制御する方式についての提案です。ルータ広告(RA)を利用した制御を想定しています。コメントとして、プライバシー等のセキュリティに関連する制御を実施するのに、RAは完全には信用できないので問題であるという点や、SLACCのみの変更では不十分であること、問題の本質はどこにあるのか検討する必要があること等が挙げられました。

前回の北京では、ミーティング時間に対して議題が非常に多く、十分に議論しきれなかったのですが、今回は議題の数が少なく、予定時間よりかなり早くWGが終了しました。

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

写真:会場となったHilton Prague — 会場となったHilton Prague(ホテルの公式Webサイトより引用)

v6ops WG (IPv6 Operations WG)

v6opsは、IPv6に関するオペレーション技術、および、共存・移行技術に関して議論するWGです。今回は、2011年3月31日(木)に、朝一と最終コマの2コマにて議論が行われました。

今回は、合計19件という非常に数多くの提案が挙がっていました。まず、ミーティングの冒頭でチェアより、v6ops WGのミーティングで発表時間を割り当てる議題の決め方に関する提案がありました。このところv6ops WGには非常に提案が多く、前回もコンセンサス確認をミーティング内でなく、事後にオンラインで実施する等で効率化を図り、多くの議題を扱えるようチェアが工夫をしていました。

しかし、それだけでは対処するのが困難な量の提案が継続的に挙がっているため、

基本的に、WG文書の議論に時間を優先的に割り当てる。
新規提案は、まずMLで議論し、参加者の興味度合いを確認。ミーティングの際、どの提案をプレゼンテーションしてもらうかは、議論状況によってチェアが決める。

ことで、取り扱う提案を選別し、議論時間を確保しようという提案です。賛成が多数であったため、次回からはこのポリシーで運営されると思われます。

今回議論された、いくつかのトピックについて、簡単に紹介します。

IPv6利用時に発生する通信問題について

今回、ミーティングの最初の時間に、‘IPv6 Brokenness’に関係する項目が連続して発表され、議論も行われました。‘IPv6 Brokenness’とは、IPv6を導入した際に発生する通信障害全般を指し、例えば、IPv6/IPv4デュアルスタック環境でIPv6接続性に問題があった場合に、IPv4にフォールバックするのに時間がかかる、という問題等がこれにあたります。

(1) IPv6接続性に問題がある際のホストの動作: IPv6からIPv4にフォールバックするのにかかる時間や、不正RAの影響、IPv6 Brokennessに対する解としての、Happy Eyeballs機構の有効性について報告がありました。
(2) Happy Eyeballsの実装レポート: 複数のTCPセッションを同時にスタートし、最初に通信できたセッションを利用することでフォールバックを回避する機構である、Happy Eyeballsの実装レポートです。ドラフトで定義されている機構の問題点、改善提案が実施されました。
(3) デュアルスタックサービスの性能に関する実験結果: デュアルスタックWebサーバに対するユーザーアクセス統計の紹介がありました。現状、IPv6による接続性の品質はIPv4の品質に劣ることや、6to4等のトンネルからの接続失敗が多いこと、デュアルスタックにした場合に、アクセスができなくなるユーザーが存在すること等が報告されました。
(4) Happy Eyeballs:デュアルスタックホストにおいて通信を成功させるために: draft-wing-v6ops-happy-eyeballs-ipv6
Happy Eyeballsの仕様について、議論されました。前回からのアップデートとして、SRCレコードの扱いに関する記述の追加、複数インタフェース対応等を追記したこと、より多くの実装例とAPIの必要性などについて報告がありました。会場から、複数セッションを同時に張る場合のサーバ側の負荷や、TCP RSTの返答が増えることの影響、TCPセッションの数を極力少なくするための、キャッシュをはじめとした機構の必要性が意見として挙げられました。

NAT64アプリケーション評価について
draft-tan-v6ops-nat64-experiences

NAT64のアプリケーションに対する影響評価の報告がありました。評価の対象はBehave WGで標準化の進んでいるNAT64 (ietf-behave-v6v4-xlate-stateful)ですが、現状、実装が存在しないため、同等の動きをすると思われるNAT-PTデバイスにて多くのアプリケーションの動作を検証、問題点を整理しています。会場からのコメントとして、このような評価は重要であり引き続き実施してほしい、評価だけでなく、発見された問題点を吟味し、必要ならば解決することが重要である、NAT44との違いはどこにあるかの検討が必要である、等が挙げられています。

World IPv6 Day参加招集(World IPv6 Day Call to Arms)について
draft-chown-v6ops-call-to-arms

2011年6月8日にWorld IPv6 Day^※として、サービスのIPv6対応を実施しようという呼びかけが世界的に行われています。この呼びかけをさらに広めること、また、IPv6を導入した場合に発生する可能性のある問題、およびWorld IPv6 Day実施にあたって情報収集の必要性を指摘することを目的とした発表が行われました。会場からは、Webサービス提供者からのユーザーの接続性に問題が発生すると困るといった意見や、6to4は使わないようにすべき、問題が発生したという情報が収集できるのか、といったコメントが出されました。実際に、IPv6導入時の問題を検証することは重要であることは多くの人が同意するものの、現在のインターネットサービスへの影響が計り知れないことによる懸念の声も多く、World IPv6 Dayについては今後とも注視していく必要がありそうです。

6to4に関する議論について

IPv6移行プロトコルとして定義されている、6to4について議論がありました。6to4は多くの実装が存在し、IPv6の接続として広く利用されていますが、品質が保証されない、パケット盗聴などのセキュリティ問題が起こりやすい、といった問題が指摘されています。IPv6をサービスとして普及させていくために、今後6to4をどうしていくべきかについて、次の3件の提案が実施されています。

(1) 6to4を利用する際のガイドライン: draft-carpenter-v6ops-6to4-teredo-advisory

6to4を利用する場合の運用、実装に対するガイドラインについての提案がありました。6to4のリレールータをしっかり管理することの必要性や、OS等で6to4を実装する場合の注意点(6to4の使用優先度をRFC3484に従うようにすべき等)について述べています。
(2) プロバイダー管理の6to4: draft-kuarsingh-v6ops-6to4-provider-managed-tunnel

NAT66と組み合わせることで、6to4の実装をそのまま利用し、プロバイダーが管理する6to4を実現する提案です。CGN (Carrier Grade NAT)と組み合わせることも想定しています。
(3) 6to4を「歴史的」ステータスに変更する提案: draft-troan-v6ops-6to4-to-historic

通信品質等、多くの問題が指摘されている6to4ですが、プロトコルとしての6to4を「歴史的」ステータスにし、利用をやめようという提案です。6to4自体の定義であるRFC3056と、6to4用のエニーキャストを定義しているRFC3068のステータスを変更することが提案されています。

ミーティングでは上記3件のプレゼンテーション終了後、6to4をどうしていくかの議論があり、結果として、(1)、(3)をWGとして継続的に議論していくことになりました。(3)がWGアイテムとして採択されたことにより、将来的に、6to4は利用されなくなると思われます。