ニュースレターNo.42/2009年7月発行

IPv6関連WG報告

第74回のIETFは、米国サンフランシスコにて、2009年3月22日から27日まで開催されました。このところの世界的な景気の低迷もあり、参加人数が激減することが危ぶまれましたが、ミネアポリスで開催された前回より200名以上多い参加者が集まりました。シリコンバレーに近い西海岸ということで、多くの方が自宅やオフィスから通っていたようです。

さて、毎回IETFでは、IPv6に関連した話題は多くのWGで議論されており、パラレルでそれらのセッションが開催されていることも多く、全てを少人数で把握することは困難な状況です。そこで本稿では、会期中に議論されたIPv6に関連したトピックスのうち、IPv6に特化した内容を議論するWGでの話題を中心に紹介します。

6man WG（IPv6 Maintenance WG）

6man WGは、IPv6のプロトコル自体のメンテナンスを実施するWGです。今回のミーティングは、2009年3月24日（火）に開催され、参加者は100名程度でした。最初にチェアより、WG文書の現状について以下のような報告がありました。

重複フラグメントに関するドラフトのラストコールが終了。コメントがあったため、改版バージョンが出た。改版バージョンに対するコメントを募集中。
予約インタフェース識別子ドラフトがRFC5453として発行された。
IPv6サブネットモデルドラフトの新バージョンが発行された。
ノード要求文書改版が進行中。

また今回の主な提案としては、以下が挙げられます。

経路制御ヘッダのIANAへの登録について
draft-arkko-ipv6-iana-routing-header
IPv6複数アドレス選択デザインチームの議論報告
draft-chown-addr-select-considerations
トンネルパケットのUDPチェックサムの扱いについて
draft-eubanks-chimento-6man

上記三つの提案について、次に簡単にご紹介します。

「経路制御ヘッダのIANAへの登録」とは、経路制御ヘッダのタイプフィールドに関する登録ガイドラインの提案です。現在、経路制御ヘッダのタイプフィールドについて、IANAへの登録は四つ（そのうちの一つであるタイプ0については、セキュリティ上の問題から利用禁止になっています）ありますが、今後追加登録の際には、IETFのレビューかIESGへの申請を必要とすることにしたいというものです。議論の中で提案者から、経路制御ヘッダのタイプを定義しているような文書が他にないかどうか知っていたら教えて欲しいというリクエストもありました。結局、会場内からは、この提案には賛成、他の定義文書については知らない、というコメントが一つあったのみで、他に意見はありませんでした。意見があれば、今後メーリングリストでコメントをして欲しいとのことです。

「IPv6複数アドレス選択デザインチームの議論報告」では、IETF72（ダブリン）に引き続き、デザインチームからIPv6ノードがアドレスを複数持っている場合のアドレス選択のあり方について以下の検討報告がありました。

アドレス選択ポリシー配布の必要性
ポリシー変更タイミングに関する考え方
インタフェースが複数あるノードの場合の扱い
それぞれのインタフェースからコンフリクトするポリシーが配布されてきた場合の扱い

v6ops WGでも、アドレス選択ポリシー配布については議論になっています。今回のIETFでは、複数インタフェースがある場合の問題に関して議論するmif BoFが6man WG終了後に開催されたこともあり、そちらとの関連や、現在のアドレス選択仕様であるRFC3484は、終点アドレス選択と始点アドレス選択を同じルールセットで記述しているが、それらを別々のルールセットとして記述するように変更することも考慮するべきではないかという意見が出されました。提案文書に対する会場からの賛成の声はそれほど多くなく、引き続きMLで議論をしていくことになりました。

「トンネルパケットのUDPチェックサムの扱い」とは、IPv6とIPv4におけるUDPの扱い方の違いについての提案です。IPv4では、UDPパケットのチェックサムはオプション扱いになっていますが、IPv6の基本仕様を定めているRFC2460では、UDPにおいて、チェックサムの計算が必須であることが定められています。この違いは、IPv4ではIPv4ヘッダ内にチェックサムフィールドがありますが、IPv6ではIPv6ヘッダ内のチェックサムを不要としたことによるものです。しかし、マルチキャストをトンネルで転送するAMTなどのプロトコルでは、トンネル部分でチェックサム相当の計算をするため、UDPカプセリングを実施するルータやエンドホストの負荷軽減のために、この計算を不要としたいということが提案されました。

チェックサムを不要とすることへの危険性が指摘される一方で、「IPv4ではチェックサムがないのだからIPv6でも同様にすべきだ」という意見や、「その目的ならUDP liteを使うべきだ」、「UDP liteは、UDPとプロトコル番号が違うため、NATを通過できない」という議論がありました。UDPチェックサムの有無による得失や、AMTの仕様も含め、メーリングリストで継続議論を行うことになりました。

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

intarea（ Internet Area Open Meeting）

intareaオープンミーティングは、Internetエリアでの話題のうち、どのWGにも属さない議題や、複数のWGにまたがった内容を議論するWGです。Internetエリアのエリアディレクターが、エリア全体の動きの紹介も実施します。今回、IPv6に関連する話題としては、DHCPv6を使用し、デフォルトルータおよびオンリンクのプリフィックスを配布してはどうか、という提案がありました。

IPv6では、デフォルト経路はルータ広告（Router Advertisement,RA）により通知されます。これに対して、IPv4と同等の動作をできるようにすべきだという意見や、RAのセキュリティを問題にする意見等があり、DHCPv6による経路情報の配布に関しては以前から何度か提案されていました。しかし、こうした提案は、同等のことを複数の手段で実施することを嫌う意見、IPv6の基本的な動作を変更することに対する懸念などがあり、否決されてきました。今回は、運用コミュニティからの意見等もあり、IETFの重鎮が提案するという形でintareaミーティング、routingエリアミーティング、dhc WGで議論が実施されました（dhc WGでは一部のみ）。今回の提案は、IPv6の基本動作を変更せずにDHCPv6による経路配布を取り込むという内容になっています。従来と同様の懸念の提起や、DHCPv6とRAのセマンティクスの違い等についても意見のある中、IPv6が広まるならばDHCPv6の利用もやむを得ないという意見もあり、継続議論となりました。

□第74回IETF intareaのアジェンダ: http://www.ietf.org/proceedings/09mar/agenda/intarea.txt

ISOC主催のパネル「The Seven Stages of IPv6 Adoption」

2009年3月24日（火）のランチセッションとして、ISOC（Internet Society）主催のIPv6ディプロイメントに関するパネル討論、「The Seven Stages of IPv6 Adoption」が行われました。このセッションは、パネリストとして後述の方々がプレゼンテーションを行い、その後に会場からの質問に答えるという形式で進みました。IETFミーティングには直接関係はありませんが、IPv6関連の話題ということで、パネリストの名前とプレゼンテーションの内容を簡単にお伝えします。

- Russ Housely氏、IETFチェア: IPv6プロトコル発祥の団体として、移行シナリオの見直し、移行技術の開発を進めていく。
-Richard Jimmerson氏、American Registry for Internet Numbers（ARIN）: IPv4アドレスの残数は確実に減っている。ARINでも従来よりIPv6への認識を高める活動をしており、最近は業界の反応も変わりつつある。
- Kurtis Lindqvist氏、Netnod社: IPv6が流行らないのはIPv4との非互換性、移行への積極的な理由がないことなどが原因。IPv4とIPv6網をつなぎ、エンドユーザー向け機器を増やしていくことが必要。
- Lorenzo Colitti氏、Google社: IPv6は新規ビジネスのチャンス。インターネットの継続利用のためにも必要。Google社におけるIPv6への取り組みの歴史を紹介
- Alain Durand氏、Comcast社: IPv4アドレスは確実になくなるが、IPv4デバイスはたくさん残る。また、コンテンツサーバがIPv6対応するには時間がかかる。ユーザーが個別のIPv4アドレスを使わずにIPv4サービスを使えるようにすることが必要。
- Sebastian Bellagamba氏、Internet Society: カリブ、ラテンアメリカ等の途上国におけるIPv6ディプロイメントの例を紹介し、政府の関与が重要なことを示す。
- Jari Arkko氏、Ericsson Research（IETF Internetエリアディレクタ）: IPv6の仕様はできあがっており、メンテナンスフェーズに入っている。IETFでの注目も、ディプロイメントへ移っている。

会場からのIPv6の意義に関する質問に対しては、「多くのデバイスが常時接続になっていくことや、今後も継続的にインターネットを利用していくためには必要」といった回答をはじめ、「やはりIPv6へ移行するインセンティブが少ないことが問題だ」というような、従来から多くある意見も出されました。特に結論を出すようなパネル討論ではなかったのですが、多くの聴衆が集まり、IPv6への関心の高さがうかがえました。

パネルの詳細、話者のプロフィール、発表スライドについては、以下のWebサイトに掲載されています。

http://www.isoc.org/isoc/conferences/ipv6panel/

v6ops WG（IPv6 Operations WG）

v6opsはIPv6に関するオペレーション技術や、移行技術に関する議論を行うWGです。今回のIETFミーティングでは、2009年3月23日（月）と27日（金）に合計3時間半の時間を割いて行われました。今回もさまざまなトピックが挙げられましたが、その中でいくつかピックアップしてご紹介します。

UPnPを用いた家庭内ネットワークでのIPv6サービス

draft-bnss-v6ops-upnp-01.txt

家庭内ネットワークのアドレッシング方法や、外部からのアクセス方法、家庭内ネットワーク間通信の要件とその解決方法の検討について、発表がありました。その中で、家庭内ネットワークではユニークローカルIPv6ユニキャストアドレス（ULA）への対応が必要であるとされ、ULAを利用するためには、IPv6対応端末のアドレス選択方式について定義したRFC3484の改訂が必要であると述べられました。また、UPnPのファイアウォール制御方法にはセキュリティの問題があり、IPv6では、よりセキュアな制御方法の検討が必要であることも伝えられました。

ある会議場ネットワークにおけるIPv6の有効化

draft-vyncke-vdv-v6ops-conf-stats-01.txt

3,000人規模のIPv6についてほとんど知識を持たない人々が集まる会議の会場ネットワークで、IPv6を有効化した際の状況に関する報告がありました。帯域やRTT、DNSトラフィック、偽RA、OS分布などについて調査が行われました。

結果としては、キャプティブポータルによる認証との組み合わせで問題が発生し、ユーザーが最初にアクセスしたサイトにAAAAレコードが付与されている場合に、認証サイトに飛ばされないという不具合がある以外は、IPv6を有効化した場合でも大した問題は発生しなかったとのことです。偽RAも発生したそうですが、対策ツールにより、大きな問題には至らなかったとのことです。

IPv4 NAT環境におけるIPv6送信元アドレス選択の問題について

draft-denis-v6ops-nat-addrsel-00.txt

IPv4 NAT環境において、6to4やTeredo等のトンネルプロトコルを用いてIPv6を利用している場合、現在のアドレス選択ルールでは、通信品質が劣ると思われるこれらのトンネルプロトコルを優先してしまう、という問題提起がなされました。

これはIPv4 NAT環境下で用いられるIPv4プライベートアドレスが、サイトローカルスコープを持ち、一方、トンネルプロトコルで付与されるIPv6アドレスはグローバルスコープであり、宛先アドレスとスコープが一致するものが優先されるという現在のルールにおいては、トンネルプロトコルで利用するアドレスが優先されてしまうためです。その場での意見としては、通信品質といってもいろいろな側面があり、帯域や遅延時間という観点もあれば、NATがなくEnd-to-End通信に有利であるという観点もあり、通信を行うアプリケーション、ネットワーク環境によって優先するべきアドレスはさまざまであるとの意見が出されました。

このような議論を鑑みるに、多少なりともIPv6の普及が進んでいる現状では、全ホストの挙動を変更するようなRFCの改訂は、かなりハードルの高い作業だと言えそうです。

6to4の適正化

draft-nward-6to4-qualification-00.txt

昨今、6to4やTeredo等のIPv6を利用するための過渡的なプロトコルの利用について、さまざまなところで普及状況の分析等が公開されていますが、その中で6to4の信頼性について問題提起がなされています。

6to4はIPv4グローバルアドレスが利用できる環境であれば、自動的にIPv6グローバルアドレスが付与され、IPv4でカプセル化してIPv6パケットをやり取りすることが可能になるというプロトコルです。しかし、このプロトコル自体には、6to4を用いてパケットをIPv6インターネットとやり取り可能であるかどうかを確認するという処理が含まれていません。そのため、6to4パケットが途中のフィルター等で落とされる環境であるにも関わらず、端末はIPv6が利用可能だと思い込んでIPv6での通信を試みるという状況に陥り、ユーザビリティの低下を招く原因となります。

本提案では、6to4のアドレスを利用する前に、インターネット中のホストを用いて通信テストを行い、全てのテストに成功した場合にのみ、6to4アドレスを端末に付与することを提案しています。テスト用のアドレスや、通信テストに関する詳細部分等について今後も議論を継続していくことになっています。

□v6ops WG: http://www.ietf.org/html.charters/v6ops-charter.html
□第74回IETF v6opsのアジェンダ: http://tools.ietf.org/html/draft-ietf-pkix-rfc4055-update-01

6ai BoF（IPv6 Address Independence BoF）

前回のミネアポリスでのIETFミーティングから脚光を浴び始めたIPv6-NATですが、behave WGから切り離され、今回はこのトピック単独で2時間半のスロットが割り当てられ、議論が行われました。

今回6aiというBoFの名前になっている理由は、NATはアドレスの独立性を提供するという側面があり、ISPから付与されるアドレスが変わってもサイト内のアドレスを付け替える必要がないことや、マルチホームが単純になるというメリットがあるものの、これがNATを導入するデメリットを上回っているかどうかの検討を目的として、今回のBoFが開催されたためです。

6ai-BoFセッションでの質問者の列（写真提供者：Cisco Systems社 Mark Townsley氏）

最初にIABのIPv6-NATに関する考察が、Dave Thaler氏より発表されました。アーキテクチャの原理原則としては、インターネットはさまざまな目的を持った主体を許容すべきであるが、非IPv6-NATな部分がIPv6-NATによる悪影響を受けるべきではないということが掲げられ、またどのような解決策であっても、End-to-Endの透過性はインターネットの成功の鍵であり、要求条件として検討するべきである、との提言がなされました。

その後、数名によるIPv6-NATに関する検討についての発表があり、最後にフリーディスカッションが行われ、非常に多くの人々がマイクに列をなしました。その場での議論としては、今回6aiというように、アドレス独立性だけにスコープを絞ったようなBoFの名前にしていることについて、トポロジー隠蔽はスコープ外なのかという質問が出ました。これに対し、スコープ内になる可能性も残されているという受け答えがあり、またトポロジー隠蔽については、まず正確な定義・理解が必要であり、ホスト数を隠蔽するのか、サイト構造を隠蔽するのか、その両方なのかについての合意に至る必要があるという意見が出されました。

最後に挙手で投票が行われた結果、ほとんどの参加者はこの問題提起に対して何らかの解決策が必要であると考えていることがわかりました。ただ、IPv6-NATが解決策として妥当かどうかについてはやや否定的であり、IPv4のNAPTで実現できることのうち、IPv6-NATで実現することについての優先順位付けが必要であると考えている人が多いということもわかりました。

現在インターネットで広くNATが利用されていますが、そこでのニーズを何らかの形でカバーできるものでなければ、いずれIPv4のNATとほぼ同等のIPv6-NATが出現することも予想されます。IETFの市場への影響力がどれ程あるのかが問われる難しい局面を迎えていると言えます。