━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 1 】特集 「第59回IETF報告」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

……………………………………………………………………………………………
1. 全体会議報告
                                                JPNIC 技術部  上野晶久
……………………………………………………………………………………………

2004年2月29日～3月4日に韓国・ソウルにて第59回IETF(*1)会議が開催されま
した。今回のIETF会議では全会議数が90余りと、前回（米国・ミネアポリス）
に比べ会議の数こそ減少しましたが、参加者は1,255名と前回を上回り、イン
ターネット技術標準化活動に対する関心の高さをうかがい知ることができまし
た。
 
全体会議は2部で構成され、3月3日には各組織の現状報告を中心とした
Business Meeting、最終日となる4日にはIETFの将来的な運営、管理体制を検
討するPlanning Meetingが開催され活発な議論が行われました。

(*1) IETF：Internet Engineering Task Force
           http://www.nic.ad.jp/ja/basics/terms/ietf.html


◆IETF Business Meeting

IETF Business MeetingではRFC-editor、IANA(*2)、IESG(*3)、およびIAB(*4)
から現状報告がなされました。
 
RFC editorレポートでは、RFC-Errataページが改善され外部ページから直接
該当するErrata項目へリンクを張ることが可能となったこと、および新たな
著作権、知的所有権に関する記述がすべてのRFCに付加されたことが報告され
ました。

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

IAB Chiarリポートでは、ISOC評議会メンバー選出の候補者として以下の5名が
登録されていると報告がありました。

  Avri Doria氏、江崎 浩氏、Erik Huizer氏、James Seng氏、Paul Wilson氏

今後のメンバー選出スケジュールについては以下のURLをご参照ください。

  http://www.iab.org/documents/docs/2004-02-07-isoc-bot-candidates.html

(*2) IANA：Internet Assigned Numbers Authority
           http://www.nic.ad.jp/ja/tech/glos-ij.html#02-IANA
(*3) IESG：Internet Engineering Steering Group
           http://www.nic.ad.jp/ja/basics/terms/iesg.html
(*4) IAB：Internet Architecture Board
          http://www.nic.ad.jp/ja/basics/terms/iab.html

 
◆IETF Planning Meeting

Planning Meetingでは、最初にEric Nordmark氏よりマルチホーム化したネッ
トワークの問題点を解決するための提案がなされました。現在はIPアドレスが
IdentifierおよびLocatorとして二つ役割を担っていますが、トランスポート
層とネットワーク層の間に中間層を新たに設け、IdentifierとLocatorを分離
させることでマルチホーム化したネットワークに拡張性を持たせようというも
のです。この提案には多くのコメントが寄せられましたが、その実現可能性に
ついて懐疑的な意見が多く聞かれました。

続いてAdvisory CommitteeよりIETF管理体制の改変を目的したInternet-Draft 
（以下I-D）の紹介がありました。この提案は、IETFの運用管理に特化した組
織となるAG（Administrative Group）を新設することでIETF活動の一層の効率
化を図るというものです。今後この提案内容を引き続き検討していくというこ
とでした。

  http://www.ietf.org/internet-drafts/draft-daigle-adminrest-00.txt

最後に、Advisory CommitteeよりIETFが担うべき役割について明文化したI-D 
の紹介がありました。さらに内容を精査し、次回の第60回IETF Meeting（米国・
サンディエゴ）までにRFCとして発行する意向があるということでした。

  http://www.ietf.org/internet-drafts/draft-alvestrand-ietf-mission-00.txt


……………………………………………………………………………………………
2. IPv6関連WG報告
                                    JPNIC IPアドレス検討委員会メンバー
                                     NTT情報流通プラットフォーム研究所
                                                              藤崎智宏
……………………………………………………………………………………………

本セクションでは、IPv6関連のトピックスを扱っている主なワーキンググルー
プ（以下WG）での議論内容について紹介いたします。


◆IPv6 WG（IP version 6 WG）

IPv6 WGでは、IPv6コア技術の標準化を進めており、3月2日の午後2コマを使っ
て議論が実施されました。今回はミーティング時間を有効に使うため、従来ミー
ティング時間のはじめにチェアが報告をしていたIPv6 WGで標準化を進めてい
る各文書のステータスは、Webでの事前紹介となりました（WGでのコメント反
映済のリストが下記URLにあります）。

  http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html

今回話し合われた主なトピックスは、

・IPv6 Node Requirement文書に関する議論
・IPv6近隣探索（RFC2461）、アドレス自動設定（RFC2462）等、IPv6ベースス
  ペックRFCのドキュメント改訂
・Optimistic DAD（簡易重複アドレス検出）に関する議論

などです。

前回まで議論が続いていた、サイトローカルアドレスの廃止、および新規のロー
カルアドレスである一意ローカルユニキャストアドレス標準に関しては、RFC 
化に向けて順調に進んでおり、今回特に議論はありませんでした。

IPv6 Node Requirement文書は、IPv6ホストやルータが実装するべき共通IPv6 
機能を定義するものです。大きな問題としてセキュリティ技術の扱い（サポー
トするべきIKE（Internet Key Exchange）のバージョンや暗号化アルゴリズム
の種類など）は、IPsec WGで議論すべきであるため、セキュリティの章は分離
すべきである、参照するべき機能はドラフト段階のものを含むべきではない等
の議論があり、文書の見直し、セキュリティ関連WG等との調整を実施すること
になりました。

ドキュメントの改訂では、ほぼ問題は収束しつつありますが、現在の文書が成
立した後に標準化されている新規技術をどう取り込むかや、他の文書との関連
等が指摘され、問題点の解決に向けて議論が進んでいます。

今回、Optimistic DAD（簡易重複アドレス検出）に関して、時間を少々長くと
り議論されました。IPv6には、アドレスの衝突を検出する重複アドレス検出
（Duplicate Address Detection/DAD）という機能を標準で実装することが求
められていますが、このDADには時間がかかるため、アドレス衝突の可能性が
低い場合に限り（IEEE EUI-64インタフェースIDの利用が確実である場合や十
分に良い乱数を利用できる場合など）、動作の一部を省略してDADが速く終わ
るようにしようというものです。近隣探索機能をセキュアにすることを検討し
ているSEND WGとの関係や、後方互換性が議論され、今後、IPv6 WGのWGドラフ
トとして標準化を進めていくことになりました。

全体として特に大きな問題はなく、標準化が順調に進んでいるという印象を受
けました。

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

□59th IETF IPv6 WGのアジェンダ
  http://www.ietf.org/ietf/04mar/ipv6.txt


◆DNSOP WG（Domain Name System Operations WG）

DNSOP WGは3月1日の午後に実施されました。もともとのプログラムでは、2日
の午後に、もう1コマ予定されていましたが、議論が順調に進み、2コマ目はキャ
ンセルとなりました（チェアがセッションはじめに使用したプレゼン資料が
http://www.1-4-5.net/~dmm/IETF/IETF59/DNSOP/agenda/ に掲載されています
のでご参照ください）。

前回、前々回と長く議論され、結論が出ていなかったIPv6ネットワークでの
DNSサーバアドレスの取得方法（DNS探索）に関してですが、このまま議論が長
く続くことを避けるため、今一度問題点をクリアにして、それぞれの手法の特
徴や運用上の問題等を取りまとめた文書を次回のIETFまでに（8月にSan Diego 
で予定されています）RFC化する、という目標がたてられ、今回数人のチーム
を構成し、文書化を進めることになっています。

その他、現在WGに提案されているドキュメントが再整理され、IPv6関連では

・IPv6利用環境でDNSを利用する際の運用上の考慮点をまとめたドラフトがRFC
  化に向けてWG Last Call
・IPv6のAAAA資源レコードの問い合わせに対して、不正な応答をするDNSの実
  装が存在し、通信を阻害することがある問題を記したドラフトがRFC化に向
  け進展
・IPv6のDNS逆引きについて、現状、逆引きが認証に利用されることがあり、
  円滑な通信実現に対して問題を引き起こしていることに対する分析と対策を
  記した文書が失効していたものを復活

という議論がありました。

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

□59th IETF DNSOP WGのアジェンダ
  http://www.ietf.org/ietf/04mar/dnsop.txt


◆v6OPS WG（IPv6 Operations WG）

v6OPS WGは3月1日午後と4日午後に、2コマ開催されました。今回、多くの時間
を使い、IPv6への移行技術として標準化が続けられているトンネリング技術に
関して、

・Opportunisticトンネリング（6to4(*5)やTeredo(*6)など）
・Zero-configuredトンネリング（ISATAP(*7)など）

という分類をし、使い方や今後の進め方や、方式自体の是非の議論が実施され
ました。利用シーンとして、プロバイダがIPv6を提供していない場合や、NAT 
の後ろ側のネットワークにIPv6接続性を提供する企業等でコストをかけずに
IPv6を利用可能にする等を想定しています。

また、IPv6の特長を有効活用するためのセキュリティモデルの提案が2件実施
されています。従来のIPv4型ファイアウォールによるネットワーク防御モデル
では、end-to-end通信が阻害されてしまう、IPsecの利用が困難である、といっ
た問題があり、IPv6の特徴を生かすことができません。これに対し、ファイア
ウォールを分散させて配置する、検疫をして通信を許可する、といった手法を
使ってはどうか、という提案がなされました。後者の方式に関しては、欧州の
IPv6ネットワークにて類似のモデルを使用した実験を行うことを考えていると
いう情報があり、共同して実際に実験をして進めてみる、ということになりま
した。

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

□59th IETF v6OPS WGのアジェンダ
  http://www.ietf.org/ietf/04mar/v6ops.txt

(*5) 6to4：http://www.nic.ad.jp/ja/tech/glos-ah.html#01-6to4
(*6) Teredo：http://www.nic.ad.jp/ja/tech/glos-kz.html#03-teredo
(*7) ISATAP：Intra-Site Automatic Tunnel Addressing Protocol
             http://www.nic.ad.jp/ja/tech/glos-ij.html#02-isatap


◆MULTI6 WG（Site Multihoming in IPv6 WG）

IPv6インターネットに特化したマルチホーム手法を検討するMULTI6 WGは3日の
午前中に開催されました。今回のミーティングで、マルチホーム手法の新規募
集は打ち切り、提案のあったマルチホーム手法をもとにIPv6でのマルチホーミ
ング手法に関する分析を実施し、今後の方向性を明確にすることになっていま
す。新規の提案としておよそ30件ほどのドラフトが寄せられ、ミーティング中
に9件が紹介されています。

また、Geoff Huston氏より、現在提案されている案の整理として、IPv6ホーミ
ング方式アーキテクチャの分析についてのプレゼンテーションがありました。
現在提案されている案は、

・プロトコルスタック間に新たに階層を設ける（ホストの識別子を扱う階層）
・トランスポート層やIP層を改変する
・ホストやルータの動作（パケットフォワーディングの動作など）を変更する
・それ以外（IPv4方式をIPv6へマッピング）

に分類されること、それぞれに共通する課題があることが報告されています。
次回のIETFまでに分析文書を完成し、それをベースにマルチホーミング手法の
標準化を進めることになっています（文書の議論を実施するために中間ミーティ
ングを開催することも予定されています）。

マルチホーミングの問題に関してはIETF全体会議でも取り上げられ、その問題
点や現状の解決案の状況が報告されており、今後の標準化の動向が注目されま
す。
 
□MULTI6 WG
  http://www.ietf.org/html.charters/multi6-charter.html

□59th IETF MULTI6 WGのアジェンダ
  http://www.ietf.org/ietf/04mar/multi6.txt


◆その他

今回、会場ホテルでのIPv6機器の展示、およびNCA(*8)/MIC(*9)のIPv6関連展
示見学ツアーがありました。

ホテルでは、IPv6ライブビデオストリーミングシステムや、SIP電話、IPv6対
応Webカメラ等の展示があり、IPv6対応の機器が実際に動作していることを体
感できました。NCAでは同様の展示に加え、IPv6への移行システムや遠隔監視
システム、情報家電などの展示が行われていました。MICのツアーは、
Ubiquitus Dreamと名付けられた展示ホールの見学でした。展示ホール自体は
まだオープン前で、工事があちこちで行われている状態でしたが、展示物はほ
とんど動作しており、来るべきRFID(*10)や各種情報家電、センサーを組み合
わせたユビキタス社会を、喫茶店、家庭、病院、学校、スーパーを模擬したセッ
トの中で体感できるようになっていました。個々の要素技術自体に特に目新し
いものはありませんでしたが、各コンポーネントがが組み合わさって実社会に
マッピングされているものを一カ所で連続的に体感できるため、非常に印象的
でした。

(*8) NCA：National Computerization Agency
          韓国電算院。コンピュータ技術、通信技術の普及政策を担当
(*9) MIC：Ministry of Information and Communication
          韓国情報通信部。韓国の情報化政策に関する主管官庁
(*10) RFID：Radio Frequency IDentification
            http://www.nic.ad.jp/ja/tech/glos-kz.html#03-RFID


……………………………………………………………………………………………
3. DNS関連WG報告
                                                JPNIC 技術部  上野晶久
……………………………………………………………………………………………

DNS関連WGのミーティングより、ENUM WGについて報告します。


◆ENUM WG（Telephone Number Mapping WG）

ENUM WGでは、まず最初にRFC発行待ちとなっているRFC2916bisの現状報告が
IESGメンバーであるAllison Mankin氏より行われました。「現在はIANAでの処
理を待っている状態だが、IESGからIANAへ審査を依頼しているI-Dは
RFC2916bisだけではないため、RFC発行までにはまだ多少の時間がかかるであ
ろう」とのことでした。

続いて各国のENUMトライアルの現状報告が行われました。日本からも(株)日本
レジストリサービスの藤原和典氏によるETJP（ENUM Traial Japan）の活動報
告が行われ、その中で指摘されていた「RFC2916bisとDDDS RFCs
（RFC3401-3404）の両義性」は会場内でも大きな反響を呼びました。藤原氏が
指摘された問題点は、Lawrence Conroy氏がすでにその他の問題点をまとめて
文書化したI-Dに付加され、正式にENUM WGで採用されることとなりました。

□藤原氏のプレゼンテーション資料
  http://member.wide.ad.jp/~fujiwara/enum/ietf59enum-impl.pdf

□Conroy氏のインターネットドラフト
  http://www.ietf.org/internet-drafts/draft-conroy-enum-experiences-01.txt


……………………………………………………………………………………………
4. セキュリティ関連WG報告
                        JPNIC CAとアプリケーション専門家チームメンバー
                                       富士ゼロックス株式会社　稲田 龍
……………………………………………………………………………………………

ここ数年、セキュリティの確保はインターネットにとって大きな課題となって
おり、各社はさまざまな対策・提案を行ってきました。IETFは、標準化を推進
する立場で活動し、多くのプロトコルに関してセキュリティ面での強化を行っ
ています。

具体的に言えば、ここ数年にわたり初日にはSecurity Tutorialが開催され、
インターネット・プロトコルに対して必要とされるセキュリティ要件に関して
の講義がなされています（後述）。さらに、I-D、RFCに関しては“Security
Consideration”の項目が必須となるなど、インターネットの標準化に関して
セキュリティは必須の要件となっています。

今回のIETFでも、新たにMOBIKE、OPSEC(*11)などの新しいWG・BoFが開催され
インターネットを自由にかつ安全に利用するための提案がなされています。

また、Security AreaのDirectorであるRussell Housley、Steven Bellovinの
両氏は、積極的に多くのWGに参加しコメントを出しセキュリティの重要さを説
いています。非公式にも多くの人間に会い、さまざまな分野に関してセキュリ
ティを推し進めています。

(*11) OPSEC：Operational Security Requirements 
             http://www.ietf.org/ietf/04mar/opsec.txt


◆Security Tutorial

Security Tutorialは2月29日に開催され、参加者は300名程度で満席となりま
した。

SUN Microsystems社のRedia Perlman女史が説明を行いました。Redia女史は、
ARP(*12)の開発者としても知られている人物でIETFの長老（女性に対して長老
とは失礼かもしれませんが）の1人でもあります。

インターネットでなぜセキュリティが重要であるかに関しての解説に始まり、
技術的なコンセプト、守るための個別の技術なども分かりやすく説明し、さら
に暗号技術に関しても詳細に述べていました。
 
暗号に関しては、「勝手に暗号を作るべきではなく、きちんとレビューを受け
たものを使うのが望ましい」というコメントを残していました。セキュリティ
プロトコルは大変難しいので、全部自分でやるのではなく、複数の人間が共同
して行うことが重要とも述べていました。

Security Tutorialで使用されたPowerPoint文書は以下のURLをご参照ください。
 
  http://sec.ietf.org/ietfsectut0304a.ppt

(*12) ARP：Address Resolution Protocol 
           TCP/IPプロトコルにおいて、IPアドレスからEthernetアドレスを
           求めるためのプロトコル


◆ MOBIKE WG（IKEv2 Mobility and Multihoming WG）

MOBIKE WGは3月1日に開催されました。本WGではIPsecで利用されるIKEv2のコ
アプロトコルとは独立に、モバイルでの必要性が高い、ローミングやマルチホー
ミングを検討しています。参加者の関心も非常に高く、200名程度の参加を集
めました。

セッションでは、以下の二つのドラフト説明が行われました。

・Address Management for IKE version 2

モバイル環境で重要となるアドレス管理をIKEに追加する提案であり、I-Dとな
りました。IKEv2でのアドレス管理は、NAT traversalで提案されていますが、
モバイルで問題となる、IPv6でのNAT対応やマルチホーミング対応を補完する
ための別提案としています。

・Design of the MOBIKE protocol

MOBIKEの設計に関する説明で、前回の第58回IETFにおけるBoFでの意見を受け
た修正案の説明です。前回、IKEv2のオプションを使用できることを指摘され
たため、IKEv2を最大限に利用するように変更しました。

□MOBIKE WG
  http://www.ietf.org/html.charters/mobike-charter.html


◆PKI4IPSEC WG（Profiling Use of PKI in IPSEC WG）

PKI4IPSEC WGは3月1日に開催され、参加者は200名ほどでした。

IPsecは、過去5年間以上にわたって標準化が行われてきました。同じ期間、
X.509(*13)証明書の利用についても定められてきました。しかし、証明書を利
用するIPsecの採用事例はほとんどありません。その理由の一つは、X.509証明
書のIPsecにおける利用についての明解な文書の欠如です。また、IPsecシステ
ムについて、証明書の入手等、証明書に関するライフサイクル運用について単
純かつ明解に規定された方法論の欠如も理由と言えます。

今回のIETFでは、WGとしてのチャーターが以下のURL掲載の内容に決まったこ
との報告と、現行のdraft-ietf-ipsec-pki-profile-04.txtに関しての議論が
行われました。

□PKI4IPSEC WG
  http://www.ietf.org/html.charters/pki4ipsec-charter.html

(*13) X.509：ITU Recommendation X.509
             http://www.nic.ad.jp/ja/tech/glos-kz.html#03-x.509


◆PKIX WG（Public-Key Infrastructure (X.509) WG）

PKIX WGは3月1日に開催され、49名が参加しました。チェアの1人であるTim
Polk氏が脊椎捻挫のため出席せず、BBNのStephen Kent氏がミーティングを仕
切っていました。

WGのミーティングは通常の通りにドキュメントステータスより始まり、粛々と
議題をこなし議論としては低調なものとなりました。しかしながら、内容とし
てはQualified CertificateのRFC化が進み、Proxy CertificateはRFC化が決ま
るなど多くの面で進展が見られました。米国外でのIETFであるため多くの常連
となるメンバーが出席しない状況であり、オフラインでのミーティングは低調
な印象を受けましたが、WGとしてのミッションは確実に消化しつつあるように
感じました。

また、IESGからの要請によりPKIX WGは終息のフェイズにあります。今後はPKI 
のインターネットでの応用範囲を広げるべくさまざまなBoF・WGが開かれると
考えられます。例えば、IPsecでのPKIの応用とプロファイルの策定を意図した
PKI4IPSECもその一例です。PKI4IPSECは前回の第58回IETFではBoFとして開催
されましたが、今回はWGとして開催されました。

□PKIX WG
  http://www.ietf.org/html.charters/pkix-charter.html


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

LTANS WGは3月4日に開催され、40名程度が参加しました。

LTANS-WGは、セキュアなデータのアーカイブと公証サービスのためのデータ構
造とプロトコルを決めることを目的とするWGであり、前回の第58回IETFにて設
立されました。

現状二つのI-Dが提案されていますが、まだStandard TrackのRFCはありません。
セッションでは、これらのI-D（Requiments/Evidence Record Syntax）に関し
ての議論が行なわれました。
 
□LTANS WG
  http://www.ietf.org/html.charters/ltans-charter.html