ENUM研究グループ 第1次報告書(第0版)
2002/11/5 ENUM研究グループ事務局
@@1．はじめに
ENUMは，インターネット上のサービスを電話番号による名前空間を用いて，
識別するメカニズムである．その仕様の検討および標準化は，IETFのENUMワー
キンググループを中心に進められており，ITU-Tでもその運用に関して検討が
進められている．
既存の電話網に接続された端末機器(電話機やファクシミリ装置)から，イン
ターネット上の端末機器への接続の際にも，このENUMは有効である．電話機
は相手を識別するために，数字，＊，＃ の 12文字の組合せによる電話番号
しか利用できない．ENUMは，この電話番号とインターネット上のアプリケー
ションを対応づけることができる．この機能すなわち既存の電話機から，イ
ンターネット電話への接続を行う際の名前(番号)の解決手段として，ENUMは
注目されている．
ENUM研究グループ(以下研究グループ)は，このENUMについて，その可能性と
課題を 技術的視点で，調査・検討をおこない，技術的課題を抽出し，
整理することを目的として設立された．
研究グループができた背景は次の通りである．
* IETFにおけるENUM関連の技術標準が明確になってきた
* ITU-T において，その国際的な運用方針がサプリメントとしてじょじょに示される
ようになってきた．
* IAB，RIPE NCC，ITU-T を中心に，ENUMのトライアルの環境ができるようになった
* 国内でも，インターネット電話が普及しはじめ，IP電話用の050 で始まる電話
番号の払いだしが開始した．
このような背景のなか，ENUMに対する理解を高め，今後の方向性についての
検討が急務になってきている．
この報告書は，研究グループの検討の結果をまとめ，第1次報告としてまとめ
たものである．
この報告書では，研究グループの調査，検討の結果のうち，
* ENUMの概要
* ENUMによって解決できる課題
* 今後の検討の進め方
を中心にまとめた．
@@1.1 研究グループの検討の目的と対象
この研究グループでの検討の目的は，次の通りである:
* ENUM技術そのものの理解
* ENUMの実現方式，運用方式，またこれに関連する検討
* ENUMの実現，運用における制度上の課題の抽出
* その他，ENUMに関連する技術的課題の検討
* ENUMを導入した際の効果と問題の明確化
このような目的を達成するために，研究グループでは，
ENUM技術と
それに関連する技術(DNS，URL，DDDS等)について中心に調査と検討を
進めている．
ENUMを実際に利用する際の，ENUM以外の重要な項目，たとえば:
* 課金に関する事項
* 発呼・着呼時の相手の認証，成りすましの問題
* 通信の秘密
* ワン切り，スパム，ダイレクトメイルなど
* 通信の品質，信頼性
については，検討の対象外とし，ENUMにフォーカシングをあて，
検討している．
これらの検討対象外の項目は，実際にENUMをベースにしたサービスの構築を
行う際には，重要な事項である．別の場での検討，または，研究グループで
の今後の検討課題としたい．
@@1.2 用語の定義
ここでは，本報告書の内容を理解するために必要な用語について定義する．
{{別紙参照}}
@@2．ENUMの概要
ENUMは，ITU-Tによる電話番号の国際的な取り決めである E.164 勧告に
基づく電話番号(以下 E.164番号)をキーとして，DNSを検索することにより，
必要なアプリケーションをURI形式で得る．
電話番号 "03-5297-2311" を，ENUMをつかって検索する場合を例にとって，
動作の様子を示す．まず，
1) 国コード付きのE.164番号にする．
+81-3-5297-2311
2) 先頭の+と数字以外の文字を抹消する．これがENUMのAUS．
+81-3-5297-2311
3) 数字以外の文字を抹消する．
81352972311
4) それぞれの数字の間にドット(".")を挿入する．
8.1.3.5.2.9.7.2.3.1.1
5) 数字を逆順にする．
1.1.3.2.7.9.2.5.3.1.8
6) 最後に文字列 ".e164.arpa" を追加する．
1.1.3.2.7.9.2.5.3.1.8.e164.arpa
この文字列をドメイン名とし，DNSに対して，NAPTRレコードを要求する．
登録が正しければ，最終的に，この番号に対するURIを得ることができる．
このドメイン名に対して，以下のようなNAPTRレコードがDNS上に登録されて
いた場合，
[[
$ORIGIN 1.1.3.2.7.9.2.5.3.1.8.e164.arpa
IN NAPTR 100 10 "u" "E2U+talk:sip" "!^.*$!sip:info@sip.nic.ad.jp!
]]
結果として，URI，
sip:info@sip.nic.ad.jp
を得る．これによりアプリケーションプログラムは，sipサーバ sip.nic.ad.jp
に登録された info@sip.nic.ad.jp に対して，SIP を用いて接続を試みる．
他のDNSのレコードと同様に，NAPTRレコードもひとつのドメイン名に対して，
複数のレコードを定義することができる．
[[
$ORIGIN 1.1.3.2.7.9.2.5.3.1.8.e164.arpa
IN NAPTR 100 10 "u" "E2U+talk:sip" "!^.*$!sip:info@sip.nic.ad.jp!" .
IN NAPTR 102 10 "u" "E2U+message:mailto" "!^.*$!mailto:info@nic.ad.jp.!" .
IN NAPTR 104 10 "u" "E2U+talk:tel" "!^(.*$)$!tel:\\1!" .
]]
NAPTRレコードの3番目，4番目のパラメータでレコードの優先度を指定することが
できる．
この例では，まず，SIPで音声サービスによる接続を優先する．次に，
SMTPによる電子メール，最後に，(この端末に接続された既存の電話網を用いて)
電話接続となる．
3番目のレコードは，NAPTRの文字置き換えのルールにより，URI
tel:+81352972311
を意味する．
{{さらに例を付録に添付．
たとえば，書き換え規則を用いた局番によるSIPサーバ区別とか．}}
このように，NAPTRを用いて，URIで表すことのできるアプリケーションを
E.164番号に対応づけることができる． たとえば:
.TS
center,tab(|);
l l.
_
サービス|URIスキーム
_
SIP|sip:
既存電話サービス|tel:, fax:, modem:
電子メール|mailto:
WEB|http:
TELNET|telnet:
H.323|???
_
.TE
NAPTRで記述可能な ENUMサービス については，最終的には，
IANAによって登録されるされる．ENUMサービスの登録手続きと要件については，
RFC2915の改訂版で，その詳細が記述されようとしている．
{{URL，URIの仕様，enumserviceプロトコル種別等を参照}}
@@2.1 ENUMの仕様
ENUMは一連のRFCによって，その仕様が規定されている．主なものは次の通り:
* RFC2916(E.164 number and DNS) は，ENUMの基本的な仕様を規定している．
現在，"The E.164 to URI DDDS Application" というタイトルで，
改訂作業が進められている．
-> draft-ietf-enum-rfc2916bis-01.txt
* RFC2806(URLs for Telephone Calls)，既存電話網との接続を示すURI，
tel:, fax:, modem: を規定．
* RFC3041〜RFC3045(Dynamic Delegation Discovery System - DDDS).
ENUMで利用されている，DNS検索，NAPTRレコード，一連の書き換え規則等が
規定されている．
@@関係するRFC
[[
2141 URN Syntax. R. Moats. May 1997. (Format: TXT=14077 bytes)
(Status: PROPOSED STANDARD)
2168 Resolution of Uniform Resource Identifiers using the Domain Name
System. R. Daniel, M. Mealling. June 1997. (Format: TXT=46528 bytes)
(Obsoleted by RFC3401, RFC3402, RFC3403, RFC3404) (Updated by
RFC2915) (Status: EXPERIMENTAL)
2169 A Trivial Convention for using HTTP in URN Resolution. R. Daniel.
June 1997. (Format: TXT=17763 bytes) (Status: EXPERIMENTAL)
2276 Architectural Principles of Uniform Resource Name Resolution. K.
Sollins. January 1998. (Format: TXT=64811 bytes) (Updated by RFC3401)
(Status: INFORMATIONAL)
2303 Minimal PSTN address format in Internet Mail. C. Allocchio. March
1998. (Format: TXT=14625 bytes) (Obsoleted by RFC3191) (Status:
PROPOSED STANDARD)
2304 Minimal FAX address format in Internet Mail. C. Allocchio. March
1998. (Format: TXT=13236 bytes) (Obsoleted by RFC3192) (Status:
PROPOSED STANDARD)
2396 Uniform Resource Identifiers (URI): Generic Syntax. T.
Berners-Lee, R. Fielding, L. Masinter. August 1998. (Format:
TXT=83639 bytes) (Updates RFC1808, RFC1738) (Status: DRAFT STANDARD)
2483 URI Resolution Services Necessary for URN Resolution. M.
Mealling, R. Daniel. January 1999. (Format: TXT=30518 bytes) (Status:
EXPERIMENTAL)
2806 URLs for Telephone Calls. A. Vaha-Sipila. April 2000. (Format:
TXT=50647 bytes) (Status: PROPOSED STANDARD)
2915 The Naming Authority Pointer (NAPTR) DNS Resource Record. M.
Mealling, R. Daniel. September 2000. (Format: TXT=41521 bytes)
(Obsoleted by RFC3401, RFC3402, RFC3403, RFC3404) (Updates RFC2168)
(Status: PROPOSED STANDARD)
2916 E.164 number and DNS. P. Faltstrom. September 2000. (Format:
TXT=18159 bytes) (Status: PROPOSED STANDARD)
3191 Minimal GSTN address format in Internet Mail. C. Allocchio.
October 2001. (Format: TXT=24235 bytes) (Obsoletes RFC2303) (Updates
RFC2846) (Status: DRAFT STANDARD)
3192 Minimal FAX address format in Internet Mail. C. Allocchio.
October 2001. (Format: TXT=18813 bytes) (Obsoletes RFC2304) (Updates
RFC2846) (Status: DRAFT STANDARD)
3401 Dynamic Delegation Discovery System (DDDS) Part One: The
Comprehensive DDDS. M. Mealling. October 2002. (Format: TXT=10172
bytes) (Obsoletes RFC2915, RFC2168) (Updates RFC2276) (Status:
INFORMATIONAL)
3402 Dynamic Delegation Discovery System (DDDS) Part Two: The
Algorithm. M. Mealling. October 2002. (Format: TXT=38925 bytes)
(Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD)
3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain
Name System (DNS) Database. M. Mealling. October 2002. (Format:
TXT=31058 bytes) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED
STANDARD)
3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform
Resource Identifiers (URI). M. Mealling. October 2002. (Format:
TXT=40124 bytes) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED
STANDARD)
3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA
Assignment Procedures. M. Mealling. October 2002. (Format: TXT=19469
bytes) (Also BCP0065) (Status: BEST CURRENT PRACTICE)
]]
@@2.2 関連する活動(団体)
@@1.6.1 IETF
TBW
@@1.6.2 ITU
TBW
@@1.6.3 ENUM Forum
TBW
@@1.6.4 UKEG
TBW
@@1.6.5その他各国の活動
TBW
@@3. ENUM導入によって期待されれるもの(解決が期待されるもの)
ここでは，ENUMを導入することによって期待されるものについて整理する．
期待される内容によって，その実装や運用方法，管理主体などが異なることが
考えられる．
@@(1) E.164 番号によるユーザとアプリケーションの識別手段として
インターネット上のアプリケーションを番号を用いて識別できる．これは，
大きくふたつの利点がある．ひとつは数字だけで記述でき，電話機のような
テンキーによる端末インタフェースで入力が可能となる．
さらに，一般的に，その電話番号によって対応したユーザを特定することができ
る．ENUMを用いて他のアプリケーションと連係した場合．電話番号を用いて，
そのユーザに対する電話以外の通信手段を統合的に提供することが可能となる．
エンドユーザAが登録したNAPTRレコードを、E.164番号を使って参照し、エ
ンドユーザ手元の端末の相応しいアプリケーションを起動して、エンドユー
ザAと通信を行うことを可能にする。アプリケーションには，電話，ファク
シミリ，携帯電話，インターネット電話，電子メール，WWWなどがある．
<fig1.eps>
[[
(1) ENUM DNSに問い合わせ．
(2) ENUM DNSから応答．
(3) 応答結果をもとにアプリケーションを選択し，接続．
]]
@@(2) 既存電話からインターネット電話への番号解決手段として
既存の電話網の加入者からインターネット電話の加入者に対してアクセスす
るときに，インターネット電話の加入者に対応するURIと対応したE.164番号
との関係を解決する必要がある．これを解決する手段としてENUMは有力な候
補である．
インターネット電話の加入者に対して，E.164番号を割り当て，その番号と，
URIの対を NAPTRレコードとして，DNSに登録する．電話網からインターネッ
トへのゲートウエイは，接続の際，DNSをE.164番号をキーにして，DNSを用
いて検索し，対応する SIPサーバに対応するURIを得る，そのURIに従って呼
を確立する．
<fig2.eps>
[[
(1) 電話機がIP電話に対して発呼．
(2) ゲートウエイがENUM DNSに問い合わせ
(3) ENUM DNSから応答．
(4) 応答結果をもとにSIPゲートウエイを選択し，接続．
]]
この場合，ENUMを用いなくても，たとえば，ゲートウエイがインターネット
電話に対応するSIPサーバが事前設定されていたり，共通信号線を解釈する
インターネット電話側のゲートウエイを用いれば，ENUMを用いずに，アクセ
スが可能となる．ただし，ENUMを用いることにより，検索のインターフェー
スの統一化，スケーラビリティなどの利点がある．
@@(3) インターネット電話から既存電話への番号解決手段とし
インターネット電話の加入者から既存の電話網の加入者へのアクセスの際に
は，必ずしも ENUM を使う必要はない．インターネット電話が通常のコン
ピュータのようなキーボードを持つものであれば，ゲートウエイをドメイン
名を用いて相手を指示すればよい．
しかし，ENUMをもちいれば，(2)と同様に統一的なインターフェースで
管理することができる．
ENUMを用いてインターネット電話から既存電話への接続の方法は，
URIスキーム tel: を用いる方法と IP電話のスキーム(たとえばsip:)を
用いる方法がある．
tel: は，電話番号を示すURIスキームで，
tel:+81352972311
といったものである．ENUMによってこのURIを得た端末は，この端末に接続
されている電話網をつかって接続を試みる．この接続ではインターネットを
利用していない．
既存電話網とインターネットとの間にゲートウエイが設置されており，SIP
サーバによってその接続が管理されている場合，URIによって，そのSIPサー
バが指示されることによって，インターネット電話の加入者からSIPを用い
て既存電話の加入者に対してアクセスが可能となる．
<fig3.eps>
[[
(1) ENUM DNSに問い合わせ．
(2) ENUM DNSから応答．
(3) 応答結果をもとに接続先を選択し，接続.
]]
固定電話のように地域に依存した電話網の場合，インターネットとのゲート
ウエイが複数あることが考えられる． ゲートウエイの選択方式としては
TRIPのようなゲートウエイ選択の専用プロトコルを用いたり，局番毎にゲー
トウエイが特定できる場合は，局番毎にそのゲートウエイを返答するように
NAPTRを設定することによって解決できる．
インターネット電話から既存電話への接続は，技術的な問題よりも，
課金の問題など制度的な問題が大きい．
@@1.5.4 電話網(含むIP電話網)の番号解決手段として
ENUMのE.164番号データベースの機能を利用して，電話事業者がENUMを電話
番号の管理，事業者間の経路情報管理のために用いることができる．電話網
としてIPを用いているような場合，IP技術をベースにしたENUMは親和性が高
い可能性がある．
<fig4.eps>
事業者やロケーションから独立した番号ポータビリティサービスや，UPT，
フリーダイヤル(着信者課金サービス)などの実現手段して，このENUMの利用
が考えられる．
@@4. ユーザENUMとオペレータENUM
ENUMサービスは，E.164番号から，特定のURLの組によって指定されるアプリケー
ションへの対応を，DNSによって行うものである．
ENUMで想定されているアプリケーションとして，音声伝送サービスやファクシ
ミリといった従来の電話網におけるアプリケーションの他に，URIで識別され
るインターネット上の一般的なアプリケーションも対象としている．これらの
アプリケーション(すなわち，DNSレコード上のURI)はE.164番号に対応するエ
ンドユーザが指定する．
ENUMサービスのうち，事業者がその網の実現のために用いるものを
オペレータENUM(またはインフラストラクチャENUM)と呼ぶことがある．
-> UKEGレポート
-> draft-stastny-enum-scenarios-00.txt
たとえば，IP電話事業者が，そのIP電話網内の電話番号による呼制御をENUM技
術を用いて実現する場合，そのENUMサービスは，オペレータENUMである．
通常のENUMはエンドユーザによって，E.164番号に対応するDNSレコードの情報
を管理するのに対して，オペレータENUMは，事業者が主体となって管理され，
登録できるアプリケーションは，その網管理のためのレコードとなる．
複数の事業者の網が相互接続された場合には，E.164番号からIPアドレスへの
変換および変換情報の管理に関して，事業者間での共通のスキームを提供する
ことが適切である．オペレータENUMはこのスキームを実現するものである．
ナンバーポータビリティのように事業者間の電話データベースとして，もちい
られる場合も，オペレータENUMである．
オペレータENUMに対して，普通のENUMをユーザENUMと呼ぶ．
ユーザENUMとオペレータENUMは，その管理方針，管理主体，管理方法，および
種々の要求条件が大きく異なっている．
@@ 4.1 オペレータENUM
{{典型的なオペレータENUMを想定した整理}}
□ 目的
- 事業者内の呼制御のため
- 事業者間での相互の呼制御のため
- 既存電話網から複数のIP電話網への呼制御のため
□ 登録者
- 網を管理する事業者が対応する番号を登録する．
- 網内のすべて電話番号に対して，DNSレコードが登録される．
□ ENUMクライアント
- 網の装置や端末
□ 要求条件
- 呼制御(ルーティング???) 解決を保証するためのエントリーの網羅性および
完全性．
- 事業者のサービスの品質に必要な，性能，信頼性，スケーラビリティ．
- クエリのアクセス制限(第3者のDNSアクセス制限)
□ DNSの構成(Tier構造)
- 事業者の構造に対応
- 場合によっては，ローカル/プライベートな構成も
□ セキュリティの問題
- クエリのアクセス制限(第3者のDNSアクセス制限)
□ 番号管理
- 事業者への番号割り当てに対応．
@@ 4.2 ユーザENUM
{{典型的なユーザENUMを想定した整理}}
□ 目的
- E.164番号保有者(?)が自身の指定する到達可能なアプリケーション公開
- E.164番号ユーザへの音声サービスでの到達方法の獲得
- E.164番号ユーザのもつ音声以外(WEB，メール)の到達方法の獲得
□ 登録者
- E.164番号保有者(?)
- E.164番号ユーザ(加入者)
- 登録者の意志にもとずく登録(opt-in)
□ ENUMクライアント
- インターネットに接続されたユーザコンピュータ内のアプリケーション
- ゲートウエイ，プロキシ等
□ 要求条件
- ユーザへの Openness と Fairness の確保
- E.164ユーザが要求する プライバシ，セキュリティレベル
- ENUMクライアントが要求する プライバシ，セキュリティレベル
□ DNSの構成(Tier構造)
- 事業者に依存しないフラットな構造
- グローバルな構成(あたりまえの)
□ セキュリティの問題
- 登録時のE.164ユーザの認証，登録データの正当性
□ 番号管理
基本的に個人ユーザが(その意志で)番号に対応するURIの設定をおこなうことから，
既存の電話番号管理との関係を明確にしておく必要がある．
★ 既存の電話番号と共有するとき
既存の事業者に割り当てられた電話番号をユーザENUMの番号としても
利用する場合は，事業者の管理するレコードとユーザの登録する
レコードに不整合が生じないような対策が必要である．
たとえば，
- レコードの優先順序の制限
- ユーザが登録する際に事業者の確認
- 事業者がユーザの申請をうけ，登録する
など．
★ ユーザENUM用の番号空間
ENUM用の番号が割り当てられれば，事業者による番号管理との，
運用管理上の衝突はなくなる．
ただし，番号空間の逼迫のなかで，制度上の問題がある．
@@5. 今後の検討のすすめかた
研究グループでは，いままでの，調査，検討の結果，ENUMの適用として，ユー
ザENUMとオペレータENUMのふたつに整理して検討する必要があるという認識に
達した．また，ユーザENUMとオペレータENUMは，それぞれ，目的や要求条件が
大きく異なっており，その結果として，性能機能要件，信頼性，セキュリティ・
プライバシ，DNSの運用管理体制に大きな違いがあることが分かった．
そこで，研究グループでは，基本的な技術について更に調査検討を進めるとと
もに，これらのふたつの適用に分けて，その要件，運用管理体制，その他の課
題について検討を進めていく．さらにこれらが共存する場合について，検討こ
とにする．
#◆ 制度の問題 (###)
#
# - 事業者間共通のデータベースとしてのENUM
#
# IP電話事業者間の電話番号解決をおこなうためのデータベースの
# 要求条件と制度．
#
# - (ベストエフォートの)インターネット電話への電話番号の付与
#
# インターネット上のIP電話端末に接続するためには，既存の電話から
# 識別できる 電話番号の付与が必要である．ある一定の品質のサービスの
# 提供を保証する事業者に対しては 050 番号の 払い出しをおこなっているが，
# 一般のインターネットに接続されたIP電話端末(に対する/を識別する)
# 電話番号の付与または払い出しが必要となる．
#
# - ユーザENUMの本格的な利用環境を実現するためには，
# 電子メールやWEBなど，
# 電気通信役務に基づく音声伝送役務以外のサービスを識別するための
# 電話番号の付与または払い出しが必要となる．
#
# # 研究会では，IP電話サービスの契約単位に割り当てることとなっている．
#
# # 電気通信番号規則では，050 は パケット交換網に接続される端末設備等に
# # 提供される音声伝送役務を識別するための 電気通信番号と規定されている．
#