バックナンバー：vol.115

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2011-12-12━
　　　　　　　　　　◆ FROM JPRS 増刊号 vol.115 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　　　　　　　　　　　第82回IETF Meeting報告
　　　　　　　　～ドメイン名／DNS関連の話題を中心に～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

今回のFROM JPRSでは、2011年11月13日から11月18日にかけて台北で開催され
た第82回IETF Meeting（以下、IETF82）で議論された話題の中から、ドメイン
名／DNS関連の話題を中心にお伝えします。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

■IETF全般の状況

▼3年ぶりに参加者が1,000人を下回る

今回のIETF82の参加者は948人と前回（IETF81）の1,127人から大きく減少し、
リーマンショックによる世界的な経済危機の中開催されたIETF73以来、3年ぶ
りに1,000人を下回りました。1996年以降に開催されたIETF Meetingで参加者
が1,000人を下回ったのはこの2回のみであり、原因の一つとして2010年の欧州
債務危機に端を発する、世界的な景気低迷が挙げられています。

また、今回のIETF82では最近アジア太平洋地域で開催されたIETF76（広島：参
加者1,152人）、IETF79（北京：参加者1,207人）と比べ開催地からの参加人数
が少なく（*1）、そのことも参加者減少の原因の一つとして挙げられています。

（*1）IETF76とIETF79では開催地から全体の30％程度の参加がありましたが、
　　　今回のIETF82では台湾からの参加は全体の6％程度に留まっています。

▼3度目の日本開催？

2012年～2013年のIETF Meetingは欧米地域での開催が既に予定されており、ア
ジア太平洋地域における次の開催予定は2014年以降となっています。今回、時
期未定ながら次回のアジア太平洋地域の候補地として、日本での開催を計画し
ている旨が発表されました。日本ではこれまでに2002年のIETF54（横浜）、
2009年のIETF76（広島）の2度にわたり、IETF Meetingが開催されています。
もし計画通り開催されれば、アジア太平洋地域におけるIETFの最多開催国とな
ります。

■dane WGの状況

daneは「DNS-based Authentication of Named Entities」に由来する、DNSを
用いたデジタル証明書（以下、証明書）の安全な配送や、証明書とサーバーの
関連付けの正しさを検証できるようにするための標準化作業を進めているWGで
す。

インターネットでは通信相手が正当なサーバーであることを検証する際、第三
者となる証明機関（認証局）が発行したサーバー証明書を使用します。daneで
はこれをDNSの委任関係を用いて検証することにより、認証局の介在なしに
サーバーの正当性を検証することが可能になります。

IETF82では、これまでのIETF Meetingで議論された各項目についての議論が継
続され、実運用可能なプロトコルを目指した作業が進められました。また、今
後の計画として、daneの運用ドキュメントの充実などが提案されました。

▼daneとDNSSECの関係

daneに相当するアイディア、つまり、DNSを証明書のインフラとして活用しよ
うという考え方そのものは以前からありました。しかし、その実現のためには
通信路への攻撃に対する耐性が必要不可欠であり、そのための技術である
DNSSECが実環境に導入されていなかったことから、実現のための障壁となって
いました。

その後、2010年7月のルートゾーンへのDNSSECの導入を皮切りに、2011年に
「.jp」や「.com」、「.net」などの主要なTLDにおいてDNSSECの正式運用が相
次いで開始され、インターネットにおいてdaneを実際に導入・運用するための
前提条件が整いました。

このような背景から、daneはDNSSEC普及のためのキラーアプリケーションの
一つとなる可能性があります。今後のdane WGの動向に要注目です。

■appsawgの状況

appsawgは「Applications Area Working Group」に由来しており、アプリケー
ションエリア全般の話題について総合的に取り扱うためのWGです。最近のIETF
における状況の変化により、従来個別に存在していたWebや電子メール関連の
WGにおいて議論されていた話題は、最近ではappsawgでまとめて議論されるよ
うになってきています。

今回のappsawgではドメイン名／DNSに関係する話題として、ICANNで進められ
ている国際化トップレベルドメイン（IDN TLD）における異体字の問題点を明
らかにし、その解決を図るためのプロジェクト（Variant Issues Project）の
概要が紹介されました。プロジェクトではアラビア文字、漢字、キリル文字、
デーバナーガリー（*2）、ギリシャ文字、ラテン文字の6種類をターゲットと
しており、各文字ごとにエキスパートが参加し、問題点の洗い出しを行ってい
ます。

（*2）デーバナーガリー（Devanagari）：北インド諸語であるヒンディー語、
　　　マラーティー語、ネパール語などで筆記・印刷に用いられている文字で
　　　す。特徴として、各文字がシローレーカー（頭線）と呼ばれる横線でつ
　　　ながっている点が挙げられます。

会議では、プロジェクトからの報告を受けてIETFが検討すべき内容として、
IDN TLDを利用する各アプリケーションがどのように動作・機能すべきかを検
討する必要がある、という指摘がありました。

また、今回のappsawgでは電子メールにおける送信元認証（Sender 
Authentication）の技術として広く普及しているSPF（Sender Policy 
Framework）を、現在の実験（Experimental）規格から標準規格に更新するた
めのWGを作成しようという提案がありました。その場ではWG作成に関する合意
には至りませんでしたが、今後WGのメーリングリストで議論を継続することと
なりました。

■weirds BOFの状況

weirdsは「WHOIS-based Extensible Internet Registration Data Service」
に由来しており、Webサービスを用いた次世代のWHOISについて議論することを
目的としています。weirdsは前回のIETF81ではbar BOF（*3）として開催され
ましたが、今回は正式なBOFとして開催されました。

（*3）IETFで開催されるBOF（Birds of a Feather）には、担当エリアディレ
　　　クターの事前承認を必須とし、将来のWG設立を目指し本会議の一部とし
　　　て公式に開催される「BOF」と、早朝・昼食時・終了後など、本会議の
　　　時間外に非公式の形で開催される「bar BOF」の2種類があります。

今回のweirdsでは目的を、国際化の完了、計算機で処理しやすい
（Machine-friendly）データモデルと表現形式の標準化、それぞれのサービス
レベルの区分けの三つとすることが説明されました。

その後、ARIN、RIPE NCC、ICANN、LACNICにおけるweirdsの実装状況と得られ
た知見が発表されました。そのうちRIPE NCCの発表において「UTF-8をフルサ
ポートしているのでシステムは国際化されている」という内容があり、会場か
らはUTF-8サポートだけをもって国際化されたというのは不十分であるという
指摘がありました。

その後、WGのチャーター案としてweirdsをRIRなどのアドレスレジストリに限
定するか、TLDなどのドメイン名レジストリも対象とするかについて議論され
ました。その場では明確な合意に至りませんでしたが、会場の雰囲気として、
まずはアドレスレジストリに限定した形で当面の問題解決を図ろう、という空
気が支配的でした。

■eai WGの状況

eaiは「Email Address Internationalization」に由来しており、電子メール
アドレスを国際化するための各プロトコルの標準化を行っています。

eaiでは現在の実験規格から標準規格への更新のための作業を継続しており、
SMTP、電子メールヘッダフォーマット、DSN（*4）の拡張については、現在の
提案がIESGによって会議終了後の11月22日に承認されました。また、POP（*5）
拡張については作業をほぼ完了、IMAP（*6）拡張については細かい部分の議論
をメーリングリストで継続し、近日中に仕様をまとめる予定となっています。

また、POP／IMAPにおけるEAIをサポートしていない場合のダウングレードにつ
いては若干の改良点が合意され、いくつかの懸念点については関係者とエリア
ディレクター、WG議長（チェア）による集中的な議論の後、改善点を提示する
こととなりました。

（*4）DSN：Delivery Status Notification
　　　電子メールの配送状況を発信者に通知するためのプロトコルとして、
　　　RFC 3464で定義されています。

（*5）POP：Post Office Protocol
　　　ユーザーが自分の電子メールをメールサーバーから取り出す時に使用す
　　　る受信用プロトコルとして、RFC 1939で定義されています。

（*6）IMAP：Internet Message Access Protocol
　　　ユーザーがメールサーバー上の電子メールを操作するためのプロトコル
　　　として、RFC 3501で定義されています。IMAPではPOPと異なり、電子
　　　メールをメールサーバー上に保存したまま管理することを想定していま
　　　す。

eaiが標準化されることにより、電子メールアドレスに日本語を含むさまざま
な言語が使用できるようになります。従来のeaiは実験規格でしたが、現在進
められている標準規格への更新が完了することにより、今後必要となるMTA
（*7）、MUA（*8）、MSA（*9）、MDA（*10）のeaiへの対応を進めるための準
備が整うことになります。

（*7）MTA：Mail Transfer Agent（メール転送エージェント）
　　　メールサーバーにおいて宛先別の振り分け、メール配送エージェント
　　　（MDA）への振り分けなど、メール転送に関する機能を担当します。代
　　　表的なMTAの実装にはsendmail、Postfix、qmail、Eximなどがあります。

（*8）MUA：Mail User Agent（メールユーザーエージェント）
　　　電子メールの読み書きや管理をするためのアプリケーションソフトウェ
　　　アで、メールソフトとも呼ばれます。従来からさまざまなMUAが開発・
　　　利用されており、最近ではWebブラウザーで利用するWebメールが広く普
　　　及しています。

（*9）MSA：Mail Submission Agent（メール投稿エージェント）
　　　メールサーバーにおいてMUAから発信されるメールの受け取りを担当し
　　　ます。spamメールなどの不正利用を防止するため、MUAからの受け取り
　　　に特化した新たなエージェントとして提案されました。MSAはSMTP認証
　　　などの機能を備え、不完全なメッセージの修正や不正利用の防止などを
　　　担当します。

（*10）MDA：Mail Delivery Agent（メール配送エージェント）
　　　 メールサーバーにおいて、MTAにより振り分けられた電子メールを受信
　　　 者に配送する機能を担当します。

■次回のIETFはパリで開催、会議参加者数の推移に注目を

次回の第83回IETF Meeting（IETF83）は2012年3月25日から30日にかけてフラ
ンスのパリで開催されます。

冒頭でも述べたように、IETF82の参加者数は前回のIETF81から大きく減少しま
した。もし参加者が1,000人を切る状況が今後も長期にわたって続いた場合、
会議参加費の更なる値上げ（*11）や会期の短縮、これまで続けてきた開発途
上国の参加者の支援（旅費・宿泊費の負担）の削減などの緊急対策を取る必要
があるともいわれています。

（*11）2009年に会議参加者の減少に伴う会議参加費の値上げ（約6％値上げし
　　　 675米ドルとする）が実施されています。

しかし、このような性急な経費削減は、IETFの活動そのものにも影響を与えか
ねません。またIETFはインターネット技術の標準化という重要な役割を担って
おり、特定のスポンサー企業や政府などからの安易な活動資金の調達は、活動
の中立性や自律性などを考慮した場合、好ましいことではありません。そのた
め、IETFが今後も健全な運営を継続していけるかどうかは、次回を含む今後の
会議参加者数の推移にかかっているともいえるでしょう。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

◎関連URI

　- IETF 82 - Taipei, Taiwan
　　http://www.ietf.org/meeting/82/
　　（IETF82ホームページ）

　- IETF 82 Preliminary & Interim Materials
　　https://datatracker.ietf.org/meeting/82/materials.html
　　（IETF82発表資料一覧）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━
■会議報告：http://jpinfo.jp/event/
■配信先メールアドレスなどの変更：http://jpinfo.jp/mail/henkou.html
■バックナンバー：http://jpinfo.jp/mail/backnumber/
■ご意見・ご要望：from@jprs.jp

当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、
ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。
また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、
リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに
ご注意ください。
その他、ご利用に当たっての注意事項は読者登録規約にてご確認ください。
http://jpinfo.jp/mail/kiyaku.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
編集・発行：株式会社日本レジストリサービス（JPRS）
http://jprs.jp/
http://日本レジストリサービス.jp/
Copyright(C), 2011 Japan Registry Services Co., Ltd.