2002/12/02 ENUM研究グループ第4回研究会
資料4
@ENUM研究グループ
@第1次報告書
(第2版)
2002年12月2日
@@1．はじめに
ENUMは，電話番号による名前空間を用いて，インターネット上のサービスを
識別するメカニズムである．その仕様の検討および標準化は，IETFの
ENUMワーキンググループを中心に進められており，ITU-Tでも
その運用に関して検討が進められている．
ENUMは，ITU-Tによる電話番号の国際的な取り決めである E.164 勧告に
基づく電話番号をキーとして，DNSを検索することにより，
そのE.164番号に対応する，
利用可能なひとつもしくは複数のアプリケーションをURI形式で得る機構である．
既存の電話網に接続された端末機器(電話機やファクシミリ装置)から，イン
ターネット上の端末機器に接続する際にも，このENUMは有効である．電話機
は相手を識別するために，数字の組合せによる電話番号
しか利用できない．ENUMは，この電話番号と，それに対応するインターネット上で
利用可能なひとつまたは複数の
アプリケーションを対応づけることができる．
この機能，すなわち既存の電話機から
インターネット電話への接続を行う際の名前(電話番号)の解決手段としても，
ENUMは注目されている．
ENUM研究グループ(以下研究グループ)は，このENUMについて，その可能性と
課題を，技術的視点で調査・検討をおこない，技術的課題を抽出し，
整理することを目的として設立された．
研究グループができた背景は次の通りである．
* IETFにおけるENUM関連の技術標準が明確になってきた．
* ITU-T において，その国際的な運用方針がサプリメントとして，
徐々に示されるようになってきた．
* IAB，RIPE NCC，ITU-T を中心に，ENUMのトライアルの環境が
できるようになった．
* 国内でも，インターネット電話が普及しはじめ，IP電話用の050 で始まる
電話番号の割当が開始された．
このような背景のなか，ENUMに対する理解を高め，今後の方向性についての
検討が急務になってきている．
この報告書は，研究グループの検討の結果をまとめ，第1次報告として
まとめたものである．
この報告書では，研究グループの調査，検討の結果のうち，
* ENUMの概要
* ENUMによって解決できる課題
* 今後の検討の進め方
を中心にまとめた．
さらに，詳細の検討については，2003年3月末に発行予定の第2次報告までに，
まとめて報告する予定である．
@@1.1 研究グループの検討の目的と対象
この研究グループでの検討の目的は，次の通りである:
* ENUM技術そのものの理解
* ENUMの実現方式，運用方式，またこれに関連する検討
* ENUMの実現，運用における制度上の課題の抽出
* その他，ENUMに関連する技術的課題の検討
* ENUMを導入した際の効果と問題の明確化
このような目的を達成するために，研究グループでは，
ENUM技術と
それに関連する技術(DNS，URL，DDDS等)を中心に調査と検討を
進めている．
ENUMを実際に利用する際の，ENUM以外の重要な項目，たとえば:
* 課金に関する事項
* 発呼・着呼時の相手の認証，成りすましの問題
* 通信の秘密
* ワン切り，スパム，ダイレクトメイルなど
* 通信の品質，信頼性
については，検討の対象外とし，ENUMにフォーカスして検討している．
これらの検討対象外の項目は，実際にENUMをベースにしたサービスの構築を
行う際には，重要な事項である．別の場での検討，または，
研究グループでの今後の検討課題としたい．
@@1.2 用語の定義
ここでは，本報告書の内容を理解するために必要な用語について定義する．
@@1.1.1 ENUM用語（一般定義）ITU,IETF等
[[AUS]]：Application Unique String
- DDDSアプリケーションへの最初の入力となる文字列
- URIにする変換サービスのインプット(RFC3263)
[[DDDS]]: Dynamic Delegation Discovery System
- 動的な書き換え規則を反復適用して、文字列を変換する仕組み（RFC3401〜3405）
[[ENUM]]：Telephone Number Mapping
- E.164番号をドメイン名に対応させ、番号に対応するURIをDNSに登録する手順
- RFC2916により定義され、IETFとITU-Tが協調して標準化作業を進めている
（IETF ENUM WG charter）
[[E.164番号]]
- ITU-T E.164勧告の付録Aの中で指定された構造、長さ、および唯一性の3つの
特性を満たす10進の数字列（電話番号） 例：+81-3-5297-2571
（ITU-T E.164 Supplement）
[[E.164カントリーコード]]
- E.164で規定される地理的な領域の国番号（ITU-T E.164）
例：日本には81が割り当てられている
[[NAPTR]]: Naming Authority Pointer
- 文字列変換によりドメインラベルやURIを生成するための書き換え規則を記述す
るためのDNSリソースレコード
- RFC2915で定義されたが、DDDSの一部としてRFC3403で再定義された
（RFC2915、RFC3403）
[[番号ポータビリティ]]：Number Portability
- サービス、プロバイダ（電話会社）、ロケーションを変更しても同じ電話番号を
使えること
@@1.1.2 ENUM用語（本報告書独自定義）
[[ ENUMアプリケーション]]
- 発着信の双方でENUMを利用するアプリケーション
例：電話、SIP、H.323、ファクシミリ、電子メール、
インスタントメッセンジャー
[[ENUMクライアント]]
- ENUM検索を行うクライアントアプリケーション
- オペレータENUM：網内の装置や端末
- ユーザENUM：インターネットに接続されたユーザコンピュータ内の
アプリケーション
[[IP電話]]
- ネットワークの一部または全部においてIPネットワーク技術を利用して提供する
音声電話サービス
[[Tier0]]
- ENUM DNS階層のトップで、現在IAB(Internet Architecture Board)が管理し、
e164.arpaが実験的に利用されている
[[Tier1]]
- E.164国番号に相当するENUM DNS階層 日本であれば 1.8.e164.arpa
[[Tier2]]
- NAPTRリソースレコードを保持するENUM DNS階層
[[インターネット電話]]
- IP電話のうち、WWW等のアプリケーションに利用されているものと同じIPネット
ワーク(インターネット)を利用するもの
[[オペレータENUM，インフラストラクチャENUM]]
- ISPや電話事業者が、事業者内または事業者相互間の経路制御のために用いる
ENUMの形態
[[管理されたIP網(Managed IP network)]]
- 帯域予約などの技術を利用することでトラフィック管理されているIP網
[[ユーザENUM]]
- ユーザが自分の電話番号とサービスの関係を規定するために用いるENUMの形態
- インターネット電話事業者が、顧客の電話番号についてインターネットからの
着信に用いる場合も含む
[[DNS]]：Domain Name System
- インターネットに接続されたコンピュータの情報（ドメイン名とIPアドレスの
対応など）を提供する仕組み
[[H.323]]
- ITU-Tが標準化したインターネットやLANなどのネットワークで使用されるマル
チメディア通信用のプロトコル群
[[IP網]]：IP network, IP based network
- ネットワーク層のプロトコルにインターネットプロトコルを
利用したネットワーク
- IPネットワーク
[[IPアドレス]]
- インターネットに接続された機器を識別するための番号
[[SIP]]: Session Initiation Protocol
- IETFが標準化したH.323と同じくインターネットやLANなどのネットワークで
使用されるマルチメディア通信用のプロトコル1999年にRFC2543として規定、
現在はその改良版がRFC3261として標準化
[[SIPサーバ]]
- IPネットワーク上でSIP通話に必要な通信制御情報をやり取りするサーバ
[[SOA]]: start of authority
- ゾーンのオーソリティを示す情報(データの始まりを表す)
[[TRIP]]: Telephony Routing over IP
- 電話番号エリアから指定番号空間に属する電話端末へ着信させるために利用
可能なVoIPシグナリングパス(= Next Hop Server)を見つけるための情報
(=Attributes)をプロバイダ(=ITAD:Internet Telephony Administrative
Domain)間で交換するためのプロトコル(RFC3219)
[[URL]]:Uniform Resource Locator
- インターネット上の各種情報リソースにアクセスする手段（プロトコル）と
場所を指定する記述様式（RFC1738）
[[URI]]:Uniform Resource Identifiers
- 抽象的な資源あるいは場所で指定された資源を識別する簡潔な文字列であり、
URLを拡張した記述様式（RFC 2396）
[[VoIP]]: Voice over IP
- インターネットやイントラネットなどのIPネットワークを介して音声通話を
実現する技術
[[ゾーン]]
- ドメインの持つ名前空間の一部分の情報
DNSには、このゾーンの情報がゾーンファイルとして格納される
[[リソースレコード(RR)]]：Resource Record
- DNSデータベースの各構成要素(レコード)
NAPTRもリソースレコードの一つ
@@2．ENUMの概要
ENUMは，ITU-Tによる電話番号の国際的な取り決めである E.164 勧告に
基づく電話番号をキーとして，DNSを検索することにより，
そのE.164番号に対応するひとつまたは複数の
アプリケーションをURI形式で得る機構である．
電話番号 "03-5297-2311" を，ENUMを使って検索する場合を例にとって，
動作の様子を示す．まず，
1) 国番号付きのE.164番号にする．
+81-3-5297-2311
2) 先頭の+と数字以外の文字を抹消する．これがENUM DDDSの検索用の文字列
AUS(DDDSの項を参照)である．
+81352972311
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を得ることができる．
なお，このTLD ``e164.arpa'' は，RFC2916で ENUM用のドメイン名と
して提案され，現在はトライアル用に利用されている．正式なドメイン名は，
ITU-T，IETF で現在議論されている．
このドメイン名に対して，以下のようなNAPTRレコードがDNS上に登録されて
いた場合，
[[
$ORIGIN 1.1.3.2.7.9.2.5.3.1.8.e164.arpa
IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@sip.nic.ad.jp!
]]
結果として，URI，
sip:info@sip.nic.ad.jp
を得る．これによりアプリケーションプログラムは，
sip:info@sip.nic.ad.jp に対して，SIP を用いてセッションを
確立することが可能であることを知ることができる．
@@2.1 ENUMで考慮しているURIスキームについて
.TS
center,tab(|);
l l.
_
サービス|URIスキーム
_
SIP|sip:
H.323|h323:
既存電話サービス|tel:+012345678;svc=voice
電話でのFAX|tel:+012345678;svc=fax
電子メール|mailto:
インターネットFAX|mailto:
WEB|http:
_
.TE
sipであれば， sip:SipUserName@SipServerName という記号で
ユーザのSIPアカウントを識別する．
@@ 2.2 DDDS (Dynamic Delegation Discovery System)
DDDSは，アプリケーション内のユニークな識別子(AUS)に対して，DNS上に作ら
れたデータベースにある書き換え規則を適用し，URIなどの結果を得るシステ
ムである．(RFC3401, RFC3402)
基本的なアルゴリズムは，
1. AUSが与えられると，アプリケーションごとに規定された最初の変換により，
データベースをひく鍵をつくる．
2. 鍵をもとにDDDSデータベースをひいて，変換規則を得る．
3. AUSに対して変換規則を適用する．
変換規則が最終結果を出すものでなければ変換結果を鍵として 2に戻る．
4. 最終結果を出す変換の結果が出力であり，URIやドメイン名，
アドレスが得られる．
DDDSデータベースとしてDNSを用い，データベースを引く鍵としては
ドメイン名を用い，
またデータの蓄積のためにNAPTRというリソースレコードをRFC3403
で定義した．
NAPTRリソースレコードの書式は以下のとおりである．
.ft CW
IN NAPTR order pref flags service regexp replacement
.ft
.TS
center,tab(|);
lf(CW) l.
order|16bit符号なし整数 小さいもの使用(preferenceより優先)
preference|16bit符号なし整数 小さいもの優先
flags|文字 “S” “A” “U” “P” 置換・解釈の制御
| S:最終結果 次はSRVを引く
| A:最終結果 次はA,AAAAを引く
| U:最終結果 URIを出力
| P:プロトコル依存
| なし:得られた結果についてさらにデータベースを引く
service|文字列 プロトコル [ +サービス ]
| このエントリが適用されるプトロコル・サービスを指定
regexp|置換文字列(正規表現で与える)
replacement|次にNAPTR引きをする場合のドメイン名
.TE
一つの鍵に複数のNAPTRリソースレコードがあった場合，まずorderの小さい
ものを選ぶ．orderが同じものが複数存在した場合，preferenceの小さいもの
を用いる．同一order値に複数の有効なリソースレコードが存在し，
preferenceの小さいものを評価して失敗した場合，次のリソースレコードを
処理する．あるorder値のリソースレコードがすべて失敗した場合は，それよ
り大きなorder値の評価はしないでエラーとする．
serviceフィールドには，このNAPTRリソースレコードが対象とするサービス
を書く．複数のNAPTRリソースレコードが存在した場合，このフィールドを先
にみて該当するか調べておけばよい．
regexpフィールドには正規表現でAUSからの置換規則を書く．
replacementフィールドには，regexpフィールドがある場合は . を書く．
@@2.3 DDDSアプリケーションとしてのENUM
ENUMはDDDSのアプリケーションの一つとして再定義されつつある．
DDDSをENUMで使うプロトコルとしてE2U (Enum to URI)が定義されている．
そのなかのサービスとして
sip, h323, ifax, tel, enum, mailto, httpなどが想定されている.
想定されているサービス，プロトコルと NAPTRのserviceフィールド，
URI例を表で示す．
.TS
center,tab(|);
l l l.
_
サービス・プロトコル|serviceフィールド|URIスキーム
_
SIP|sip|sip:info@sip.nic.ad.jp
H.323|h323|h323:info@h323.nic.ad.jp
インターネットFAX|E2U+ifax|mailto:info-fax@nic.ad.jp
既存電話サービス|E2U+tel|tel:+81352972311;svc=voice
電話でのFAX|E2U+tel|tel:+81352972311;svc=fax
電子メール|E2U+message:mailto|mailto:info@nic.ad.jp
WEB|E2U+message:http|http://www.nic.ad.jp/
_
.TE
ENUMの概要で説明した + ではじまるE.164電話番号がENUMのAUSとなり，最初
の知られた変換は，前述した電話番号からe164.arpaドメイン下のドメインに
変換する規則である．
またENUMではNAPTRには "U" フラグを書くことになっている．DDDSの機能の
うち反復はしない．
他のDNSのリソースレコードと同様に，NAPTRリソースレコードもひとつのド
メイン名(検索鍵)に対して複数のリソースレコード(DDDSデータベース)を定
義することができる．
[[
$ORIGIN 1.1.3.2.7.9.2.5.3.1.8.e164.arpa
IN NAPTR 100 10 "u" "E2U+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+tel" "!^(.*$)$!tel:\\1!" .
]]
この例では，まず，SIPで音声サービスによる接続を優先する．次に，
SMTPによる電子メール，最後に，(この端末に接続された既存の電話網、
あるいは契約IP電話会社のメディアゲートウェイを用いて)
電話接続となる．
3番目のリソースレコードは，NAPTRの文字置き換えのルールにより，URI
tel:+81352972311
を意味する．
また，局番 +8135297 以下の 4桁分の番号すべてを一つのSIPサーバに担当さ
せたい場合，DNSのワイルドカードと正規表現による置換を使って，
sip:NNNN@sip-server.jp (NNNNは4桁番号)のようなURIにできる．
AUSは +8135297xxxx とする
[[
$ORIGIN 7.9.2.5.3.1.8.e164.arpa
* IN NAPTR 100 10 "u" "E2U+sip" "!^+8135297(.*)$!sip:\\1@sip-server.jp!" .
]]
+81352972311を検索すると，sip:2311@sip-server.jp を得る．
このようにして DDDSを用いて，URIで表すことのできるアプリケーションを
E.164番号に対応づけることができる．
@@2.4 ENUMの仕様
ENUMは一連のRFCによって，その仕様が規定されている．主なものは次の通り:
* RFC2916(E.164 number and DNS) は，ENUMの基本的な仕様を規定している．
現在，"The E.164 to URI DDDS Application" というタイトルで，
改訂作業が進められている．
-> draft-ietf-enum-rfc2916bis-02.txt
* RFC2806(URLs for Telephone Calls)，既存電話網との接続を示すURI，
tel:, fax:, modem: を規定．
現在，"The tel URL for Telephone Calls" というタイトルで，
現状の実装にあわせてtel: のみを規定する．
-> draft-antti-enum-rfc2806bis-06.txt
* RFC3401〜RFC3405(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.5 ENUMのTier構造とDNSのゾーン構造
ENUMのTier構造やDNSのゾーン構造は，国ごとの事情により決められる．日本
における構造については議論が必要である．ここでは構造の複数案と考え方
について述べる．
(注：Tier構造を正確に記述するためには，ENUMに関わる組織・事業体等の整
理が別途必要．第1次報告では概要を示すに留め，第2次報告までに整理し記述
することとする．)
@@2.5.1 Tier構造
日本ではひとつの国番号81をひとつの国で使っているため，Tier0とTier1の
境界は，国番号に相当するドメイン1.8.e164.arpaとすることが適当と考えら
れる．
Tier1とTier2の境界についてはいくつかの案が考えられる．このうち代表的
な案について述べる．
@@(1) 電話番号の事業者への割当単位
電話番号(日本においては総務省令である電気通信番号規則に基づく電気通
信番号)は，例えば固定電話では市内局番(03-5297のように0ABCDE)，IP電話
では050-CDEFの単位で，事業者ごとに割り当てている．この単位に相当する
レベルをTier1 とTier2の境界として考えることができる(図 2.2(3))．
従来より電話番号は，番号管理主管庁と電気通信事業者との階層管理に
より効率的に管理されており，この割当単位とTier1/Tier2の境界を一
致させることにより，同様に効率的な管理というメリットが得られる．
電話番号の割当を受ける事業者とTier2レジストリ等の事業者を一致させる
場合には，電話番号でのサービス利用者とENUM利用者との一貫性を取ること
も容易である．この場合，事業者間番号ポータビリティが行われているよう
な場合には，該当する番号について，Tier2のDNSゾーン中に，NAPTRリソー
スレコードの代わりに別のTier2 プロバイダへのNSリソースレコードを記述
するなどの工夫が考えられる．
@@(2) Tier1で電話番号すべての桁まで持つ場合
Tier2を別にせずNAPTRリソースレコードまでTier1レジストリで持つ場合(図
2-1(1)) や，Tier2 を別として電話番号個別にNSリソースレコードにて
Tier1からTier2を指定する場合(図2-1(2))が相当する．
図2-1(1)は，Tier1レジストリのみで解決可能であり，Tier1の責任範囲が大
きい．図2-2(2)は，番号個別でTier2プロバイダを指定することが可能であ
り，ユーザが自由にTier2プロバイダを選択するモデル等への対応が可能で
ある．
@@(3) Tier1の分割
Tier1内のあるレベルで境界を設け，複数のTier1レジストリに分割する方法
が考えられる(例：図2.2(4))．例えば，IP電話050，固定電話03エリア，等，
ある単位でTier1 の上部と下部を分け，別の事業体で行うことが考えられる．
Tier1レジストリ事業への参加の機会を増やすといった政策を選択する場合などに，
この方式の採用が想定される．
(注: 日本の電話番号では0A0(電話種別)や0AB0(高度系サービス)などがある
ため，03 のようなAの単位で番号を分けると固定電話とその他サービスが混
在する形となる．電話種別やサービスごとのような分け方をしたい場合には，
0ABCのCの番号にてTier1 内を分割する必要がある．)
@@Tier構造 図2.1
<enum-fig-04.eps>
@Tier構造 図2.2
<enum-fig-05.eps>
@@2.5.2 ENUM DNSゾーン構造
前節で述べた構造のTierごとに，単数または複数のゾーンによる運用が
想定される．ゾーンを分割するか否かは，そのゾーンの管理者あるいは
運用者の決断に委ねられ，管理のしやすさ，性能などの運用上の要件により
決定されるものと考えられる．
なお，レジストラの受け付け範囲とゾーン構造とは，独立にすることが可能
である．一致させる場合にはゾーンごと，一致させない場合には個別の電話
番号毎などで，レジストラによるレコード変更権限の確認等が必要になると
考えられる．
@@2.6 関連する団体や活動
ここでは，ENUMに関連する国際的な団体や関連する活動について，
その概要を紹介する．
@@2.6.1 IETF
@@活動概要
TCP/IPなどのインターネットで利用される技術を標準化する組織．
インターネットの標準化を統括するIABの下部機関．
ここで策定された技術仕様はRFC として公表される．
@@Status
1999年10月にENUM-WG設立．2000年1月にITU主催による「公衆網とIPネット
ワークとのインターワーキング・ワークショップ」に参加．
2000年9月ENUMプロトコルRFC化(RFC2916)．
2002年7月にドラフトされたRFC 2916bisが最新．
@@関連URL
-> http://www.ietf.org/ (IETF)
-> http://www.ietf.org/html.charters/enum-charter.html
(Telephone Number Mapping (enum) WG)
@@2.6.2 ITU
@@活動概要
電気通信に関する国際標準の策定を目的とする，国際連合の下位機関．本部
はスイスのジュネーブ．第3回世界電気通信政策フォーラム（WTPF: World
Telecommunication Policy Forum 2001）において，IP電話の世界的な導入・
普及に向けたオピニオン（宣言）を採択（2001年3月）．
@@Status
2000年1月，ITU-Tにおいて開催された「公衆網とIPネットワークとのインター
ワーキング・ワークショップ」より，IETFと共に検討を開始．同年10月に開
催されたITU-T SG2 WP1会合において，ENUM DNSに設定されるE.164番号の管
理手順をガイドラインとして策定することが決定される．2001年1月に開催
された「ENUMワークショップ」では，各国関係者間で意見交換が行われ，課
題がリストアップされる．その後，1月，9月のITU-T SG2を経て，2002年5月
に地理的国番号用ENUM Supplement採択．
@@関連URL
-> http://www.itu.int/home/index.html (ITU)
-> http://www.itu.int/osg/spu/enum/index.html (ITU ENUM)
@@2.6.3 ENUM Forum
@@活動概要
e164.arpa(仮)をルートとするE.164番号を使ったDNS構造に基づくRFC2916の
仕組みをNANP(North American Numbering Plan)配下の米国，北米諸国にお
いて採用するための枠組みを作ることを目的に2001年8月に設立．
@@Status
Tier 1並びにTier 2に対する要求条件を取り纏めた書類「Unified
Document」を2002年11月にリリース．各役割や接続条件に加え，プロヴィ
ジョニング，セキュリティー，プライバシー等に関しても言及．
@@関連URL
-> http://www.enum-forum.org/ (ENUM Forum)
-> http://www.enum-forum.org/documents.html (The ENUM Forum - Documents)
@@2.6.4 UKEG
@@活動概要
英国においてENUMを導入する際の課題並びにその解決策を産業界の立場から
取り纏めDTI(英国貿易産業省)に提言することを目的に2001年9月に設立．
@@Status
「ENUMに基づくサービス市場を英国で実現するためには如何なる導入の枠組
みの採用が好ましいか」というPreliminary Reportを2002年4月リリース．9
月にTrial参加呼び掛けの正式アナウンスが行なわれた．
@@関連URL
-> http://www.dti.gov.uk/cii/regulatory/enum/index.shtml (DTI ENUM)
-> http://www.dti.gov.uk/cii/regulatory/enum/egp_report.shtml
(UKEG Preliminary Report on ENUM April 02)
@@2.6.5 ETSI
@@活動概要
欧州における通信関係標準化機関．ITUが政府代表主体の国際機関である
のに対し，標準化活動が主体の地域標準化機関(欧州域外も含む)といえる．
通信関係のEN(欧州規格)や，ETS(欧州通信規格)を制定．
@@Status
TIPHON(Telecommunications and Internet Protocol Harmonization Over
Networks)プロジェクトを設けて，IPネットワーク上での音声通話やマルチ
メディア通信の商用サービス化に向けた統一仕様の策定について検討．2002
年10 月にヨーロッパ地域におけるENUM相互接続のための最低要件を提言．
@@関連URL
-> http://www.etsi.org/ (ETSI)
-> http://www.etsi.org/frameset/home.htm?/tiphonweb/ (TIPHON)
-> http://portal.etsi.org/tiphon (TIPHON Portal Site)
@@2.6.6 その他各国の活動
各国でENUMのトライアルを行うに当り，RIPE NCC管理下の元「国番号.
e164.arpa」というドメインが付与された．詳細は下記の通り．
.TS
center,tab(|);
c c c c
l l l l.
_
E.164国番号|国名|権限受任団体|承認日
_
246|Diego Garcia|Government|'02/08/12
247|Ascension|Government|'02/08/12
290|Saint Helena|Government|'02/08/12
31|Netherlands|Ministry|'02/05/23
36|Hungary|CHIP/IszT|'02/07/15
43|Austria|Regulator|'02/06/11
44|UK|DTI/Nominum|'02/05/16
48|Poland|NASK|'02/07/18
49|Germany|DENIC|'02/05/16
55|Brazil|Brazilian Internet Registry|'02/07/19
86|China (c)|CNNIC|'02/09/02
878 10|(a)|VISIONng|'02/05/16
991 001|(b)|NeuStar|'01/02/02
_
.TE
注
(a) UPT用番号(UPT:Universal Personal Telephony)．
(b) ENUM用に取得されたトライアル用番号(2002年12月6日期限切れ，2002年
12月のITU-T SG2会合にて期限更新の見込み)．
(c) 2002年6月30日トライアル終了見込み．
@@2.6.7 ENUM関連勧告等の検討変遷
<ENUMhistory.eps>
@@3. ENUM導入によって期待されれるもの(解決が期待されるもの)
ここでは，ENUMを導入することによって期待されるものについて整理する．
期待される内容によって，その実装や運用方法，管理主体などが異なることが
考えられる．
@@(1) E.164 番号によるアプリケーションの識別手段として
インターネット上の利用可能なひとつまたは複数のアプリケーションを
E.164番号を用いて識別できることから，E.164番号を用いて，
そのE.164番号ユーザ
(E.164番号で識別される電気通信サービスを受けている利用者)に対する
電話以外の通信手段を統合的に提供することが可能となる
これには，アプリケーションの識別を数字だけで記述でき，電話機のような
テンキーによる端末インタフェースで入力が可能となるなどの利点がある．
エンドユーザAが登録したNAPTRリソースレコードを，
エンドユーザBは
E.164番号を使って参照し，
エンドユーザBの端末の相応しいアプリケーションを起動して，
エンドユーザAと通信を行うことを可能にする．
アプリケーションには，
電話，ファクシミリ，インターネット電話，電子メール，WWWなどがある．
<fig1.eps>
[[
(1) ENUM DNSに問い合わせ．
(2) ENUM DNSから応答．
(3) 応答結果をもとにアプリケーションを選択し，接続．
]]
@@(2) 既存電話からインターネット電話への電話番号解決手段として
既存の電話網の加入者からインターネット電話の加入者に対してアクセスす
るときに，インターネット電話の加入者に対応するURIと対応したE.164番号
との関係を解決する必要がある．これを解決する手段としてENUMは有力な候
補である．
インターネット電話の加入者に対して，E.164番号を割り当て， その番号と，
URIの対をNAPTRリソースレコードとして，DNSに登録する．
電話網からIP網へのゲートウエイは， 接続の際，
DNSをE.164番号をキーにして検索し, 対応するIP電話の加入者が，
SIPで接続可能である場合には, 対応するSIP URIが得られ,
そのURIに従って呼を確立する．
<fig2.eps>
[[
(1) 電話機がIP電話に対して発呼．
(2) ゲートウエイがENUM DNSに問い合わせ
(3) ENUM DNSから応答．
(4) 応答結果をもとにSIPゲートウエイを選択し，接続．
]]
この場合，ENUMを用いなくても，
たとえば，E.164番号に対応したSIPサーバの情報をゲートウエイが持つことにより，
ENUMを用いずに，アクセスが可能となる．
ただし，ENUMを用いることにより，検索のインターフェースの統一化，
スケーラビリティなどの利点がある．
また，SIP以外にもインターネット電話のプロトコルとして，H.323を用いる
場合もある．このときは，H.323の URIスキームが 応答される．
@@(3) インターネット電話から既存電話への電話番号解決手段として
インターネット電話の加入者から既存の電話網の加入者へのアクセスの際に
は，必ずしも ENUM を使う必要はない．インターネット電話が通常の
コンピュータのようなキーボードを持つものであれば，ゲートウエイを
ドメイン名を用いて相手を指示すればよい．
しかし，ENUMを用いれば，(2)と同様に統一的なインターフェースで
管理することができる．
ENUMを用いたインターネット電話から既存電話への接続の方法には，
URIスキーム tel: を用いる方法と IP電話のスキーム(たとえばsip:)を
用いる方法がある．
tel: は，電話番号を示すURIスキームで，
tel:+81352972311
といったものである．ENUMによってこのURIを得た端末は，電話網に直接
接続されている場合にはIP網を利用せずに電話網から接続を試みてもよい．
この接続ではインターネットを
利用していない．
既存電話網とインターネットとの間にゲートウエイが設置されており，SIP
サーバによってその接続が管理されている場合，URIによって，そのSIPサー
バが指示されることによって，インターネット電話の加入者からSIPを用いて
既存電話の加入者に対してアクセスが可能となる．
<fig3.eps>
[[
(1) ENUM DNSに問い合わせ．
(2) ENUM DNSから応答．
(3) 応答結果をもとに接続先を選択し，接続.
]]
なお，インターネットと電話網のゲートウエイが複数ある場合，
ゲートウエイの選択方式としては，TRIPのようなゲートウエイ選択の
専用プロトコルを用いる方式や，
特定のゲートウエイを返答するようにNAPTRリソースレコードを設定する方式が
考えられる(例えば，局番毎にゲートウエイをが特定できる場合，
局番毎にNAPTRリソースレコードを設定する方式)．
インターネット電話から既存電話に接続する場合には，技術的な課題に加えて，
課金や制度などについて既存電話サービスとの整合性を考慮する必要がある．
@@(4) 電話網(含むIP電話網)の番号解決手段として
ENUMのE.164番号データベースの機能を利用して，電話事業者がENUMを電話
番号の管理，事業者間の経路情報管理のために用いることができる．電話網
としてIPを用いているような場合，IP技術をベースにしたENUMは親和性が高
い可能性がある．
<fig4.eps>
たとえば，番号ポータビリティ(事業者間，ロケーションなど)やUPT，フリー
フォーン(着信者課金サービス)などの実現手段として，このENUMの利用が考
えられる．
@@4. ユーザENUMとオペレータENUM
ENUMサービスのうち，事業者がその網の実現のために用いるものをオペレー
タENUM(またはインフラストラクチャENUM)と呼ぶことがある．
-> UKEGレポート
-> draft-stastny-enum-scenarios-00.txt
たとえば，IP電話事業者が，E.164番号による接続をそのIP電話網内に閉じて，
独自の情報を含むENUM技術を用いて実現する場合，そのENUMサービスは，
オペレータENUMである．
複数の事業者の網が相互接続された場合には，E.164番号からIPアドレスへの
変換および変換情報の管理に関して，事業者間で事前の合意のうえ，
事業者間での共通のスキームを提供することも可能である．オペレータENUMを，こ
のスキームとして利用してもよい．
事業者によっては，事業者間ポータビリティの共有データベースとして，ENUM
を用いることがある．この場合も，オペレータENUMである．
なお，オペレータENUMは番号払出を受けた事業者毎，もしくは，事前に
相互に合意のある事業者集団毎に構築するものであり，
その実現方法はそれぞれの判断に委ねられるものである．
一方，オペレータENUMに対して，IETFやUKEG，ENUM Forum などで，一般的に
検討されているENUM を ユーザENUM と呼ぶ．
ユーザENUMは，番号払出を受けた事業者毎に参加・不参加の判断は
ありうるものの，参加する場合には事業者共通でパブリックなものとして
運用する必要がある．このため，ユーザENUMを構築するとした場合の
詳細について検討ておく必要である．
ユーザENUMとオペレータENUMは，その管理方針，管理主体，管理方法，
および，種々の要求条件が大きく異なっている．
たとえば，管理主体については，ユーザENUMはエンドユーザによって，
E.164番号に対応するDNSレコードの情報を管理するのに対して，
オペレータENUMでは，事業者が主体となって，DNSレコードを管理し，
登録できるアプリケーションは，
その網で提供されるサービスのためのレコードとなる．
また，ENUM DNS のアクセスについては，
ユーザENUMの場合は，エンドユーザ(のアプリケーション)が
インターネットを使って通常のDNS手順でアクセスするのに対して，
典型的なオペレータENUMでは，網の装置やオペレータ端末(事業者が提供する端末)が
呼接続のために利用し，エンドユーザは特にDNSアクセスを意識する必要はない．
@@ 4.1 ユーザENUM
ここでは，典型的なユーザENUMを想定して，その条件を整理した．
第2次報告までに，さらに詳細を検討することとする．
□ 目的
- E.164番号ユーザ(E.164番号で識別される電気通信サービスを受けている利用者)
自身の指定する到達可能なアプリケーション公開
- E.164番号ユーザへの音声サービスでの到達方法の獲得
- E.164番号ユーザのもつ音声以外(WEB，メール)の到達方法の獲得
□ 登録者
- E.164番号ユーザ
□ ENUMクライアント
- インターネットに接続されたユーザコンピュータ内のアプリケーション
- ゲートウエイ，プロキシ等
□ 要求条件
- ユーザへの Openness と Fairness の確保
- E.164ユーザが要求する プライバシ，セキュリティレベル
- ENUMクライアントが要求する プライバシ，セキュリティレベル
- 登録者の意志に基づく登録(opt-in)
□ DNSの構成(Tier構造)
- グローバルな構成
□ セキュリティの問題
- 登録時のE.164番号ユーザの認証，登録データの正当性
□ 番号管理
基本的に個人ユーザが自らの意志で番号に対応するURIの設定をおこなうこ
とから，既存の電話番号管理との関係を明確にしておく必要がある．
★ 既存の電話番号と共有するとき
既存の事業者に割り当てられた電話番号をユーザENUMの番号としても
利用する場合は，E.164番号をENUMで利用する者が，
そのE.164番号で識別されるサービスを受けている利用者であることを
確認する必要がある．また，ENUMにて，そのE.164番号で識別される
電気通信サービスに相当するサービスを受けている場合には，
本来のサービスとユーザの登録するレコードに不整合が生じないような
措置を施すことにより，混乱を避けるべきという考え方がある．
この場合，たとえば，
- レコードの優先順序の制限
- ユーザが登録する際の事業者による確認
- ユーザの申請に基づく事業者の登録
などの措置が必要と考えられる．
★ ユーザENUM用の電話番号空間
ENUM用の番号が割り当てられれば，既存の電話番号の管理との整合性を
考慮する必要がなくなる，ただし，電話番号は希少であり有効な利用が
求められることから，新たな電話番号の必要性について，制度面を含め，
検討する必要がある．
@@ 4.2 オペレータENUM
ここでは，典型的なオペレータENUMを想定して，その条件を整理した．
第2次報告までに，さらに詳細を検討することとする．
□ 目的
- 事業者内の呼接続のため
- 事業者間での相互の呼接続のため
- 既存電話網から複数のIP電話網への呼接続のため
□ 登録者
- 網を管理する事業者が対応する番号を登録
- 網内のすべて電話番号に対して，DNSレコードが登録
□ ENUMクライアント
- 網の装置やオペレータ端末
□ 要求条件
- 呼接続のためのアドレス解決を保証するためのエントリーの網羅性および
完全性
- 事業者のサービスの品質に必要な，性能，信頼性，スケーラビリティ
- クエリのアクセス制限(事前合意のあるオペレータ集団関係者以外DNS
アクセスの禁止)
□ DNSの構成(Tier構造)
- 事業者の構造に対応
- 場合によっては，ローカル/プライベートな構成も
□ セキュリティの問題
- クエリのアクセス制限(事前合意のあるオペレータ集団関係者以外DNS
アクセスの禁止)
□ 番号管理
- 事業者への番号割り当てに対応
@@5. 今後の検討のすすめかた
研究グループでは，いままでの，調査，検討の結果，ENUMの適用として，ユー
ザENUMとオペレータENUMのふたつに整理して検討する必要があるという認識に
達した．また，ユーザENUMとオペレータENUMは，それぞれ，目的や要求条件が
大きく異なっており，その結果として，性能機能要件，信頼性，セキュリティ・
プライバシ，DNSの運用管理体制に大きな違いがあることが分かった．
そこで，研究グループでは，基本的な技術について更に調査検討を進めるとと
もに，これらのふたつの適用に分けて，その要件，運用管理体制，その他の課
題について検討を進めていく．さらにこれらが共存する場合について，検討す
ることにする．
@ENUM研究グループ会員一覧
@@ 会員 (五十音順 敬称略)
* 一井 信吾
* インターネットフォーラム
* (株)インフォセック
* NTT コミュニケーションズ(株)
* 沖電気工業(株)
* KDDI(株)
* 後藤 滋樹
* JENS(株)
* (社)情報通信技術委員会
* (社)テレコムサービス協会
* 東京通信ネットワーク(株)
* 日商エレクトロニクス(株)
* ニフティ(株)
* 日本サイバースペース(株)
* 日本テレコム(株)
* 日本電気(株)
* 日本電信電話(株)
* (社)日本ネットワークインフォメーションセンター
* (株)日本レジストリサービス
* ネットワンシステムズ(株)
* フュージョン・コミュニケーションズ(株)
* 富士通(株)
* 三菱商事(株)
@@ オブザーバ
* 総務省 総合通信基盤局電気通信事業部電気通信技術システム課
@@事務局
* (社)日本ネットワークインフォメーションセンター