ENUM研究グループ第2次報告書(V1) 1
ENUM研究グループ
報告書(案)
(第1版)
2003年5月8日
ENUM研究グループ第2次報告書(V1) 2
(blank)
ENUM研究グループ第2次報告書(V1) 3
1．はじめに
ENUM は，電話番号による名前空間を用いて，インターネット上の
サービスを 識別するメカニズムである．その仕様の検討および標
準 化 は，IETFの ENUMワーキンググループを中心に進められてお
り，ITU-Tでも その運用に関して検討が進められている．
ENUMは，ITU-Tによる電話番号の国際的な取り決めであ る E.164
勧 告 に 基づく電話番号をキーとして，DNSを検索することによ
り， そのE.164番号に対応する， 利用可能なひとつもしくは複数
のアプリケーションをURI形式で得る機構である．
た とえば， 既存の電話網に接続された端末機器(電話機やファク
シミリ装置)から，イン ターネット上の端末機器に接続 す る 際
に，このENUMは有効である．電話機 は相手を識別するために，数
字の組合せによる電話番号 しか利用できない．ENUMは，ひとつの
電話番号と，それに対応するインターネット上で 利用可能なひと
つまたは複数の アプリケーションを対応づけることができる．
この機能，すなわち既存の電話機から インターネット電話への接
続を行う際の名前(電話番号)の解決手段としても， ENUMは注目さ
れている．
ENUM 研究グループ(以下研究グループ)は，このENUMについて，そ
の可能性と 課題を，技術的視点で調査・検討をおこない，技術的
課題を抽出し， 整理することを目的として設立された．
研究グループができた背景は次の通りである．
o IETFにおけるENUM関連の技術標準が明確になってきた．
o ITU-T において，その国際的な運用方針がサプリメントとし
て， 徐々に示されるようになってきた．
o IAB，RIPE NCC，ITU-T を中心に，ENUMのトライアルの環境 が |
整った．
o 国 内 で も，インターネット電話が普及しはじめ，IP電話用
の050 で始まる 電話番号の割当が開始された．
このような背景のなか，ENUMに対する理解を高め，今後の方向 性
についての 検討が急務になってきている．
この報告書では，研究グループの調査，検討の結果のうち， |
o ENUMの概要 |
o ENUMによって解決できる課題 |
o ENUMの登録モデル |
o ENUMの個人情報保護とセキュリティ |
を中心にまとめた．
ENUM研究グループ第2次報告書(V1) 4
1.1 研究グループの検討の目的と対象
この研究グループでの検討の目的は，次の通りである:
o ENUM技術そのものの理解
o ENUMの実現方式，運用方式，またこれに関連する検討
o ENUMの実現，運用における制度上の課題の抽出
o その他，ENUMに関連する技術的課題の検討
o ENUMを導入した際の効果と問題の明確化
このような目的を達成するために，研究グループでは， ENUM技術
と それに関連する技術(DNS，URL，DDDS等)を中心に調査と検討を
進めている．
ENUM研究グループ第2次報告書(V1) 5
1.2 用語の定義
こ こでは，本報告書の内容を理解するために必要な用語について
定義する．
1.2.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）
- ITU-T E.164勧告で規定される国際公衆電気通信番号． 外国
からの着信も可能な番号であり，国番号を含めて15桁以内の
番号． (総務省IPネットワーク技術に関する研究会報告書)
E.164カントリーコード
- E.164で規定される地理的な領域の国番号（ITU-T E.164）
例：日本には81が割り当てられている
NAPTR: Naming Authority Pointer
- 文字列変換によりドメインラベルやURIを生成するための 書
き換え規則を記述す るためのDNSリソースレコード
- RFC2915で定義されたが，DDDSの一部としてRFC3403で再定義
された． （RFC2915，RFC3403）
番号ポータビリティ：Number Portability
- サービス，プロバイダ（電話会社），ロケーションを変更し
ても同じ電話番号を 使えること．
1.2.2 ENUM用語（本報告書独自定義）
ENUMアプリケーション
- 発 着 信の双方でENUMを利用するアプリケーション 例：電
話，SIP，H.323，ファクシミリ，電子メール， インスタ ン
トメッセンジャー
ENUMクライアント
- ENUM検索を行うクライアントアプリケーション
- オペレータENUM：網内の装置や端末
- ユーザENUM：インターネットに接続されたユーザコンピュー
ENUM研究グループ第2次報告書(V1) 6
タ内の アプリケーション
IP電話
- (狭義)品質が保証されたIPネットワークを利用する帯域保証
型 の音声電話サービス であり，一般的にインターネット電
話よりサービス品質は優れる傾向がある． 本報告 書 で は
「IP電話」をこの意味で用いている．
- (広義)IP技術を用いた音声電話サービス．インターネット電
話と上述の狭義の IP電話を包含．総務省のIPネットワー ク
技 術に関する研究報告書では 「IP電話」をこの意味で用い
ている．
Tier0
- ENUM DNS階層のトップで，現在IAB(Internet Architecture
Board)が管理し， e164.arpaが実験的に利用されている．
Tier1
- E.164 国 番 号 に 相 当するENUM DNS階層 日本であれば
1.8.e164.arpa
Tier2
- NAPTRリソースレコードを保持するENUM DNS階層
インターネット電話
- インターネットを利用するベストエフォート型の音声電話サ
ー ビスであり， ネットワークの状態によりサービス品質は
変動する．
オペレータENUM，インフラストラクチャENUM
- ISPや電話事業者が，事業者内または事業者相互間の経路 制
御のために用いる ENUMの形態
管理されたIP網(Managed IP network)
- 帯域予約などの技術を利用することでトラフィック管理され
ているIP網
ユーザENUM
- ユーザが自分の電話番号とサービスの関係を規定するために
用いるENUMの形態
- インターネット電話事業者が，顧客の電話番号についてイン
ターネットからの 着信に用いる場合も含む
DNS：Domain Name System
- インターネットに接続されたコンピュータの情報（ドメイン
名とIPアドレスの 対応など）を提供する仕組み
EPP: Extensible Provisioning Protocol
- GRRP要求仕様を満たす汎用のレジストリ・レジストラ間の通
信プロトコルで あり，XMLベースで拡張性が高い．現在標準
化作業中である．
GRRP 要 求 仕 様: Generic Registry-Registrar Protocol
Requirements
- 汎用のレジストリ・レジストラ間の通信プロトコルの要求仕
ENUM研究グループ第2次報告書(V1) 7
様 で， Informational RFCとしてRFC3375にまとめられてい
る．
H.323
- ITU-Tが標準化したインターネットやLANなどのネットワーク
で使用されるマル チメディア通信用のプロトコル群
IP網：IP network, IP based network
- ネットワーク層のプロトコルにインターネットプロトコルを
利用したネットワーク
- IPネットワーク
IPアドレス
- インターネットに接続された機器を識別するための番号
RTP: Realtime Transport Protocol
- 映像や音声データをリアルタイムに適した形で転送するため
の プロトコルで あり，映像・音声データを単位時間ごとに
パケットに分割して，パケット ヘッダにパケット順序や
タイムスタンプを付加して転送する．(RFC1889)
SIP: Session Initiation Protocol
- IETFで標準化された，インターネットやLANなどのネットワ
ーク上で マルチメディアセッションを確立するために使用
されるシグナリング プロトコル． 1999年にRFC2543として
規定され，2002年6月にRFC3261として改版された．
SIPサーバ
- IPネットワーク上でSIP通話に必要なセッション確立など の
処理を仲介する サーバ
- SIPサーバの種類として，プロキシサーバ，リダイレクトサ
ーバ，登録サーバの 3種類がある．
o プロキシサーバ: SIPリクエストを転送したり，代理 送
信するサーバ
o リダイレクトサーバ: SIPリクエストを受け取り，着信
側の現在のアドレスを発信側に返すサーバ プロキシ サ
ーバーとは違いSIPリクエストを転送しない
o 登録サーバ(レジストラ): UAの現在位置を登録するリク
エスト（REGISTERリクエスト）を受け取り， ロ ケ ー
ションサーバなどに登録されている情報を更新するサー
バ
SOA: start of authority
- ゾーンのオーソリティを示す情報(データの始まりを表す)
TCP: Transmission Control Protocol
- トランスポート層のコネクション 型 プ ロ ト コ ル で あ
り，RFC793で定義されて いる．
TLS: Transport Layer Security protocol
- アプリケーション間の通信に隠密性と安全性を提供するプロ
トコルで， TCPなどの既存の信頼性のあるトランスポート層
プロトコルの上に位置する． RFC2246で定義されている．
ENUM研究グループ第2次報告書(V1) 8
- Netscape社が開発したSSL(Secure Socket Layer)プロトコル
をベースにIETFで 標準化された．
TRIP: Telephony Routing over IP
- 電話番号エリアから指定番号空間に属する電話端末へ着信さ
せ る ために利用 可能なVoIPシグナリングパス(= Next Hop
Server)を見つけるための情報 (=Attributes)をプ ロ バ イ
ダ(=ITAD:Internet Telephony Administrative Domain)間で
交換するためのプロトコル(RFC3219)
UDP: User Datagram Protocol
- トランスポート層のコネクションレス型プロト コ ル で あ
り，RFC768で定義され ている．
URL:Uniform Resource Locator
- イ ンターネット上の各種情報リソースにアクセスする手段
（プロトコル）と 場所を指定する記述様式（RFC1738）
URI:Uniform Resource Identifiers
- 抽象的な資源あるいは場所で指定された資源を識別する簡潔
な文字列であり， URLを拡張した記述様式（RFC 2396）
VoIP: Voice over IP
- インターネットやイントラネットなどのIPネットワークを介
して音声通話を 実現する技術
ゾーン
- ドメインの持つ名前空間の一部分の情報 DNSには，このゾー
ンの情報がゾーンファイルとして格納される
リソースレコード(RR)：Resource Record
- DNSデータベースの各構成要素(レコード) NAPTRもリソース
レコードの一つ
ENUM研究グループ第2次報告書(V1) 9
2．ENUMの概要
ENUMは，ITU-Tによる電話番号の国際的な取り決めであ る E.164
勧 告 に 基づく電話番号をキーとして，DNSを検索することによ
り， そのE.164番号に対応するひとつまたは複数の アプリ ケ ー
ショ ンをURI形式で得る機構である． この章では，ENUMの概要に
ついて解説する．
(注)ここでは，本報告書発行時点(2003年5月)でのRFC， イン |
タ ー ネッ トドラフトおよびIETFなどでの検討に基づいて，
ENUM技術について解説する． ENUMで対応づけられるアプリケ
ー ションの種類や記述方法， ENUMの技術仕様を含め， ここ
で紹介する事項については，今後，変更される可能 性 が あ
る．
2.1 ENUMの動作例
電 話番号 "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リソースレコード
ENUM研究グループ第2次報告書(V1) 10
がDNS上に登録されて いた場合，
$ORIGIN 1.1.3.2.7.9.2.5.3.1.8.e164.arpa
IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@nic.ad.jp!" .
結果として，URI，
sip:info@nic.ad.jp
を得る．これによりアプ リ ケ ー ショ ン プ ロ グ ラ ム は，
sip:info@nic.ad.jp に対して，SIP を用いてセッションを 確立
することが可能であることを知ることができる．
NAPTR行のE2U+sipと変換規則のURIを書き換えることで， 電話 番
号に対するH.323やインターネットFAX，WEBや電子メールなどのア
ドレスを 書くことができる．詳細は後述する．
ENUM研究グループ第2次報告書(V1) 11
2.2 DDDS (Dynamic Delegation Discovery System) |
DDDSは，アプリケーション内のユニークな識別の た め の 文 字 |
列(AUS)に対して，DNS上に作ら れたデータベースにある書き換え
規則を適用し，URIなどの結果を得るシステ ムであ る．(RFC3401
〜RFC3405)
基本的なアルゴリズムは，
1. AUSが与えられると，アプリケーションごとに規定された最
初の変換により， データベースをひく鍵をつくる．
2. 鍵をもとにDDDSデータベースをひいて，変換規則を得る．
3. AUSに対して変換規則を適用する． 変換規則が最終結果を出
すものでなければ変換結果を鍵として 2に戻る．
4. 最 終結果を出す変換の結果が出力であり，URIやドメイン
名， アドレスが得られる．
DDDSデータベースとしてDNSを用い，データベースを引く鍵として
は ドメイン名を用い， またデータの蓄積のためにNAPTRというリ
ソースレコードをRFC3403，RFC3404 で定義した． NAPTRリソース
レコードの書式は以下のとおりである．
IN NAPTR order preference flags service regexp replacement |
order 16bit符号なし整数 小さいもの使用(preferenceより優先)
preference 16bit符号なし整数 小さいもの優先
flags 文字 “S” “A” “U” “P” 置換・解釈の制御
S: 最終結果 次はSRVを引く
A: 最終結果 次はA, AAAAを引く
U: 最終結果 URIを出力
P: プロトコル依存
なし: 得られた結果についてさらにデータベースを引く
service 文字列 プロトコル [ +サービス ]
このエントリが適用されるプトロコル・サービスを指定
regexp 置換文字列(正規表現で与える)
replacement 固定ドメイン名を返せばよい場合はregexpのかわりに
ここにドメイン名を書く
一 つ の 鍵 に 複 数のNAPTRリソースレコードがあった場合，ま
ずorderの小さい ものを選ぶ．orderが同じものが複数存在した場
合，preference の小さいもの を用いる．同一order値に複数の有
効なリソースレコードが存在し， preferenceの小さいものを評価
し て 失 敗 し た 場合，次のリソースレコードを 処理する．あ
るorder値のリソースレコードがすべて失敗した場合は，それよ
り大きなorder値の評価はしないでエラーとする．
ENUM研究グループ第2次報告書(V1) 12
service フィールドには，このNAPTRリソースレコードが対象とす
るサービス を書く．複数のNAPTRリソースレコードが存在した 場
合，このフィールドを先 にみて該当するか調べておけばよい．
regexpフィールドには正規表現でAUSからの置換規則を書く．
replacement フィ ールドには，regexpフィールドがある場合は .
を書く．
NAPTRリソースレコードは,ENUMだけではなくSIPサーバ情報を指定 |
するためにも 用いられている(RFC3263)．
ENUM研究グループ第2次報告書(V1) 13
2.3 DDDSアプリケーションとしてのENUM
ENUM はDDDS の アプリケーションの一つとして再定義されつつあ
る．
DDDSをENUMで使うプロトコルとしてE2U (Enum to URI)が定義され
て い る． そのなかのサービスとして sip, h323, ifax, tel,
enum, mailto, httpなどが想定されている.
想定されているサービス・プロトコルと NAPTRのserviceフィール |
ド， URIスキーム例を表で示す． 正式には，RFC2916bisがRFC化 |
された後にそれに従い， サービスごとにserviceフィールドとURI |
な ど の 機 能 を 定義したスタンダード トラックか BCP (Best |
Current Practices) のRFCを書き，IANAに登録する. |
----------------------------------------------------------------------||
サービス・プロトコル serviceフィールド URIスキーム ||
----------------------------------------------------------------------||
SIP E2U+sip sip:info@nic.ad.jp||
H.323 E2U+h323 h323:info@h323.nic.ad.jp||
H.323による電話 E2U+voice:h323 h323:info@h323.nic.ad.jp||
インターネットFAX E2U+ifax:mailto mailto:info-fax@nic.ad.jp||
既存電話 E2U+voice: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/||
----------------------------------------------------------------------||
ENUMの概要で説明した + ではじまるE.164電話番号がENUMのAUSと
な り，最初 の知られた変換は，前述した電話番号からe164.arpa
ドメイン下のドメインに 変換する規則である．
また，ENUMにおけるNAPTRのフラグは現時点で"u"のみ定義され て
いる．
他 の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@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
ENUM研究グループ第2次報告書(V1) 14
を意味する．
また，局番 +8135297 以下の 4桁分の番号すべてを一つのSIPサー
バに担当さ せたい場合，DNSのワイルドカードと正規表現によ る
置換を使って， sip:nnnn@sip-server.jp (nnnnは4桁番号)のよう
なURIにできる．
AUSは +8135297nnnn とする
$ORIGIN 7.9.2.5.3.1.8.e164.arpa
* IN NAPTR 100 10 "u" "E2U+sip" "!^+8135297(.*)$!sip:\1@35297.sip-server.jp!" .
+81352972311を検索すると，sip:2311@35297.sip-server.jp を得
る．
こ のようにして DDDSを用いて，URIで表すことのできるアプリケ
ーションを E.164番号に対応づけることができる．
ENUM研究グループ第2次報告書(V1) 15
2.4 ENUMの仕様
ENUMは一連のRFCによって，その仕様が規定されている．主なもの
は次の通り:
o RFC2916(E.164 number and DNS) は，ENUMの基本的な仕様を規
定している． 現在，"The E.164 to URI DDDS Application" と
いうタイトルで， 改訂作業が進められている．
=> draft-ietf-enum-rfc2916bis-05.txt |
o RFC2806(URLs for Telephone Calls)，既存電話網との接続を示
すURI， tel:, fax:, modem: を規定． 現 在，"The tel URL
for Telephone Calls" というタイトルで， URIではサービスの
種類は示さないという現状の 合意にあわせてtel: のみを規 定
する．
=> draft-antti-enum-rfc2806bis-08.txt |
tel: URIにパラメータを付加してサービスの種類を示そうとい
う提案がある．
=> draft-brandner-tel-svc-00.txt
o RFC3401〜RFC3405(Dynamic Delegation Discovery System -
DDDS). ENUMで利用されている，DNS検索，NAPTRリソースレコ
ード， 一連の書き換え規則等が 規定されている．
ENUM研究グループ第2次報告書(V1) 16
関係する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
ENUM研究グループ第2次報告書(V1) 17
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)
ENUM研究グループ第2次報告書(V1) 18
2.5 ENUMのTier構造とDNSのゾーン構造
ENUMのTier構造やDNSのゾーン構造は，国ごとの事情により決めら
れる．日本 における構造については議論が必要である．ここでは
構造の複数案と考え方 について述べる．
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-1(2)は，番号個別でTier2プロバイダを指
定することが可能であ り，ユーザが自由にTier2プロバイダを選
択するモデル等への対応が可能で ある．
(3) Tier1の分割
Tier1内のあるレベルで境界を設け，複数のTier1レジストリに分
割する方法 が考えられる(例：図2.2(4))．例えば，IP電話050，
固定電話03エリア，等， ある単位でTier1 の上部と下 部 を 分
け，別の事業体で行うことが考えられる．
ENUM研究グループ第2次報告書(V1) 19
Tier1 レジストリ事業への参加の機会を増やすといった政策を選
択する場合などに， この方式の採用が想定される．
(注: 日本の電話番号では0A0(電話種別)や0AB0(高度系サービス)
な どがある ため，03 のようなAの単位で番号を分けると固定電
話とその他サービスが混 在する形となる．電話種別やサービ ス
ご と の よ う な 分け方をしたい場合には， 0ABCのCの番号に
てTier1 内を分割する必要がある．)
ENUM研究グループ第2次報告書(V1) 20
Tier構造 図2.1
ENUM研究グループ第2次報告書(V1) 21
Tier構造 図2.2
ENUM研究グループ第2次報告書(V1) 22
2.5.2 ENUM DNSゾーン構造
前節で述べた構造のTierごとに，単数または複数のゾーンによ る
運用が 想定される．ゾーンを分割するか否かは，そのゾーンの管
理者あるいは 運用者の決断に委ねられ，管理のしやすさ，性能な
どの運用上の要件により 決定されるものと考えられる．
な お，レジストラの受け付け範囲とゾーン構造とは，独立にする
ことが可能 である．一致させる場合にはゾーンごと，一致させな
い場合には個別の電話 番号毎などで，レジストラによるレコード
変更権限の確認等が必要になると 考えられる．
2.5.3 ENUMレジストリ・レジストラ間通信 |
ENUM DNSを運用する場合には DNS 登録を管理するENUMレジストリ |
が必要になる． |
従来のgTLDやccTLDのドメイン名空間(たとえば.jp)には， 一つの |
レジストリと登録受け付け窓口としての複数のレジスト ラ が あ |
る． 登録者はレジストラを介してドメイン名の登録や登録内容の |
変更を行ない， レジストリは登録された内容に基づいて DNSのゾ |
ーンを作成し， DNSの提供を行なう． |
これまではレジストリごとに独自のレジストリ・レジストラ間 通 |
信プロトコルを用いていたが， IETF PROVREG WGにてレ ジ ス ト |
リ・ レジストラ間の汎用通信プロトコルを 決めることとなり， |
レジストリ・レジストラ間通信の要求仕様であ る GRRP(Generic |
Registry Registrar Prococol) をRFC3375 と して定めた． 現 |
在，GRRP要 求 仕 様 を 満 た すEPP(Extensible Provisioning |
Protocol) を策定中である． 標準化されると，多くのレジストリ |
ではEPPをサポートすることが推奨される． |
EPPはXMLベースで拡張性が高いプロトコルとして設計され， 以下 |
のコマンドを定義している． これらのコマンドを組合せ，コマン |
ド列としてレジストリデータベースを 操作する．それぞれのトラ |
ンザクションはloginで始まり，logoutで終る． EPPは通信の枠組 |
を規定し，通信トランスポートや扱うオブジェクト については別 |
途定める． |
login 認証を行ない，EPPサーバとのやりとりを開始する ||
logout EPPサーバとのやりとりを完了する ||
check オブジェクトを取り扱うことができるかを確認する ||
info 既存オブジェクトの情報を得る ||
poll 自分宛のqueueに蓄積されているメッセージを要求する||
create オブジェクト生成 (ドメイン名登録) ||
delete 既存オブジェクト削除 ||
transfer 既存オブジェクトを管理するレジストラを変更する ||
update 既存オブジェクトの持つ登録情報の変更 ||
=> draft-ietf-provreg-epp-09.txt |
EPP で 使 う 通 信 の ト ラ ン ス ポ ー ト として，TCP(TLS) |
やBEEP，SOAP，MAILを 使う方法が提案されている． |
ENUM研究グループ第2次報告書(V1) 23
=> draft-ietf-provreg-epp-tcp-06.txt |
=> draft-ietf-provreg-epp-beep-03.txt |
=> draft-liu-epp-soap-00.txt |
=> draft-brunner-epp-smtp-00.txt |
登録するオブジェクトに関しては，ドメイン名，ホスト情報， コ |
ンタクト情報の扱いについて策定中である． |
=> draft-ietf-provreg-epp-domain-07.txt |
=> draft-ietf-provreg-epp-host-07.txt |
=> draft-ietf-provreg-epp-contact-07.txt |
ENUM については，ドメイン名レジストリへの拡張の形で提案され |
ている． |
=> draft-ietf-enum-epp-e164-02.txt |
このドラフトでは，gTLDのドメイン名レジストリになくENUMに 必 |
要 な 機能について定義している．具体的には E.164ドメイン名 |
とNAPTRフィールドの値 である．この定義により， Tier1, Tier2 |
の それぞれのレジストリ，レジストラ間の通信を取り扱うことが |
できる． |
ENUM研究グループ第2次報告書(V1) 24
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)．
2003年4月の draft-ietf-enum-rfc2916bis-05.txt が最新だがす |
ぐ06を出し， 標準化プロセスを進めようとしている．
関連URL
=> http://www.ietf.org/ (IETF)
=> http://www.ietf.org/html.charters/enum-charter.html
(Telephone Number Mapping (enum) WG)
ENUM研究グループ第2次報告書(V1) 25
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)
ENUM研究グループ第2次報告書(V1) 26
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)
ENUM研究グループ第2次報告書(V1) 27
2.6.4 UKEG
活動概要
英国においてENUMを導入する際の課題並びにその解決策を産業界
の立場から 取り纏めDTI(英国貿易産業省)に提言することを目的
に2001年9月に設立．
Status
「ENUMに基づくサービス市場を英国で実現するためには如何なる
導入の枠組 みの採用が好ましいか」というPreliminary Report
を2002年4月リリース．9 月にTrial参加呼び掛けの正式アナウン
スが行なわれた．
関連URL
=>
http://www.dti.gov.uk/industries/ecommunications/policy_consultation.html
(DTI ENUM)
=>
http://www.dti.gov.uk/industry_files/other/enumgroup.doc
(UKEG Preliminary Report on ENUM April 02)
=>
http://www.dti.gov.uk/industries/ecommunications/key_dti_contacts.html
(ENUM関連コンタクト先)
ENUM研究グループ第2次報告書(V1) 28
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)
ENUM研究グループ第2次報告書(V1) 29
2.6.6 その他各国の活動
各国でENUMのトライアルを行うに当り，RIPE NCC管理下の元「国
番号. e164.arpa」というドメインが付与された．
=> http://www.ripe.net/enum/request-archives/ (RIPE)
=> http://www.itu.int/itudoc/itu-t/enum/enum-app.html
(ITU-T)
ENUM研究グループ第2次報告書(V1) 30
2003年5月5日時点での登録状況の通り．
+------------+----------------------+-----------------------------+-----------+
|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 |
+------------+----------------------+-----------------------------+-----------+
|33 | France | DiGITIP(Government) | '03/02/28 |
+------------+----------------------+-----------------------------+-----------+
|358 | Finland | Finnish Communications | '03/02/26 |
| | Regulatory Authority | | |
+------------+----------------------+-----------------------------+-----------+
|36 | Hungary | CHIP/IszT | '02/07/15 |
+------------+----------------------+-----------------------------+-----------+
|40 | Romania | MinCom | '03/02/26 |
+------------+----------------------+-----------------------------+-----------+
|43 | Austria | Regulator | '02/06/11 |
+------------+----------------------+-----------------------------+-----------+
|44 | UK | DTI/Nominum | '02/05/16 |
+------------+----------------------+-----------------------------+-----------+
|46 | Sweden | NPTA | '02/12/10 |
+------------+----------------------+-----------------------------+-----------+
|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 |
+------------+----------------------+-----------------------------+-----------+
|971 | United Arab | Etisalat | '03/01/13 |
+------------+----------------------+-----------------------------+-----------+
|991 001 | (b) | NeuStar | '01/02/02 |
+------------+----------------------+-----------------------------+-----------+
注
(a) UPT用番号(UPT:Universal Personal Telephony)．
(b) 2003年11月2日にトライアル終了見込み．
(c) 2002年6月30日トライアル終了見込み．
ENUM研究グループ第2次報告書(V1) 31
2.6.7 ENUM関連勧告等の検討変遷
ITU-Tを中心にしたENUM関連勧告等の検討の変遷を以下に示す．
ENUM研究グループ第2次報告書(V1) 32
3. ユーザENUMとオペレータENUM
本研究グループでは，ENUMをユーザENUMとオペレータENUMのふ た
つに分類した．
E.164 番 号 で 識 別される電気通信サービスを受けている ユー
ザ(E.164番号ユーザ)が，自らの意図でその番号に対して， ユ ー
ザの指定したアプリケーションをENUMレコードに登録するものを
「ユーザENUM」と呼ぶ．
また，電気通信電話番号で識別されるサービスを実現す る た め
に， そ の 番号の割り当てを受けてるサービス提供者の意図で
ENUMレコードを設定するものを「オペレータENUM」と呼ぶ．
注: オペレータENUMをインフラストラクチャENUMと呼ぶことが
ある． UKEGレポート
後 述 す るように，ユーザENUMとオペレータENUMは，その管理方
針，管理主体， 管理方法，および，種々の要求条件が大き く 異
なっている．
また，実際のシステムでは，その中間的なENUMも想定できるが，
この二つのENUMの組合せと考えることができる．
IETFやUKEG，ENUM Forumなどで，一般的に検討され て い るENUM
は， ユ ー ザENUM である． 日本では，IP電話との関係のなか
でENUMに関心がもたれている． IP電話事業者がIP電話サービスの
実現手段としてENUMを使った場合， 「オペレータENUM」である．
そこで本研究グループでは，ユーザENUMとオペレータENUMの両 方
を検討し， 報告する．
ユ ーザENUMとオペレータENUMは，その管理方針，管理主体，管理
方法， および，種々の要求条件が大きく異なっている．
たとえば，管理主体については，ユーザENUMはエンドユ ー ザ に
よって， E.164番号に対応するDNSレコードの情報を管理するのに
対して， オペレータENUMでは，事業者が主体となって，DNSレ コ
ー ドを管理し， 登録できるアプリケーションは， その網で提供
されるサービスのためのレコードとなる．
また，ENUM DNS のアクセスについては， ユーザENUMの場合 は，
エンドユーザ(のアプリケーション)が インターネットを使って通
常のDNS手順でアクセスするのに対して， 典型的 な オ ペ レ ー
タENUM では，網の装置やオペレータ端末(事業者が提供する端末)
が 呼接続のために利用し，エンドユーザは特にDNSアクセスを 意
識する必要はない．
本 研究グループでは，ENUMを，ユーザENUMとオペレータENUMのふ
たつに 整理して検討することとする．
ENUM研究グループ第2次報告書(V1) 33
3.1 ユーザENUM
ここでは，典型的なユーザENUMを想定して，その条件を 整 理 し
た．
ユ ーザENUMは，番号払出を受けた事業者毎に参加・不参加の判断
は ありうるものの，参加する場合には事業者共通でパブリックな
ものとして 運用する必要がある．このため，ユーザENUMを構築す
るとした場合の 詳細について検討しておく必要である．
□ 目的
- 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の番号とし
ENUM研究グループ第2次報告書(V1) 34
ても 利用する場合は，E.164番号をENUMで利用する者 が， そ
のE.164 番号で識別されるサービスを受けている利用者であるこ
とを 確認する必要がある．また，ENUMにて，そのE.164番号で識
別 される 電気通信サービスに相当するサービスを受けている場
合には， 本来のサービスとユーザの登録するレコードに不整 合
が 生じないような 措置を施すことにより，混乱を避けるべきと
いう考え方がある．
この場合，たとえば，
- レコードの優先順序の制限
- ユーザが登録する際の事業者による確認
- ユーザの申請に基づく事業者の登録
などの措置が必要と考えられる．
★ ユーザENUM用の電話番号空間
ENUM用の番号が割り当てられれば，既存の電話番号の管理との整
合 性を 考慮する必要がなくなる，ただし，電話番号は希少であ
り有効な利用が 求められることから，新たな電話番号の必要 性
について，制度面を含め， 検討する必要がある．
ENUM研究グループ第2次報告書(V1) 35
3.2 オペレータENUM
たとえば，IP電話事業者が，E.164番号による接続をそのIP電話網
内に閉じて， 独自の情報を含むENUM技術を用いて実現する場合，
これは，オペレータENUMである．
複数の事業者の網が相互接続された場合には，E.164番号からIPア
ドレスへの 変換および変換情報の管理に関して，事業者間で事前
の合意のうえ， 事業者間での共通のスキームを提供することも可
能である．オペレータENUMを，こ のスキームとして利用してもよ
い．
事 業者によっては，事業者間ポータビリティの共有データベース
として，ENUM を用いることがある．この場合も，オペレータENUM
である．
な お，オペレータENUMは番号払出を受けた事業者毎，もしくは，
事前に 相互に合意のある事業者集団毎に構築するものであり，
その実現方法はそれぞれの判断に委ねられるものである．
こ こでは，典型的なオペレータENUMを想定して，その条件を整理
した．
□ 目的
- 事業者内の呼接続のため
- 事業者間での相互の呼接続のため
- 既存電話網から複数のIP電話網への呼接続のため
□ 登録者
- 網を管理する事業者が対応する番号を登録
- 網内のすべての電話番号に対して，DNSレコードを登録
□ ENUMクライアント
- 網の装置やオペレータ端末
□ 要求条件
- 呼接続のためのアドレス解決を保証するためのエントリーの網
羅性および 完全性
- 事業者のサービスの品質に必要な，性能，信頼性，スケーラビ
リティ
- クエリのアクセス制限(事前合意のあるオペレータ集団関係 者
以外DNS アクセスの禁止)
□ DNSの構成(Tier構造)
- 事業者の構造に対応
- 場合によっては，ローカル/プライベートな構成もありうる
□ セキュリティの問題
ENUM研究グループ第2次報告書(V1) 36
- クエリのアクセス制限(事前合意のあるオペレータ集団関係者
以外DNS アクセスの禁止)
□ 番号管理
- 事業者への番号割り当てに対応
ENUM研究グループ第2次報告書(V1) 37
3.3 比較表
+-------------------+---------------------+-----------------------+
| ユーザENUM オペレータENUM |
+-------------------+---------------------+-----------------------+
| | | |
登録者 ユーザ 事業者(サービス提供者) |
| | | |
+-------------------+---------------------+-----------------------+
| | | |
利用目的 ユーザ(登録者)の指示 事業者がサービスを |
| するサービスを公開 実現するために公開 |
| | | |
登録URIの種別 多様 事業者が提供するサービ |
| | スを識別するためのURI |
| | | |
| その電話の割り当てを 電話サービスの場合は |
| うけた事業者との関係 SIP/H323/TELなどに限定 |
| で，登録可能なURIの | |
| 種別が限定される可能 | |
| 性もありうる | |
+-------------------+---------------------+-----------------------+
| | | |
適用する番号空間 既存の電話番号を利用 事業者に割り当てられ |
| する場合は制度，方針 番号空間 |
| による | |
| | | |
| ENUM専用番号が割り当て| |
| られた場合はその空間 | |
| | | |
+-------------------+---------------------+-----------------------+
| | | |
日本の現行制度による不一致 一致 |
電話番号割り当て者と制度上の問題を整理する現行制度との整合性あり |
登録者の一致 必要あり | |
| | | |
番号に対する管理責任ユーザと事業者間で 事業者 |
| 整理が必要 | |
| | | |
+-------------------+---------------------+-----------------------+
| | | |
検索者 インターネットユーザ 事業者のサービスのユーザ|
| | 網内装置，事業者端末 |
| | | |
DNSサーバ性能/品質 インターネット品質 必要に応じて，事業者が |
| | 強化 |
| | | |
検索端末 普通のインターネット +網内装置，事業者端末 |
| アプリケーションを利 | |
| 用する一般ユーザ端末 | |
| | | |
+-------------------+---------------------+-----------------------+
ENUM研究グループ第2次報告書(V1) 38
(続き)
+---------------------+--------------------+-----------------------+
| ユーザENUM オペレータENUM |
+---------------------+--------------------+-----------------------+
| | | |
登録内容の網羅度 ユーザの意志による 事業者のサービスを実現 |
| 登録のため opt-in に するために用いるため， |
| よる選択的登録になる その事業者に割り当てら |
| | れた番号範囲内では網羅 |
| | 的に登録される |
| | | |
+---------------------+--------------------+-----------------------+
| | | |
アーキテクチャ 通常のインターネット 事業者の都合によること |
| 上のDNSサービスに近いがあり，その都合を忠実 |
| | に考慮すれば複雑/多様． |
| | | |
| = 均一 = キメラ |
| | | |
| | 個別の事象を事業者マタ |
| | ーとすれば，共通部分は |
| | シンプル |
| | | |
+---------------------+--------------------+-----------------------+
| | | |
Tier構造 2.1(2) 2.2(3) > 2.2(4) > 2.1(2)|
| | | |
| 場合によるので要検討 場合によるので要検討 |
| | | |
グローバルツリの必然性あり 場合によってはローカル |
| | ツリーによるENUMライク |
| | サービスで |
| | | |
| | 特定の事業者間でのデー |
| | タベースとして用いるだ |
| | けならグローバルにする |
| | 必要なし |
| | | |
| | 参照対象が不特定なら， |
| | グローバルにする必要 |
| | あり |
| | | |
+---------------------+--------------------+-----------------------+
ENUM研究グループ第2次報告書(V1) 39
(続き)
+---------------------+---------------------+-------------------------+
| ユーザENUM オペレータENUM |
+---------------------+---------------------+-------------------------+
| | | |
登録RR/URIに対する ユーザの登録内容による事業者が登録するため |
トラブル ため，多い可能性あり 少ない可能性．トラブル |
| | 対応者が明解． |
| | | |
サービス全体の サービスの関係者が サービスの関係者は明確． |
トラブルと解決 複数でその解決は面倒 解決の手順はシンプル |
| (かも)． (かも)． |
| | | |
問題発生時の被害の範囲ユーザに留まる(かも) 事業者のサービス全体に |
| | 影響する(かも) |
| | | |
+---------------------+---------------------+-------------------------+
| | | |
登録/更新頻度 (利用者の数にもよるが)新番号割り当て，構成 |
変更量 多 変更時のため，更新頻度は |
| | 少ないが，一回の変更量は多|
| | | |
登録変更時の手間 大 小(シンプルにすることも) |
(認証/課金の項目を | | |
|参照) | | |
| | | |
+---------------------+---------------------+-------------------------+
| | | |
レジストラが認証する ユーザ 事業者 |
対象(=登録者) | | |
| | | |
レジストラが認証する 多 小 |
対象の数 | | |
| | | |
レジストラが認証する 大 小 |
手間 | | |
| | | |
レジストラ=登録者の なし あり |
可能性 | | |
| | | |
+---------------------+---------------------+-------------------------+
| | | |
レジストラの | | |
課金対象 ユーザ 事業者 |
| | | |
レジストラの | | |
料金回収の手間 大 小 |
| | | |
レジストラの | | |
料金未回収リスク あり 小(ex.事業者の廃業) |
| | | |
+---------------------+---------------------+-------------------------+
ENUM研究グループ第2次報告書(V1) 40
(続き)
+-----------------+---------------------+----------------------+
| ユーザENUM オペレータENUM |
+-----------------+---------------------+----------------------+
| | | |
WHOIS/プライバシ ユーザを識別する情報の事業者のポリシで |
| 扱い/保護のためのルー ユーザの情報を隠す |
| ルが必要 ことが可能 |
| | | |
プライバシ問題 顕著 簡単(にすることも) |
| | | |
+-----------------+---------------------+----------------------+
| | | |
セキュリティ インターネットレベル 事業者が必要に応じて |
| | 強化 |
| | | |
守る対象 全般 全般 |
| | | |
+-----------------+---------------------+----------------------+
| | | |
レジストラ，登録者WEB等簡易なインタフ EPP等のトランザクション|
インタフェース ェース(典型) インターフェース(典型) |
| | | |
+-----------------+---------------------+----------------------+
ENUM研究グループ第2次報告書(V1) 41
4. ENUM導入によって期待されるもの(解決が期待されるもの)
ここでは，ENUMを導入することによって期待されるものについ て
整 理する． 期待される内容によって，その実装や運用方法， 管
理主体などが異なることが考えられる．
ここではENUM導入によって期待される事項を以下のように分類 し
た:
(1) E.164 番号によるアプリケーションの識別手段として
(2) 既存電話からインターネット電話への電話番号解決手段とし
て
(3) インターネット電話から既存電話への電話番号解決手段とし
て
(4) 既存電話(含むIP電話)の番号解決手段として
(1)はユーザENUMで期待される典型的な目的である．また， (4)は
オペレータENUMで期待される典型的な目的である． (2)，(3)は，
インターネット電話の運用方法によって， ユーザENUMで運用され
る場合と，オペレータENUMで運用される場合， または，それらが
混在した運用方法の場合が考えられる．
ENUM研究グループ第2次報告書(V1) 42
(1) E.164 番号によるアプリケーションの識別手段として
ENUMにより，ひとつのE.164番号を， インターネット上の利用可
能なひとつまたは複数のアプリケーションに 対応づけること が
で き る ことから，E.164番号を用いて， そのE.164番号ユーザ
(E.164番号で識別される電気通信サービスを受けている利用 者)
に 対する 電話以外の通信手段を統合的に提供することが可能と
なる．
これには，アプリケーションの識別を数字だけで記述でき，電話
機 のような テンキーによる端末インタフェースで入力が可能と
なるなどの利点がある．
エンドユーザAが登録したNAPTRリソースレコードを， エンド ユ
ー ザBは E.164番号を使って参照し， エンドユーザBの端末の相
応しいアプリケーションを起動して， エンドユーザAと通信を行
うことを可能にする． アプリケーションには， 電話，ファクシ
ミリ，インターネット電話，電子メール，WWWなどが 想定されて
いる．
(1) ENUM DNSに問い合わせ．
(2) ENUM DNSから応答．
(3) 応答結果をもとにアプリケーションを選択し，接続．
ENUM研究グループ第2次報告書(V1) 43
(2) 既存電話からインターネット電話への電話番号解決手段とし
て
既存の電話網の加入者からインターネット電話の加入者に対して
ア ク セ スす るときに，インターネット電話の加入者に対応す
るURIと対応したE.164番号 との関係を解決する必要がある． こ
れを解決する手段としてENUMは有力な候 補である．
イ ンターネット電話の加入者に対して，E.164番号を割り当て，
その番号と， URIの対をNAPTRリソースレコードとして，DNSに登
録する． 電話網からIP網へのゲートウエイは， 接続の際， DNS
をE.164番号をキーにして検索し, 対応するIP電話の加入者 が，
SIP で 接続可能である場合には, 対応するSIP URIが得られ, そ
のURIに従って呼を確立する．
(1) 電話機がIP電話に対して発呼．
(2) ゲートウエイがENUM DNSに問い合わせ
(3) ENUM DNSから応答．
(4) 応答結果をもとにSIPゲートウエイを選択し，接続．
この場合，ENUMを用いなくても， たとえば，E.164番号に対応し
たSIPサーバの情報をゲートウエイが持つことにより， ENUMを用
いずに，アクセスが可能となる． ただし，ENUMを用いること に
よ り，検索のインターフェースの統一化， スケーラビリティな
どの利点がある．
また，SIP以外にもインターネット電話の プ ロ ト コ ル と し
て，H.323 を用いる 場合もある．このときは，H.323の URIスキ
ームが 応答される．
ENUM研究グループ第2次報告書(V1) 44
(3) インターネット電話から既存電話への電話番号解決手段と し
て
インターネット電話の加入者から既存の電話網の加入者へのアク
セスの際に は，必ずしも ENUM を使う必要はない．イ ン タ ー
ネッ ト電話が通常の コンピュータのようなキーボードを持つも
のであれば，ゲートウエイを ドメイン名を用いて相手を指示 す
ればよい．
し かし，ENUMを用いれば，(2)と同様に統一的なインターフェー
スで 管理することができる．
ENUMを用いたインターネット電話から既存電話への接続の方法に
は， URIスキーム tel: を用いる方法と IP電話のスキーム(たと
えばsip:)を 用いる方法がある．
tel: は，電話番号を示すURIスキームで，
tel:+81352972311
といったものである．ENUMによってこのURIを得た端末は，電 話
網 に直接 接続されている場合にはIP網を利用せずに電話網から
接続を試みてもよい． この接続ではインターネットを 利用して
いない．
既存電話網とインターネットとの間にゲートウエイが設置されて
おり，SIP サーバによってその接続が管理されている場 合，URI
によって，そのSIPサー バが指示されることによって，インター
ネット電話の加入者からSIPを用いて 既存電話の加入者に対して
アクセスが可能となる．
(1) ENUM DNSに問い合わせ．
(2) ENUM DNSから応答．
(3) 応答結果をもとに接続先を選択し，接続.
なお，インターネットと電話網のゲートウエイが複数ある場合，
ゲートウエイの選択方式としては，TRIPのようなゲートウエイ選
択の 専用プロトコルを用いる方式や， 特定のゲートウエイを返
答するようにNAPTRリソースレコードを設定する方式が 考えられ
る( 例 えば，局番毎にゲートウエイを特定できる場合， 局番毎
にNAPTRリソースレコードを設定する方式)．
インターネット電話から既存電話に接続する場合には，技術的な
課 題に加えて， 課金や制度などについて既存電話サービスとの
整合性を考慮する必要がある．
ENUM研究グループ第2次報告書(V1) 45
(4) 既存電話(含むIP電話)網の番号解決手段として
ENUMのE.164番号データベースの機能を利用して，電話 事 業 者
がENUM を電話 番号の管理，事業者間の経路情報管理のために用
いることができる．電話網 としてIPネットワークを用いてい る
よ うな場合， IP技術をベースにしたENUMは親和性が高いことが
考えられる．
たとえば，番号ポータビリティ(事業者間，ロケーション な ど)
やUPT，フリー フォーン(着信者課金サービス)などの実現手段と
して，このENUMの利用が考 えられる．
(注)ただし，これらを実現するためにはENUM以外に複雑な
仕組みを必要とする
ENUM研究グループ第2次報告書(V1) 46
5. SIPとSIPのENUM対応
現 在，インターネット電話で主流となるであろうセッション確立
のための プロトコルは，SIP である．
ここでは，SIPについて，その概要を説明し，SIPのENUM対応に つ
いて述べる．
現 在の仕様では，SIPにおける ENUMの適用については，完全に規
定されておらず， 曖昧な点がおおい． IETFでは，この点につ い
て Sipping(Session Initiation Proposal Investigation) ワー
キンググループを 中心に検討が進められている．
5.1 SIPの概要
Session Initiation Protocol(SIP)は，通信を行うインター ネッ
ト 上の エンドポイント(ユーザーエージェントと呼ばれる，以下
SIP UA)がお互いを 発見し，相互にセッションの特性の合意を 行
い， セッ ションの確立と開放を おこなうためのプロトコルであ
る． その基本仕様は RFC3261 によって規定されている．
SIPはセッション確立およびその開放のためのプロトコルで， 実
際 の 通信は，SIPによって合意されたプロトコルによって行われ
る． 電話の場合，代表 的 な プ ロ ト コ ル は RTP(Realtime
Transport Protocol, RFC1889)である．
エ ン ド ポイントである SIP UA 同士が直接， SIPを用いてセッ
ションの確立を行うこともできるが， 通常は，SIPサーバの一 種
である SIPプロキシサーバ(以下 SIPプロキシ)を経由して， セッ
ション確立のメッセージが転送されることで， エンドポイント間
のセッションの確立が行われる．
着 呼側では，SIP登録サーバとロケーションサーバが， 着呼対象
のSIP UA と SIP接続先を識別する SIP URI との対応づけを おこ
なう，
ENUM研究グループ第2次報告書(V1) 47
次の図でこれらの関係を示す:
典型的なセッション確立の流れはおおまかに次の通りである:
着 呼側のSIP UAの登録を行う．これは，事前設定または，SIP UA
の 電源投入時，アプリケーション起動時などに自動的に行 わ れ
る．
1) 着呼側 SIP UA は，SIPの REGISTERリクエストを用いて， SIP
UA を利用するユーザの SIP URI (論理アドレ ス，Address-of-
Record, AoR) と， SIP UA に到達するための SIP URIの対応の
登録要求を， SIP登録サーバに対しておこなう．
2) SIP登録サーバは，ロケーションサーバに対して，1)の対応 を
登録する (SIPプロトコル範囲外)．
以上の手順により，着呼側の SIP UA の登録が完了する． この登
録の手順は通常周期的(標準値1時間毎)に行われる．
さらに， 次の手順により，発呼側のSIP UA から，着呼側の SIP
UAに対して セッション確立の要求(INVITEメッセージ)が伝達され
る．
3) 発呼側の SIP UA は， 事前に設定または，発呼時に指定さ れ
た， SIPプロキシサーバに対して， INVITEリクエストを用いて
通信相手の SIP URI (AoR) を送る．
4) SIPプロキシサーバは SIP URI のドメイン名部分を取り出し，
DNSに問い合わせ， 着呼側のSIPプロキシのIPアドレスを得る．
5) 着呼側のSIPプロキシに対して，INVITEリクエストを転送する
6) 着呼側のSIPプロキシは，ロケーションサーバに対して， 通信
相手のSIP URI に対応する，SIP UA の問い合わせを行う．
7) 着呼側SIP UA に対して，INVITEリクエストを転送する．
着呼側のSIP UA は，このINVITEリクエストに対する応答を発呼側
の SIP UA に返し， 発呼側の SIP UA は ACKリクエストによる確
認メッセージを返したのち，
8) RTPによる通信(会話)
を開始する．
以上の手順を，4者間のリクエストメッセージと応答メッセージで
みると 次の通りである:
ENUM研究グループ第2次報告書(V1) 48
5.2 SIP URI と 着呼側のSIPプロキシの発見
SIP では 通信相手を識別するため識別子として， URIの一種であ
る SIP URI を用いる(RFC2361)．たとえば，
sip:taro@example.co.jp
のようにメールアドレスに似た形式をもつ．
こ こで，example.co.jp は 着呼側のドメイン名で， taro は そ
のドメインの ロケーションサーバに登録された ユーザ 名 で あ
る．
発呼側の SIP プロキシは，この SIP URI から， 着呼側の SIPプ
ロキシを発見する． 発見の手順は RFC3263「Session Initiation
Protocol (SIP): Locating SIP Servers」 に規定されている．
着 呼側の SIPプロキシは，SIP URI のドメイン部分を， DNSを用
いて，NAPTRレコード，SRVレコード，AまたはAAAAレコードの順に
検索を行い， 着呼側の SIP プロキシのIPアドレスを得る．
sip:taro@example.co.jp を 例にあげる． 発呼側のプロキシは
example.co.jp に対する NAPTRレコードのDNS問い合わせを 行 う
と， 以下のようなレコードが見つかる:
; order pref flags service regexp replacement
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.co.jp.
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.co.jp.
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.co.jp.
こ れは，サーバがTCP上のTLS，TCP，UDPにこの優先順で対応して
いることを示す． 発呼側のSIPプロキシはTCPとUDPに対応して い
る ので， TCPを選択し，_sip._tcp.example.co.jp の SRVの問い
合わせを行う． その問い合わせの結果，以下のようなレコードが
見つかる:
;; Priority Weight Port Target
IN SRV 0 1 5060 server1.example.co.jp.
IN SRV 0 2 5060 server2.example.co.jp.
さ らに，着呼側のSIPプロキシは， DNSによるAまたはAAAAレコー
ド の 問 い 合 わ せ に よっ て， 相 手 の プ ロ キ シ
server1.example.co.jp または server2.example.co.jp の IPア
ドレスを得る．
5.3 SIPサーバのENUM対応
ENUMをSIPサービスに導入する方法は， SIP のクライアントプ ロ
グラムが対応する方法と， プロキシサーバが対応する方法のふた
つが考えられる．
SIP クライアントが対応
SIPのアプリケーションプログラムが， ユーザから電話番号によ
ENUM研究グループ第2次報告書(V1) 49
る 通 信 相手の指定をうけると， アプリケーションプログラム
は， 指定された電話番号を ENUMの変換ルールにしたがってドメ
イン名に変換し， そのドメイン名にしたがってNAPTRレコードに
よるDNS検索をおこなう． 着呼側のSIP URIが得られたなら， そ
のSIP URI を用いて，SIP UA としてSIPの処理を開始する．
SIP プロキシが対応
SIPのアプリケーションプログラムが， ユーザから電話番号によ
る通信相手の指定をうけると， 電話番号を含 む 適 当 な SIP
URI(tel: スキーム)に変換し， SIPプロキシに対して，その SIP
URI を用いて接続要求を行う．
SIPプロキシは， 指定された電話番号を ENUMの変換ルールに し
た がっ て ド メ イン名に変換し， そのドメイン名にしたがっ
てNAPTRレコードによるDNS検索をおこなう． 着呼側のSIP URIが
得 られたなら， そのSIP URI を用いて，SIP UA としてSIPの処
理を開始する．
SIPプロキシではなく，SIPリダイレクトサーバがこの処理を行っ
てもよい．
現 在のIETFの議論では，クライアントによる処理が良いとされて
いる．
=> draft-ietf-sipping-e164-02.txt
SIPプロキシが対応する場合， SIP UA から伝達される電話番号を
含 む SIP URI について， パラメータも含めて標準的なフォー
マットを決めておく必要がある．
SIP クライアントがENUMを処理する場合の典型的なセッション 確
立手順を， DNS問い合わせを中心に図で示す．
ENUM研究グループ第2次報告書(V1) 50
6. ENUM登録の流れ
ENUM サービスにおける情報の登録更新の流れについて， ITU-Tの
レジストリ・レジストラモデルを基本に， その登録の流れについ
て提示する．
6.1 ITU-Tレジストリ・レジストラモデル
ITU-Tでは，ENUMサービスの登録管理をレジストリ，レジストラモ
デルにしたがって， 整理している．まず，このモデルにしたがっ
て，ENUMレコードがどのように， 登録管理されるのか整理する．
ITU-T では，登録管理の役割分担を行う機能として， 以下のエン
ティティを提案している．
o マネージャ(管理責任者)
ドメイン名の管理責任者．
o レジストリ
レ ジストリデータベースを運用管理する機関．レジストリデー
タ ベースを元にDNSゾーンファイルを生成する．
o レジストラ
レジストラントの申請を受け，登録資格チェックなどの登録 受
け付け 手続きを行ったのち，レジストリに対して登録を依頼す
る．
o レジストラント(登録申請者)
そのドメイン名の登録申請者．
ENUM研究グループ第2次報告書(V1) 51
ITU-TのSG2によるサプリメント「National ENUM Suppliment」 で
は Tier0, Tier1, Tier2 における役割を以下のように規定してい
る．
総務省 平成14年度 電気通信番号に関する研究会(第2回)
資料2-2 ENUMに関するITU-T SG2標準化動向 7ページ
=>
http://www.soumu.go.jp/joho_tsusin/polcyreports/chousa/bango/pdf/020704_2_02.pdf
Tier1，Tier2の実装は国内マターとなっている．
ENUM研究グループ第2次報告書(V1) 52
6.2 レジストリ，レジストラ登録更新の流れ
レジストリ，レジストラモデルでは，登録者からDNSに登録される
までの 主な流れは次のようになる．
1) 登録者はTier2レジストラに登録更新申請を行う．
2) 必要に応じてその番号の認証機関(典型的には割り当てられ た
事業者)に確認のうえ Tier2レジストラは申請内容を確認し正当
であれば． Tier2レジストリに対して登録更新申請を お こ な
う． もし，申請が新規登録またはTier2レジストリを変更する
ような申請なら (Tier1の登録内容の変更が必要などきは)Tier1
レジストラに対して， 登録変更申請を行う．
2') Tier2 レ ジ ストリはレジストリデータベースを更新したの
ち，Tier2の DNSゾーンファイルを生成する．
3) Tier1レジストラは申請内容を確認し正当であれば． Tier1 レ
ジストリに対して登録更新申請をおこなう．
3') Tier1 レ ジ ストリはレジストリデータベースを更新したの
ち，Tier1の DNSゾーンファイルを生成する．
6.3 レジストラの確認事項
レジストラは申請者からの登録更新申請を受け，その申請内容 を
確認のうえ， 正しければ，レジストリにその内容を送る．
この際の確認内容としては次のようなものがあげられる．
o 申請者の認証．申請者が本人であることを確認する．
o 申請者の権限の確認．申請者がその申請を受ける資格があるか
どうかの確認． Tier2レジストラでは，申請者が対応するE.164
番 号 の 加 入 者であることを， Tier1レジストラでは，申請
者(Tier2レジストラ)が対応するNSレコードを 管理するTier2レ
ジストラであることを確認する．
o 申請内容の確認．申請者からの登録更新の内容が適切であるこ
との確認． Tier2レジストラでは，申請内容が対応するE.164番
号 のNAPTRレコードとして 適切であることを， Tier1レジスト
ラでは，申請内容のネームサーバ情報が申請者の管理する ドメ
イン名の範囲内であることを確認する．
ENUM研究グループ第2次報告書(V1) 53
6.4 登録管理情報
レ ジ ス トリおよびレジストラはENUMサービスの維持管理のため
に， 登録内容の他に登録者に関する情報を保持する． さらに 登
録内容にしたがって，DNSのゾーンファイルを生成し， DNSサービ
スとしてインターネット上に公開したり， WHOISインターフェ ー
スで，その内容の一部を公開する．
主 な登録内容と管理するエンティティ，公開の方法をまとめると
次の通りである:
----------------------------------------------------------------------
登録内容 保持者 DNSでの WHOISでの
公開 公開
----------------------------------------------------------------------
E164番号 Tier2レジストラ/レジストリ ○ ○
NAPTRレコード Tier2レジストラ/レジストリ ○ ○
登録者名 Tier2レジストラ/レジストリ - △
連絡先 Tier2レジストラ/レジストリ - ○
住所 Tier2レジストラ - △
認証情報 Tier2レジストラ - - 1)
課金情報 Tier2レジストラ - - 2)
Tier2 NS-RR Tier1レジストラ/レジストリ ○ ○
Tier2レジストラ/レジストリ
Tier2名 Tier1レジストラ/レジストリ - ○
連絡先 Tier1レジストラ/レジストリ - ○
認証情報 Tier1レジストラ - - 1)
----------------------------------------------------------------------
1) パスワード，公開鍵などの認証情報
2) クレジットカード番号，口座番号など．Tier2レジストリが
登録者に課金する場合．
ENUM研究グループ第2次報告書(V1) 54
6.5 登録の手順のバリエーション
日本では E.164番号は電気通信事業者に対して割り当てられる．
番号は電気通信事業者の事業のために割り当てられるため， その
事業目的とENUMでの利用に関して，整合性をとる必要がある．
ENUM サービスのために，既存のE.164番号を利用した場合の， 登
録手順のバリエーションについて提示する．
実際にENUMサービスを実現するには，唯一の登録手順で行う必 要
はなく， 適当な番号領域(事業者の番号割り当て単位)ごとに，そ
れぞれ， 個別の登録管理手順が採用されることになる．
ENUM研究グループ第2次報告書(V1) 55
6.5.1 登録モデル1
電気通信事業者が，加入者の申請をうけ，確認ののちTier2レ ジ
ス トリ経由で Tier2 DNS を更新する．ここで，電気通信事業者
は Tier2 レジストラの機能を 持つ．
ENUM研究グループ第2次報告書(V1) 56
このモデルのバリエーションとして，電気通信事業者 が，Tier2
レジストリの 機能も兼ね，Tier2レジストリデータベースの運用
管理，DNSゾーンファイルの 生成も行う．
ENUM研究グループ第2次報告書(V1) 57
6.5.2 登録モデル2
電気通信事業者とは独立に，Tier2レジストラ が，登録申請をう
け る． 申請者が加入者どうかは，その番号に対応する電気通信
事業者が確認/承認を 行う．
これは，ISPや他事業者が，Tier2レジストラを行う場合が，この
モデルに あたる．
ENUM研究グループ第2次報告書(V1) 58
6.5.3 登録モデル3
その番号に対するENUMサービスを用いた着信を設定するために，
電気通信事業者が設定するケース． この場合，事業者がその サ
ー ビ スを実現するための オペレータENUMサービス． したがっ
て，加入者の意図とは関係なく，E.164番号に対するレコード を
登録する．
ENUM研究グループ第2次報告書(V1) 59
6.5.4 課金モデル1
o レジストリは費用を事業者に請求
o 事業者が加入者(登録者)との契約に基づいて加入者(登録者)に
請求
6.5.5 課金モデル2
o レジストリは費用を加入者(登録者)に請求．
o 加入者(登録者)はレジストリと事前の契約を行う場合もあり．
ENUM研究グループ第2次報告書(V1) 60
6.6 登録ポリシ
すでに述べた通り， 日本では E.164番号は電気通信事業者に対し
て割り当てられる． 番号は電気通信事業者の事業のために割り当
てられるため， その事業目的とENUMでの利用に関して，整合性を
とる必要がある．
割り当てを受けた事業者は登録ポリシを策定し， ENUMに登録する
際には，当該番号の割り当てをうけた事業者が策定した ポリシに
したがって，登録するという仕組みが必要である．
ここでは，登録ポリシと考えられるものの例をあげる． これらの
組合せが，実際の登録ポリシとなる．
o 強制: 事業者が自ら， 事業者がサービスしている電話機に着信
す るため、 加入者の意志とは関係なく強制的に登録する． オ
ペレータENUMでの標準的な登録ポリシ．
o 選択: 利用者が自らの意志で登録する． いわゆる オプトイ ン
の考え方． ユーザENUMでの標準的な登録ポリシ．
o サービスの限定: 登録できるサービスを限定させる． 例えば，
その番号の TEL URI および MAILTO URI に限定させるなど．
o サービスおよびパラメータの限定: 例えば sipを登録する場 合
の SIPプロキシの限定．
o 優先度の限定: 例えば，登録する際には，その番号の TEL URI
または 事業者の指定した SIP URI を最優先のレコードとし て
登録する．
ENUM研究グループ第2次報告書(V1) 61
7. 個人情報保護とセキュリティ，信頼性
7.1 個人情報保護
ENUM の扱うサービス，インターネット利用者間の通信は，個人的
な利用も多く， 個人情報保護について十分に考慮する必要 が あ
る． ENUMサービスで取り扱われるENUMユーザの個人情報および関
連する情報について， その取り扱いに関する方針と取り扱い手続
きを明確にする必要がある．
ENUMサービスが扱う情報は大きく3つに区分される:
(1) DNSに登録される情報．具体的には NAPTRレコードと それに
含まれるパラメータ．
(2) WHOIS情報． インターネットの運用管理のために公開され る
ド メ イ ン 名 の登録者情報， 登録者名，連絡先等．一般的
にWHOIS と呼ばれる公開情報．
(3) 顧客情報．レジストリ/レジストラが保持する，登録管理のた
めの情報， 登録者識別情報，課金のための情報．
それぞれの情報区分によって，その扱いの方針が異なる．
個人情報の扱いの原則として， 登録者に対して，それぞれの区分
に対する，情報収集の目的を 提示し，事前に了承を得る必要があ
る． すなわち，
o 登録するNAPTR情報はDNSによって公開されること
o 登録者の連絡先はWHOISによって公開される．WHOISの目的は
- インターネットの分散運用管理のため
- 登録者が登録情報を確認するため
公 開情報以外の情報は，システム，取扱手続き上適切な管理が必
要 他の目的での利用，流出を防止する仕組みが必要である． さ
ら に， 年齢，性別，その他 ENUMサービスを行ううえで必要のな
い個人情報に ついては，極力，収集，蓄積しないなどの配慮も必
要である． 個人情報保護の動向，インターネットにおける個人情
報の取扱に対する動向を 注目する必要がある．
以下，それぞれの区分について，さらに検討する．
DNS情報
DNSに登録される情報は，すべて公開される． 個人情報をできる
だけ隠蔽させるために，NAPTR レコードに登録される URI に 個
人を識別する情報を含めないなどの工夫が必要である．
たとえば，mailto: の情報に対して，ユーザ 山田さんを連想 さ
せる mailto:yamada@exmaple.co.jp を登録するのではなく， ラ
ンダ ム な ユ ー ザ 名 aci2hnwz と し， NAPTR と し て
mailto:aci2hnwz@exmaple.co.jp を 登 録， メールサーバが
aci2hnwz を yamada に対応させる． これにより，E.164番号 に
ENUM研究グループ第2次報告書(V1) 62
対 応する ユーザが 山田さんであることを 隠蔽することができ
る．
WHOIS情報
WHOIS情報については， インターネットの分散管理を維持するた
め の 登 録 情 報 の 公開の原則と， 個人情報の保護につい
て，ICANNを中心に検討が進められている． この検討の状況をみ
な がら， インターネット運用管理とユーザの個人情報の保護の
双方の立場を満たす， 情報管理の方針を策定し，運用する必 要
がある．
顧客情報
登 録者を認証するためのパスワード等の情報， 課金のための，
銀行口座番号やクレジットカード番号など， 公開する必要の な
い 情報については， それを必要とする事業者内の担当者にだけ
アクセスを制限するといった 適切な機密管理が必要である． さ
ら に，外部から不用意に情報がアクセスされないような， シス
テムのセキュリティ対策が必要である(後述)．
7.2 アクセス制御
DNSの情報はインターネット全体で公開され，インターネットユー
ザはだれでも その登録情報をアクセスできることを原則としてい
る． ENUMが E.164番号というグローバルな名前空間をキーとして
いるため， DNSのシングルツリー上に E.164番号を対応させ， ア
プリケーションを対応づけることは，DNSのこの原則と整合性がと
れている．
一方，登録ユーザまたはサービスを提供するプロバーダは， その
サービス形態からENUMの通信サービスを限定させたいという要 請
もある．
DNS は公開を原則としたシステムのため， 問い合わせを受けるユ
ーザを厳密に限定させることは難しい． したがって，DNSをベ ー
スにしたENUMもユーザを厳密に限定させることは難しい．
BINDには問い合わせクライアントのIPアドレスを限定させる， ア
クセスコントロールリスト(ACL)の機能がある． また，DNSのツリ
ー を ユ ーザ毎に分ける，スプリットDNSの機構もつくれる． た
だ，キャッシュサーバの動作によっては，このアクセスコント ロ
ールは 期待通りの動作ができない状況が考えられる．
さ ら に，ENUM(DNS) は番号とURIとのマッピングを行うだけなの
で， 対応する URI が何らかの方法で分かってしま え ば， そ
のURIを用いて直接，サービスにアクセスできてしまう．
サービスを特定ユーザに限定するには， 最終的には，実際のアプ
リケーション(SIP，メール)のアクセス制限機能を 用いるべき で
ある．
ENUM研究グループ第2次報告書(V1) 63
7.3 セキュリティ対策
ENUM サ ー ビスはDNSをベースとするサービスである． したがっ
て，ENUMサービスのセキュリティを検討するにあたって， ENUM固
有の課題， DNSに起因する課題， ENUMを含むコミュニケーション
サービスに関する課題， インターネット上のネットワークシステ
ムに起因する課題に， 区分して検討する必要がある．
こ れらの区分ごとに，対応方針，対策・調整を行うコミュニティ
が違うので， この区分は重要である．
また，ENUMユーザに対して，リスクを事前の説明を行う必要が あ
る． このリスクが高いサービスに関しては， 事前に説明し確認
したユーザに，サービスを限定する必要がある．
ENUM固有の課題
- 登録申請者の成りすまし
- 登録データの改ざん，不適切な情報の登録
- 網羅的検索
- 登録システムへのDOS(サービス不能攻撃)
DNSに起因する課題
- DNSクエリの傍聴とDNSレスポンスの改ざん・偽造
- DNSサーバの成りすまし
- ゾーン転送のエラー，ゾーンファイルの改ざん
- キャッシュサーバの内容の偽造
- DNSサーバへのDOS(サービス不能攻撃)
ENUMを含むコミュニケーションサービスに関する課題
- 通信の傍受，改ざん
- 成りすまし(発信者認証，発信者通知)
- 着信者認証
- 迷惑メール，スパムメール
- 輻輳対策
- 通信相手，サーバへのDOS(サービス不能攻撃)
インターネット上のネットワークシステムに起因する課題
- システム侵入と破壊，情報流出
- 災害時対策
ENUM研究グループ第2次報告書(V1) 64
7.3.1 ENUM固有の課題
登録申請者の成りすまし
登録者に成りすまして，ENUM情報を登録したり，更新，抹消 す
る行為である． これを防ぐには，登録者の認証，更新データの
正当性のチェックを適切に おこなう必要がある．
また，このような事故が発生した場合，事故前の正しい状態 に
もどすための システム対応も重要である．
登録データの改ざん，不適切な情報の登録
本来，登録できない NAPTRレコードを登録したり，URIを登録す
る． 登録者が本来登録できない他人のアドレスを登録す る な
ど．
網羅的検索
ENUMの名前空間が 連続した番号のため，悪意な網羅的検索は頻
発する可能性が高い． しかし， 現在のDNS技術では， DNSの網
羅的検索は対応は困難である．
イ ンターネット電話サービスでは，料金が定額であるケースが
あることから 電子メールにおけるスパムメールのような，スパ
ム電話のような， 迷惑電話が多発することが予想させる．
網羅的検索で，NAPTRに含まれるメールアドレスのリストも容易
に 入手できてしまう．
WHOISについては，利用者を限定させる，アクセス容量規制を
おこなうなどの対策が考えられるが本質的解決にはならない．
DNS，WHOISによって インターネット上に公開された情報はENUM
サービスにおいて網羅的な 検索が行われることを前提に，サー
ビスを構築する必要がある． インターネット電話の場合， SIP
の発信者認証やアクセスコントロールの適切な運用が必要で あ
る．
登録システムへのDOS(サービス不能攻撃)
一 般のインターネットサービスノードと同様に， DOSを受ける
可能性がある． 登録システムは，DNSに比べてタイムクリ ティ
カ ルでないので， 通常のシステムのDOS検出および対策を行え
ばよい．
7.3.2 DNSに起因する課題
DNSサーバに対するセキュリティ問題は広くしられており， その
対 策として DNSSEC，TSIG などの技術開発が行われている． し
かし，抜本的な解決は行われておらず， 運用によって問題の 健
在 化を防いでいるのが現状である． ENUMサービスを構築する際
も，DNSの運用ノウハウを十分に理解したうえで， システムの構
築・ 運用を行い， さらに，DNSSEC，TSIG等の技術開発を推進す
ENUM研究グループ第2次報告書(V1) 65
る必要がある．
以下，簡単に，DNSのセキュリティ上の課題を列挙する:
DNSクエリの傍聴とDNSレスポンスの改ざん・偽造
DNSクライアントとサーバの通信路を傍受し， クエリIDを入 手
し，このIDを用いて偽のレスポンスを返す．
DNSサーバの成りすまし
クライアントに偽のDNSサーバを設定させる．
ゾーン転送のエラー，ゾーンファイルの改ざん
プライマリサーバとセカンダリサーバの間のゾーンファイルの
転送を妨害または改ざんする．
キャッシュサーバの内容の偽造
キャッシュサーバに特殊なクエリを発し，キャッシュサーバの
内容を改ざんする． いわゆる Cache Poisoning．
DNSサーバへのDOS(サービス不能攻撃)
DNSサーバに大量のクエリを送り， DNSサーバ本来のサービスを
不能とさせる攻撃．
7.3.3 ENUMを含むコミュニケーションサービスに関する課題
ENUMサービスは，インターネット上のコミュニケーションサービ
スにおける 接続の最初の部分を担うにすぎない． ENUM問い合わ
せに続くサービス(SIP，H323，メールなど)と連係しながら， セ
キュリティ対策が必要である．
通信の傍受，改ざん
ENUM サービスは，通信相手を特定するためのマッピングサービ
スであり， 通信を媒介するものではない．通信内容の秘密，改
ざん防止については， 接続以降のプロトコルで解決する必要が
ある．
SIPの場合，SIP UA，SIPサーバ間は TLS を使ったり， 通信 時
は RTP を IP Secで運用するなどの対策である． メールの場合
は，機密性を必要とするなら，S/MIME や PGPの利用を する な
どである．
DNSの問い合わせの記録から，どのIPアドレスからどのレコード
の問い合わせが 来たかは分かる．しかし，ネームサーバへの問
い 合わせの多くは， ISPやユーザ組織のキャッシュサーバから
の問い合わせのため， 各ユーザの通信相手を特定するのは難し
い．
しかし，ログについては適切な管理が必要である．
ENUM研究グループ第2次報告書(V1) 66
成りすまし(発信者認証，発信者通知)
発 信者のアドレス，電話 番号等を偽る，成りすましは， 適切
な対策をとらなければ技術的に容易である．
通信の傍受，改ざんと同様．
着信者認証
通信の傍受，改ざんと同様．
迷惑メール，スパムメール
ENUMでは電話番号をキーにメールアドレスが知られてしまう た
め、迷惑メー ルが発生する可能性が考えられる。また網羅的検
索の結果として、スパム メールにつながる可能性も考え ら れ
る.
相手認証やアクセスコントロールは， この問題の現実的レベル
で有効な手段である． サービスを構築する際には，このことを
十分に配慮したうえで， 相手認証やアクセスコントロール機能
をユーザに提供する必要がある．
通信相手，サーバへのDOS(サービス不能攻撃)
通信を行う相手のサーバや端末，大量のパケット発信などに よ
るDOSは， サービス提供者やISPによる監視と適切な対応が必要
となる．
7.3.4 インターネット上のネットワークシステムに起因する課題
ENUMサービスも一般的な インターネット上のネットワークシ ス
テ ムの持つシステム上の 課題をもつ．以下に代表的な例をあげ
る．
システム侵入と破壊，情報流出
システムの脆弱性を狙った，システム侵入，破壊の可能性は 常
に あ る． また，侵入後，非公開の登録データをアクセスした
り，改ざんする 可能性もある．
セキュリティポリシの設定と，ネットワークアクセスの制限，
脆弱性対策，監視体制など， 一般的なセキュリティ対策を十分
にとる必要がある．
災害時対策
災害時のシステム破壊などを想定した， バックアップシステム
等の体制が必要である．
ENUM研究グループ第2次報告書(V1) 67
7.4 可用性の維持
ENUMサービスの可用性(availability)の維持が必要． ただし，登
録変更サービスとDNSサービスでは，その要件は大きく異なる．
パラメータは以下の通り:
o 性能(レスポンスタイム)
o 故障率
o 災害時の対応
o 輻輳の対策，DOS(運用不能攻撃)の対応
サ ービスレベル(サービス品質)として各種パラメータを規定し，
対策を実施する 必要がある．
ユーザENUMサービスにおいては，基本的には， インターネット上
のサービスの一部なので， そのサービスレベルは従来のインター
ネット上のDNSサービスの サービスレベルと同じ 考え方で 設 定
し，実施すれば良い．
オペレータENUMサービスでは，そのサービス内容が， 通常のイン
ターネットサービスより上のサービスレベルを 設定 す る 場 合
は，DNS サーバ(セカンダリサーバ，キャッシュサーバ)の 増設等
の対策が必要となる．
ENUM研究グループ第2次報告書(V1) 68
7.5 DNSの信頼性
DNSサービスの信頼性を向上させる手段として，DNSセカンダリ サ
ーバの設置がある． 特定のDNSゾーンを管理するDNSサーバを複数
台配置する方法である． マスターデータを管理するサーバをプラ
イマリサーバ， そのコピーをもつサーバをセカンダリサーバと呼
ぶ．
レジストリデータの内容が更新されたとき， その内容をプライマ
リサーバに伝達する． プライマリサーバは変更があったことを，
各セカンダリサーバに通知する． セカンダリサーバは，プライマ
リサーバに対してゾーン情報の転送要求をおこない その内容を更
新し， プライマリサーバとセカンダリサーバ間の情報を一致させ
る．
DNS のプロトコルの制約から，セカンダリサーバは 10台程度が上
限である． エニキャスト技術により，その台数を増やすことが可
能 で あるが， 専用のIPアドレス，AS番号の割り当てが必要であ
る．
ENUM研究グループ第2次報告書(V1) 69
最後に
2002年9月30日のグループ発足以来，ENUM 研究グルー プ で は，
ENUM 技術の理解を深めることを目的とし， ほぼ 1ヶ月に一度の
ペースでの研究会を行い，さらに分科会を開催し， ユーザENUM・
オペレータENUM という形に ENUM サービスを類型化し，検討を重
ねてきた． 検討の結果，ENUMに対する理解も高まり，多くの課題
が明確になった．
ENUM はE.164番号をドメイン名としてDNSに登録する技術として，
IETF，ITU-T等で国際的な標準化作業が進んできたが， 国内的 に
は総務省「IPネットワーク技術に関する研究会」において IP電話
の実装手段として紹介されたのを契機に幅広く注目を集めるこ と
と なった． 本研究グループも， この考え方をベースにスタート
した． これは，本研究グループで定義するオペレータENUMの範疇
に入るアプリケーションである．
現在，IP電話サービスの整備が進んでいるが， その相互接続方法
については，IP電話事業者同士が連携して， もしくは単独で事業
者間並びに固定網との相互接続の方法の検討を進めており， 現段
階では，ENUMそのものに対する強いニーズが生まれているとは 言
いがたい状況である． 自ら登録するユーザENUMについても，その
ニーズは必ずしも顕在化している とは言えない．
しかし，事業者同士のよりオープンなインターフェースによる 相
互 接続の要求， インターネット電話の普及，E.164番号による電
話以外のアプリケーション識別への 要求が高まることによって，
また，海外のENUMの状況によっては， このENUM技術へのニーズが
急速に高まってくることが考えられる．
ENUM技術をサービスとして構築・運用するには技術面，制度 面，
ビジネス面 での 多くの課題を解決する必要があり， これらの面
から継続して検討していく必要がある．
ENUM研究グループ第2次報告書(V1) 70
Appendix A. 電気通信番号
A.1 日本における番号計画
日本では，電気通信番号は，「電気通信事業法」に基づき， 総務
省によって管理されており， その具体的な管理は「電気通信番号
規則」によって定められている．
電気通信番号は，電気通信事業者に対して電気通信役務の提供 の
た めに 割り当てられる． 電気通信番号は番号の範囲によって，
割り当て対象となる事業種別， 識別の対象が規定されている．
主な電気通信番号としては次のようなものがある．
0ABCDEFGHJ
- 固定端末系伝送路設備を識別するための電気通信番号
- FGHJを単位として事業者に割り当てられ，ABCDEにて事業者 識
別される
- 通常，0AB-J番号と称される．
050CDEFGHJK
- パケット交換網に接続される端末設備等に提供される音声伝送
役務を識別するため の電気通信番号
- GHJKを単位として事業者に割り当てられ，CDEFにて事業者識別
される
070CDEFGHJK
- PHSに係る端末系伝送路設備を識別するための電気通信番号
- GHJKを単位として事業者に割り当てられ，CDEFにて事業者識別
される
080CDEFGHJK
090CDEFGHJK
- 携帯電話に係る端末系伝送路設備を識別するための電気通信番
号
- FGHJKを単位として事業者に割り当てられ，CDEにて事業者識別
される
そのほか，フリーフォン・着信課金サービス（0120DEFGHJ）， 分
担課金 サービス（0570DEFGHJ）などの電気通信番号についても，
将来的にはENUMへの投入が 検討される可能性がある．
詳細は電気通信番号規則等を参照のこと．
A.2 ENUMにおける電話番号
050 は IP電話での利用を目的としてできた番号領域である． し
たがって， IP電話は 050 または 特に認められたときは 0AB~J番
号が利用できる．
ENUM研究グループ第2次報告書(V1) 71
割り当てにあたっては，一定の通信品質，信頼性の確保が必要 で
あり， 通常のインターネットを用いたインターネット電話のため
に， 050または0AB-J番号は割り当てられることは現在の技術レベ
ルでは 困難である．（現状なし）
A.3 電話番号の管理権限
電 話番号（電気通信番号）は，対象となる設備を保有する電気通
信事業者， もしくは対象となる役務を提供する電気通信事業者に
対し総務省から割り当てられ， 電気通信事業者により管理されて
いる． 一方，ユーザENUMにおいては，NAPTRレコードにおける 電
話 番号とURIとの関連付けは ユーザの意思に基づいて行われるた
め， 関連付けられたURIへの到達可否等の管理については， ユー
ザに委ねられるとの考えもある．
何 れの場合においても，電話番号について管理が必要な案件につ
いては， ENUMにおいても考慮が必要である．（例：番号逼迫等の
理由による電話番号の変更など）
A.4 電気通信番号の他目的使用について
既 存の電気通信番号を利用して「本来識別する役務や設備」以外
の役務や アプリケーションを対応づけることに関して，制度面の
整理が必要と思われる．
本 来，その電気通信番号の割り当てを受けた事業者のサービスに
影響を与 える可能性があるので，登録できる番号帯域に制限を設
けたり，登録内容 について事業者が何らかの制限(登録方針)を設
けることについて，その可 否も含めて検討が必要である．
=> 割り当てを受けた事業者と登録するユーザの役割/責任/管理権
限の明確化
A.4 ENUMのための電気通信番号の割り当てについて
ユ ーザENUMを展開した場合の，主にENUMのレコードを識別するた
めの 電気通信番号の割り当てについて検討を行う必要がある．
電気通信番号の逼迫のなか，安易な割り当ては出来ないが，音 声
役務，電 話設備の識別を主眼とする，電気通信番号の割り当てに
ついて，識別対象， 割り当ての管理運営制度について，再検討す
る必要がある．
上 記のユーザENUMのレコードに用いられる電気通信番号の割り当
ての検討が 不十分な段階において，技術的な検証等の目的 に よ
り， ENUMの実験が必要と思われる状況においては，既存の電気通
信番号に影響を与えない， 実験用の電気通信番号を付与する案も
考えられる．
実験用の電気通信番号の割り当てができない場合には， 実験参加
者に割り当てられた，既存の 電話番号のみを利用すること に な
り，実験が限定されることも考えられる．
A.5 特番の扱い
ENUM研究グループ第2次報告書(V1) 72
ENUM における 110，118，119 のような緊急通報に関するいわゆ
る特番のあつかいについて， 検討が必要である．ここでは，その
解題を列挙するにとどめる．
イ ンターネット電話で緊急通報の特番を考える場合，次の点に注
目する必要がある:
a) 国際的な名前空間での特番の扱い．
b) 発信者の位置に依存した名前解決の仕組み．
c) 接続時の優先的な扱い，発信者の位置の特定．
緊急通報用の特番は国毎に決めるため，国際的には統一されて い
な い． 例えば，警察への通報は日本では 110 であるが，米国で
は 911 である． ENUMサービスはDNSを用いている．DNSはグロ ー
バルな名前空間を管理し， クエリの位置によらず同じ答えを返す
ため， 特番のような，発信者の国に依存した名前管理は難しい．
さらに，特番は E.164の番号体系ではないため， ENUMツリー下の
空間に ENUMに緊急通信用の電話番号をどのように表現するか決め
る 必要がある． たとえば，0.1.1.1.8.e164.arpa. 導入するにし
ても，十分な検討が 必要である．
110はその発信者に近い警察機関への接続が要求される． ま た，
接 続についても優先的な扱いを行い発信者の位置の特定する必要
がある． これらの機能について，ENUMだけを用いて実現すること
は難しい．
ENUM研究グループ第2次報告書(V1) 73
ENUM研究グループ会員一覧
会員 (五十音順 敬称略)
o 一井 信吾
o インターネットフォーラム
o (株)インフォセック
o NTT コミュニケーションズ(株)
o 沖電気工業(株)
o KDDI(株)
o 後藤 滋樹
o JENS(株)
o (社)情報通信技術委員会
o (社)テレコムサービス協会
o 東京通信ネットワーク(株)
o 日商エレクトロニクス(株)
o ニフティ(株)
o 日本サイバースペース(株)
o 日本テレコム(株)
o 日本電気(株)
o 日本電信電話(株)
o (社)日本ネットワークインフォメーションセンター
o (株)日本レジストリサービス
o ネットワンシステムズ(株)
o フュージョン・コミュニケーションズ(株)
o 富士通(株)
o 三菱商事(株)
ENUM研究グループ第2次報告書(V1) 74
オブザーバ
o 総務省 総合通信基盤局電気通信事業部電気通信技術システム課
事務局
o (社)日本ネットワークインフォメーションセンター