ニュースレターNo.40/2008年11月発行

IPv6関連WG報告

2008年7月27日（日）から8月1日（金）まで、アイルランドのダブリンにて、2008年夏のIETFが開催されました。ダブリンは日本に比べ、かなり涼しく過ごしやすかったのですが、会場および投宿ホテルがダブリン郊外のゴルフリゾートであり、食事等でダウンタウンまで出るのにバスで30分ほどかかるため、場所的には少々不便を感じました。

本稿では、会期中に議論された、IPv6に関連したトピックスをいくつか紹介します。

IEPGミーティング（Internet Engineering and Planning Group）

IETFミーティングは、正式には日曜日の正午から始まります。IEPGミーティングは毎回その直前、日曜日の午前中に開催されています。

今回は、IPv6に直接関係のあるトピックスとしては、APNICのGeorge Michaelson氏が発表した6to4のDNS逆引きサーバの登録状況紹介のみでした。6to4は、IPv4からIPv6への移行プロトコルとしてIETFで標準化され、Windows XP以降やApple社のAirMac Extremeに実装されています。このプロトコルを用いることで、IPv6 over IPv4トンネルを利用し、IPv4のみの環境からIPv6インターネットにアクセスすることができます。この発表では、6to4のDNS逆引き登録状況について紹介があり、2005年初頭に始まったこの試行サービスの登録数は線形に増加しており、現在は900以上の登録があること、米国、欧州が大部分を占めていることが述べられました。6to4は、IPv4からIPv6への過渡期に利用される移行プロトコルの一つではありますが、Windows OSに実装されたこともあり、実際の利用者は多いと思われます。

その他、IPv6には直接関係はありませんが、Randy Bush氏より、ISP網に導入される可能性のあるキャリアグレードNAT（CGN）について、否定的な見解が述べられました。CGNは、IPv4アドレスの在庫枯渇に対する一つの対応方法として検討が進められており、今回のIETFでも実装方法の提案や、導入に関するプレゼンテーションが実施されています。

□IEPGのWebページ

http://www.iepg.org/

6man WG（IPv6 Maintenance WG）

6manワーキンググループ（WG）は、IPv6のプロトコル自体のメンテナンスを実施するWGです。チャーターには、「IPv6プロトコルに対するマイナーな変更のみ扱う」、と明記されています。今回は、水曜日の午前中にミーティングが開催されましたが、6man WGのチェアでIPv6プロトコルの提案者の一人として有名なRobert Hinden氏は、所用により欠席で、もう一人のチェアである Brian Haberman氏が全て取り仕切るミーティングとなりました。

今回の議題は、

PMIP6 向けのルータ広告改訂（PMIP6 Indication and Discovery）

draft-damic-netlmm-pmip6-ind-discover

IPv6 複数アドレス選択およびRFC3484の改訂

draft-arifumi-6man-rfc3484-revise
draft-6man-addr-select-sol

ルータ広告のMフラグとOフラグの扱い

draft-cha-ipv6-ra-mo

断片化ヘッダの問題（Overlapping Fragments）

draft-krishnan-6man-overlap-fragment

拡張ヘッダの標準フォーマット

draft-krishnan-ipv6-exthdr

の5点、となっています。

「PMIP6向けのルータ広告改訂」は、現在netlmm WGで標準化の進んでいるPMIP6（Proxy Mobile IPv6）に関連し、ネットワークがPMIP6をサポートしているかどうかを判断するために、IPv6のルータ要請/広告に手を入れたい、という提案です。これに対して、今後提案される可能性のある、いろいろなプロトコルについてアドレス割り当てレベルで機能を導入するようなことは困難であるという指摘等がありました。この提案は、6man WGのミーティング時点ではnetlmm WGでもまだ議論中ということであり、そちらでの議論が終わり、本提案の内容にnetlmm WGとして合意が得られた時点で再度検討することになりました。

「IPv6複数アドレス選択およびRFC3484の改訂」では、アップリンクから割り当てられた複数のIPv6アドレスを持つノードにおいて、通信の際に通信相手に応じた適切なIPv6アドレスを始点アドレスとして選択する機構に関する議論および、現在標準化されているアドレス選択に関する標準であるRFC3484の改訂に関する議論が実施されました。これは、RFC3484には、ノードが複数IPv6アドレスを保有する場合や、通信相手が複数のアドレスを持つ場合に、どのアドレスを利用するかの選択アルゴリズムが記述されていますが、標準化当初にデフォルトとして定義された条件が、その後追加定義されたULA等の新たな特殊用途アドレスに対応していない、等の問題点が指摘され、現在の状況に合わせて改訂しようというものです。また、あらゆる環境をカバーするような条件を作ることは不可能なため、デフォルトを変更するためのアドレス選択ポリシーを配布しよう、という提案に関しても議論されました。その結果、アドレス選択条件を動的に変更できるようにすることが必要だ、という合意が得られ、今後、アドレス選択ポリシーの配布をどのように実施するかを検討するチームを作り、議論を実施することになっています。

「ルータ広告のMフラグとOフラグの扱い」は、ルータ広告メッセージ中の、アドレス割り当て方式を制御するビットの扱いに対する改訂の提案です。MフラグとOフラグの扱いについては、6man WGの前身であるIPv6 WGでもかなり長い間議論され、現在の仕様に落ち着いた、という経緯があります。議論の中で、提案者が述べている問題が、本当に一般的な問題で多くの人が困る事象なのか、どこまでが仕様で、どこからが実装に依存するものであるのかの線引きの問題ではないか等の意見が出されました。この両フラグについて、問題を明確にするために、メーリングリストで議論を継続することとなりました。

「断片化ヘッダの問題」は、IPv6の拡張ヘッダの一つである断片化ヘッダに、IPv4の断片化でも問題になった、“重複断片の扱い（Overlapping fragments）”に関するセキュリティ的問題があるため、この対処が必要というものです。IPv4におけるこの問題は、RFC1858に述べられています。同様の問題がIPv6でも起こることはRFC4962に書かれていますが、現状、対処がなされておらず、また、IPv4で起こりうる問題よりも、IPv6の方がより深刻であるということが指摘されました。この問題に早急に取り組むことになり、提案ドラフトをWGアイテムとすること、および早急にRFC2460の改訂を図る方向で進めることになりました。

「拡張ヘッダの標準フォーマット」は、IPv6拡張ヘッダは、基本フォーマットが定義されておらず、新規に定義された場合には、既存実装では拡張ヘッダのサイズがわからない可能性があるという問題についてです。これを防ぐため、標準的な、TSVフォーマット（Type/Size/Value）を導入しようというものです。前回のIETFに引き続き議論されました。メーリングリストでも多くの意見があり、それらに対応してドラフトがアップデートされましたが、標準フォーマットを決めることの意義や、ヘッダ設計の概念的な部分に踏み込んでしまう可能性、また、決めたとしても、それをどのように周知していくのか等の指摘がなされました。ミーティングでは、賛同が多く、メーリングリストで意見を募集し、WGとして引き続き検討していく方向となっています。

□6man WG

http://www.ietf.org/html.charters/6man-charter.html

□第72回 IETF 6man WGのアジェンダ

http://www3.ietf.org/proceedings/08jul/agenda/6man.html

v6ops WG（IPv6 Operations WG）

v6opsは、IPv6とIPv4の共存技術、IPv6のディプロイメントに関する話題を扱うWGです。今回は一コマのミーティングを予定していましたが、直前に一コマ追加となり、月曜日の午前中と、木曜日の午後一番の2スロットで議論が開催されました。

一コマ目のミーティングでは、NAT-PTに代わるIPv6の移行技術に関する話題、IPv6のCPEルータに対する要求条件の話が実施されました。前回と同様、NAT-PTに代わる技術は多くの人がIPv6の導入に必要だと考えているためか、参加者が非常に多く、用意された席数では足りず、立ち見が出てしまうほど盛況なセッションでした。前回のミーティングにて、v6ops WGでは移行プロトコルに対する要求条件を中心に扱う方向になっており、今回のミーティングでも要求条件の議論に多くの時間を費やしました。IPv4/IPv6のプロトコル変換機構が持つべき必須の基本機能、推奨機能に関する提案として、既存ノードへの変更許容の是非、ネイティブ接続の優先、DNSとの連携時におけるDNSのセマンティクス変更不可、サポートする上位層プロトコル、NATの標準化を実施する、behave WGの定義した要求条件への準拠の必要性などについて議論されましたが、意見が百出し、議論時間が足りず、メーリングリストで引き続き議論を実施することとなりました。

この他にIPv6を利用したIPv4 NATを実施するプロトコルとして、

• draft-despres-v6ops-apbp（GAPプロトコル）
• draft-durand-dual-stack-lite（464変換）

について、概略の説明が実施されました。それぞれ、プロトコル自体は別WGで議論をすることになります（behave WGにて、IPv4/IPv6変換プロトコルについての提案が実施され、議論されています）。

IPv6のCPEルータに対する要求条件は、ケーブルTVネットワークにおけるケーブルモデム/ホームルータの標準である、eRouter仕様に対応するようなIPv6 CPEルータの仕様を記述することを目的とした提案です。CPEルータの持つべき機能として、ISPとの接続機能、ファイアウォール機能、宅内機器へのアドレス付与機能等があげられています。ミーティングにおいて、このようなドキュメントの必要性についてはコンセンサスを得られましたが、ドラフト自体にはまだ不足点も多く、引き続きメーリングリストで議論を実施することになりました。

二コマ目のセッションでは、一コマ目に予定されていましたが時間切れで先送りされたルータ広告に関するセキュリティの議論、アドレス割り振りのガイドライン（RFC3177）に関する議論、トンネルプロトコルのセキュリティに関する議論、および、ブロードバンドネットワークにおけるIPv6実装に関する議論が実施されました。

不正なルータ広告の扱いに関する議論は、ここ数回継続して実施されています。今回は、不正なルータ広告の扱いに関する要求条件ドラフトと、それに対する解としてのRA Guardについてのプレゼンテーションが実施されました。要求条件ドラフトに対しては、過去にあった不正なDHCPサーバや、不正な無線アクセスポイントに関する議論を参照するとよい、といったコメントがありました。不正なルータ広告に関するドラフトは、今後v6opsのWGアイテムとして議論されることになり、RA Guardに関してはRFC化に向けてWGラストコールをかけることになりました。この他、アドレス割り振りのガイドラインについては、前回議論が再開され、今回v6opsのWGアイテムとして検討を実施することとなりました。また、トンネルプロトコルのセキュリティについては、前回までTeredoのセキュリティ、として提案されていたものをトンネル一般の話として書き直したため、IPv6に特化した内容でなくなりました。そのため、今後v6opsでなくintareaにて議論を継続することになりました。最後に、ブロードバンドフォーラムとのリエゾンとして、ブロードバンドネットワークにおけるIPv6実装についてのプレゼンテーションがあり、この内容についてはメーリングリストでコメントを募集することとなりました。

今回のv6ops WGは議論の内容が多岐にわたり、それぞれ非常に活発に議論され、多くがメーリングリストでの継続議論となっています。IPv4アドレス在庫枯渇に関連して、IPv6への注目が高まっていることがうかがえました。

□v6ops WG

http://www.ietf.org/html.charters/v6ops-charter.html
http://www.6bone.net/v6ops/

□第72回 IETF v6ops WG のアジェンダ

http://www3.ietf.org/proceedings/08jul/agenda/v6ops.html

この他に、IPv6への移行に関し、全体セッションでもパネル討論が実施されています。

第72回IETFミーティングの各種情報は、以下のURLより参照可能です。

□全体プログラム、WGアジェンダ、発表資料

https://datatracker.ietf.org/meeting/72/materials.html
(2009年4月16日現在、 http://www.ietf.org/proceedings/08jul/ に移動)

□録音

http://videolab.uoregon.edu/events/ietf/
(2009年4月16日現在、 ftp://videolab.uoregon.edu/pub/videolab/media/ietf72/ に移動)

（NTT情報流通プラットフォーム研究所/JPNIC IPアドレス検討委員会メンバー 藤崎智宏）