JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト

増刊号

vol.58

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2006-08-01━
                     ◆ FROM JPRS 増刊号 vol.58 ◆
━！ＪＰ━━━━━━━━━━━━━━━━━━━━━━━━━ＪＰＲＳ━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                   第66回 IETF Meeting 報告（後編）
                       ～EAI、ENUM、IEPG報告～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

前編に続きまして、今回、後編として、EAI、ENUM、IEPGに関して報告します。

          ◇                     ◇                     ◇

▼EAI（Email Address Internationalization） WG

EAI WGは、メールアドレスを国際化し、ASCII文字以外の文字をメールアドレ
スとして使用可能とするための方式を議論するWGです。

EAI WGでは2006年5月に北京でWG Interim（臨時） Meetingが開催されていま
すが、いくつかのドキュメントについてはそこで議論された事項がInternet 
Draftに反映されないまま今回のWGで試験実装を含めて発表され、他のドキュ
メント著者や会場が混乱していました。そのため、Internet Draftに書かれて
いないことをベースとした発表はしないよう、Chairから注文がありました。

会場での議論では、Downgrade（既存のシステムと互換性を維持するための変
換）時に、国際化メールアドレスを特定のアルゴリズムで自動変換してよいこ
とを示すATOMICパラメータについて、多くの時間が費やされました。会場の合
意としてはATOMICは削除することになりましたが、その後もMLで継続して議論
されています。

個別のドキュメントに関する議論の中では、SMTP拡張に関し、メール送受信者
の情報を伝えるコマンド（MAIL FROM、RCPT TO）以外にもメールアドレスを含
むコマンド（DSNなど）があり、その扱いについても記述すべきという指摘が
ありました。また、メーリングリスト拡張に関しては、ドキュメント著者から
mailto URIおよびIRIは国際化メールアドレスに対応する代替ASCIIメールアド
レスをサポートすべきかが課題であると説明され、結論は出ていません。
Downgradeに関しては、会場からDowngradeしたヘッダを保存するために導入す
る新規ヘッダの形式について、汎用的な1つのヘッダを導入するよりも既存ヘッ
ダである個別のものを規定したほうがよいとの指摘があり、考慮することにな
りました。

各ドキュメントの著者たちはすぐに次のInternet Draftを出して、WGメンバー
がレビューできるようにすることが合意されました。


▼ENUM（Telephone Number Mapping） WG

ENUM WGは、ENUM技術の標準の決定、運用のための技術資料の作成、および
ENUM運用に関する情報交換を行うためのWGです。

今回の会議では、従来から継続しているENUM実装者向けのドキュメント、新し
いENUMサービス、インフラストラクチャENUMの提案だけではなく、ENUMプロト
コルであるRFC3761そのものを大規模に更新する提案の議論が行われました。

今回の会議では、ここ数回にわたりWGでの議論の対象となってきたENUM実装者向
けのドキュメントである「ENUM Implementation Issues and Experiences」
（L. Conroy氏とJPRS藤原和典の共著）について、ENUM標準を更新すべきと指
摘する部分があるため、その部分を分けたほうがよいという議論がありました。
このドキュメントについては、WG Chairと著者で進めかたを検討し、WGに報告
することとなりました。

IM、vcard、カレンダーなどのENUMサービス提案と、ENUMサービスを登録する
ガイドラインドキュメントについては、WGでほぼ合意が得られ、WG Last call
にかけられることになりました。

インフラストラクチャENUMについての議論では、インフラストラクチャENUM用
のTLDとしてie164.arpaが提案されましたが、特に議論にはなりませんでした。

◎関連ドキュメント
  - The E.164 to Uniform Resource Identifiers (URI)
    Dynamic Delegation Discovery System (DDDS) Application for 
    Infrastructure ENUM 
    http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-00.txt

最後に、WG ChairのPatrik Faltstrom氏からENUMプロトコルの作り直しについ
ての議論が提案されました。RFC 3761 bisと呼ばれる新しいENUMプロトコル提
案では、従来のENUMの抱える問題点の解決が提案されています。従来の問題点
のうち、大きなものは以下の通りです。

 - ENUM・DDDSの標準にオーバースペックな点・曖昧な点がある
   （この点については前述のENUM実装者向けドキュメントでも指摘していま
     す。）

 - 実験サービスを登録した場合の動作の定義が曖昧で、衝突を防ぐ方法が記
   述されていない

 - ENUMサービスのIANA登録に時間がかかる

 - 一つの名前（RRSet）に複数のサービスを記述するため、DNSパケットが大
   きくなり、解釈の手間も大きい

これらの問題を解決するために、SRVリソースレコードのような使い方をする
URIリソースレコードを定義し、ENUMサービスごとに別々のドメイン名にURIを
登録するという提案が行われました。

たとえば、一つの電話番号にSIP URIとH.323 URIを登録した場合、従来のENUM
では

  <enumドメイン名>  NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.jp!" .
  <enumドメイン名>  NAPTR 10 100 "u" "E2U+h323" "!^.*$!h323:info@example.jp!" .

とDNSに記述しましたが、今回の提案では、以下の通り記述することになりま
す。

  _sip._enum.<enumドメイン名> URI 10 10 "sip:info@example.jp"
  _h323._enum.<enumドメイン名> URI 10 10 "h323:info@example.jp"

従来のENUMでは、一度のDNS検索でSIP URIとH.323 URIの両方が得られるため、
DNSパケットサイズが大きくなりますし、DNS応答を解釈して必要なURIを得る
必要があります。新提案の場合は、サービスごとにドメイン名が決まるため、
一つのENUM番号に複数のサービスを登録している場合でも、検索時には一つの
サービスだけのURIを検索することになり、DNS応答が小さくなります。今回の
例ですと、ある番号のSIPサービスについてのENUM検索は、_sip._enum.<enum
ドメイン名>へのURIリソースレコードの検索となり、結果は一つのリソースレ
コードとなります。

この提案についての議論で、従来のENUM標準との互換性がないことが指摘され
ました。この提案についてはこれから深く議論していくことになりそうです。


▼IEPG（Internet Engineering Planning Group） Meeting

IEPGは、インターネット運用についての情報交換を行うグループで、IETF会議
に併せて開催されています。ここでは、DNSやインターネットインフラに関す
る発表をいくつかピックアップして紹介します。

まず最初に、VeriSignのMatt Larson氏から、VeriSignで観測されたDNSの再帰
的な問い合わせを使ったDDoS攻撃について報告がありました。発表の中では、
この攻撃の恐ろしいところは2Gbpsで120Gbpsの攻撃を生み出せることであり、
攻撃を検出してもISPとしては容易にフィルタで対処できないということが指
摘されました。また、UDPはそもそも安全ではなく、DNS以外にも同様の攻撃の
もととなる可能性があることが指摘されました。抜本的な対策のためには、ソ
ースアドレスが偽造されたIPパケットを内部から外部に出さない方法を示した
BCP 38を始める必要があることが強く訴えられました。ちなみに、攻撃に使わ
れたドメイン名の第2位はRootドメイン（.）だったとのことです。

DNSに関する他の話題として、CAIDAのNeville Brownlee氏からはCAIDA/
DNS-OARCで行っているIP Anycastを導入しているRootサーバ（C、E、F、K）の
観測について報告されました。この観測ではRootサーバへのDNS問合せログを
分析し、そのソースアドレスからIP Anycast Nodeに届くトラフィックの世界
地図を描いたり、Node毎にASやIPアドレス帯がどの程度分散しているかをグラ
フ化したりしています。

インターネットインフラに関する話題として、APNICのGeoff Huston氏から最
新の観測に基づき、RIRの持っているアドレスプールからIPv4アドレスがなく
なる時期は2011年頃と見込まれるとの報告がありました。そのため、2009～
2012年には現在のIPv4アドレス割当フレームワークは終焉を迎えるだろうと予
測されていますが、その次の展開はまだ結論が出ていません。

━！ＪＰ━━━━━━━━━━━━━━━━━━━━━━━━━ＪＰＲＳ━━
              編集・発行：株式会社日本レジストリサービス(JPRS)
                            http://jprs.jp/
                            http://日本レジストリサービス.jp/
                会議報告：  http://jpinfo.jp/event/
  メールニュース配信解除：  http://jpinfo.jp/mail/
          ご意見・ご要望：  from@jprs.jp

当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、
ニュースグループまたは他のメディア等へ許可なく転載することを禁止します。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Copyright(C), 2006 Japan Registry Services Co., Ltd. 2006年08月01日