ニュースレターNo.41/2009年3月発行

IPv6関連WG報告

第73回のIETFは、2008年11月16日から21日まで、米国ミネアポリスにて開催されました。既にミネアポリスは最高気温がほぼ摂氏0度という気候で、日本に比べてかなり寒く、また、暖房のためか部屋が極端に乾燥しており、体調を崩していた日本の方が非常に多く見受けられました。

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

写真:ミネアポリスの中心部 — 第73回IETFのミーティング会場近辺から見たミネアポリスの中心部

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

IEPGミーティングは、毎回、IETFミーティング開始前の日曜日の午前中に開催されています。IPv6に関連する発表としては、IEPGのチェアであるKurtis Lindqvist氏による、.se（スウェーデン）におけるIPv6利用状況に関する報告、および、Brian Carpenter氏のリナンバリングに関する検討がありました（Brian氏の代理でチェアが発表しました）。

IPv6の利用状況に関しては、このところNANOG等のオペレーターミーティングや、APNICのようなRIRミーティングでもしばしば報告されますが、その多くは現状、IPv6トラフィックはほとんどない、というものです。今回のKurtis氏の発表では、トラフィック量の具体的な値にはあまり触れられませんでしたが、IPv6対応したコンテンツサーバ（ニュースサイト）におけるアクセス状況の分析結果についての報告がありました。このサイトでは、2008年1月から9月までの間に、11,504のアドレスからのアクセスがあり、アクセス手段の内訳は、6to4が83%、ネイティブが10.5%、Teredoが2%となっていること、また、OS種別では、Mac OS Xが52%と多く、WindowsVistaが21%であったとのことです。

この他にも、別なサイトの短期間データも紹介されましたが、トラフィックの大部分はまだまだトンネルプロトコルであることが指摘されています。Kurtis氏は、この原因の一つとして、「xDSLやFTTx等のブロードバンドネットワークにおけるIPv6技術の標準化が十分でない」という意見がオペレーターより寄せられていることを紹介していました。

□IEPGのWebページ: http://www.iepg.org/

6man WG（IPv6 Maintenance WG）

6manワーキンググループ（WG）は、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回は、月曜日の午後最初のコマにて、120名程度の参加者のもと、ミーティングが開催されました。

最初に、チェアから、アジェンダの確認と、WGで扱っている文書について、次の通り現状報告がありました（これらの項目が、IETF73開始時点における6man WGのオフィシャルな議論アイテムとなっています）

前回議論になった重複フラグメントに関するドラフトのWGアイテム化
予約インタフェース識別子ドラフトをIESGにレビュー依頼
IPv6サブネットモデルについては、問題点について議論継続
アドレス選択問題解法ドラフトは、設計チームの結果が出るまで議論停止
ノード要求文書については、今回議論

今回は、

フローラベルの利用方法の提案
IPv6複数アドレス選択に関する報告
ノードに対する要求仕様議論
ルータ広告を利用したDSL回線識別方法の提案
短命IPv6アドレスの提案
IPv6アドレスのステート拡張
ドメイン名を利用したインタフェース選択

のそれぞれの項目について、議論が実施されました。次に、このうち重要な議論について説明します。

2.の「IPv6複数アドレス選択に関する報告」と3.の「ノードに対する要求仕様議論」は前述の通り、6man WGとしての正式な対応アイテムとなっています。2.のIPv6複数アドレス選択に関する議論報告は、前回のIETFでの6man WGミーティングにて設立が決まった、IPv6アドレス選択設計チームの議論報告です。ノードが複数のIPアドレスを持っている場合、通信をする際に使用するアドレスを選択することが必要になります。その際に使用する選択ポリシーを配布する機構について、どのようなタイミングでポリシー配布が必要か、また、どれくらいの頻度で配布することが必要かの検討結果として、多くの場合、頻度的にはそれほど多くなく、また、ネットワーク管理者がポリシー配布のトリガーとなることが多いという報告がありました。会場から、ポリシー配布のみでなく、ベースとなっているRFC3484のアドレス選択機構自体の検討も進めてほしいという意見がありました。今後、配布に使用するプロトコルの検討等、さらに議論を進めていくとのことです。

5.「短命IPv6アドレスの提案」は、IPv6の新たなアドレスとして、アプリケーションが短時間だけ利用する「短命IPv6アドレス」を定義しようという提案です。従来、匿名性等を担保するために、ランダムなアドレスを一定期間利用する、一時アドレス（RFC4941）が定義され、既にWindows Vista等で利用されています。今回提案された「短命IPv6アドレス」は、アドレスの有効期限をさらに短く、アプリケーションが通信する“セッション”毎とすることで、匿名性を向上させ、アドレスが外部に漏れることから発生するセキュリティ問題を防ごう、というものです。発表では、実装して試験をし、問題がないとのことでしたが、会場からは、短時間でアドレスを大量に使用する場合、ルータ等のNDキャッシュへの影響が大きいことや、セッション毎にアドレスが変わるとなると、現在、サーバ側は、同じノードは同じアドレスを使っているという前提で動いているものがあるため、通信のセマンティクスが変わってしまう、といった意見が出されました。

7.の「ドメイン名を利用したインタフェース選択」では、複数のネットワークインタフェースを持ち、別々のネットワークに同時に接続しているノードが通信をする場合、通信先のネットワークを選ぶ際にドメイン名を利用することを提案しています。それぞれのネットワークがDNSサーバアドレスをノードに伝える際、ドメインサフィックスも同時に伝え、そのドメインサフィックスに該当する名前解決、通信は、該当するインタフェース向けに実施しようというものです（日本では、NTT東西の提供するアクセス網にて、同様の技術がアドホックに利用されています）。この提案に対しては、利用用することで実現可能であるといった議論が実施されました。

それぞれの新提案については、継続議論となっています。

□6man WG: http://www.ietf.org/html.charters/6man-charter.html
□第73回IETF 6man WGのアジェンダ: http://www3.ietf.org/proceedings/08nov/agenda/6man.html

v6ops WG（IPv6 Operations WG）

v6opsは、IPv6とIPv4の共存技術、IPv6のディプロイメントに関する話題を扱うWGです。今回は火曜日の午後最初のコマにて、ミーティングが実施されています。参加者は、150名程度に見受けられました。

前回ダブリンで開催されたIETFでは、IPv6/IPv4の共存技術であるIPv6トランスレータに関する議論が長時間にわたって実施されましたが、2008年10月1日と2日にカナダのモントリオールにて開催されたsoftwire、v6ops、behave、intareaの各WG合同のIPv4-IPv6共存中間ミーティングでの議論の結果を受け、実際のプロトコル策定議論は、behave WGとsoftwire WGにて実施されることになりました。

今回は、

不正ルータ広告への対応に関する提案
CPEルータの仕様に関する提案
Teredoの拡張に関する提案
サイト境界ルータ発見プロトコルと経路制御に関する提案
スウェーデンにおけるIPv6利用の紹介
Google社におけるIPv6統計情報の紹介

の六つの項目の議論がありましたが、最後の2点は状況紹介であり、v6opsで扱う議論項目が急に少なくなってしまった感がありました。ここでも、このうち重要な議論について、ご説明します。

セッションは、チェアからのWG文書5点に関するステータス報告から始まりました。WG文書を含め、現在v6ops WGで扱っている内容は、セキュリティに関する話題が多くなっています（上記5点のWG文書のうち3点が、CPEルータ、ルータ広告、トンネル機構のそれぞれのセキュリティに関する検討となっています）。

1.の「不正ルータ広告への対応に関する提案」は、ここ数回議論が続いています。今回議論された対象は、要求条件ドラフトに関するもので、前回のIETFでWGアイテムとして認定された文書の改版です。この要求条件ドラフトと、解法の一つであるRA Guardの双方のドラフトについて、WGラストコールが実施されることになりました（執筆時（2008年12月時点）において、既にMLでのラストコール期間は終了しています）。

2.の「CPEルータの仕様に関する提案」に関しても、ここ数回継続的に議論されています。前回IETFのWGミーティングにおいて、この提案は重要であるとの合意は得られましたが、内容的に不足点が多く、WG文書化は見送られていました。今回の改版で、モデルや環境の追記、不必要と指摘された記述の削除、IPv4からの移行/共存に関する記述の追記等を実施し、WG文書として今後検討を継続することとなりました。3.の「Teredoの拡張提案」は、Teredoを改良し、より多くの種類のIPv4 NAT環境下で動作するようにしたことについて、非常に詳しい解説がありました。こちらは、v6opsで扱う内容を超えるものがあるため、intareaにて議論が継続されますが、v6opsでもWGラストコールがかかる予定です。

5. 「スウェーデンにおけるIPv6利用の紹介」と6. 「Google社におけるIPv6統計情報の紹介」は、IPv6のトラフィック状況などに関する報告です（5.は、IEPGで報告されたものと同じものです）。6.は、Google社のサービス向けのトラフィックからIPv6の普及度合いなどを測定したもので、測定手法の紹介、IPv6浸透の状況について多角的に報告がありました。これによると、IPv6の普及度合いが高いのはロシアやフランスで、日本はかなり下位となっています。私見ですが、日本の普及度合いが低く測定されている原因としては、計測トラフィックの60%程度が6to4であり、IPv6ネイティブアドレスがついている場合や、IPv4グローバルアドレスが端末に直接付与されない場合には6to4機構が利用されないことから、環境的な問題ではないかと思われます。Google社の報告の結論としては、IPv6の普及度は低いものの、増加傾向であること、現状では6to4がIPv6移行プロトコルの主流を占めることが述べられています。

□v6ops WG: http://www.ietf.org/html.charters/v6ops-charter.html
http://www.6bone.net/v6ops/
□第73回IETF v6ops WG のアジェンダ: http://www.ietf.org/proceedings/08nov/agenda/v6ops.txt

behave WG（Behavior Engineering for Hindrance Avoidance）

behaveという名前からはちょっと想像が難しいですが、behaveはIPv4で広く普及しているNATの挙動を定義するワーキンググループです。標準仕様が定義されないままに広く普及してしまったNATにはさまざまな実装があり、NATトラバーサルの処理が複雑化しEnd-to-End通信を阻害してしまうことになるため、NATの実装をBCP（ Best CurrentPractices）として文書化するというのが主な目的です。

今回の第73回IETFの会期中に、behaveのセッションは3回行われました。これまでのbehaveで扱っていたNATに関係する各種提案に加え、2008年10月にモントリオールで行われたIPv4-IPv6共存中間ミーティングで提案されたIPv4とIPv6の共存技術のうち、IPv4-IPv6トランスレーションに関する方式をbehaveで扱うことになったため、三つのスロットを取って議論が行われました。また、中間ミーティングで検討された技術のうち、トンネル方式をベースとしたものはsoftwireにて議論が行われました。

behaveで行われた、IPv6とIPv4の在庫枯渇対策に関係する議論としては以下のものがありました。

IPv4-IPv6トランスレーションに関する提案
draft-baker-behave-v4v6-framework
draft-baker-behave-v4v6-translation
draft-bagnulo-behave-nat64
draft-bagnulo-behave-dns64
draft-vogt-durand-virtual-ip6-connectivity
大規模NATに関する提案
draft-nishitani-cgn
draft-shirasaki-nat444-isp-shared-addr
ユーザー毎に使用できるポートを制限する提案
draft-ymbk-aplusp
draft-bajko-v6ops-port-restricted-ipaddr-assign
draft-boucadair-port-range
draft-despres-sam
draft-boucadair-dhc-port-range
IPv6 NATの提案
draft-mrw-behave-nat66

IPv4-IPv6トランスレータとしては最初に、Fred Baker氏から中間ミーティングでの議論の結論として、NAT64方式とIVI方式が統合されてトランスレーション方式のベースとなり、トランスレーションに関する機能毎にドキュメントを分割して検討していくという、トランスレーション方式の検討のフレームワークについて説明がありました。ドキュメントとして、全体のフレームワークについて記述したドラフト、パケットの変換ルールを規定したSIIT（RFC2765）の更新について記述したドラフト、ステートフルアドレス変換方式への拡張（今のところIPv6からIPv4への変換方式のみ）について記述したドラフト、DNS ALGでのアドレス合成について記述したドラフト、そしてその他の要素（FTP ALG等）について記述したドラフトという構成になっています。

アドレス変換方式に関する議論としては、対象とするトランスポートプロトコルがTCPやUDPだけになっているが、SCTP、DCCPやIPSecなどの新しいプロトコルは考慮しなくていいのかという質問がありましたが、SCTP、DCCPやIPSecなどのプロトコルは変換方式についての議論が尽くされておらず、別のドラフトとして進めるという意見が大勢を占めました。

大規模NATに関してはKDDI株式会社の中川あきら氏より発表があり、4-4NATや6-4NATなど各種のアドレス変換をISPや企業網で利用する場合に共通して必要となる機能を整理した提案と、4-4-4NATすなわち、IPv4 NATを2回行うモデルに関する提案がありました。また、この4-4-4モデルを利用する際の、ISPの空間で利用するアドレスについて、本提案ではISPで共有できるアドレスブロックの新設を提案しており、その議論はintareaのセッションにて別途行われました。

同じくIPv4アドレス在庫枯渇に関する技術として、ユーザーにIPv4グローバルアドレスを付与するが、利用できるポート範囲を制限するというA+Pと呼ばれる方式がRandy Bush氏より提案されました。本方式のメリットとしては、ユーザーがISPのNATの配下に収容されるのではなく、利用は制限されるものの、あくまでグローバルIPv4アドレスがユーザーに付与されるため、End-to-Endの透過性が保持されるというものです。しかし、ISP内でのルーティングや、ユーザーが使用しているルータや時には端末への変更が必要であり、実際に利用するにはクリアすべき障壁の多い方式になっています。

また、3回目のセッションではMargaret Wasserman氏とFred Baker氏より、NAT66、つまりIPv6からIPv6へのNATに関する発表がありました。IPv6の設計思想の一つとして、IPv4で現在広く使用されているNATを使わないようにする、というものがありましたが、本提案の趣旨としては、IPv6においてもなおNATを必要とするケースがあることから、IPv6NATを実装し利用する人々が出てくることは不可避であり、そこでIETFとしてはIPv4 NATのような標準仕様のない混沌とした状況を生み出さないためには、IPv6 NATの標準仕様を策定する必要がある、という論調になっています。

具体的な適用先としては、企業ネットワークなどが挙げられ、特にネットワーク間を接続する際にトポロジーの隠蔽が必要であり、双方向のNATが必要である、などの提言がありました。NATを利用しないためにIPv6を標準化し、普及を推進してきたIETFとしては、非常に重要なトピックであり、さまざまな議論が交わされました。否定派の意見としては、IETFでNAT66がRFCになることで、NAT66の普及を促進してしまうのではないか、IPv6でのセキュリティ実現方法について記述したLNP（RFC4864）でカバーできているのではないか、といった意見がありました。その場でのディスカッションでは、肯定否定というのではなく慎重派が多いように見受けられましたが、結論としては本提案内容をベースとして議論を継続することになりました。

□v4v6interim: http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
□behave WG: http://www.ietf.org/html.charters/behave-charter.html
□第73回IETF behave WGのアジェンダ: http://www.ietf.org/proceedings/08nov/agenda/behave.html

intarea（Internet Area Open Meeting）

先にbehaveの項でも触れましたが、ISP等でNATを行う場合にNAT配下で利用するアドレスとして、ISP共有アドレス（ISP Shared Address）の新設に関する提案がKDDI株式会社の中川氏よりありました。NAT配下で利用するアドレスとしては、RFC1918で定義されるプライベートアドレスを利用することが一般的ですが、ISPでこのアドレス空間を使った場合に、ユーザーが設置するNAT装置配下で利用するアドレス空間とバッティングする可能性があり、通信障害が発生するため別のアドレスブロックが必要であること、またISP共有アドレスとしてどの程度の大きさのアドレスブロックが必要か、などの説明がありました。この提案に関する議論としては、現在利用されていないクラスE（240/4）の空間を利用してはどうか、ISPによっては際限なく大きなアドレス空間を要求するのではないか、ISP共有アドレスを利用している複数のISPマルチホームしている場合にはやはり通信障害が発生するのではないか、といったものがありました。その場の結論としては、メーリングリストで継続して議論を行うということになりました。

また、これらのIPv4アドレス在庫枯渇、IPv6への移行といった一連のトピックに関して、今回の第73回IETFと次回のIETFとの間に、マルタ島にて中間ミーティングを開催して集中議論を行うことが計画され、参加者数の調査などが行われていたのですが、3回目のセッションにおいて、マルタ島での中間ミーティングはキャンセルになったことが発表されました。中止の理由としては十分な参加者数が期待できないことが主だと思われますが、場所を移して中間ミーティングが行われるかもしれないとのことでした。