━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 1 】特集 「第60回IETF報告」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
……………………………………………………………………………………………
1. 全体会議報告
JPNIC 技術部 木村泰司
……………………………………………………………………………………………
◆概要
2004年8月1日(日)～2004年8月6日(金)、米国カリフォルニア州・サンディエゴ
にあるSheraton San Diego Hotel & Marinaにて、第60回IETFが開かれました。
サンディエゴはアメリカ西海岸のメキシコに近くにある都市で、一年を通じて
気候が温暖であることで知られているところです。しかし今回は8月でありな
がら、夜になると長袖が必要になるほど肌寒くなることがありました。
今回のIETF参加登録人数は1,511名でした。第59回（韓国・ソウル）の1,255名、
第58回（米国・ミネアポリス）の1,233名、第57回(オーストリア・ウィーン）
の1,304名に比べて増加しています。最も参加人数が多かったのはアメリカで、
次いで日本、韓国、ドイツ、フランスと続いていました。合計で40ヶ国からの
参加があったようです。
今回のIETFでは、120以上のセッションが開かれ、その中で11のBoFが開かれま
した。前回と同様に、Plenary（全体会議）はIETF Business MeetingとIETF
Planning Meetingの二つに分かれて行われました。
◆IETF Business Meeting
IETF Business Meetingでは、今回のIETFでのネットワークに関する報告、RFC
Editorからの報告、IANA(*1)による報告、IESG(*2)による報告、IESGのプロセ
スチーム（PROTO）の紹介、WSIS(*3)における議論の紹介、IAB(*4)からの報告
が行われました。
RFC Editorからの報告では、RFC1が発行されてから2004年4月7日がちょうど35
周年にあたることや、RFC2223の記述に代わる新たな著作権表示と知的所有権
に関するアナウンスがありました。詳細は下記Webページをご覧ください。
□RFC Copyrights
http://www.rfc-editor.org/copyright.html
IESGからはPROTOチームに関する報告がありました。PROTOチームとは、エリア
ディレクター（以下、AD）のドキュメントプロセスの一部を担うグループで、
2004年1月に結成されています。PROTOチームに関する詳細は下記Webページを
ご覧ください。
□IESG Process and Tools（PROTO）Team
http://www.mip4.org/proto/
(*1) IANA：http://www.nic.ad.jp/ja/tech/glos-ij.html#02-IANA
(*2) IESG：http://www.nic.ad.jp/ja/basics/terms/iesg.html
(*3) WSIS：http://www.nic.ad.jp/ja/tech/glos-kz.html#03-wsis
(*4) IAB：http://www.nic.ad.jp/ja/tech/glos-ij.html#02-IAB
◆IETF Planning Meeting
IETF Planning Meetingでは、IRTF(*5)のASRG(*6)からSPAMの現状と対策に関
するプレゼンテーションと、IABによるSecurity workshopに関する報告、IETF
の新たなドキュメント体制チームのステータスレポート、IETFの管理組織に関
するステータスレポートが行われました。
ASRGのプレゼンテーションでは、SPAMメールが、必要なメールよりも多く配送
されている現状や対策、関連するプロトコルの標準化活動を行っているMARID
WG(*7)の紹介が行われました。
IABのSecurity workshopに関する報告では、CERTに報告されるインシデント数
の増加や詐欺行為の発生といった、量的・質的な変化、SSHやVPNといった技術
の適用場面の特徴、Peer-to-PeerのセキュリティやDDoS、フィッシングといっ
た未対策である分野の年代別の違いなどが紹介されました。
IETFの新たなドキュメント体制チームについては、General ADのHarald
Alvestrand氏よりステータスレポートが行われました。第59回IETFの頃から始
まった、ドキュメント化プロセスの効率化はICAR(*8)、NEWTRK(*9)、PROTO、
EDUといったチーム（一部WG）によって進められており、それぞれの人数や活
動内容のドキュメント化が進んでいるといった報告が行われました。
最後にIETFの運用組織（Administrative Group）に関して、ドキュメント化が
進行中である旨の報告、コンサルタントのCarl Malamud氏の紹介、
Administrative GroupがどのようにISOC(*10)と関連していくかについてのプレ
ゼンテーションが行われました。
(*5) IRTF：http://rfc-jp.nic.ad.jp/what_is_ietf/ietf_section3.html
(*6) ASRG：Anti-Spam Research Group
http://asrg.sp.am/
(*7) MARID WG：MTA AuthorizationRecords in DNS WG
http://www.ietf.org/html.charters/marid-charter.html
(*8) ICAR：Improved Cross-Area Review
http://www.ietf.org/html.charters/icar-charter.html
(*9) NEWTRK：New IETF Standards Track Discussion
http://www.ietf.org/html.charters/newtrk-charter.html
(*10) ISOC：http://www.nic.ad.jp/ja/tech/glos-ij.html#02-ISOC
……………………………………………………………………………………………
2. IPv6関連WG報告
JPNIC IPアドレス検討委員会メンバー
NTT情報流通プラットフォーム研究所
藤崎智宏
……………………………………………………………………………………………
◆MULTI6（Site Multihoming in IPv6）WG
MULTI6 WGは8月2日(月)の午前中に開催されました。このWGは、IPv6インター
ネットに特化したマルチホーム（【 4 】インターネット用語1分解説参照）手
法の検討・標準化をその目的としています。
MULTI6 WGではIETFに先立ち、2004年6月に、同じカリフォルニア州のサンタモ
ニカにて中間ミーティング（Interim Meeting）を実施しました。この中間ミー
ティングにて、前回ソウルで開催された第59回のIETFミーティングで提案され
た30あまりの提案を整理し、その整理に基づき今後MULTI6 WGで実施していく
標準化の内容について議論をしました。その結果、マルチホーミング問題の根
本的な解決を目指した、IPアドレスのホスト識別子としての機能とインターネッ
ト上の場所を示す場所指定機能を分離する手法（Wedgelayer 3.5／Fat IPと呼
んでいます）にしぼって、今後WGにて検討を進めていくことになっています。
今回のミーティングでは、中間ミーティングの結果を受け、WGの文書として
RFC化を進めている文書の進捗報告（IPv4でのマルチホーミング手法の整理を
実施した文書、マルチホーミングを実施する際に考慮すべき点を整理した文書、
マルチホーミングの主にセキュリティの観点からの脅威をまとめた文書、IPv6
におけるマルチホーミング手法を体系的に整理した文書の標準化が現在進行し
ています）、および、Wedgelayer 3.5／Fat IP手法の今後の進め方の議論が実
施されました。次回のIETFまでに、現在提案されているいくつかの同系統提案
をマージし、WGとしてのマルチホーミング手法提案を完成することを予定して
います。
□multi6 WG
http://www.ietf.org/html.charters/multi6-charter.html
□60th IETF multi6 WG のアジェンダ
http://www.ietf.org/ietf/04aug/multi6.txt
□Interim Meeting のアジェンダ
http://www.ietf.org/meetings/Interim-MTGs/Multi6-Interim.txt
◆IPv6（IP version 6）WG
IPv6のコア技術の標準化を進めているIPv6 WGのミーティングは、8月4日(水)
午後の1コマ2時間でしたが、検討項目が非常に多く、活発な議論が実施されま
した。
今回話し合われた主なトピックスは、
・IPv6近隣探索（RFC2461）、アドレス自動設定（RFC2462）等、IPv6ベースス
ペックRFCのドキュメント改訂
・前回に引き続き、Optimistic DAD（簡易重複アドレス検出）に関する議論
・IPv6のアドレス自動設定の際に利用されるパケット中の二つのフラグ（Mフ
ラグとOフラグ）の取り扱い
などです。
まず、議論のはじめに、DNSOP WGにてとりまとめを実施した、IPv6における
DNS探索機構に関する文書について、現状報告とIPv6 WGとしての意見紹介があ
りました。この文書は前々から懸案事項になっている、IPv6ノードがDNSサー
バを発見するための複数の提案について、三つの提案（DHCP利用、ルータ広告
（RA）利用、well-knownアドレス利用）を整理、比較したもので、現在DNSOP
WGにてラストコール中となっています。提案を一つか複数かにしぼるのかどう
かなどといった今後の進め方について、DNSOP WGでもはっきりとした方向性は
出ていませんが、IPv6 WGにおいてもWGに提案が挙がっているルータ広告を利
用する手法について標準化を進めるべきかどうか結論は出ず、DNSOP WGの進捗
待ち、という形になっています。
ドキュメントの改訂は、RFC2462改訂文書がWGラストコールを終了、IESG送付
を実施、RFC2461、RFC2463改訂文書がIETF後WGラストコール実施予定となって
います。
前回、多くの時間が割かれた Optimistic DAD（簡易重複アドレス検出）に関
しては、機構としてはほぼ問題点も収束し、RFC化に向けて進めることにはな
りましたが、後方互換性（既存機器に本当に影響を及ぼさないか）についての
懸念が表明され、この部分に関しては継続して議論を続けていくことになって
います。
アドレス自動設定において、ノードの動作を制御するルータ広告パケット中の
Mフラグ（Managed address configurationフラグ）、Oフラグ（Other
stateful configurationフラグ）に関しては、このフラグの解釈について曖昧
な点があったため、それを整理しました。ルータ広告がない場合にはどうする
かなど検討もれがあり、再整理をすることになっています。
全体的に、標準における細かな部分（オプションの解釈など）の再整理、利用
時の問題が中心になってきており、IPv6の標準化としては特に大きな問題はな
く、順調に進んでいるという印象を受けました。
□IPv6 WG
http://www.ietf.org/html.charters/ipv6-charter.html
http://playground.sun.com/pub/ipng/html/ipng-main.html
□60th IETF IPv6 WG のアジェンダ
http://www.ietf.org/ietf/04aug/ipv6.txt
◆v6OPS（IPv6 Operations）WG
v6OPS WGは8月2日(月)午後と5日(木)午前に2コマ開催されました。今回、最初
の予定では2コマ目が金曜日午前に割り当てられていたのですが、前回も含め
ここしばらく金曜日にはWGミーティングが開催されてないこともあり、既に予
定を決めてしまったなど多くの変更要望があがったため、木曜日午前に2コマ
目のスケジュールが変更になった、とどたばたした経緯がありました。
さて、v6OPSでは、ここ数回、IPv6への移行シナリオ、移行技術を中心に活動
を進めてきました。移行シナリオのうち、特に企業向けシナリオに関しては、
進捗が遅いということで早急な進行が要請されました。今回のIETF終了後、早
急にRFC化に向けた作業が進められる予定です。移行シナリオ関連では、大学
キャンパスネットワークのIPv6移行のケーススタディが報告されました。IPv4
と比べ、アクセス制御に難点があること、PKI等、IPv6対応が必要なプラット
フォームがあること、NFSやX11など、対応が未熟なソフトウェアがあることな
どが挙げられており、会場からは、NFSはかなり前から対応済みであるはずだ
等の意見が寄せられました。
移行技術に関しては、今回も多くの時間が割かれており、トンネル端点の自動
設定、トンネルの使い方、IPsecとの併用などが議論されました。このあたり
は移行に利用するISATAP／Teredooといったプロトコルの詳細を含め、延々と
議論されてはいますが、利用シーンを含め、今後広範囲で使われていくとは考
えにくいこと、また、日本などIPv6に早くから取り組んでいる地域ではIPv6ネ
イティブ接続が主流になりつつあり、利用が想定しにくいことなどの問題があ
ります。次回のIETFでは、移行技術の取り扱いも含め今後v6ops WGをどのよう
な方向に進めていくかの議論が実施される予定です。
□v6OPS WG
http://www.ietf.org/html.charters/v6ops-charter.html
http://www.6bone.net/v6ops/
□60th IETF v6ops WG のアジェンダ
http://www.ietf.org/ietf/04aug/v6ops.txt
……………………………………………………………………………………………
3. DNS関連WG報告
JPNIC DNS運用健全化タスクフォースメンバー
東京大学 情報基盤センター
関谷勇司
……………………………………………………………………………………………
◆DNSEXT（DNS Extensions）WG
前回の第59回IETFにおいてはBoFが開催されなかったDNSEXT WGですが、今回は
2コマ開催されました。そのうち1コマは、DNSSEC(*11)に関する議論に費やさ
れました。DNSSEC bisとして標準化が進められてきたDNSSECですが、基本とな
るドラフトがIESGのレビューに回されるなど、やっと標準化されそうです。し
かし、実際の運用に際してはまだまだ普及しておらず、どうやって効率的に鍵
の管理、交換、更新を行うか、不確定な部分が残されています。
今回のDNSSEC議論においても、DNSSECの普及に関して残された問題が中心とな
りました。まず、DNSSECを利用することのできる実装の確認と、鍵管理に利用
できるツールの紹介が行われました。また、それぞれの実装がサポートしてい
るプロトコルと、リゾルバの対応状況についても報告がありました。さらに、
DNSSECの署名をアプリケーションから確認するためのAPI(*12)についても、そ
の必要性を含めて議論されました。これらに関しては、特に明確な結論を出し
たわけではなく、現状の確認とさらなる調査ということで議論は終了しました。
さらに、DNSSECの鍵更新に関する手法や、NSEC(*13)をたどっていくことでゾー
ンに存在するレコードを全部たどることができてしまうという問題に関しても
議論が行われました。これらはDNSSEC普及の大きな障害となっているという認
識がWG全体にあり、解決のための手法が求められています。まだ明確な解決策
は存在せず、そもそもDNSSECに求められるものはという点からも議論がなされ
ました。
次に、DNSSEC以外で議論された事項に関して報告します。まず、
draft-austein-dnsext-nsid-01に関して報告します。これはDNSOP WGにて議論
された、draft-ietf-dnsop-serverid-02に関連するもので、Server IDを独立
の応答として行うのではなく、EDNS0(*14)のオプションとして応答することに
よって、通常の名前解決応答に含ませてしまおう、というものです。また、
draft-ietf-dnsext-mdns-33がようやくWGラストコールとなりました。さらに、
BoFの最後には、これからDNSEXT WGが進む方向性について議論が行われました。
チェアはDNSSECの鍵管理に関する事項を中心に、DNSOP WGと協力してこれから
のWGを進めていきたいと考えていました。これに対して、DNSOP WGとのすみ分
けはどうするのだ等の質問がなされ、DNSOP WGからの運用のフィードバックを
うけて、プロトコルの標準化を行っていきたいとの意見が述べられていました。
□DNSEXT WG
http://www.ietf.org/html.charters/dnsext-charter.html
(*11) DNSSEC：http://www.nic.ad.jp/ja/tech/glos-ah.html#01-DNSSEC
(*12) API：http://www.nic.ad.jp/ja/tech/glos-ah.html#01-API
(*13) NSEC：http://www.nic.ad.jp/ja/tech/glos-kz.html#03-NSEC
(*14) EDNSO：http://www.nic.ad.jp/ja/tech/glos-ah.html#01-EDNSO
◆DNSOP（Domain Name System Operations）WG
今回は、DNSOP WGとして2時間のBoFが開催されました。まず最初にWGドラフト
全体の状態確認から始まり、そして個々のドラフトについて、状態が発表もし
くは確認されました。今回のBoFでは、特に中心となる大きな議題はありませ
んでした。IPv6でのDNS運用に関連するドラフトがいくつかと、DNSの実装上の
挙動や、プロトコルの制限からくる挙動に関するドラフトが主な議論となりま
した。また、DNSSECの運用に関連するドラフトや、すでに失効してしまったド
ラフトが更新されて復活したものもありました。そのうちのいくつかを報告し
ます。
・draft-ietf-dnssec-operational-practices-01
DNSSECにおける運用上の要点をまとめたドラフトです。編集的な変更のみで、
そろそろWGラストコールがかかりそうでした。しかし、まだDNSSECを運用して
いる人が少ないため、実経験に基づく運用上の注意点があれば、フィードバッ
クしてほしいとのコメントがありました。
・draft-ietf-dnsop-serverid-02
一度失効してしまったドラフトなのですが、今回復活しました。Server IDと
呼ばれる、DNSサーバの識別子を取得するための機構をDNSのプロトコルに追加
しようというドラフトです。これは、同一IPアドレスを複数台のDNSサーバに
割り当てる、DNSのanycastサービスが普及した際に、どのDNSサーバから応答
を得ているのかを識別するのに使うことができます。大きな反対意見もなく、
このまま標準化が進みそうです。
・draft-yasuhiro-dnsop-increasing-dns-server-01
このドラフトはまだWGドラフトではなく、さらに一度失効してしまったドラフ
トですが、今回復活しました。DNSゾーンに記述されるIPアドレス数が増える
ことによる、応答サイズの増大と、それを抑える方法について考察されたドラ
フトです。多くの人の関心を集めており、さらなる考察が求められていました。
・draft-ietf-dnsop-ipv6-dns-configuration-01
IPv6クライアントのDNSサーバ自動設定に関して、三つの手法をまとめたドラ
フトです。前回のDNSOP WG BoFの大きな議題となっており、ドラフトとして発
行されました。早めにラストコールをかけたいと議論されていました。
□DNSOP WG
http://www.ietf.org/html.charters/dnsop-charter.html
……………………………………………………………………………………………
4. セキュリティ関連WG報告
JPNIC 技術部 木村泰司
……………………………………………………………………………………………
◆PKIX（Public-Key Infrastructure (X.509)）WG
PKIX WGは8月4日(水)の午前に行われました。参加者は100名ほどで、前回の約
50名と少なかった状況から、通常の規模に戻っています。ただし各ドキュメン
トに特化した議論がほとんどであるためか、途中退席される方が見受けられま
した。
PKIX WGは第57回IETF以降終息に向け、既存のトピックのドキュメント化を中
心に議論を進めています。最初にドキュメントステータスの発表が行われまし
た。前回のIETF以降から今回のIETFまでに、下記のRFCが発行されました。
RFC 3739 "Qualified Certificates Profile"
RFC 3770 "Certificate Extensions and Attributes Supporting
Authentication in PPP and Wireless LAN"
RFC 3779 "X.509 Extensions for IP Addresses and AS Identiers"
RFC 3820 "Internet X.500 Public Key Infrastructure Proxy
Certificate Profile"
この他に四つのInternet-Draft（以下、I-D）がIESGに承認され、10のI-DがAD
またはWGのレビュー中の状態です。
次に、提案されたWGのマイルストーンが提示されました。このスケジュールに
よると2005年の春までに、RFC3279とRFC3280の更新、テキスト文字列の処理、
OCSPv2の拡張に関する活動を完了する予定になっています。
続いて、ドラフト・ドキュメントに関する議論が行われました。今回の議論で
はLDAP(*15)関連、文字列比較ルール、RFC3280の更新、証明書検証プロトコル
のSCVPといった話題がありました。
LDAPに関しては、LDAPスキーマとエントリの記述方法に関するプレゼンテーショ
ンがありました。LDAPスキーマは、エントリのDIT（Directory Index Tree）
構造とOpenLDAP(*16)バージョン2.2.1に設定が含まれていることが発表されて
いました。正式に組み込まれるのはOpenLDAP側のレビューの後であるとのこと
です。
文字列比較ルールについては、UTF8Stringといった文字データの種別の違いを
超えた比較ルールの必要性やDCコンポーネントに対するルールなど、既存のルー
ルとの使い分けなどについて議論が行われていました。
最後に、恒例のリエゾンによるプレゼンテーションとして、韓国のKISA
（Korea Information Security Agency）のTae Choi氏からPKIの為のユーザイ
ンターフェースの要件に関するプレゼンテーションと、IKEv2とOCSPを効率よ
く利用するためのメッセージに関してMike Myers氏によるプレゼンテーション
が行われました。
□PKIX WG
http://www.ietf.org/html.charters/pkix-charter.html
(*15) LDAP：http://www.nic.ad.jp/ja/tech/glos-kz.html#03-ldap
(*16) OpenLDAP：http://www.openldap.org
◆PKI4IPSEC（Profiling Use of PKI in IPSEC）WG
PKI4IPSEC WGは8月4日(水)の午後に行われました。参加者は200名程で、依然
人気のあるセッションです。2004年5月に、IKEで使われる証明書プロファイル
に関する提案draft-ietf-ipsec-pki-profile-04が、WGのI-Dとして
draft-ietf-pki4ipsec-ikecert-profile-00に改訂され、さらに-01に更新され
ているため、多くの変更点がプレゼンテーションされました。
変更があった点は、IKEにおけるIPアドレスペイロードの書式と検証方針、一
度検証された証明書の扱いや、CERTREQペイロードに含めていた識別名（DN）
が鍵情報になるなど、多岐にわたっています。また-00から-01での更新では、
証明書の鍵用途拡張のフィールドがある場合の解釈方法や、認証局が拡張の鍵
用途拡張フィールドを加えないなど、PKIX WGの仕様を深く解釈したうえでの
提案がなされていました。
この議論と平行して証明書管理の要求事項をまとめた
draft-bonatti-pki4ipsec-profile-reqts-01をWGで扱うことになり、今後、こ
のドキュメントをもとにして議論が進められるようです。
□PKI4IPSEC WG
http://www.ietf.org/html.charters/pki4ipsec-charter.html
□プレゼンテーション資料・ドキュメント
http://www.icsalabs.com/html/communities/pki4ipsec/
※コメント／対応管理表のようなデータがありドキュメントでの対応状況が
簡単に分かるようになっています。
◆MASS（Message Authentication Signature Standards）BoF
MASS BoFは、8月5日(木)の午前に開かれました。定員100名弱の部屋には入り
きれないほどの人数が参加したため、大きな部屋に移動して行われるという一
幕もありました。
MASS BoFで提案しているWGは、MARID WGで扱っている、認証の為のDNSレコー
ドを利用して、メールメッセージを認証できるようにするという目標を持って
います。SPAM等のメールで使われるような著名なドメイン名と似ていながら異
なるドメイン名をかたった場合に、判別ができるという効果を狙っています。
このBoFでは、WGのゴールやチャーターが始めに提示され、次にDomainKeyと呼
ばれる認証の為に使われる鍵の使い方や、DomainKeyを使ったメールメッセー
ジ、MTA signatureと呼ばれる署名に関するプレゼンテーションがありました。
しかし、会場からはフィッシング（銀行などのWebサーバと似たような発信元
（ドメイン名）のメールを使った詐欺行為）において根本的な解決にならない、
S/MIMEとの違いは何か、といった厳しい意見が出されました。
◆その他
今回のIETFのSAAG（Open Security Area Directorate：セキュリティエリア全
体会議）では、会場から認証技術とdeployment（利用・展開）に関して以下の
ような議論が起こっていました。
・PKIの広範囲で工学的なdeploymentが必要。それには組織的な導入活動が必
要。
・認証の仕組みとネットワークアクセスのユーザーにとっての透過的な関連の
必要性。
PKIX WGが、新たな実践面でのトピックを扱いにくくなっており、ネットワー
ク・プロトコルでの認証技術の利用といった実践的な話題を扱う場が、より多
く必要になっている状況がうかがわれました。
セッションの最後には、エリアディレクターのSteven Bellovin氏より、次回
のIETFで実践的なトピックを扱うBoFが開催されることが示唆されました。今
後、認証技術のdeploymentに関する議論は、注目を集めることが予想されます。
JPNICはインターネットの円滑な運営を支えるための組織です
- JPNIC
-
IPアドレス・AS番号
指定事業者向け各種申請手続/お知らせ
一般ユーザーの方
-
JPNIC会員
会員向け情報/各種変更手続
入会のご案内
