ニュースレターNo.43/2009年11月発行

IPv6関連WG報告

スウェーデンの首都ストックホルムにて、2009年7月26日から31日まで、第75回のIETFが開催されました。世界的な景気の低迷、および米国以外での開催ということで、今回も参加人数の減少が懸念されていましたが、前回のサンフランシスコとほぼ同数の1,124名の参加となりました。また、国別の参加人数は、日本を抜いて中国が第2位となっています。会議中も多くのワーキンググループ(WG)で、中国の方がプロトコルの提案をしたり、活発に意見を述べる等、目立っている印象がありました。

本稿では、IPv6に特化した内容を議論するWGでの話題を中心に紹介します。

6man WG(IPv6 Maintenance WG)

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回のミーティングは、水曜日の午後最初のコマにて開催されました。

まずは、いつもの通り、チェアより今回のミーティング議題の確認および、WGで取り組み中の四つの文書(フラグメント重複問題、ノード要求仕様、アドレス選択解法、IPv6サブネットモデル)に関する状況紹介がありました。また、このうち、ノード要求仕様、アドレス選択解法の二つについては、議論も実施しました。

今回のミーティングでは、

1.ノード要求仕様文書に関する議論: (draft-ietf-6man-node-req-bis)
2.ルータ広告メッセージにおける回線識別子: (draft-krishnan-6man-rs-mark)
ノード広告メッセージにおける回線識別子
(draft-li-6man-ns-mark)
3.IPv6アドレスのテキスト表記方法: (draft-kawamura-ipv6-text-representation)
4.UDPのトンネルトランスポートモード: (draft-fairhurst-6man-tsvwg-udptt)
5.アドレス選択問題について: アドレス選択ポリシー間の矛盾解決
(draft-arifumi-6man-addr-select-conflict)
6.アドレス選択デザインチーム議論報告: (draft-chown-addr-select-considerations)

といった内容が議論されています。

上記のうち、1、2、3、5につき、簡単に紹介します。

1.ノード要求仕様文書に関する議論

RFC4294として発行されている、IPv6ノードの要求仕様文書に関する改版提案に対する議論です。しばらく議論が止まっていましたが、近頃、再開されています。CPEルータのような、ルータとしてもホストとしても動作するノードをどう扱うかといった問題や、MIPv6の経路最適化を「SHOULD(すべき)」としている現在のRFCの記述は、経路最適化の実装が少ないことなどから適切でない、といった意見が出されました。また、この文書の位置付け(ステータス)に関する議論も実施されています。元のRFC4294は「Informational」というステータスですが、これをより強いものにすべきではという意見がある一方、他のRFCで規定されている以上の制限を付けるべきではないという意見もあり、内容とは独立して議論を実施することになっています。

2.ルータ広告メッセージにおける回線識別子／ノード広告メッセージにおける回線識別子

一部のADSL等では同じセグメント上に複数の顧客が存在することがあり、顧客ごとに別の広告メッセージを返答することができないため、メッセージを識別するための回線識別子オプションを新設しようという提案です。これに対し、ユニキャストの広告メッセージは使えないのか、CPEルータを設置してDHCPv6-PDを使用すべきだといった意見や、そもそも同じセグメント上に複数の顧客が存在するようなモデルがおかしいのであり、VLANで顧客ごとにセグメントを分けるトンネルリンクを使用するといった手法を採るべきだ、という環境自体に対する意見等、提案に否定的な意見が多く出されました。

3.IPv6アドレスのテキスト表記方法

IPv6アドレスの表記方法はRFC4291で規定されていますが、現在の規定では、同じアドレスが複数の別表記で記述可能となっています。このためテキストデータやアドレス管理表から特定のアドレスを検索する場合や、電話サポート等でアドレスを知らせる場合に誤解が起こる可能性があるため、表記方法を統一しようという提案です。2009年7月に開催されたJANOG24や、JPOPM16でもプレゼンテーションがありました。趣旨に同意する意見が多く、会場ではWGとして取り扱うべきだという意見が多数を占めました。そのため、MLにて、WG文書として扱うべきかの合意を確認することになりました(2009年8月10日現在、ML上で数名の賛同が得られています。)

5.アドレス選択問題について(アドレス選択ポリシー間の矛盾解決)

前回、前々回のIETFに引き続き、IPv6ホストがアドレスを複数持っている場合の、アドレス選択のあり方について、その検討状況の報告がありました。今回は特に、複数の上流から矛盾するアドレス選択ポリシーが配布された場合に、そのポリシーをどうマージするかに特化した提案が実施されました。時間の関係で、議論はそれほどできませんでした。こちらの提案についてもチェアから参加者に対して、WGとして取り組む必要のある内容かとの問いかけがありましたが、提案ドラフトを読んでいる人の数が多くなかったため、MLにて確認をすることになりました。

□6man WG: http://www.ietf.org/dyn/wg/charter/6man-charter.html
□第75回 IETF 6man WGのアジェンダ: http://www.ietf.org/proceedings/75/agenda/6man.html

v6ops WG(IPv6 Operations WG)

v6ops WGは、IPv6に関するオペレーション技術や、移行技術に関する議論を実施するWGです。以前のダブリンでのIETFから、移行技術の標準化についての議論はbehave WGで実施されることになり、内容が薄くなるかと思われました。しかし、今回は火曜日の午後全ての時間(3コマ)を埋めるほどの提案があり、引き続き活発な議論が実施されました。

今回の議論内容は、次のようになっています。

1コマ目：ディプロイメントに関する問題

Internet Exchange(IXP)でのIPv6ディプロイメント(draftietf-v6ops-v6inixp)
IPv6サービスとIPv6/IPv4間通信を実現するハイブリッドISPフレームワーク(draft-xu-v6ops-hybrid-framework)
IPv6移行のための段階的キャリアグレードNAT(CGN)導入(draft-jiang-v6ops-incremental-cgn)
Teredoクライアントに対するICMPv6エコー応答生成(draftdenis-icmpv6-generation-for-teredo)
非決定的なIPv6トンネルの弊害(draft-vandevelde-v6opsharmful-tunnels)
IPv4サービスプロバイダネットワークでのIPv6提供(drafttownsley-ipv6-6rd)

2コマ目：CPEルータに関する問題

家庭向けIPv6インターネットサービス提供用CPEにおける簡易セキュリティ推奨機能(draft-ietf-v6ops-cpe-simple-security)
IPv6 CPEルータのユースケースと要求仕様(draft-donleyipv6-cpe-rtr-use-cases-and-reqs)
IPv6 CPEルータ推奨機能(draft-ietf-v6ops-ipv6-cpe-router)

3コマ目：その他の問題

IPv4とIPv6のGreynets(draft-baker-v6ops-greynet)
IPv6エニーキャストを利用した負荷分散と疑似モビリティ(draftluo-v6ops-6man-shim6-lbam)

この中で、1コマ目、2コマ目の議論内容について紹介します。

1コマ目の「ディプロイメントに関する問題」セッションでは、IPv6導入モデルに関する提案、移行プロトコルや移行技術に関する提案／問題が議論されました。

IXPにおけるIPv6導入モデルでは構築例として、/47相当の空間を取得し、片方の/48をグローバルインターネットに経路広告せずに、IXP内部的に利用する方法に関しての議論等がありました。IXP文書はレビュー後、WGラストコールが実施される予定です。また、ISPにおけるIPv6導入手法として、IPv4/IPv6変換の導入や、CGNの導入とIPv4上でIPv6をトンネルで提供する手法から、IPv6上でIPv4を提供するモデルへの移行といったモデルの提案等が実施されました。現在、変換プロトコルはbehave WGで、トンネルプロトコルはsoftwire WGで議論されていることもあり、この文書をv6ops WGで扱うべきかという議論になりましたが、WGの文書として議論を継続することになっています。

写真:次回IETFのブース — 会場内に設置された次回IETF(広島開催)のブース

Teredoに関する問題提起では、Teredoは通信確認にICMPv6を利用しており、IPv4/IPv6トランスレータが入った環境や、ファイアウォール等でICMPv6が落ちた場合に通信できなくなるため、その改善提案が行われました。これに対しては、Teredo通信より、IPv4通信を優先するべきである等の意見が出され、ML上で継続議論になりました。また、Teredoのようなトンネルを用いてIPv6通信を実現している場合に、そのトンネルが複数のプロバイダをまたいだりする際、通信品質の担保ができなくなる等の問題があるため、このような非決定的(non-deterministic)なIPv6トンネルは問題であるという提案も実施されています。この提案に対し、問題はわかるが、6to4などは既に広くディプロイしており、利用を停止することは困難であるという意見や、そもそも「非決定的(nondeterministic)」の定義はどうなのか、といった議論となりました。

2コマ目の「CPEルータに関する問題」では、CPEの要求仕様や、CPEに載せるべきセキュリティ機能の議論が実施されました。CPEの要求仕様に関する議論では、上流からDHCPv6-PDで受け取ったプリフィクスを下流に委譲する手法や、経路の設定等が議論になりました。セキュリティ機能の提案では、IPv4と同じセキュリティ概念をIPv6に持ち込むことの是非や、CPEルータがどのような機能をどの程度持つべきか、といったことが長時間議論されました。特に、ドラフトで機能要件として挙げている、トンネルパケットの扱いについては激しい議論になり、MLで継続議論となりました。IPv6 CPEルータ推奨機能の議論では、同様の議論をブロードバンドフォーラムや、ケーブルLab、3GPP等でも実施しているため、他団体の筆者を加え、内容をアップデートする方向で調整することになりました。

□v6ops WG: http://www.ietf.org/dyn/wg/charter/v6ops-charter.html
http://go6.net/ipv6-6bone/
□第75回 IETF v6ops のアジェンダ: http://www.ietf.org/proceedings/75/agenda/v6ops

behave WG
(Behavior Engineering for Hindrance Avoidance WG)

behaveは主にNATの挙動に関して扱うWGですが、その技術的な関連性の高さからIPv6/IPv4変換についての議論も行われています。今回は、そのIPv6/IPv4変換を中心にさまざまな提案がなされた関係で、二つのスロットにわたってセッションが行われました。

- draft-ietf-behave-v6v4-framework-00
- draft-ietf-behave-v6v4-xlate-00
- draft-ietf-behave-v6v4-xlate-stateful-01
- draft-ietf-behave-dns64-00

IPv6/IPv4変換に関するトピックとしては、上記Internet-Draftに関する議論が行われ、前回からの検討状況のアップデートについて報告がありました。

この一連のInternet-Draftについての目新しい変更点としては、前回ご紹介した^※1NAT66と呼ばれるIPv6からIPv6へのNATの提案でも触れられていた、checksum neutralityについての言及があったことが挙げられます。checksum neutralityとは、アドレス変換の前後で上位層(主にトランスポート層)のヘッダーで利用されるチェックサムの値に影響を与えないようにする、というものです。これは変更前後のアドレス対をうまく選ぶことで実現が可能です。例えば16ビットのCRCチェックサムを利用しているTCPでは、変換後のアドレスのうち16ビットをうまく選ぶことで、チェックサムを不変にしたままNATをすることができます。

このchecksum neutralityによるメリットとしては、今後新たなトランスポート層プロトコルが出現した際にも、同じチェックサム計算方式を使ってさえいれば、NAT装置をその新プロトコルに対応させる必要なく利用できる、ということがあります。しかし、IPv6/IPv4変換の場合は、IPv6とIPv4でUDPチェックサムの扱いが異なる、つまりIPv6ではUDPチェックサムが必須となったことから、結局再計算をせざるを得ないケースが出る、等の議論が行われました。

- draft-thaler-behave-translator-addressing-00

また、behaveのチェアを務めるDave Thaler氏からは、IPv6/IPv4変換の際に用いるダミーアドレスとして、どのようなアドレスが望ましいか、という検討の発表がありました。

IPv6からIPv4変換を行う際のダミーアドレスには、ダミーIPv6アドレスの、どの部分にIPv4を埋め込むべきか、またダミーアドレスとして用いるアドレスは、各サイトで取得したアドレスを使用するべきか、それともwell-knownなプリフィクスを定義すべきか、またプリフィクス長はどの程度必要か、といったさまざまな角度から、またそれぞれのIPv6/IPv4変換シナリオについて分析した結果が報告されました。

その他にも、LSN(Large Scale NAT)と呼ばれるISP等でNATを行う方式や、そのNAT装置の信頼性をより高めるための方式、そしてNATが介在している場合でも、アプリケーションが通信相手を正しく認識するための方式等、さまざまな提案があり、議論が行われました。

□behave WG: http://www.ietf.org/dyn/wg/charter/behave-charter.html
□第75回 IETF behave WGのアジェンダ: http://www.ietf.org/proceedings/75/agenda/behave.html

softwire WG(Softwires WG)

softwire WGでは、トンネルを用いてIPv4 over IPv6、またはIPv6 over IPv4通信を実現する方式を検討するWGです。基本的にはDS-lite(Dual stack lite)と呼ばれる方式にまとまりつつあるのですが、今回は6rd(もともとはIPv6 Rapid Deploymentの意)という、IPv6 over IPv4通信を実現する方式についての議論も行われました。

- draft-townsley-ipv6-6rd-00

簡単に説明すると、6to4というIPv4グローバルアドレスを保持しているサイトにIPv6アドレスを自動割り当てし、IPv6接続性を自動的に提供する方式があるのですが、これを特定のサイト内で完結させ、管理性を高めた方式がこの6rdとなっています。実際にもともとの提案者のRemi Despres氏は、FREE TelecomというフランスのISPにおいて、商用のIPv6接続サービスを提供するための方式として使用しているとのことです。

ここ最近、IPv6の普及度を調査したレポートなどにおいて、IPv6の通信品質の悪さが取りざたされており、その原因が6to4やTeredo等の、IPv4ネットワーク上で提供されるIPv6トンネル接続方式にあるとされています。そこで、6to4やTeredoといったプロトコルを廃止しよう、またはより信頼性を向上させようという提案がなされています。本方式はこういったIPv6への移行のためのプロトコルではなく、より管理性と品質の高いIPv6接続サービスを提供するための方式として提案されています。こういった背景から、6rdは比較的大勢のサポート獲得に成功しており、WGアイテムとなる予定ですが、まずその前にWGのチャーターを変更する必要があり、それを待ってWGアイテムとして公開される予定になっています。

□softwire WG: http://www.ietf.org/dyn/wg/charter/softwire-charter.html
□第75回 IETF softwire WGのアジェンダ: http://www.ietf.org/proceedings/75/agenda/softwire

homegate bar-BoF

ホームネットワークにフォーカスし、ユーザーエクスペリエンスの向上、セキュリティの維持、新機能の導入、という三つのテーマを扱うhomegate WGの設立をめざす動きがあります。今回は、公式なBoFとしてスロットを申請していたのですが、主にスコープに不明確な部分があるとの理由から、開催には至りませんでした。そこで、bar bof、すなわち非公式BoFという形で、有志によりIETFミーティングの設定時間外にミーティングが行われました。

そこで検討されたトピックとしては、DNSSEC、IPv6/DHCPv6、ECN/RED、Multicast、Security、Firmware更新、ゼロコンフィグ、デバイスの管理方法、複数サブネット、といった項目がありました。

それぞれのトピックについて、興味を持っている人がどれぐらいいるかについて確認していくという形で進められましたが、どのトピックも扱う必要が無いと感じている人は少数で、どれもこれも扱うという流れになってしまったようです。

また、さらにはWG化された場合のアウトプットとして、ホームゲートウェイの要求仕様書などのようなものができた場合には、v6ops等のIETF内の他のWGで既に部分的に行われている活動とはどうすみ分けがされるのか、またIETF以外にもさまざまなSDO(Standards Developing Organization)で取り扱われている仕様書との関係はどうなるのか、といった方向に話は発散する一方となってしまい、なかなかWGのスコープを明確に定めるのには至らないという様子でした。

homegateのセッションのスライド等はIETFのWebサイトから取得できるようにはなっていませんが、メーリングリストが開設されており、依然活発な議論が行われているようです。次のURLから参加できますので、ご興味のある方はぜひご参加ください。