NTT情報流通プラットフォーム研究所 藤崎 智宏／松本 存史
1. 第70回IETF概要
第70回IETFは、2007年12月2日（日）から12月7日（金）まで、カナダのバンクーバーにて開催された。今回は、世界37カ国から1,114名の参加があった（水曜日のプレナリにおけるIETF議長からの報告，IETF web上の最終参加者は1,128名）。参加者推移を図1にしめす。前回、第69回の米国シカゴIETFでは40カ国、1,146名（同、1,175名）とほぼ同人数の参加となった。また、参加者の国別割合を図2に示す。地元カナダからの参加が多いが、それ以外はほぼ前回と同じ国別順位である。
例年、冬のIETFミーティングは11月中に開催されることが多いが、今年は12月に入っての開催となった。そのためか、会議初日には積雪があり、会期中を通し、厳しい寒さの中でのIETFとなった。地元の方に伺ったが、バンクーバで積もるほど雪が降るのは非常に珍しいとのことである。
2.IEPG（Internet Engineering and Planning Group）ミーティング
2日（日）の午前中に開催されたIEPGミーティングでは、当初、IPアドレスの割り振りに関するトピックスと、IPv6のトラフィック観測に関する発表が予定されていたが、話者の飛行機遅れ等の理由から、プログラムが100%入れ替わり、全5件の発表が実施された。入れ替わった後のプログラム、発表資料はIEPGのwebページ（http://www.iepg.org/2007-12-ietf70/index.html）より参照可能である。
IPv6に関連する話題としては、Ed Lewis 氏より .biz TLD (Top Level Domain) のDNSサーバに関する報告があった。彼の運営する.bizドメインのDNSサーバのうち、j.gtld.biz は2007年3月に追加されたが、IPv6アドレスのみしか付与されておらず、DNS rootのglueレコードにも，IPv6アドレスのみしか登録されていない（2008年1月現在も同様であった）。新規登録の際に、IANA（Internet Assigned Numbers Authority, http://www.iana.org）から、「まじ？（Are you sure?）」と聞かれたとのことである。報告時まで、特に技術的問題は報告されていない、とのことではあるが、問題が皆無ではなく、他者から「Aレコードを付け忘れている」との指摘があったり、IPv6に対応していないDNSのテストツールがエラーを出したり、ということがあったとのことである。また、観測の結果、既に「experimental」ステータスになり、ほとんど使用されないはずのA6（A6の問題点については、RFC3364を参照）による問い合わせがかなりあるとのことである。結論として、一番手間がかかっているのは、問い合わせ対応ということであり、技術的には問題なさそうである。
DNSに関連するが、root DNSのzoneにも、ようやくIPv6 アドレスが付与されることになった。2008年2月4日に実施される予定とのことである。関連した技術文書がIANAのwebページに掲載されており（http://www.icann.org/committees/security/sac018.pdf）、また、詳細については、今後、IANAのwebサイトに載るとのことである。
□IEPG の web ページ
http://www.iepg.org
3. 6man WG（IPv6 Maintenance WG）
IPv6プロトコル本体は、ipng wg にて標準化が開始され、その後、ipv6 wgに引き継がれて議論されてきた。そのipv6 WGも、IPv6プロトコル自体は標準化が終了したとして、IETF会期中における face-to-faceミーティングを2005年11月のバンクーバーミーティングにて終了し、その後はメーリングリスト上での議論のみが実施されてきた。しかしながら、IPv6の実利用が本格的になるにつれ、そのプロトコル仕様や、ipv6 WGにて策定されたいくつかのRFCに対する変更が提案されるようになり、新たに、IPv6プロトコルのメンテナンスを目的としたWGとして6man WGが設立され、今回、初めてのミーティングが水曜日の朝一のコマで実施された。
6man WGはチャータにおいて、IPv6のマイナーな改版のみを実施するということが明記されいる。ミーティング時にチャータに挙げられている議論内容は、
- ・RAフラグオプション
- ・ルーティングヘッダ タイプ 0 （RH0）の無効化
- ・IPv6 over PPP圧縮ネゴシエーション
- ・管理組織割当ユニークローカルIPv6アドレス（ULA-C)
の4つのみであり、このうち、RAフラグオプション、ルーティングヘッダタイプ0の無効化についてはミーティング前にはほぼ議論は終わり、RAフラグオプションについては、既にRFCが発行（RFC5075）されており、RH0無効化についてはRFC発行直前である（2007年1月20日現在の最新ドラフトは、draft-ietf-ipv6-deprecate-rh0-01）。IPv6 over PPP圧縮については、今回は議論が実施されなかった。
今回のミーティングにて議論された項目は、
- 1．RFC3177改版ドラフトに関する議論の喚起
- 2．RFC 4294 IPv6 Node Requirements の改版に関する議論
- 3．インタフェース識別子の登録に関する議論
- 4．ルータ広告（RA）とDHCPオプションに関する提案
- 5．アドレス選択に関する議論
- 6．IPv6のアドレス自動設定機構の変更提案
- 7．管理組織割当ユニークローカルIPv6アドレス（ULA-C）に関する議論
等である。チャータにマイナーな改版のみ、と宣言されてはいるが、今回の議論中、6のIPv6のアドレス自動設定変更提案（draft-dickson-v6man-new-autoconf）や，4のルータ広告とDHCPオプションに関する提案（draft-krishnan-intarea-ra-dhcp）は、IPv6の基本的な仕様に影響する変更提案であった。双方とも今回は否決されているが、IPv6の普及をさらに進めるためにも、基本仕様に影響するような議論の動向については、注視していく必要があると思われる。その他の項目については、今後、継続的に議論が実施される予定である。
6man WGに関する情報や、第70回IETFにおける6manミーティングの資料、議事録などは以下から参照可能である。
□6man WG
http://www.ietf.org/html.charters/6man-charter.html
□第70回 IETF 6man WG 関連情報
http://www3.ietf.org/proceedings/07dec/6man.html
4. v6ops WG (IPv6 Operations WG)
v6ops WGは、IPv6とIPv4の共存技術、IPv6のデプロイメントに関する話題を扱う。今回のv6ops WZミーティングは、月曜午後の二コマ目に開催された。「IPv6 Operations "normal" meeting」と、木曜日午後一の「IPv6 Transition Discussion」の二コマ開催された。
「IPv6 Operations "normal" meeting」セッションは、通例のv6ops WGミーティングであり、チェアより、v6ops WGで現在扱っているワーキンググループドラフトの進行状況の紹介が実施された後、
1．不正ルータ広告（RA）に関する議論
2．不正ルータ広告（RA）の、L2での防御に関する提案
3．Teredo のセキュリティに関する提案
に関する議論が実施された。1、2の、不正ルータ広告に関する議論は、前回の第69回IETFミーティングでもかなり議論されている。今回、解決案を含めた形で1としてドラフト化され（draft-chown-v6ops-rogue-ra）また、解決案として、2（draft-vandevelde-v6ops-ra-guard）が提案された。この不正RA問題については、既にIETFでは標準化済みのRAにセキュリティを付加する技術であるSEND（RFC3971）を利用すれば解決可能ではあるが、SEND自体、実装が少ない、設定が手間である、といった意見がだされた。2は、L2スイッチでのフィルタ等を利用して、RAを送出できるノードを制限することで解決するという提案であるが、無線LANの環境ではL2スイッチが常に存在するわけではない、といった問題提起があった。また、不正RAには，a）設定ミス、b）不正アタック、が考えられ、どのような手段を用いても、a）は防ぐことが困難である、という意見も出された。ぞれぞれ、今回は特に結論は出なかった。
3で議論されたのは、NATを越えてIPv6 over IPv4トンネルを実現するTeredoのセキュリティに関してである。このトピックスについても、継続的に議論されてる。
今回は、Teredo 自体のセキュリティ向上に関する提案（draft-krishnan-v6ops-teredo-update）と、前回より継続の、Teredoそのものに関する問題提起（draft-ietf-v6ops-teredo-security-concerns-01）が議論されている。Teredoのセキュリティ向上に関する提案は、アドレスの一部を乱数により導出する機能を付与することで、Teredoアドレスが推測されにくくする、というものである。また、セキュリティに関する問題提起は、Teredo を利用した場合、NATやファイアウォールなどを超えて、網のセキュリティポリシーを無視した通信が可能になってしまうことへの問題提起である。Teredo 自体の議論もあったが、昨今、策定したプロトコルに対するセキュリティ問題が多く提起され、対策が後手後手になっていることを指摘する声や、極論として、議論を実施する時間が無駄なのでTeredoのような、危険なプロトコルは使用禁止としてしまうだけでよい、といった意見出された。しかしながら、既にプロトコルとして広く実装されていることなども鑑み、v6ops WGとして取り組みを実施していくことで合意が得られている。
ニコマ目の「IPv6 Transition Discussion」セッションでは、IPv4／IPv6のプロトコルトランスレーション方式であるNAT-PTのRFCが廃止（Historical）になったことを受け、代替となる技術を中心に議論が実施された。
セッションのはじめに、Jordi Palet氏より、IPv6の現在のトラフィックボリュームに関する報告があった。Jordi氏が統計を取ったあるサイトでは、IPv6のネイティブトラフィックこそそれほど多くないものの、Teredoプロトコルや6to4などのトンネルトラフィックを含めた場合、IPv4よりもIPv6の方がトラフィック量が多いという調査結果が提示された。調査対象ネットワークの一般性が質問に挙がったが、機器のIPv6対応の進展を示すデータではあると考えられる。
引き続き、新たなIPv4ホストとIPv6ホスト間の相互通信を実現する技術に関する検討が実施された。検討にあたり、発生する問題をまとめた発表（問題提起：Probelm statement）や、問題解決にあたってどのような要求条件があるか（Requirements）、IPv6への移行シナリオに関する検討などの議論が実施された。
IPv6/IPv4プロトコルトランスレータの代替となる技術もいくつか提案された。提案アプローチは、NAT-PTのような、通信路中の装置によってIPv4-IPv6変換を行うというアプローチではなく、端末自体を含む通信路中でIPv4-IPv6変換を二回実施し、上位のアプリケーションには途中でのプロトコル変換による影響を与えないというものである。これは、NAT-PTが廃止された理由の一つには、IPv6インターネットにIP層のアドレス変換を行う装置(すなわち、NAT装置)を導入することになる。NATが存在すると、アプリケーションに制限が発生することが問題視されているためである。
この他にも、IPv4アドレスの在庫枯渇が目前に迫っているという事実を反映した議論が実施された。従来 v6ops WG やその前身であるngtrans WGで想定していたIPv4／IPv6デュアルスタック環境による移行シナリオにおいても、グローバルIPv4アドレスが不足するために、IPv4についてはISPでNATを実施し、ユーザーにはプライベートアドレスを割り振るというモデルが議論されている。
2011年にIPv4アドレスの在庫が枯渇すると言われ、IPv6の導入、IPv4との共存環境の構築が急務であり、事業者側からはトランスレータの必要性が叫ばれている昨今、IETFが実環境で導入・実施可能な解を提示できない場合＜，IPv6への移行を各事業者がそれぞれ手探りで進めることとなり、技術的にも混乱が発生する可能性がある。実践的なIPv6/IPv4の共存技術の確立が急務だと考えられる。
□v6ops WG
http://www.ietf.org/html.charters/v6ops-charter.html
http://www.6bone.net/v6ops/
□第70回 IETF v6ops WG 関連情報
http://www3.ietf.org/proceedings/07dec/v6ops.html
第70回IETFミーティングの各種情報は、以下のURLより参照可能である。
□ 全体プログラム、WGアジェンダ、発表資料
https://datatracker.ietf.org/meeting/70/materials.html
□ 録音
http://videolab.uoregon.edu/events/ietf/
