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

ドメイン名関連会議報告

2006年

第66回 IETF Meeting 報告（後編）

～EAI、ENUM、IEPG報告～

2006/08/02

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

会議風景
IETF(The Internet Engineering Task Force) Meetingにおいて発表を行うJPRS 藤原和典

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が提案されましたが、特に議論にはなりませんでした。

関連ドキュメント



最後に、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のメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。