ニュースレターNo.33/2006年7月発行

第65回IETFレポート

全体会議報告

2006年3月19日～24日まで、米国ダラスのヒルトンホテルにて第65回IETFが開催されました。開催日となる3月19日は、20数年ぶりとなる嵐でホテルの前の道路が冠水するという異例の事態でした。開催期間中は、一転して雨もなく晴天の中での開催となりました。

今回のIETFの参加登録者数は、1,324名(36ヵ国)と発表がありました。ここ数回の推移を見てみますと、極端に人数の増減はなく、参加人数が1200～1500名程度に安定してきているようです。

今回のIETFでは、123のセッションが開かれました。このうち、7セッションがBoFでした。ここでは、通常、水曜日と木曜日に行われるPlenaryの様子を報告いたします。

Operations and Administration Plenary

通常、水曜日に行われるPlenaryは、IETFの運営に関する全体会議になります。内容は、IETF議長による参加人数の報告から始まって、スポンサーであるNokia社の紹介、ネットワーク状況の報告、IESG^※1の新旧メンバー紹介、RFCエディタやIANA^※2からの活動報告などです。

まず、議長であるBrian Carpenter氏から参加者の報告があり、IETF全体の活動概要として、前回のバンクーバー会議から今回の会議までで7個の新しいWGが開催され、18のWGが終了し、184のRFCが発行されたと報告がありました。

その後、スポンサーであるNokia社の携帯端末製品の紹介やネットワークの設営に貢献した方の紹介がありました。特に、無線ネットワークの環境については、通信が途絶えるということもなく、非常に快適な環境でした。(毎回、ネットワーク環境で悩まされたりしますが、今回は、苦痛に感じることはありませんでした。)特に、今回は、開催初日が嵐ということで、作業をされた方には、特別に苦労があったようです。

また、IESG及びIAB^※3のメンバーで勇退される方の紹介があり、特に長年、IESGのメンバーとして尽力していたBert Wijnen氏、Allison Mankin氏に対して、IETF議長から感謝の言葉がありました。

最後は、オープン・マイクロホンということで、参加者が自由に発言できる時間となります。そこでは、RFCとしてドキュメント化する際のレビューアの選定の仕方に関するコメントや役員の重複の仕方などについてコメントがよせられました。中には、休憩時間のクッキーの数が少ないというようなコメントもありましたが、翌日には改善されていました。(私もこのコメントの恩恵を得ることができました。)

Technical Plenary

通常、木曜日に行われるPlenaryは、技術的な議論を行う全体会議になります。まず、IAB、IRTF^※4での活動報告が各議長より行われました。

IRTFの報告では、IRTF全体の概要として、新しいリサーチ・グループとなるTransport Modeling Research GroupとInternet Congestion Control Research Groupが活動を始めたということやその他のグループのトピックスの紹介がありました。

続いて、End-to-Endリサーチ・グループからそのグループの概要や現在、注目している点について報告がありました。このグループでは、将来のインターネットが、どのようになるのか、その技術要素について議論しており、量子コンピューティング、センサー端末などをキーワードにどのようなアーキテクチャを必要とするのかについて、評価をしていくという報告がありました。

IABメンバーであるEricRescorla氏からは、「分散ハッ シュテーブル入門」と題して、プレゼンテーションが実施されました。現在のP2Pネットワークの基礎技術となっている分散 ハッシュテーブルについて、Chord方式に注目してその技術的な紹介が行われました。関連して、セキュリティに対する課題やDNSへの応用、SIPPINGもしくはSIP-P2P BoFで議論されている位置情報を分散ハッシュテーブルに格納して、SIPによるVoIPを実現する方法などが紹介されました。

その後、IAB議長からは、最近のIABの話題として、IPv6のマルチホームに関する議論、アーキテクチャの観点からプロトコル策定に関する議論、SPAM、Phishingに代表される予期しないトラフィックに関する議論があがっていることの報告やIRTF、ISOC^※5に関連した活動の報告がありました。

今回のIETFは、20th Anniversaryということで、Social Eventなどところどころにこれを祝うロゴが見受けられました。21年目となる次回は、Ericsson社スポンサーによるカナダ・モントリオールでの開催となります。

(NTT情報流通プラットフォーム研究所 小林淳史)

DNS関連WG報告

dnsop WG(Domain Name System Operations WG)

IETF65では、2時間のWGミーティングが開催されました。まず初めに行われた議論は、WGチャーターの更新でした。議論の結果、dnsop WGの新しい活動内容として、以下の6つが提案されました。

1. DNS zoneのSOAレコードやTTL、グルーレコードを含め、DNSの動作に影響を与える設定に関するガイドラインを作成もしくはレビューする
2. DNSSECの運用に関するガイドラインを作成もしくはレビューする
3. IPv4/IPv6混在環境における運用のガイドラインを作成もしくはレビューする
4. DNSを利用した他のプロトコルに関してレビューする
5. リゾルバとサーバの性能評価
6. DNSに関する用語の定義

今までのWGの活動から大きく変化するわけではなく、DNSSEC運用やIPv6/IPv4混在環境におけるDNSの運用に議論の重点がおかれる点は変更ありません。

次に、draft-andrews-full-service-resolversに関する議論が行われました。このドラフトは、リゾルバサーバとして機能するDNSサーバが持つべきzoneについて提案したものです。RFC1918のアドレススペースやローカルアドレスとして利用されているアドレススペースに関して、逆引のauthoritative zoneを持つべきと提案がなされました。

最後に、Open Resolverについての注意の喚起が行われました。アクセス制限をかけていないリゾルバサーバがDoS攻撃に利用される事象が発生しているので、WGとしてガイドラインが必要ではないか、と提案がありました。

□dnsop WG

http://www.ietf.org/html.charters/dnsop-charter.html

□第65回IETF dnsop WGミーティングのアジェンダ

http://www3.ietf.org/proceedings/06mar/agenda/dnsop.txt

dnsext WG(DNS Extensions WG)

ドキュメントの進展確認では、LLMNR(Linklocal Multicast Name Resolution)の仕様を定めたドラフトが、Informational RFCとなることが確認されました。

DNSSECに関する議論では、前回に引き続きNSEC3に関する報告が行われ、解決された7つの問題と、まだ残る6つの問題について述べられました。残っている課題の中には、NSEC3に特有の問題ではないものも含まれています。しかし、仕様として固まるには、もう少し時間がかかりそうです。詳しくはhttp://www.nsec3.org/に明記されています。さらに、DNSSEC認証の起点となる、Trust Anchorの自動更新に関する議論が行われました。まだ議論の段階であり、手法の詳細は決定していない段階です。要求事項の洗い出しが行われました。

また、TAHI ProjectによるDNSテストイベントの結果が報告されました。DNS実装の仕様をテストするためのツールも公開されました。詳しくはhttp://www.tahi.org/dns/ に述べられています。

最後に、RFC4035をさらに更新することも議論され、NSEC3を盛りこみ、wildcardの扱いに関して追記すべきことが議論されました。

□dnsext WG

http://www.ietf.org/html.charters/dnsext-charter.html

□第65回IETF dnsext WGミーティングのアジェンダ

http://www3.ietf.org/proceedings/06mar/agenda/dnsext.html

(JPNIC DNS運用健全化タスクフォースメンバー/東京大学 情報基盤センター 関谷勇司)

IPv6関連WG報告

2006年3月19日～24日にかけて米国はダラスで開催されました第65回IETFミーティングのIPv6関連WGの動向についてレポートします。前回の第64回IETFミーティングをもってipv6 WGのセッションは最後となり^※6、今回はipv6 WGのセッションは行われませんでした。しかし、IPv6に関係するトピックは様々なワーキンググループで取り上げられており、IPv6自体に関する議論を行うフェーズから、IPv6をいかに使うかを議論するフェーズへとシフトしているという印象を受けました。その中で、v6ops、intarea、shim6というIPv6に関連の深いWGのトピックをご紹介します。

v6ops WG (IPv6 Operations WG)

IPv6の運用上見つかった問題や、デプロイメントに関する話題を扱うv6ops WGのミーティングは、3月23日前回同様2時間で行われました。

今回のセッションで発表された主なトピックは、

• ケーブルテレビネットワークにおけるIPv6導入シナリオの検討
• ワイヤレスブロードバンドアクセスネットワークにおけるIPv6の普及シナリオ(draft-shin-v6ops-802-16-deployment-scenarios-00.txt)

などや、また既存のドラフトに対する変更点の紹介などでした。

米国のケーブルテレビにおける通信規格等の標準化を 行っているCableLabsという研究組織から、ここでケーブルテレビネットワークにおいてIPv6の導入シナリオが検討結果の発表がありました。ケーブルモデムをL2ブリッジとするモデルや、 ルータとするモデルなどが検討され、ここでユーザーに配布するアドレスブロックとケーブルモデム自体に付与する管理用のアドレスを別々のものとすることや、ユーザーへのアドレス配布はDHCPv6を用いることなどが提案されました。DHCPv6を用いる理由としては、RAよりも厳密なアクセス制御が行えることと、現在のIPv4のアクセスネットワークにおけるモデルを踏襲したということでした。DHCPv6の利用を強制するための方法として、RA(ルータ広告)にはプレフィックスリストを付けず、RAのMフラグとOフラグを1にセットして広告するという手法を提案していましたが、会場からはその方法は何か問題を引き起こすかもしれないというコメントがありました。

v6opsでは、様々な環境におけるIPv6の普及シナリオ・導入モデルを検討し、それらをRFCとして公開してきました。IEEE802.16において検討されてきた、WiMAX等のブロードバンドワイヤレスアクセスネットワーク技術のサービス開始を目前に控え、こういった環境でのIPv6の導入モデルについて、ETRI(韓国電子通信研究院)とサムソン社といった韓国のメーカーから提案がありました。BS(Base Station: ISPの基地局)やMS(Mobile Station: 加入者の基地局)といった設備に対して、どういったトポロジーを用い、アドレスを割り当てるのかといったモデルの検討や、802.16のアクセスリンク上で、IPv6のQoSやMulticast をどのように実現するか、といった検討の結果が発表されました。

□v6ops WG

http://www.ietf.org/html.charters/v6ops-charter.html

□第65回 IETF v6ops WG ミーティングのアジェンダ

http://www3.ietf.org/proceedings/06mar/agenda/v6ops.txt

intarea WG(Internet Area Open Meeting WG)

Internet Areaの各WGのトピックの紹介や、どのWGにも属さないトピック、またエリア全体のトピック等が扱われるInternet Areaのオープンミーティングが行われました。最初に、MargaretWasserman氏に代わって、エリクソン社のJari Arkko氏が新しいAD(エリアディレクター)に就任したという発表があり、もう一人のADであるMark Townsley氏とのエリア内のWGの分担について説明がありました。なお、ipv6やshim6など、6lowpanを除くIPv6関連WGの多くはJari Arkko氏の担当となりました。

IPv6に関するトピックとしては、IESGに届くInternet-Draftの多くにIPv6に関する誤りが含まれているという指摘がMargaret Wasserman氏からありました。アドレスアーキテクチャの違いや、フラグメンテーション、MTU関係、Neighbor Discoveryや、ドキュメント用IPv6プレフィックス等に関する誤解が多く見受けられ、またIPv6を完全に無視しているものも多いということでした。IPv6に関する記述を強制することについて議論が行われ、各WGのCharterでIPv6に関する扱いを明記すべきであるという意見や、その記述がない場合の扱いを規定すべきである等の意見が出されました。

□第65回 IETF intarea WG ミーティングのアジェンダ

http://www3.ietf.org/proceedings/06mar/agenda/intarea.txt

shim6 WG(Site Multihoming by IPv6 Intermediation WG)

shim6はIPv6において小規模サイトがマルチホームするための方式の検討を行ったmulti6というWGの後継となるWGです。現在IPv4においてグローバルルーティングテーブルの増大を招いているとされるPIアドレスを導入せずに、通信を行うエンドホスト間の連携によりマルチホームを実現するshimと呼ばれる方式のプロトコル策定を行うことを目的として設立されました。昨年はIETFのプレナリーでも取り上げられ、NANOGなどのオペレータグループでも盛んに議論が交わされるなど、IETFのみならずインターネットの未来を占う重要なトピックといえるでしょう。

今回のセッションの主なトピックは以下の通りです。

• shimプロトコルの仕様について
  (draft-ietf-shim6-proto-04.txt)
• IABマルチホームBoFについて報告
• shimプロトコルのID/Locatorスプリット拡張
  (draft-nordmark-shim6-esd-00.txt)

shimプロトコルの基本仕様は、interimミーティング等を経てほぼ決定され、軽微な修正が施されるのみという状況になっています。今回の発表では、前回のセッションからの変更点が説明され、WGLC(WGでの最終合意)を行ってもよいかどうかという提案がなされました。会場からは、このshimプロトコル自体は問題ないが、実装はまだ存在しないという状況でExperimentalとして標準化すべきではないか、今後誰が実装を行うのか、またMobileIPv6やHIP(Host Identity Protocol)との関係はどうなっているのか同じホストで同時に使用できるのか、という質問や意見が出され、Last Callを行うには至りませんでした。

NANOG35やAPRICOT2006において、shim6の提案するマルチホーム方式に関するオペレータとの議論が行われ、その報告がありました。現在のマルチホームはバックボーンルータでの経路制御によってサイト単位で実現されていますが、shim6のアプローチはホスト単位でこれを行うことになり、この変更点は非常にインパクトが大きく、特にトラフィックエンジニアリングに関してこれまで実現できていたことが実現できなくなる、という意見が出されました。また、それ以外にもエンドシステムにこの機能を持たせることで、エンドシステムが複雑になり スケーラビリティの問題があるということも指摘されました。

そしてセッションの最後に長時間を割いて行われたのが、shimプロトコルのID/Locatorスプリット拡張の議論です。これは、shimプロトコルにグローバルユニークなID(ホスト識別子)を導入し、また経路上のルータにおいてアドレスの書き換えを許すことで、サイト単位でのトラフィックエンジニアリングを可能にするというものです。これは上で述べた最近のNANOG等のコミュニティからのトラフィックエンジニアリングに対する要望に応えた提案になっています。会場からは、グローバルユニークなIDを導入するのであれば、HIPと同じになるので、協調して進めていくべきだという意見が出ました。

一度は決まりかけたかに見えたshimプロトコルですが、ここにきて実運用上の課題が浮き彫りになり、大幅な方向転換を視野にいれた検討が行われるなど、再びmulti6時代の混迷を彷彿とさせる状況になっています。今後の動向が注目されます。

□shim6 WG

http://www.ietf.org/html.charters/shim6-charter.html

□第65回 IETF shim6 WG ミーティングのアジェンダ

http://www3.ietf.org/proceedings/06mar/agenda/shim6.txt

(NTT情報流通プラットフォーム研究所　松本存史)

---

※1　IESG：Internet Engineering Steering Group

IETFの活動と標準化プロセスの、技術的な側面についての責任を担っているグループ

※2　IANA：Internet Assigned Numbers Authority

南カリフォルニア大学情報科学研究所(ISI)のJon Postel教授が中心と なって始めたプロジェクトグループで、ドメイン名、IPアドレス、プロトコル番号など、インターネット資源のグローバルな管理を行っていた。2000年2月にはICANN、南カリフォルニア大学、及びアメリカ政府の三者の合意により、IANAが行っていた各種資源のグローバルな管理の役割はICANNに引き継がれ、現在IANAは、ICANNにおける機能の名称として使われている。

※3　IAB ：Internet Architecture Board

インターネットの技術コミュニティ全体の方向性やインターネット全体のアーキテクチャについての議論を行う技術者の集団。ISOCの技術理事会(Technical Advisory Group)としても機能し、インターネットを支える多くの重要な活動を監督している。

※4　IRTF：Internet Research Task Force

http://rfc-jp.nic.ad.jp/what_is_ietf/ietf_section3.html

※5　ISOC：Internet Society

非営利の国際組織で、インターネット技術およびシステムに関する標準化、教育、ポリシーに関する課題や問題を解決あるいは議論することを目的としている。

※6　WG自体は継続しMLでの議論は行われている