ニュースレターNo.27/2004年7月発行

第59回IETF

2004年2月29日～3月4日に韓国・ソウルにて第59回IETF会議が開催されました。全体会議、IPv6、DNS、セキュリティ関連ワーキンググループ（以下、WG）のレポートをお届けします。

1. 全体会議報告

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

◆IETF Business Meeting

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

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

IAB Chiarリポートでは、ISOC評議会メンバー選出の候補者としてAvri Doria氏、江崎浩氏、Erik Huizer氏、James Seng氏、Paul Wilson氏の5名が登録されていると報告がありました。

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

http://www.iab.org/documents/docs/2004-02-07-isoc-bot-candidates.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-02.txt

（JPNIC 技術部上野晶久）

2. IPv6関連WG報告

本セクションでは、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
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^※4やTeredo^※5など）
Zero-configuredトンネリング（ISATA^※6など）

という分類をし、使い方や今後の進め方や、方式自体の是非の議論が実施されました。利用シーンとして、プロバイダが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

◆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^※7／MIC^※8のIPv6関連展示見学ツアーがありました。

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

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

3. DNS関連WG報告

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 Trial Japan）の活動報告が行われ、その中で指摘されていた「RFC2916bisとDDDS RFCs （RFC3401-3404）の両義性」は会場内でも大きな反響を呼びました。藤原氏が指摘された問題点は、Lawrence Conroy氏がすでにその他の問題点をまとめて文書化したI-Dに付加され、正式にENUM WGで採用されることとなりました。

（JPNIC 技術部上野晶久）

藤原氏のプレゼンテーション資料: 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報告

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

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

今回のIETFでも、新たにMOBIKE、OPSEC^※10などの新しいWG・BoFが開催されインターネットを自由にかつ安全に利用するための提案がなされています。また、Security AreaのDirectorであるRussell Housley、Steven Bellovinの両氏は、積極的に多くのWGに参加しコメントを出しセキュリティの重要さを説いています。非公式にも多くの人間に会い、さまざまな分野に関してセキュリティを推し進めています。

◆Security Tutorial

Security Tutorialは2月29日に開催され、参加者は300名程度で満席となりました。SUN Microsystems社のRedia Perlman女史が説明を行いました。Redia 女史は、ARP^※11の開発者としても知られている人物でIETFの長老（女性に対して長老とは失礼かもしれませんが）の1人でもあります。

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

Security Tutorialで使用された資料: http://sec.ietf.org/ietfsectut0304a.ppt

◆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^※12証明書の利用についても定められてきました。しかし、証明書を利用する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

◆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）に関しての議論が行なわれました。

（JPNIC CAとアプリケーション専門家チームメンバー／富士ゼロックス株式会社　稲田龍）

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

※1　IANA：Internet Assigned Numbers Authority: http://www.nic.ad.jp/ja/tech/glos-ij.html#02-IANA
※2　IESG：Internet Engineering Steering Group: http://www.nic.ad.jp/ja/basics/terms/iesg.html
※3　IAB：Internet Architecture Board: http://www.nic.ad.jp/ja/basics/terms/iab.html
※4　6to4: IPv6パケットをIPv4パケットにカプセル化し、IPv4インターネット上にトンネルを構築する手法の一つ
※5　Teredo: IPv4のNAT環境にあるホストが、トンネル接続を行うための移行技術。UDPにIPv6パケットをカプセル化し、IPv4インターネット上のTeredoサーバとトンネルを設定することでIPv6通信を実施する
※6　ISATAP：Intra-Site Automatic Tunnel Addressing Protocol: IPv6接続がないデュアルスタックホストをIPv6インターネットに接続するための自動トンネル技術の一つ
※7　NCA：National Computerization Agency: 韓国電算院。コンピュータ技術、通信技術の普及政策を担当
※8　MIC：Ministry of Information and Communication: 韓国情報通信部。韓国の情報化政策に関する主管官庁
※9　RFID：Radio Frequency IDentification IC: タグを使い、無線で人やモノを識別・管理する仕組み
※10　OPSEC：Operational Security Requirements: http://www.ietf.org/ietf/04mar/opsec.txt
※11　ARP：Address Resolution Protocol: TCP/IPプロトコルにおいて、IPアドレスからEthernetアドレスを求めるためのプロトコル
※12　X.509：ITU Recommendation X.509: 証明書のフィールド（項目名と値）や、その扱いについて勧告した国際標準