ニュースレターNo.26/2004年3月発行

第58回IETF

第58回IETF会議が、2003年11月9日～14日の6日間にわたり米国・ミネアポリスで開催されました。全体会議、およびIPv6、DNS、セキュリティ関連ワーキンググループ（以下、WG）のレポートをお届けします。

1. 全体会議報告

第58回IETF会議期間中に、各WGのMeetingやBoFなど110の会議が設けられ、連日活発な議論が行われました。さらに、今回のIETF全体会議（Plenary Meeting）は、活動報告を主としたIETF Administration Plenaryと、議論・意見交換を主としたPlenary Presentationで構成され、12日と13日の夜間（19:30～22:00）に開催されました。

◆IETF Administration Plenary

今回の第58回IETF会議には、29の国と地域から1,211名の参加があった旨の報告がありました。最も参加者数が多かった国は米国、2位が日本、3位が韓国以下、ドイツ、フランス、イギリス、カナダ、フィンランドと発表されました。

第57回IETF以降発行されたRFCとしては、DHCPv6（RFC3315）や RFCのSecurity Consider -ations sectionを記述するためのガイドライン（RFC3552）などがあり、SIPに関連するドキュメントが多数発行されていることも特徴の一つとして報告がありました。

IAB（Internet Architecture Board）からは、「音声トラフィックの輻輳制御に関する懸念」「インターネットの研究と発展に関する懸念と提言」などの文書がドラフトされているとの報告がありました。RFCとして公開された文書は、「パケットヘッダ中のサービス識別子の使用に関する考察（RFC3639）」などがあり、「DNS wildcardの使用に関する懸念」を公開したこともトピックの一つになっていました。これらIAB作成の文書は、以下のURLから参照可能ですので、詳細については下記URLをご参照ください。

http://www.iab.org/documents/

IANAからは、新General ManagerにDoug Barton氏が就任したこと、Steve Conte氏がスタッフに加わったことなどが報告されました。また、Workflow Management System の開発が進められており、現在テストが進められているとの報告がありました。

RFCエディタからは、第57回IETF以降、93のドキュメントが提出され、86のRFCを公開した旨の報告がありました。同時に、2003年10月31日時点でInternet-Draft（以下、I-D）149文書が作業処理中であることも報告されました。

http://ftp.rfc-editor.org/in-notes/IETFreports/

Advisory Committeeからの報告では、この委員会の目的「IETFの管理組織とRFC Editor/IETF事務局/IANAとの関係について再検討すること」「IETFの機能を向上させるために必要な組織変更を提案すること」について説明があり、現在IETFが抱える問題点とその改善に向けた提案やRFC2418（IETF Working Group Guidelines and Procedures）の改訂作業が進められていることなどが紹介されました。

◆Plenary Presentation

「Insecurities at the Edge」と題して、セキュリティに関する不安感を利用し、お金をゆすり取る事件が発生している事例（2003年11月11日付 London Financial Times の記事）や、ウイルスの感染力を示すデータ、SPAMの増加傾向を示すデータなどを材料に、インターネットユーザーに降り注ぐ危険性に対してIETFが行うべき対応策の可能性について議論が行われました。また、前日のAdvisory Committeeからの報告を受けて、IETFの組織体制に関する議論が深夜まで行われました。

（JPNIC 技術部小島育夫）

2. IPv6関連WG報告

◆IPv6 WG（IP version 6 WG）

IPv6 WGは今回、11日の夕刻と12日の午後の2コマ開催されました。主なトピックスとしては、

IPv6近隣探索（RFC2461）、ICMPv6（RFC2463）、アドレス自動設定（RFC2462）等、IPv6ベーススペックRFCのStandard化に向けたドキュメント改訂
サイトローカルアドレスの廃止、および新たに提案中の一意ローカルユニキャストアドレスに関する議論

等が議論されました。

ドキュメントの改訂では、IPv6の移動機構を提供するモバイルIPv6に合わせた改訂提案が多く盛り込まれていましたが、この時点での改訂にはモビリティ等、新たな機能に関する変更を盛り込むべきではない、という意見が多く出され、その他の問題も含めて引き続きメーリングリスト（以下、ML）上で議論することとなっています。

サイトローカルアドレスの廃止に関しては、サイトローカルアドレスが持っていた問題点とその利用停止に関するI-D「Deprecating Site Local Address」に関する現状、およびMLで得たコメントの紹介があり、引き続きRFC化に向けて議論を続けることとなりました。

また、サイトローカルアドレスの代替として提案されている一意ローカルユニキャストアドレス（Unique Local IPv6 Unicast Address）については、IETFミーティング以前にWGとして仕様文書のFIX（WG last call）が図られましたがコメントが多く、また、ミーティングの際にもこのアドレスをアプリケーションで特別扱いする必要があるか、サイト境界でのフィルタリングに関する問題等、記載すべき内容がある、といった指摘がありました。結果として再度ドキュメントを改訂後、WGでのFIXを図った後にRFC化に進むこと、とされています。このアドレス空間は、企業内ネットワークやclosedネットワーク等、多くの場所での利用が想定されており、IPv6の普及推進を阻害しないためにも早急な標準化が期待されます。

IPv6 WG: http://www.ietf.org/html.charters/ipv6-charter.html; http://playground.sun.com/pub/ipng/html/ipng-main.html

◆DNSOP WG

（Domain Name System Operations WG）
DNSOP WGでは前回に引き続き、IPv6ネットワークでのDNSサーバアドレスの取得方法（DNS探索）が議論されました。議論の開始時に、議長よりDNS探索に関する議論を今回で終結し、一つの推奨方式を決めたい、との表明があり、また、参加者からも、どの方式を実装するかを判断するためにも早急に決めてほしいという要望があがっていました。

今回議論の対象になったDNS探索手法は、

簡易DHCPを用いる方法
<IPv6 DHCP-lite>
well-knownアドレスを用いる方法
<Pre-configured server address>
ルータ通知（RA）を用いる方法
<Router Advertisement>

の三つに大別でき、それぞれI-Dとして提案されています。議論では、それぞれの方法のドキュメントの現状、実装状況、得失等が報告され、また各手法の詳細に関する質疑応答が実施されました。既に標準化がある程度進んでいる簡易DHCPによる方法を推奨する意見が多かったのですが、モバイルIPv6等の移動系における利用や非力なノードでの実装の容易さを理由として、ルータ通知手法に対してもかなりの支持がありました。参加者の多くは一つの手法に絞ることには賛成でしたが、どの方式にするかという明確な結論はでず、議論は持ち越しとなっています。
※DNSOP WGについては「3.DNS関連WG報告」もご覧ください。

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

◆v6OPS WG（IPv6 Operations WG）

v6OPS WGは10日と12日午後に、2コマ開催されました。前回から引き続き、IPv6の導入シナリオ、ノードでIPv6機能をデフォルトで有効にすることに関する是非等について議論がありました。また、実際にIPv6デュアルスタックサービスを実施しているプロバイダからの具体的な事例が紹介されました。第三世代携帯電話ネットワーク（3GPP）／IS／企業ネットワーク／SOHO等管理者不在のネットワークのIPv6導入シナリオは、企業やISP等の協力を得て進展しており、どこまで文書化する必要があるのかを考え、収束を図りつつある状況です。

v6OPS WG: http://www.ietf.org/html.charters/v6ops-charter.html; http://www.6bone.net/v6ops/

◆MULTI6 WG（Site Multihoming in IPv6 WG）

IPv6インターネットに特化したマルチホーム手法を検討するMULTI6 WGでは前回百出した議論を整理し、WGとしての方向性を明確にするためにデザインチームを組織してマルチホーム手法の案を作成し、今回のミーティングでその案が議論されました。SOHO等、小規模ネットワークに対しては始点アドレスによるルーティングによって冗長性を確保するという案が紹介され、ドラフト化にむけた作業が行われることになっています。より一般的なマルチホームの解法としては、IPアドレスが本来持っている位置指定の機能と識別子としての機能を明確に分離し、ホストにアドレスとは別の不変の識別子を付与することによってマルチホームを実現しよう、という案が出されました。今後は、これらの案を含めてMULTI6で扱うトピックスを限定し、有効なマルチホーム実現手法を検討していくことになっています（具体的には、次回のミーティングまでに提案された手法のみを議論の対象にする、ということになっています）。

（JPNIC IPアドレス検討委員会メンバー／NTT情報流通プラットフォーム研究所藤崎智宏）

議論が集中した新マルチホーム案：

draft-nordmark-multi6-noid-01.txt
draft-nordmark-multi6-sim-01.txt
draft-nordmark-multi6-threats-00.txt

MULTI6 WG: http://www.ietf.org/html.charters/multi6-charter.html

3. DNS関連WG報告

◆DNSOP WG

今回のDNSOP WGミーティングは、2日にわけて行われました。まず、初日のセッションでは、現在I-Dとして発行され、標準化が進行している文章に関して、更新時の変更点と文章の現状の確認が行われました。また、期限切れになった文章に関して、WGとして必要な文章は、更新して復活させるべきとの議論が行われました。次に、DNS Security（DNSSEC）を運用していくにあたって必要となる、Key Rolloverに関する要求事項をまとめよう、という議論が行われました。さらに、初日の最後の議題として、これからの DNSOP WG活動の方向性を決めるために、WGチャーター更新に関する話し合いが行われました。その結果、DNSSECの運用に関して必要な議論である、Key RolloverやKey Management、Key長増大によるパケットサイズへの影響といった項目を、WGとして活発に行っていこうという確認がなされました。

2日目には、前回のIETFにおけるDNSOP WGミーティングからの課題となっていた、IPv6におけるDNSサーバ発見の仕組みを決定するための議論が行われました。IPv6では、ホストの自動設定を行う際に、ステートレス自動設定が利用される場合が多く、この場合にDNSサーバのアドレスを通知するための仕組みが必要とされています。この仕組みとして、以下の3種類が提案されています。

　IPv6 DHCP-lite
　Pre-configured server address
　Router Advertisement

IPv6 DHCP-liteとは、IPv6 DHCPを利用してDNSサーバのアドレスを通知する仕組みです。Pre-configured server addressとは、あらかじめ定義されたIPv6アドレスを用いanycastによってDNSサーバを提供する仕組みです。最後に、Router Advertisementとは、DNSサーバアドレスをRouter Advertisementに含んで通知する、という方法です。セッションの最後に、どの方法を標準とするか、チェアが議決を行おうとしたのですが、まだそれぞれの方式に関しての議論が活発に交わされ、統一するに至りませんでした。IPv6普及のために必要な機構であるため、今回のミーティングで決定できなかったのは残念です。

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

◆DNSEXT WG

DNSEXT WGでは、主にDNSSECに関する議論が行われました。WGから発行されているI-Dも、DNSSECに関するものが多くなっています。まず、現在発行されているI-Dの状態が確認されました。次に、DNSのwildcardレコードの利用方法を明確化するための議論が行われました。さらに、次世代DNSSECの仕様を決めるための議論が行われました。

DNSSECの基本仕様は、過去に一度提案されたのですが、実際の運用に適した仕様でなかったため、あまり利用されませんでした。そこで、もっと運用に適したDNSSECの仕様を決定しようという動きがあり、DNSEXT WGにて議論が開始されました。この流れを受け継いで、今回のDNSEXT WGのミーティングでは、DNSSECの仕様に関する議論に一番時間が割かれました。DNSEXT WGでは、次回も引き続きDNSSECに関する議論が行われていきます。

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

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

4. セキュリティ関連WG報告

今回のIETFでは、14のセキュリティエリアのセッションが行われ、そのうちの四つがBoFでした。BoFは人気のあるセッションなので、ほとんどが100名を超える盛況ぶりでした。これらのBoFを含めて、セキュリティ（認証とIPsec）に関連したセッションの話題をお送りします。

◆LTANS WG （Long-Term Archive and Notary Services WG）

文書の長期保存と公証サービスに関するWGです。今回のIETFで、初めてセッションが開かれました。文書の長期保存と公証サービスとは、電子文書に電子署名を施し、それを長期にわたって維持することで、記載事実の正当性を長期的に担保するサービスです。

想定されているサービスでは、電子署名を利用するためにPKI（Public-Key Infrastructure）を用いるため、このセッションにはPKIX（Public-Key Infrastructure eXchange）WGのチェアであるTim Polk氏を始め、PKIX WGで相互運用性実験ChallengePKI 2002の紹介をされたことのある稲田龍氏など、PKIX WGに関係した参加者が多く見られました。

今回のセッションでは、長期保存のサービスを実現するためのフォーマットとそのサービスにアクセスするためのプロトコルを決めるという目的の確認や、このWGで扱う要求事項の範囲についての議論などが行われました。

LTANS WG: http://www.ietf.org/html.charters/ltans-charter.html

◆Profiling Use of PKI in IPSEC BoF

PKIを利用した認証機能をIPsecで利用するため、PKIの公開鍵証明書がどのように扱われるべきかを決める目的のBoFセッションです。IPsecおよびIKE （Internet Key Exchange）のためにPKIを正しく活用できる場面が少ないという状況を打開するため、利用形態をトンネルモードに限定するなどしてモデルの単純化を図っています。

このBoFでは、PKIX WGやIPsec WGに関係した参加者が多く見られ、また参加者が100名を超えており、活発で真剣な議論が行われていました。今回のセッションでは、チャーターの内容、特に目標と実現ステップを中心に議論が行われました。

Profiling Use of PKI in IPSEC BoF: http://www.ietf.org/ietf/03nov/pki4ipsec.txt

◆PKIX WG (Public-Key Infrastructure eXchange WG)

X.509に基づいて、PKIのさまざまな仕様を標準化することを目的としたWGです。RFC3280、RFC3281が出て以降、最近のPKIX WGではLDAP（Lightweight Directory Access Protocol）関連の仕様や証明書のパス構築の再ドキュメント化、OCSP（Online Certificate Status Protocol）やSCVP（Simple Certificate Validation Protocol）といったオンラインプロトコルなどについての議論が主に行われています。まず最初に各ドキュメントの状態が紹介されました。

前々回までに議論が行われていたPermanent Identifier、CMP、CRMF、Logotypes
→IESGからいくつかのコメントが出ている状態
IPアドレスとAS識別子を証明書に含めるプロファイルのI-D、代理の認証を行う証明書プロファイルのProxy Certificate
→エリアディレクターのコメント待ち
SCVP、Attribute Certificate Policies extension、Qualified Certificates Profile、Certification Path Building、NIST Recommended EC、Domain Parameters For PKIX
→ WG Last Callの状態
SIM、LDAP Specification、Progression of 3279/3280（3280bisにあたるものが2004年早々にI-Dとして出されるようです）、OCSPv2 extensions
→ 現在WG内で議論が進行中

この後、RFC3039になっているQualified Certificateの更新と、Certificate Path BuildingのI-Dに関するプレゼンテーションが行われました。PKIX WGのセッションでは毎回、最後にPKIX WGに関連する活動の紹介などが行われます。今回はOASIS PKI Technical CommitteeのPKIに関する取り組みとNISTにおける相互運用実験のパス検証に関する紹介が行われました。