ニュースレターNo.40/2008年11月発行
第72回IETF報告 全体会議報告
概要
年に3回開催されるIETFでは、1回以上を北米以外で実施することになっています。今回は、その“北米以外”にあたっており、アイルランドで開催されました。アイルランドといえば、子供の頃に聞いた丸山薫作詞の「汽車に乗って」の一節、「日が照りながら雨のふる/あいるらんどのやうな田舎へ行かう」を思い出しますが、そのような天候ではなく、朝方雨が降っても昼間は太陽が輝き、隣接するゴルフ場の芝生を美しく照らす素敵なところでした。緯度が高いため、日が暮れるのも20時半過ぎで、朝から晩まで続く会議で1日がやたらと長く感じるIETFですが、最後のセッションを聞いた後もまだ日が出ているため、ちょっといつもとは違う感覚を味わうことができました。
会場は、ダブリン市内からバスで30分ほどの田園地帯にあり、普段はゴルフのための宿泊客が多いようで、ヘリコプターで来るゲストのためにヘリポートが備わっており、会期中も頻繁にヘリコプターが行き来していました。隔離された環境に、世界中から研究者や技術者が集まって、議論に没頭する1週間となりました。
| 会期： | 2008年7月27日～8月1日 |
| 会場： | CityWest Hotel（Dublin, Ireland） |
| 参加費： | 635USD（early registrationの場合） |
| セッション数： | 118（tutorial、training、plenary sessionを除くWGやBoFセッション数） |
| ホスト： | Alcatel-Lucent社（通信機器ベンダー） |
| 参加登録者数： | 1,183人（前回比50人増、1,000人強で常態化しているようです） |
| 参加国数： | 48ヶ国（国別の分類などもUS、JP、DEなど変わらず。参加国数も常態化） |
今回の会場は、ゴルフ場の中にあり、宿泊施設とメイン会議場の他にも数棟の建物内の会議場がありました。鮮やかなグリーンやよく手入れのされた草花を見ながらの移動は気分転換にもなり、また、途中のテラスやバルコニーにもイスやテーブルがあり、そこかしこで議論をしている人でにぎわっていました。
会期の始まる直前に、ComputerWorld※1のWebサイトに、IETFチェアのRuss Housley氏による「IETFでは、現在VoIP、MPLS、P2PとならんでIPv4/IPv6プロトコル変換機がホットトピックである」というインタビュー記事が公開されました。しかし、IETFではプレナリをはじめ、この話に触れる発言もなく、特にどのプロトコルに力を入れているということもなく、どの標準化作業についてもタフな議論がされていたように思います。
IETF Technical Plenary
今回は、Technical Plenaryが4日目（2008年7月30日、17:00～19:30）にあり、Operations and Administration Plenaryが5日目に行われました。
Welcomeスピーチの後、ホストのAlcatel-Lucent社（アイルランド支社のKevin O'Callaghan氏）のホスト・プレゼンテーション、IRTFとIABからのレポートに続き、「IPv6 Deployment Forum」のタイトルでテクニカルセッション、オープンマイクという流れでした。
ホスト・プレゼンテーションでは、通信機器ベンダーらしく、通信環境の変遷についてどのようなことを課題として取り組んできたか、最近のトレンドは何か、という発表がありました。エコロジー（エネルギー問題）についての取り組みの紹介では、いくつか実例紹介があり、その中でも、富士通社がspamを低減することで消費エネルギー（電力）を削減したというエピソードは、海外で聞く日本の評判という点からも興味深いものがありました。
「IRTF Report」では、IRTFチェアのAaron Falk氏から、DTNRG※2で開発した参照コード“DTN2”※3がSource Forgeにも掲載され取得できるようになったことの報告がありました。最近の各リサーチグループの動きの中では、ICCRG※4内に、リサーチペーパー作成のためのデザイン&ドラフティングチームが形成されていることの紹介がありました。また、SIPのアプリケーションやIPv6についてのリサーチについてもトピックとしてあがっているとのことでした。
続くOlaf Kolkman氏による「IAB update」では、通常のドキュメント更新状況や多組織との協調活動報告のほかに、「RFC Editor Model」というタイトルで、RFCの執筆から発行までの整理と提言がされました。この提案では、RFCの生産工程における担当者とその役割が提示されるとともに、具体的には、“stream producers”、“stream approvers”、“production house”、“publisher”、という大きな枠組みがあり、その中における“RFC Editor”の“production house”と“publisher”に対する関与の仕方を整理しています。詳細は、IABのWebページ※5で閲覧可能で、コメントも受け付け中です。
また、IABとして現在まとめている文書のうち、前回紹介された、「よいプロトコルの条件」（What makes For successful protocol?, draft-iab-protocol-success-02.txt）は、RFC5218として発行されたという報告がありました。
これにより、現在進行中のIAB文書は、「ヘッダと常用文」が追加されて、次の三つになります。
- 「Internet上の端末設定の原則」（Principles of Internet Host Configuration, draft-iab-ip-config-04.txt）
- 「DNS拡張を行う際のデザインの選択性について」（Design choices when expanding DNS, draft-iab-dns-choices-06.txt）
- 「ヘッダと常用文」（Headers and Boilerplates, draft-iab-streams-headers-boilerplates-00.txt）
IAB主導で進められているアーキテクチャに関する活動としては、2008年4月25～26日にストックホルムで開催した会合があり、この結果は、「IPモデルの進化（The evolution of the IP model, draft-thaler-ip-model-evolution-01.txt）」「ピアツーピアのアーキテクチャ（Peer to Peer Architecture, draft-camarillo-iab-p2p-archs-00.txt）」としてまとめられたほか、今回のテクニカルプレナリの企画につながったそうです。
前回報告のあった、ITU-TとIETFによるMPLSの拡張に関するジョイント・ワーキング・チームについては、draft-bryant-mpls-tp-jwt-report-00.txtとして成果がまとめられたそうです。そのほかにも、OECDとも、世界経済におけるインターネットのもたらす経済と将来性についての議論が始まったそうです。
Olaf氏からは最後に、IABのロゴマークが紹介されました。ロゴデザインは、Dow Street氏によるものだそうです。
パネルディスカッション形式で行われた、「IPv6 Deployment Forum」では、開催に先立って、このディスカッションのモデレーターであるIABのGregory Lebovitz氏から参加者に、概要や参考情報などが提示されました。※6
IPv6の普及については、“ニワトリと卵の問題”と揶揄される状況も見受けられますが、そのような状況でもIPv6によるサービスを開始している事業者も出始めています。こうした先例を知ることによって、IPv4の在庫枯渇問題（RIRからの新規割り当てアドレス売り切れ）やIPv6を取り入れていくことにどう立ち向かうのかヒントを得るとともに、IETFがどのようにサポートしていくべきであるのかを見極めたいというのが、今回のパネルディスカッションの狙いでした。
セッションは、Lebovitz氏から、あらためて主旨説明がされた後、IETFが手掛けたIPv6の移行作業の一つとして、NAT-PT（Network Address Translation-Protocol Translation）の話がありました。NAT-PTは、2000年の2月に、RFC2766として発行されましたが、2007年7月にRFC4966により“Historic Status”となっています。しかし、1年たって状況をみてみると、NAT-PTであげられている利用例は現存しており、NAT-PTの必要性は残っているという説明がありました。実際に、IETF72でも、三つのWGと二つのエリアミーティング、一つのBoFで取り上げられていたそうです。
ということで、「現場の苦労を語る」ために選ばれた、5人のパネリストの紹介がありました。
- ARINのMark Kosters氏
- Comcast社のAlain Durand氏
- NTTコミュニケーションズ社のShin Miyakawa氏
- Google社のLorenzo Colitti氏
- Apple社のStuart Cheshire氏
ARINのKosters氏からは、IPv4とIPv6のアドレススペースの動向について、わかりやすい統計資料を用いた説明がありました。IPv4の5大RIRへの割り振りでは、ARIN/RIPE/APNICでそれぞれ30%ずつを分け合っており、これはLIRやISPへの割り当てとほぼ合致するため、実際の利用状況もそのようになっていると言えます。一方で、IPv6の割り振りは、各RIR に/12ずつ均等に分配されているため、その/12内のLIRやISPへの割り当て状況が報告されていました。RIR内の割り当て件数で推移をみると、およそ50%がRIPEで、APNICが30%、ARINが18%、LACNICとAfriNICが2%といった状況であるという報告がされました。また、ポリシー提案状況について、IPv4では枯渇や割り振りサイズであるのに対して、IPv6では、プロモーションをはじめとして割り当てと割り振りそのものについてとなっていて、プロトコルバージョンの普及度合いによって議論の内容に違いがあるという興味深い報告もされていました。
続いて、Comcast社のAlain Durand氏からは、全米一の巨大CATV網におけるIPv6の導入について話がありました。Comcast社では、インフラ（CATVバックボーン）のIPv6対応、その次に家庭への接続計画とラボテストという2段階のアプローチで取り組んできたそうです。CATV業界では、DOCSISというケーブルモデムの仕様があり、これのバージョン3.0で、IPv6対応となっているという事情もあるようですが、それでもベンダーから対応ソフトがなかなか入手できないなどの苦労があったそうです。また、数100万世帯分のIPv4アドレスを苦労して調達・管理し続けるより、IPv6の大きなスペースをまとめて入手し、それを使ったケーブルモデムの管理ネットワークを設計構築してしまう方が安上がりという考えも当初あったようです。
ところが、現実の問題として、ケーブルモデムから先の家庭内の事情として、家庭内の機器はやはりIPv4ベースのものが多く、また、その家庭内の機器の通信先であるコンテンツサーバもIPv4ベースであるという事情から、CATVバックボーンがIPv6に対応しても、IPv4パケットを受け取り、IPv6対応バックボーンを通過して、IPv4網に流す仕組みは必要である、という結論に達したそうです。さらに、IANAからRIRへのIPv4グローバルアドレスの新規割り振りができなくなった際には、これまでのISPからホームゲートウェイにIPv4グローバルアドレスを割り当てられることもなくなります。そのため、現在、同社ではこれまでの、「やがてくるIPv6対応のためのネットワーク計画」に、「IPv4だけの機能しか持たない機器」の救命策の導入を行っているそうです。Durand氏からは、三つのプランが提示されました。
| プランA： | デュアルスタック対応のホームゲートウェイを提供するが、IPv4のみの接続性は提供しないという案 |
| プランB： | IPv4プライベートアドレス対応のホームゲートウェイを提供し、ISPのIPv4プライベート網に接続するダブルNAT案 |
| プランC： | デュアルスタック対応のホームゲートウェイを提供し、IPv4のみの機器にはIPv4overIPv6トンネルを提供してIPv4の接続性をもたせるデュアルスタック・ライト案 |
それぞれのプランのメリット・デメリットを踏まえ、プランCが既存顧客にとっても、デュアルスタックの環境を持つユーザー、将来増えると目されるIPv6顧客のいずれにとってもよいと結論づけていました。そして、プランCを遂行するには、ISPのバックボーン内にIPv4ネットワークをつなぐためのキャリアグレードNAT（Network Address, protocol translator）を導入する必要性を訴えていました。
一方、Google社のIPv6対応はとてもシンプルな要求によるものです。それは、「IPv6だけの環境を持つユーザーが出てきた時にコンテンツを提供できるようになっていること」だそうです。そして、もしもIPv6でコンテンツを提供することが、もっとよいユーザーサービスにつながるのであれば、推進していくというゴモットモな動機が表明されていました。Google社がIPv6を用いることで検証したいのは、具体的には、
- IPv6によって、遅延やパケットロスが低減するかどうか
- NATレスによるAjaxアプリケーションの挙動の向上（多数コネクション接続時のNAPTによるポート消費解消）
- NATトラバーサル対応からの解放（開発時間をもっと別のことに使えるようにしたい）
といったあたりです。また、IPv4の在庫枯渇問題に対するGoogle社の答えも非常にシンプルで、RIRのアドレスプールがなくなった時の根本的な解決策はIPv6を使うということであり、アドレスプールは2011年末になくなることがわかっているのだから、「なぜIPv6なのか」と言っている場合ではなくて、「いつやるべきか」ということが問題であり、
- やるなら早いうちに対応しておく方が良い（サービス品質が求められる前に）
- すぐやる方が後からせっぱつまって対策するより、コスト削減につながる
- IPv6対応は、高等理論いっぱいの難しいことではないが、時間はかかりそうだという考えの着地点が、「今」だった
という説明がありました。とはいえ、Google社におけるIPv6対応も、いわゆる「20%プロジェクト」として開始され、試験環境を整え、社内会合のネットワークで試し、ネットワークが立ち上がることによってアプリケーション側の対応が始まり、という具合に進んできたそうです。その後、規模を大きくし、精度を高める、というステップを踏んできたそうです。そうした体験から、「IPv6はIPv4ほどすんなりとは進まないから、オペレーターは注意深く、ゆっくり、確実に取り組んだ方がいい」という助言がありました。ただし、「高等な理論は必要なく、時間がかかるだけ」というフォローもありました。
ここまでのところ、Google社はIPv6にすごく好意的であるという印象を受けますが、機器・相互運用性についての現状評価は厳しく、期待に反して、実装されていない機能や信頼性がない事象の紹介がされるとともに、「インターネット（相互に接続し合って成り立つネットワーク網）ではない」という嘆きも表明されていました。しかし、解決策の見えている問題ばかりとして捕らえているようであり、その上で、Google品質を保つにはどうすべきか?という課題解決に向けて取り組んでいるようです。また、キャリアグレードNATについての考えは、できるだけクライアントはIPv6に移行すべきと考えているようで、そうした中でもIPv4コンテンツにアクセスすることができるように、「IPv6-Only Networks with NAT-PT」を提案していました。ここでも、IPv4 NATより、こちらの構成の方がまだまし、というアンチNATの発言が強調されていたように思います。最後に、IETFへの要望として、以下の4点が伝えられました。
- IPv6-onlyのネットワークへの最低限のNAT-PT機能（RFC2766の部分的復活）
- point-to-pointリンクへの/127接続（RFC4291の該当部分の改訂）
- IPv6のVRRPの策定
- /48を使ったマルチホーム
最後のパネリストである、Apple社のCheshire氏からは、OS、Apple TVといった機器、iTunesなどのアプリケーション、.MacのようなxSP機能の提供者というあらゆる側面から話がありました。前述のように、Apple社が世に出す製品は沢山あるのですが、どれもIPネットワークを利用するものばかりで、IPv6をサポートした際にも、TCP/IPの基本的な挙動上でのIPv4とIPv6双方の共存面に苦労したようです。Apple社では、そうした困難に遭遇した際には、純粋にOSとして、またアプリケーションとして、それを扱うISPというそれぞれの立場に立って、「これはイケル」と思えるものとそうではないものに整理して対処にあたってきたそうです。
その結果、TCP確立時のIPv6-IPv4フォールバック問題（接続に時間がかかったり、タイムアウトしたりする問題）には、getaddrinfo（）関数をカスタマイズして、IPv6の接続性を確認した上でIPv6のコネクションを張るように改良をしたり、“connect-by-name”と呼ばれるAPIを使って、TCPの名前解決をせずにアプリケーションをオープンするような仕組みを取り入れるといった工夫を随所に施した上での製品提供となっている、という説明がありました。Cheshire氏自身は言及していませんでしたが、説明にあったようなIPv4とIPv6を同時に動かした上で共存状況での挙動について、早くから取り組んできたことによって得た知見が活かされ、対処できているよい例だと思われました。
パネリストの発表が一通り終わった後に、モデレーターと会場からのQ&Aがありましたが、
- DHCPv6を使った設定やDHCPv6 Proxyなどの利用はうまくいくか。問題点はないか
- キャリアグレードNATなどの議論はなぜBEHAVE WGで行われているのか
- softwireはどうなのか
- proxy（Application Level Gateway）はどうなのか
- Googleでv6クライアントのダイレクト・コネクションについて気にするのはなぜなのか
- キャリアグレードNATなどのような中間機器を新しく開発するのは本当に必要なのか
- v4だけでしか通信できない機器は本当にそんなにあるのか。どういう想定なのか。どれぐらい見越す必要があるのか
といった幅広い領域に対する質問が飛び交っていました。キャリアグレードNATなどについては、BEHAVE-WGを中心に議論が継続中です。
IETF Operations and Administration Plenary
Operations and Administration Plenaryでは、今回はホスト・プレゼンテーションも前日のテクニカル・プレナリで行われ、淡々とIETFの運営（NOC、IETFチェア、IETF trustチェア、IAOCチェア、IAD、NomCom、EDUチーム）に関する報告がされました。
標準化作業について、前回のミーティング後からのRFC発行数（88）、I-D投稿数（107）、そのうちIANAに依頼したレビュー数などの報告がありました。
今後のミーティング予定の発表では、次回IETF73のミネアポリスから、IETF76まで来年1年分の発表がありました。次が、2009年の開催予定です。
- IETF74 2009年3月22日～27日 サンフランシスコ（アメリカ）
ホストはJuniper Networks社 - IETF75 2009年7月26日～31日 ストックホルム（スウェーデン）
ホストは.SE - IETF76 2009年11月8日～13日 広島（日本）
ホストはWIDEプロジェクト
その後のIAOC Q&Aの時間に、IAOCから、2010年の開催予定地であるアナハイムとアトランタ（いずれもUSA）に関心のある人は、ホストを探していますのでぜひともよろしく、というアナウンスがありました。
IESG Q&Aでは、IESGの標準化プロセスへの介入方法や、権限について苦情に近い質問が出ていました。これに対して、かなり長時間、IESG内でどういうプロセスを持っているか、議論はどの程度行われているか、著者へのコンタクトやADへの協力体制はどうなっているか、といった説明が丁寧になされていました。途中、ダブリンの醸造所で誕生したギネスビールがIESGに振る舞われるという場面がありましたが、その後も継続して、この質問については、trackerというツールにより著者以外にも全ての人に対してどのようなコメントがされ著者の反応はどうか、といった状況は公開されていること、絶えずADやWGに対して満足されるような支援であるか考えながら進めているといった回答がされていました。
IAB Q&Aは、前もって、Olaf氏よりメーリングリストで事前に質問事項を送って、時間短縮をしようという提案がされていましたが、結局ポストされたのは1件で、内容も、「プレナリの時間は延長可能ですか」というものだったという哀しい発表がされていました。実際の会場からの質問は、nomcom processに関するもの、NATやトンネルプロトコルと協調動作する新しいインターネットプロトコルを作成すべきなのではないかというもの、NATやトンネルプロトコルに関係してUDPのカプセル化についての議論、Unicodeの普及に関しての援助依頼、といった事項があがっていました。いずれも継続した議論となりそうです。
余談
テクニカル・プレナリの「IPv6普及パネル」で、Google社発表の決め台詞として、「IPv6 is Not Rocket Science」という言葉が使われていましたが、発表スライドには、右肩に「TM」とありました。本当に、商標登録しているのか気になるところです（この言葉、初出典は、DNSの設定について述べたBill Manning氏のようです）。
IETF71に引き続き、無線のアクセスポイントとロケーション情報を使った、GEOPRIVとECRIT wgの実験がされていましたが、呼びかけがattendee listで行われる程度で、プレナリでの報告も特段されないのが残念でしたが、今回の実験については、Webサイト※7が開設されていました。実験結果は、それぞれのWGでの活動として実を結んでいるようです。
次回のIETF73は、2008年11月16日から11月21日まで、北米に戻って、ミネアポリスにて、Google社のメインホストで開催されます。すでに、会議の参加登録、ホテルの受け付けなどがスタートしたというアナウンスがありました。
（株式会社インテック・ネットコア 廣海緑里）
- ※1 Computerworld.jp“「IPv6にもNATは必要」--- IETF会長が明言 ”
- http://www.computerworld.jp/topics/nb/116249.html
- ※2 Delay Tolerant Networking Research Group（DTNRG）
- http://www.dtnrg.org/wiki
- ※3 DTN2
- https://sourceforge.net/project/showfiles.php?group_id=101657
- ※4 Internet Congestion Control Research Group（ICCRG）
- http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG
- ※5 Proposed RFC Editor Structure
- http://www.iab.org/documents/resources/RFC-Editor-Model.html
- ※6 IAB's Introduction to the Wed Technical Plenary
- http://www.ietf.org/mail-archive/web/ietf/current/msg52686.html
- ※7 Location Services @IETF72
- http://geopriv.googlepages.com/
