ENUM研究グループ報告書

1

ENUM研究グループ

報告書

2003年5月23日(030602D)

ENUM研究グループ報告書

2(blank)ENUM研究グループ報告書

3

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 で始まる

4

ENUM研究グループ報告書

電話番号の割当が開始された．
このような背景のなか，ENUMに対する理解を高め，今後の方向性についての 検討が急務になってきている．
この報告書では，研究グループの調査，検討の結果のうち，• ENUMの概要• ENUMによって解決できる課題• ENUMの登録モデル• ENUMにおける個人情報保護とセキュリティ
を中心にまとめた．

ENUM研究グループ報告書

5

1.1 研究グループの検討の目的と対象
この研究グループでの検討の目的は，次の通りである:• ENUM技術そのものの理解• ENUMの実現方式，運用方式，またこれに関連する検討• ENUMの実現，運用における制度上の課題の抽出• その他，ENUMに関連する技術的課題の検討• ENUMを導入した際の効果と問題の明確化
このような目的を達成するために，研究グループでは， ENUM技術と，それに関連する技術(DNS，URL，DDDS等)を中心に調査と検討を進めている．

6

ENUM研究グループ報告書

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を生成するための書き換え規ENUM研究グループ報告書

7

則を記述す るためのDNSリソースレコード- RFC2915で定義されたが，DDDSの一部としてRFC3403で再定義された． (RFC2915，RFC3403)
番号ポータビリティ：Number Portability- サービス，プロバイダ(電話会社)，ロケーションを変更しても同じ電話番号を 使えること．

1.2.2 ENUM用語(本報告書独自定義)
ENUMアプリケーション- 発着信の双方でENUMを利用するアプリケーション 例：電話，SIP，
H.323，ファクシミリ，電子メール， インスタントメッセンジャー
ENUMクライアント- ENUM検索を行うクライアントアプリケーション- オペレータENUM：網内の装置や端末- ユーザENUM：インターネットに接続されたユーザコンピュータ内のアプリケーション
IP電話- (狭義)管理されたIPネットワークを利用し，品質が保証された音声電話サービス であり，一般的にインターネット電話よりサービス品質は優れる傾向がある． 本報告書では「IP 電話」をこの意味で用いている．
- (広義)IP技術を用いた音声電話サービス．インターネット電話と上述の狭義の IP電話を包含．総務省のIPネットワーク技術に関する研究報
告書では 「IP電話」をこの意味で用いている．
Tier0- ENUM DNS 階層のトップで，現在IAB(Internet Architecture Board) が管理し， e164.arpaが実験的に利用されている．
Tier1

8

ENUM研究グループ報告書- 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研究グループ報告書

9

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種類がある．
• プロキシサーバ: SIPリクエストを転送したり，代理送信する
サーバ

10

ENUM研究グループ報告書• リダイレクトサーバ: SIPリクエストを受け取り，着信側の現在のアドレスを発信側に返すサーバ． プロキシサーバとは違いSIPリクエストを転送しない• 登録サーバ(レジストラ): UAの現在位置を登録するリクエス
ト(REGISTERリクエスト)を受け取り， ロケーションサーバ
などに登録されている情報を更新するサーバ
SOA: Start Of Authority- ゾーンのオーソリティを示す情報(データの始まりを表す)
TCP: Transmission Control Protocol- トランスポート層のコネクション型プロトコルであり，RFC793で定義されて いる．
TLS: Transport Layer Security protocol- アプリケーション間の通信に隠密性と安全性を提供するプロトコル
で， TCPなどの既存の信頼性のあるトランスポート層プロトコルの上に位置する． RFC2246で定義されている．
- 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)

ENUM研究グループ報告書

11

URI:Uniform Resource Identifiers- 抽象的な資源あるいは場所で指定された資源を識別する簡潔な文字列であり， URLを拡張した記述様式(RFC 2396)
VoIP: Voice over IP- インターネットやイントラネットなどのIPネットワークを介して音声通話を 実現する技術
ゾーン- ドメインの持つ名前空間の一部分の情報 DNSには，このゾーンの情報がゾーンファイルとして格納される
リソースレコード(RR)：Resource Record- DNSデータベースの各構成要素(レコード) NAPTRもリソースレコード
の一つ

12

ENUM研究グループ報告書

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

ENUM研究グループ報告書

135) 数字を逆順にする．
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@nic.ad.jp!" .

結果として，URI，
sip:info@nic.ad.jp
を得る．これによりアプリケーションプログラムは， sip:info@nic.ad.jp に対して，SIP を用いてセッションを 確立することが可能であることを知ることができる．
NAPTR行のE2U+sipと変換規則のURIを書き換えることで， 電話番号に対するH.323やインターネットFAX，WEBや電子メールなどのアドレスを 書くことができる．詳細は後述する．

14

ENUM研究グループ報告書

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

A
U
P
文字 S
置換・解釈の制御
S: 最終結果 次はSRVを引く
A: 最終結果 次はA, AAAAを引く
U: 最終結果 URIを出力
P: プロトコル依存

ENUM研究グループ報告書

15

なし: 得られた結果についてさらにデータベースを引く
service

文字列 プロトコル [ +サービス ]このエントリが適用されるプトロコル・サービスを指定

regexp

置換文字列(正規表現で与える)

replacement

固定ドメイン名を返せばよい場合はregexpのかわりに
ここにドメイン名を書く

一つの鍵に複数のNAPTRリソースレコードがあった場合，まずorderの小さいものを選ぶ．orderが同じものが複数存在した場合，preferenceの小さいもの を用いる．同一order値に複数の有効なリソースレコードが存在し， preferenceの小さいものを評価して失敗した場合，次のリソースレコードを 処理する．あるorder値のリソースレコードがすべて失敗した場合は，それよ り大きなorder
値の評価はしないでエラーとする．
serviceフィールドには，このNAPTRリソースレコードが対象とするサービス
を書く．複数のNAPTRリソースレコードが存在した場合，このフィールドを先 にみて該当するか調べておけばよい．
regexpフィールドには正規表現でAUSからの置換規則を書く．
replacementフィールドには，regexpフィールドがある場合は . を書く．
NAPTRリソースレコードは,ENUMだけではなくSIPサーバ情報を指定するためにも 用いられている(RFC3263)．

16

ENUM研究グループ報告書

2.2 DDDSアプリケーションとしてのENUM
ENUMはDDDSのアプリケーションの一つとして再定義されつつある．
DDDSをENUMで使うプロトコルとしてE2U (Enum to URI)が定義されている．
そのなかのサービスとして sip, h323, ifax, tel, enum, mailto, httpなどが想定されている.
想定されているサービス・プロトコルと NAPTRのserviceフィールド， URIス
キーム例を表で示す． 正式には，RFC2916bis がRFC 化された後にそれに従い， サービスごとにserviceフィールドとURIなどの機能を定義した RFCを発行し，IANAに登録する．
サービス・プロトコル

serviceフィールド

URIスキーム

SIP
H.323
H.323による電話

E2U+sip
E2U+h323
E2U+voice:h323
E2U+ifax:mailto
E2U+voice:tel
E2U+telE2U+message:mailto
E2U+message:httpsip:info@nic.ad.jp
h323:info@nic.ad.jp
h323:info@nic.ad.jp
mailto:info-fax@nic.ad.jp
tel:+81352972311;svc=voice
tel:+81352972311;svc=fax
mailto:info@nic.ad.jp
http://www.nic.ad.jp/

インターネットFAX
既存電話
電話でのFAX
電子メール
WEB

ENUMの概要で説明した + ではじまるE.164電話番号がENUMのAUSとなり，最初 の知られた変換は，前述した電話番号からe164.arpaドメイン下のドメイ
ンに 変換する規則である．
また，ENUMにおけるNAPTRのフラグは現時点で"u"のみ定義されている．
他のDNSのリソースレコードと同様に，NAPTRリソースレコードもひとつのド メイン名(検索鍵)に対して複数のリソースレコード(DDDSデータベース)を定 義することができる．

ENUM研究グループ報告書

17$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を意味する．
また，局番 +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番号に対応づけることができる．

18

ENUM研究グループ報告書

2.3 ENUMの仕様
ENUMは一連のRFCによって，その仕様が規定されている．主なものは次の通り:• RFC2916(E.164 number and DNS) は， ENUM の基本的な仕様を規定している． 現在，"The E.164 to URI DDDS Application" というタイトルで， 改訂作業が進められている．
☞ draft-ietf-enum-rfc2916bis-06.txt• RFC2806(URLs for Telephone Calls) ，既存電話網との接続を示す URI ， tel:,fax:, modem: を規定している． 現在，"The tel URL for Telephone Calls" というタイトルで， URIではサービスの種類は示さないという現状の 合意にあわせてtel: のみを規定する．
☞ draft-antti-enum-rfc2806bis-08.txt• RFC3401 〜RFC3405(Dynamic Delegation Discovery System - DDDS). ENUM で利用されている，DNS検索，NAPTRリソースレコード， 一連の書き換え規
則等が 規定されている．

ENUM研究グループ報告書

19

関係する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

20

ENUM研究グループ報告書

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: PROPOSEDSTANDARD)
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: PROPOSEDSTANDARD)
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研究グループ報告書

21

2.4 ENUMのTier構造とDNSのゾーン構造
ENUMのTier構造やDNSのゾーン構造は，国ごとの事情により決められる．日
本 における構造については議論が必要である．ここでは構造の複数案と考え方 について述べる．

2.4.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で電話番号すべての桁まで持つ場合

22

ENUM研究グループ報告書

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 の上部と下部を分け，別の事業体で行うことが考えられる．
Tier1レジストリ事業への参加の機会を増やすといった政策を選択する場合などに， この方式の採用が想定される．
(注: 日本の電話番号では0A0(電話種別)や0AB0(高度系サービス)などがある
ため，03 のようなAの単位で番号を分けると固定電話とその他サービスが混 在する形となる．電話種別やサービスごとのような分け方をしたい場合には， 0ABCのCの番号にてTier1 内を分割する必要がある．)

ENUM研究グループ報告書

23

Tier構造 図2.1

e164.arpa.

e164.arpa.

Tier0

Tier0
1.8.e164.arpa.

Tier1

1.8.e164.arpa.

Tier1

TN

TN
Tier2

(1)
: NS Record: NAPTR Record(2)(enum-fig-04.obj)

24

ENUM研究グループ報告書

Tier構造 図2.2
e164.arpa.

e164.arpa.

Tier0

Tier0
1.8.e164.arpa.

Tier1

1.8.e164.arpa.
Tier1

050xxxx

050yyyy03xxxx050

03

03xxxx050xxxx 050yyyy

Tier2

Tier2
TN
(3)
: NS Record: NAPTR RecordTN(4)(enum-fig-05.obj)

ENUM研究グループ報告書

25

2.4.2 ENUM DNSゾーン構造
前節で述べた構造のTierごとに，単数または複数のゾーンによる運用が 想定される．ゾーンを分割するか否かは，そのゾーンの管理者あるいは 運用者の決断に委ねられ，管理のしやすさ，性能などの運用上の要件により 決定されるものと考えられる．
なお，レジストラの受け付け範囲とゾーン構造とは，独立にすることが可能である．一致させる場合にはゾーンごと，一致させない場合には個別の電話番号毎などで，レジストラによるレコード変更権限の確認等が必要になると考えられる．

2.4.3 ENUMレジストリ・レジストラ間通信
ENUM DNSを運用する場合には DNS 登録を管理するENUMレジストリが必要になる．
従来のgTLDやccTLDのドメイン名空間(たとえば.jp)には， 一つのレジストリと登録受け付け窓口としての複数のレジストラがある． 登録者はレジストラ
を介してドメイン名の登録や登録内容の変更を行ない， レジストリは登録された内容に基づいて DNSのゾーンを作成し， DNSの提供を行なう．
これまではレジストリごとに独自のレジストリ・レジストラ間 通信プロトコ
ルを用いていたが， IETF PROVREG WGにてレジストリ・レジストラ間の汎用通信プロトコルを 決めることとなり， レジストリ・レジストラ間通信の要求仕様である GRRP(Generic Registry Registrar Protocol) をRFC3375 として定めた． 現在，GRRP要求仕様を満たすEPP(Extensible Provisioning Protocol) を策定中である． 標準化されると，多くのレジストリではEPPをサポートすることが推奨される．
EPPはXMLベースで拡張性が高いプロトコルとして設計され， 以下のコマンドを定義している． これらのコマンドを組合せ，コマンド列としてレジスト
リデータベースを 操作する．それぞれのトランザクションはloginで始まり，
logout で終る． EPP は通信の枠組を規定し，通信トランスポートや扱うオブ26

ENUM研究グループ報告書

ジェクト については別途定める．
login
logout
check
info
poll
createdeletetransfer
update

認証を行ない，EPPサーバとのやりとりを開始する
EPPサーバとのやりとりを完了する
オブジェクトを取り扱うことができるかを確認する
既存オブジェクトの情報を得る
自分宛のqueueに蓄積されているメッセージを要求する
オブジェクト生成 (ドメイン名登録)
既存オブジェクト削除
既存オブジェクトを管理するレジストラを変更する
既存オブジェクトの持つ登録情報の変更☞ draft-ietf-provreg-epp-09.txt
EPPで使う通信のトランスポートとして，TCP(TLS)やBEEP，SOAP，MAILを使う方法が提案されている．
☞ 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に必要な 機能

ENUM研究グループ報告書

27について定義している．具体的には E.164ドメイン名とNAPTRフィールドの値である．この定義により， Tier1, Tier2のそれぞれのレジストリ，レジストラ間の通信を取り扱うことができる．

28

ENUM研究グループ報告書

2.5 関連する団体や活動
ここでは，ENUMに関連する国際的な団体や関連する活動について， その概要を紹介する．

2.5.1 IETF
活動概要
TCP/IPなどのインターネットで利用される技術を標準化する組織． インターネットの標準化を統括するIABの下部機関． ここで策定された技術仕様
はRFC として公表される．

Status1999 年10 月にENUM-WG 設立．2000 年1 月にITU 主催による「公衆網とIP
ネット ワークとのインターワーキング・ワークショップ」に参加． 2000年
9月ENUMプロトコルRFC化(RFC2916)．
現在，ENUM ワーキンググループでRFC2916 を修正したRFC を策定中であり， draft-ietf-enum-rfc2916bis-06.txtが合意されつつある．

関連URL☞ http://www.ietf.org/ (IETF)☞ http://www.ietf.org/html.charters/enum-charter.html (Telephone Number Mapping (enum)
WG)ENUM研究グループ報告書

29

2.5.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)

30

ENUM研究グループ報告書

2.5.3 ENUM Forum
活動概要
e164.arpa(仮)をルートとするE.164 番号を使ったDNS 構造に基づくRFC2916の 仕組みをNANP(North American Numbering Plan) 配下の米国，北米諸国にお いて採用するための枠組みを作ることを目的に2001年8月に設立．

StatusTier1 並 び に Tier2 に 対 す る 要 求 条 件 を 取 り 纏 め た 書 類 「 Unified
Document」を2002 年11 月にリリース．各役割や接続条件に加え， プロ
ヴィジョニング，セキュリティ，プライバシ等に関しても言及．

関連URL☞ http://www.enum-forum.org/ (ENUM Forum)☞ http://www.enum-forum.org/documents.html (The ENUM Forum - Documents)

ENUM研究グループ報告書

31

2.5.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関連コンタ
クト先)

32

ENUM研究グループ報告書

2.5.5 ETSI
活動概要
欧州における通信関係標準化機関．ITUが政府代表主体の国際機関である のに対し，標準化活動が主体の地域標準化機関(欧州域外も含む)といえる．
通信関係のEN(欧州規格)や，ETS(欧州通信規格)を制定．

StatusTIPHON(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研究グループ報告書

33

2.5.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)

34

ENUM研究グループ報告書

2003年5月5日時点での登録状況の通り．
国名E.164国番号

権限受任団体承認日

246

Diego Garcia

Government’02/08/12

247

Ascension

Government’02/08/12

290Saint Helena

Government’02/08/12

31

Netherlands

Ministry’02/05/23

33

FranceDiGITIP(Government)’03/02/28

358

FinlandRegulatory Authority

Finnish Communications’03/02/26

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

SwedenNPTA’02/12/10

48

Poland

NASK’02/07/18

49

Germany

DENIC’02/05/16

55

BrazilBrazilian 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) 2003年6月30日トライアル終了見込み．

ENUM研究グループ報告書

35

2.5.7 ENUM関連勧告等の検討変遷
ITU-Tを中心にしたENUM関連勧告等の検討の変遷を以下に示す．

 

¦³'   ¦ ³' ¦³'¦³'ªªul}N^ª ¥¬¤

  

ª

îï 

è

¥¬¤

Yj}vp{bþ^ÎÖß éèÚz¥¬¤Yj}vp{b îïVþ^ÎÖß éè¦³'  
¦³'

ª

ª

1
ÚzUá¡
èMoé



so»Å

Úz
þ^ÎÖß éso»ÅèVþ^ÎÖß èR­Öß éé

¥¬¤

¥¬¤

¦³'

ª

 ¥Æ ¥ÆÅ¼Æ îï  ª­

Pj¥

Pjô



«À¼É

Úz

¤»Å

«À¼É

¤ª»Å



1ª¶¤.PNô~§¦_®

«À¼É



36

ENUM研究グループ報告書

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 はエンドユーザによって，E.164番号に対応するDNSレコードの情報を管理するのに対して， オペレータ
ENUMでは，事業者が主体となって，DNSレコードを管理し， 登録できるア
プリケーションは， その網で提供されるサービスのためのレコードとなる．

ENUM研究グループ報告書

37

また，ENUM DNS のアクセスについては， ユーザENUMの場合は，エンドユーザ(のアプリケーション)が インターネットを使って通常のDNS手順でアクセスするのに対して， 典型的なオペレータENUMでは，網の装置やオペレー
タ端末(事業者が提供する端末)が 呼接続のために利用し，エンドユーザは特にDNSアクセスを意識する必要はない．
本研究グループでは，ENUM を，ユーザENUM とオペレータENUM のふたつに 整理して検討することとする．

38

ENUM研究グループ報告書

3.1 ユーザENUM
ここでは，典型的なユーザENUMを想定して，その条件を整理した．
ユーザENUMは，番号割り当てを受けた事業者毎に参加・不参加の判断は あ
りうるものの，参加する場合には事業者共通でパブリックなものとして 運用する必要がある．このため，ユーザENUMを構築するとした場合の 詳細について検討しておく必要である．
□ 目的- E.164番号ユーザ(E.164番号で識別される電気通信サービスを受けている利用者) 自身の指定する到達可能なアプリケーション公開- E.164番号ユーザへの音声サービスでの到達方法の獲得- E.164番号ユーザのもつ音声以外(WEB，メール)の到達方法の獲得□ 登録者- E.164番号ユーザ□ ENUMクライアント- インターネットに接続されたユーザコンピュータ内のアプリケーション- ゲートウエイ，プロキシ等□ 要求条件- ユーザへの 透明性 と 公平性 の確保- E.164ユーザが要求する プライバシ，セキュリティレベル- ENUMクライアントが要求する プライバシ，セキュリティレベル- 登録者の意志に基づく登録(opt-in)□ DNSの構成(Tier構造)

ENUM研究グループ報告書

39- グローバルな構成□ セキュリティの問題- 登録時のE.164番号ユーザの認証，登録データの正当性□ 番号管理
基本的に個人ユーザが自らの意志で番号に対応するURIの設定をおこなうことから，既存の電話番号管理との関係を明確にしておく必要がある．
★ 既存の電話番号と共有するとき
既存の事業者に割り当てられた電話番号をユーザENUMの番号としても 利用する場合は，E.164番号をENUMで利用する者が， そのE.164番号で識別されるサービスを受けている利用者であることを 確認する必要がある．また，ENUMにて，そのE.164番号で識別される 電気通信サービスに相当するサービスを受けている場合には， 本来のサービスとユーザの登録するレコードに不整合が生じないような 措置を施すことにより，混乱を避けるべきという考え方がある．
この場合，たとえば，- レコードの優先順序の制限- ユーザが登録する際の事業者による確認- ユーザの申請に基づく事業者の登録などの措置が必要と考えられる．
★ ユーザENUM用の電話番号空間
ENUM用の番号が割り当てられれば，既存の電話番号の管理との整合性を考慮する必要がなくなる，ただし，電話番号は希少であり有効な利用が 求
められることから，新たな電話番号の必要性について，制度面を含め， 検

40

ENUM研究グループ報告書

討する必要がある．

ENUM研究グループ報告書

41

3.2 オペレータENUM
たとえば，IP 電話事業者が，E.164 番号による接続をそのIP 電話網内に閉じて， 独自の情報を含むENUM技術を用いて実現する場合， これは，オペレー
タENUMである．
複数の事業者の網が相互接続された場合には，E.164番号からIPアドレスへの変換および変換情報の管理に関して，事業者間で事前の合意のうえ， 事業者間での共通のスキームを提供することも可能である．オペレータENUMを，こ のスキームとして利用してもよい．
事業者によっては，事業者間ポータビリティの共有データベースとして，
ENUM を用いることがある．この場合も，オペレータENUMである．
なお，オペレータENUM は番号割り当てを受けた事業者毎，もしくは，事前に 相互に合意のある事業者集団毎に構築するものであり， その実現方法はそれぞれの判断に委ねられるものである．
ここでは，典型的なオペレータENUMを想定して，その条件を整理した．
□ 目的- 事業者内の呼接続のため- 事業者間での相互の呼接続のため- 既存電話網から複数のIP電話網への呼接続のため□ 登録者- 網を管理する事業者が対応する番号を登録- 網内のすべての電話番号に対して，DNSレコードを登録□ ENUMクライアント- 網の装置やオペレータ端末

42

ENUM研究グループ報告書□ 要求条件- 呼接続のためのアドレス解決を保証するためのエントリーの網羅性および完全性- 事業者のサービスの品質に必要な，性能，信頼性，スケーラビリティ- クエリのアクセス制限(事前合意のあるオペレータ集団関係者以外DNS ア
クセスの禁止)□ DNSの構成(Tier構造)- 事業者の構造に対応- 場合によっては，ローカル/プライベートな構成もありうる□ セキュリティの問題- クエリのアクセス制限(事前合意のあるオペレータ集団関係者以外DNS ア
クセスの禁止)□ 番号管理- 事業者への番号割り当てに対応

ENUM研究グループ報告書

43

3.3 比較表
ユーザENUM

オペレータENUM

登録者

ユーザ

事業者(サービス提供者)

利用目的

ユーザ(登録者)の指示するサービスを公開

事業者がサービスを実現するために公開

登録URIの種別

多様事業者が提供するサービスを識別するためのURI

その電話の割り当てをうけた事業者との関係で，登録可能なURIの種別が限定される可能性もありうる

電話サービスの場合は
SIP/H323/TELなどに限定

既存の電話番号を利用する場合は制度，方針による事業者に割り当てられ
番号空間

適用する番号空間

ENUM専用番号が割り当てられた場合はその空間
日本の現行制度による
電話番号割り当て者と登録者の一致不一致
制度上の問題を整理する必要あり一致
現行制度との整合性あり

番号に対する管理責任

ユーザと事業者間で
整理が必要

事業者

検索者

インターネットユーザ

事業者のサービスのユーザ
網内装置，事業者端末

DNSサーバ性能/品質

インターネット品質

必要に応じて，事業者が
強化

検索端末

普通のインターネット
アプリケーションを利用する一般ユーザ端末

左記端末，
網内装置，事業者端末

44

ENUM研究グループ報告書(続き)
ユーザENUM

オペレータENUM

登録内容の網羅度

ユーザの意志による登録のため opt-in による選択的登録になる事業者のサービスを実現するために用いるため，その事業者に割り当てられた番号範囲内では網羅的に登録される

アーキテクチャ

通常のインターネット
上のDNSサービスに近い

事業者の都合によることがあり，その都合を忠実に考慮すれば複雑/多様．

均一

キメラ
個別の事象を事業者マターとすれば，共通部分はシンプル

Tier構造グローバルツリーの必然性

2.1(2)

2.2(3) > 2.2(4) > 2.1(2)場合によるので要検討

場合によるので要検討あり

場合によってはローカル
ツリーによるENUMライク
サービスで対応可能
特定の事業者間でのデー
タベースとして用いるだ
けならグローバルにする
必要なし
参照対象が不特定なら，グローバルにする必要あり

ENUM研究グループ報告書

45

(続き)
ユーザENUM

オペレータENUM

登録RR/URIに対するトラブル

ユーザの登録内容によるため，多い可能性あり事業者が登録するため少ない可能性．トラブル
対応者が明解．

サービス全体のトラブルと解決サービスの関係者が複数でその解決は面倒(かも)．

サービスの関係者は明確．
解決の手順はシンプル(かも)．

問題発生時の被害の範囲 ユーザに留まる(かも)事業者のサービス全体に影響する(かも)

登録/更新頻度変更量(利用者の数にもよるが)多

新番号割り当て，構成
変更時のため，更新頻度は少ないが，一回の変更量は多

登録変更時の手間(認証/課金の項目を参照)

大小(シンプルにすることも)レジストラが認証する対象(=登録者)

ユーザ

事業者

レジストラが認証する
対象の数

多

少

レジストラが認証する
手間

大

小

レジストラ=登録者の
可能性

なし

あり

レジストラの
課金対象

ユーザ

事業者

レジストラの
料金回収の手間大小レジストラの料金未回収リスクあり

小(ex.事業者の廃業)

46

ENUM研究グループ報告書(続き)
ユーザENUM

オペレータENUM

WHOIS/プライバシ

ユーザを識別する情報の扱い/保護のためのルー
ルが必要

事業者のポリシでユーザの情報を隠すことが可能

プライバシ問題顕著

簡単(にすることも)セキュリティ

インターネットレベル

事業者が必要に応じて
強化

守る対象

全般

全般

レジストラ，登録者
インターフェース

WEB等簡易なインターフェース(典型)

EPP等のトランザクション
インターフェース(典型)ENUM研究グループ報告書

47

4. ENUM導入によって期待されるもの(解決が期待されるもの)
ここでは， ENUM を導入することによって期待されるものについて整理する． 期待される内容によって，その実装や運用方法， 管理主体などが異なることが考えられる．
ここではENUM導入によって期待される事項を以下のように分類した:(1) E.164 番号によるアプリケーションの識別手段として(2) 既存電話からインターネット電話への電話番号解決手段として(3) インターネット電話から既存電話への電話番号解決手段として(4) 既存電話(含むIP電話)網の番号解決手段として(1)はユーザENUMで期待される典型的な目的である．また， (4)はオペレータ
ENUMで期待される典型的な目的である． (2)，(3)は，インターネット電話の運用方法によって， ユーザENUMで運用される場合と，オペレータENUMで運用される場合， または，それらが混在した運用方法の場合が考えられる．

48

ENUM研究グループ報告書(1) E.164 番号によるアプリケーションの識別手段としてENUMにより，ひとつのE.164番号を， インターネット上の利用可能なひとつまたは複数のアプリケーションに 対応づけることができることから，
E.164番号を用いて， そのE.164番号ユーザ (E.164番号で識別される電気通信サービスを受けている利用者)に対する 電話以外の通信手段を統合的に提供することが可能となる．
これには，アプリケーションの識別を数字だけで記述でき，電話機のようなテンキーによる端末インターフェースで入力が可能となるなどの利点がある．
エンドユーザAが登録したNAPTRリソースレコードを， エンドユーザBはE.164 番号を使って参照し， エンドユーザB の端末の相応しいアプリケー
ションを起動して， エンドユーザAと通信を行うことを可能にする． アプ
リケーションには， 電話，ファクシミリ，インターネット電話，電子メー
ル，WWWなどが 想定されている．

ENUM研究グループ報告書

49

User-ATel

IP Tel

Web

Mail

SIP

SIP

ENUM
HTTP

SMTP

(3) (3)(3)(3)

tel: sip:

http: mailto:

(2)

(1)

fig1.esp

User-B(1) ENUM DNSに問い合わせ．
(2) ENUM DNSから応答．
(3) 応答結果をもとにアプリケーションを選択し，接続．

50

ENUM研究グループ報告書(2) 既存電話からインターネット電話への電話番号解決手段として既存の電話網の加入者からインターネット電話の加入者に対してアクセスするときに，インターネット電話の加入者に対応するURIと対応したE.164番
号 との関係を解決する必要がある．これを解決する手段としてENUMは有
力な候 補である．
インターネット電話の加入者に対して，E.164 番号を割り当て， その番号と， URIの対をNAPTRリソースレコードとして，DNSに登録する． 電話網
からIP網へのゲートウエイは， 接続の際， DNSをE.164番号をキーにして検索し, 対応するIP電話の加入者が， SIPで接続可能である場合には, 対応する
SIP URIが得られ, そのURIに従って呼を確立する．

ENUM
(2)

(3)
(4)

(1)
G

SIP

(4)
SIP
fig2.esp(1) 電話機がIP電話に対して発呼．
(2) ゲートウエイがENUM DNSに問い合わせ(3) ENUM DNSから応答．
(4) 応答結果をもとにSIPゲートウエイを選択し，接続．

この場合，ENUMを用いなくても， たとえば，E.164番号に対応したSIPサーバの情報をゲートウエイが持つことにより， ENUMを用いずに，アクセスが可能となる． ただし，ENUM を用いることにより，検索のインターフェースの統一化， スケーラビリティなどの利点がある．
また，SIP以外にもインターネット電話のプロトコルとして，H.323を用いる 場合もある．このときは，H.323の URIスキームが 応答される．

ENUM研究グループ報告書51(3) インターネット電話から既存電話への電話番号解決手段としてインターネット電話の加入者から既存の電話網の加入者へのアクセスの際には，必ずしも ENUM を使う必要はない．インターネット電話が通常の コン
ピュータのようなキーボードを持つものであれば，ゲートウエイを ドメイ
ン名を用いて相手を指示すればよい．
しかし，ENUMを用いれば，(2)と同様に統一的なインターフェースで 管理することができる．
ENUMを用いたインターネット電話から既存電話への接続の方法には， URI
スキーム tel: を用いる方法と IP電話のスキーム(たとえばsip:)を 用いる方法がある．
tel: は，電話番号を示すURIスキームで，
tel:+81352972311
といったものである．ENUMによってこのURIを得た端末は，電話網に直接接続されている場合にはIP網を利用せずに電話網から接続を試みてもよい．
この接続ではインターネットを 利用していない．
既存電話網とインターネットとの間にゲートウエイが設置されており，SIP
サーバによってその接続が管理されている場合，URIによって，そのSIPサー バが指示されることによって，インターネット電話の加入者からSIPを用いて 既存電話の加入者に対してアクセスが可能となる．

52

ENUM研究グループ報告書

ENUM
G SIP

(3)

G SIP

(3)

(2)

(3)

(1)

tel: sip:
fig3.esp(1) ENUM DNSに問い合わせ．
(2) ENUM DNSから応答．
(3) 応答結果をもとに接続先を選択し，接続.

なお，インターネットと電話網のゲートウエイが複数ある場合， ゲートウ
エイの選択方式としては，TRIPのようなゲートウエイ選択の 専用プロトコ
ルを用いる方式や， 特定のゲートウエイを返答するようにNAPTRリソース
レコードを設定する方式が 考えられる(例えば，局番毎にゲートウエイを特定できる場合， 局番毎にNAPTRリソースレコードを設定する方式)．
インターネット電話から既存電話に接続する場合には，技術的な課題に加えて， 課金や制度などについて既存電話サービスとの整合性を考慮する必要がある．

ENUM研究グループ報告書53(4) 既存電話(含むIP電話)網の番号解決手段としてENUMのE.164番号データベースの機能を利用して，電話事業者がENUMを
電話 番号の管理，事業者間の経路情報管理のために用いることができる．
電話網 としてIPネットワークを用いているような場合， IP技術をベースにしたENUMは親和性が高いことが考えられる．

ENUM
G
R
G

PSTN
G

ISP

G

ManagedIP
Network
G

G

PSTN
fig4.eps

たとえば，番号ポータビリティ(事業者間，ロケーションなど)やUPT， フ
リーフォン(着信者課金サービス)などの実現手段として，このENUMの利用が考 えられる．
(注)ただし，これらを実現するためにはENUM以外に複雑な 仕組みを必要とする

54

ENUM研究グループ報告書

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研究グループ報告書

55

次の図でこれらの関係を示す:

ロケーションサーバ

DNS
4
SIPプロキシ
サーバ

6
5

2

SIPプロキシ
サーバ

7

3

SIP登録
サーバ

1

RTPによる通信
8
SIP UASIP UA

発呼側

着呼側

sip-00

典型的なセッション確立の流れはおおまかに次の通りである:
着呼側の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メッセージ)が伝達される．

56

ENUM研究グループ報告書

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研究グループ報告書

発呼側
SIP UA

57

SIPプロキシ
サーバ

INVITE
100 Trying
180 Ringing
200 OK

着呼側

SIPプロキシ
サーバ

INVITE
100 Trying
180 Ringing
200 OKSIP UAINVITE180 Ringing
200 OK

ACK

通話
BYE
200 OK

sip-01

58

ENUM研究グループ報告書

5.2 SIP URI と 着呼側のSIPプロキシの発見
SIP では 通信相手を識別するため識別子として， URI の一種である SIP URIを用いる(RFC2363)．たとえば，
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
IN NAPTR 50
50"s""SIPS+D2T"
IN NAPTR 90
50"s""SIP+D2T"
IN NAPTR 100 50"s""SIP+D2U"

regexp replacement"" _sips._tcp.example.co.jp.
"" _sip._tcp.example.co.jp.
"" _sip._udp.example.co.jp.

これは，サーバがTCP上のTLS，TCP，UDPにこの優先順で対応していることを示す． 発呼側のSIPプロキシはTCPとUDPに対応しているので， TCPを選択
し，_sip._tcp.example.co.jp の SRVの問い合わせを行う． その問い合わせの結果，以下のようなレコードが見つかる:;;

Priority Weight Port

TargetENUM研究グループ報告書

IN SRVIN SRV

0
0

59

1
2

5060
5060

server1.example.co.jp.
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の変換ルールにしたがってドメイン名に変換し， そのドメイン名にしたがって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リダイレクトサーバがこの処理を行ってもよい．

60

ENUM研究グループ報告書

現在のIETFの議論では，クライアントによる処理が良いとされている．
☞ draft-ietf-sipping-e164-02.txt
SIPプロキシが対応する場合， SIP UA から伝達される電話番号を含む SIP URIについて， パラメータも含めて標準的なフォーマットを決めておく必要がある．
SIP クライアントがENUMを処理する場合の典型的なセッション確立手順を，
DNS問い合わせを中心に図で示す．

ENUM研究グループ報告書

61

DNSサーバ発呼側SIPクライアント
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!" .

SIPプロキシ
INVITE
sip:info@nic.ad.jp
nic.ad.jp?

IN NAPTR 100 50 "s" "SIP+D2U""" _sip._udp.nic.ad.jp.

_sip._udp.nic.ad.jp ?
IN SRV 0 1 5060 sipserver.nic.ad.jp.

sipserver.nic.ad.jp?

IN A 202.12.30.144

着呼側

SIPプロキシ
sipserver.nic.ad.jp

ロケーションサーバ

202.12.30.144
INVITE
sip:info@nic.ad.jp
info@nic.ad.jp?

sip:info@sipinfo.nic.ad.jp?

sipinfo.nic.ad.jp
IN A 202.12.30.145

SIP UAsipinfo.nic.ad.jp
INVITE
sip:info@sipinfo.nic.ad.jp

通話202.12.30.145

62

ENUM研究グループ報告書

6. ENUM登録の流れ
ENUM サービスにおける情報の登録更新の流れについて， ITU-T のレジスト
リ・レジストラモデルを基本に， その登録の流れについて提示する．

6.1 ITU-Tレジストリ・レジストラモデル
ITU-Tでは，ENUMサービスの登録管理をレジストリ，レジストラモデルにしたがって， 整理している．まず，このモデルにしたがって，ENUMレコード
がどのように， 登録管理されるのか整理する．
ITU-T では，登録管理の役割分担を行う機能として， 以下のエンティティを提案している．
• マネージャ(管理責任者)
ドメイン名の管理責任者．
• レジストリ
レジストリデータベースを運用管理する機関．レジストリデータ ベース
を元にDNSゾーンファイルを生成する．
• レジストラ
レジストラントの申請を受け，登録資格チェックなどの登録受け付け 手
続きを行ったのち，レジストリに対して登録を依頼する．
• レジストラント(登録申請者)
そのドメイン名の登録申請者．

ENUM研究グループ報告書

63

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の実装は国内マターとなっている．

64

ENUM研究グループ報告書

6.2 レジストリ，レジストラ登録更新の流れ
レジストリ，レジストラモデルでは，登録者からDNSに登録されるまでの 主な流れは次のようになる．

Tier0
DNS
委任

IAB
(RIPE NCC に委託)

ITU-T

Tier0
Registry

Tier0
Registrar

加盟国

1.8.e164.arpa

認証機関

Tier1
DNS

3’)

Tier1
Registry3)

Tier1
Registrar

確認x.x.x.1.8.e164.arpa

委任

2)
Tier2
DNS

2’)

Tier2
Registry2)

Tier2
Registrar

認証機関

確認

1)
登録者

1) 登録者はTier2レジストラに登録更新申請を行う．
2) 必要に応じてその番号の認証機関(典型的には番号を割り当てられた事業者)に確認のうえ Tier2レジストラは申請内容を確認し正当であれば． Tier2レジ
ストリに対して登録更新申請をおこなう． もし，申請が新規登録またはTier2レジストリを変更するような申請なら (Tier1の登録内容の変更が必要な
どきは)Tier1レジストラに対して， 登録変更申請を行う．

ENUM研究グループ報告書

652’) Tier2レジストリはレジストリデータベースを更新したのち，Tier2の DNS
ゾーンファイルを生成する．
3) Tier1レジストラは申請内容を確認し正当であれば． Tier1レジストリに対して登録更新申請をおこなう．
3’) Tier1レジストリはレジストリデータベースを更新したのち，Tier1の DNS
ゾーンファイルを生成する．

6.3 レジストラの確認事項
レジストラは申請者からの登録更新申請を受け，その申請内容を確認のうえ，
正しければ，レジストリにその内容を送る．
この際の確認内容としては次のようなものがあげられる．
• 申請者の認証．申請者が本人であることを確認する．
• 申請者の権限の確認．申請者がその申請を受ける資格があるかどうかの確認． Tier2レジストラでは，申請者が対応するE.164番号の加入者であることを， Tier1レジストラでは，申請者(Tier2レジストラ)が対応するNSレコード
を 管理するTier2レジストラであることを確認する．
• 申請内容の確認．申請者からの登録更新の内容が適切であることの確認．
Tier2レジストラでは，申請内容が対応するE.164番号のNAPTRレコードとして 適切であることを， Tier1レジストラでは，申請内容のネームサーバ情報
が申請者の管理する ドメイン名の範囲内であることを確認する．

66

ENUM研究グループ報告書

6.4 登録管理情報
レジストリおよびレジストラはENUMサービスの維持管理のために， 登録内
容の他に登録者に関する情報を保持する． さらに登録内容にしたがって，
DNSのゾーンファイルを生成し， DNSサービスとしてインターネット上に公開したり， WHOISインターフェースで，その内容の一部を公開する．
主な登録内容と管理するエンティティ，公開の方法をまとめると次の通りであ
る:
DNSでの

WHOISでの公開

公開

Tier2レジストラ/レジストリ○○

NAPTRレコード

Tier2レジストラ/レジストリ

○

○

登録者名
連絡先
住所
認証情報
課金情報

Tier2レジストラ/レジストリ
Tier2レジストラ/レジストリ
Tier2レジストラ
Tier2レジストラ
Tier2レジストラ

-

△
○
△
-

Tier2 NS-RR

Tier1レジストラ/レジストリ
Tier2レジストラ/レジストリ○○

Tier2名Tier1レジストラ/レジストリ
Tier1レジストラ/レジストリ
Tier1レジストラ

-

○
○
-

登録内容

保持者

E164番号

連絡先
認証情報

1)
2)

1)

1) パスワード，公開鍵などの認証情報
2) クレジットカード番号，口座番号など．Tier2レジストリが登録者に課金する場合．

ENUM研究グループ報告書

67

6.5 登録の手順のバリエーション
日本では E.164番号は電気通信事業者に対して割り当てられる． 番号は電気通信事業者の事業のために割り当てられるため， その事業目的とENUMでの利用に関して，整合性をとる必要がある．
ENUMサービスのために，既存のE.164番号を利用した場合の， 登録手順のバ
リエーションについて提示する．
実際にENUMサービスを実現するには，唯一の登録手順で行う必要はなく，適当な番号領域(事業者の番号割り当て単位)ごとに，それぞれ， 個別の登録管理手順が採用されることになる．

68

ENUM研究グループ報告書

6.5.1 登録モデル1
電気通信事業者が，加入者の申請をうけ，確認ののちTier2レジストリ経由
で Tier2 DNS を更新する．ここで，電気通信事業者は Tier2 レジストラの機能を 持つ．

認証機関
Tier1
DNS

Tier1
Registry

Tier1
Registrar

認証機関
Tier2
DNS

Tier2
Registry

Tier2
Registrar
電気通信事業者

regpolicyA0

登録者(加入者)

ENUM研究グループ報告書

69

このモデルのバリエーションとして，電気通信事業者が，Tier2 レジストリの 機能も兼ね，Tier2レジストリデータベースの運用管理，DNSゾーンファ
イルの 生成も行う．

認証機関
Tier1
DNS

Tier1
Registry

Tier1
Registrar

認証機関
Tier2
DNS

Tier2
Registry

Tier2
Registrar
電気通信事業者

regpolicyA1

登録者(加入者)

70

ENUM研究グループ報告書

6.5.2 登録モデル2
電気通信事業者とは独立に，Tier2レジストラ が，登録申請をうける． 申請
者が加入者どうかは，その番号に対応する電気通信事業者が確認/承認を 行
う．

認証機関
Tier1
DNS

Tier1
Registry

Tier1
Registrar

認証機関
Tier2
DNS

Tier2
Registry

Tier2
Registrar

電気通信事業者

regpolicyA2

登録者(加入者)

これは，ISPや他事業者が，Tier2レジストラを行う場合が，このモデルに あたる．

ENUM研究グループ報告書

71

6.5.3 登録モデル3
その番号に対するENUMサービスを用いた着信を設定するために， 電気通信事業者が設定するケース． この場合，事業者がそのサービスを実現するための オペレータENUMサービス． したがって，加入者の意図とは関係な
く，E.164番号に対するレコードを登録する．

認証機関
Tier1
DNS

Tier1
Registry

Tier1
Registrar

認証機関
Tier2
DNS

Tier2
Registry

Tier2
Registrar

登録者

電気通信事業者

72

ENUM研究グループ報告書

6.5.4 課金モデル1• レジストリは費用を事業者に請求• 事業者が加入者(登録者)との契約に基づいて加入者(登録者)に請求

契約

Tier2
Registry

事業者

請求
請求

契約
加入者(登録者)

6.5.5 課金モデル2• レジストリは費用を加入者(登録者)に請求．
• 加入者(登録者)はレジストリと事前の契約を行う場合もあり．

契約

Tier2
Registry

請求

事業者

契約
加入者(登録者)

ENUM研究グループ報告書

73

6.6 登録ポリシ
すでに述べた通り， 日本では E.164番号は電気通信事業者に対して割り当てられる． 番号は電気通信事業者の事業のために割り当てられるため， その事業目的とENUMでの利用に関して，整合性をとる必要がある．
割り当てを受けた事業者は登録ポリシを策定し， ENUMに登録する際には，当該番号の割り当てをうけた事業者が策定した ポリシにしたがって，登録するという仕組みが必要である．
ここでは，登録ポリシと考えられるものの例をあげる． これらの組合せが，実際の登録ポリシとなる．
• 強制: 事業者が自ら， 事業者がサービスしている電話機に着信するため、 加
入者の意志とは関係なく強制的に登録する． オペレータENUMでの標準的な登録ポリシ．
• 選択: 利用者が自らの意志で登録する． いわゆる オプトインの考え方． ユー
ザENUMでの標準的な登録ポリシ．
• サービスの限定: 登録できるサービスを限定させる． 例えば，その番号のTEL URI および MAILTO URI に限定させるなど．
• サービスおよびパラメータの限定: 例えば sipを登録する場合の SIPプロキシの限定．
• 優先度の限定: 例えば，登録する際には，その番号の TEL URI または 事業者の指定した SIP URI を最優先のレコードとして登録する．

74

ENUM研究グループ報告書

7. 個人情報保護とセキュリティ，信頼性
7.1 個人情報保護
ENUMの扱うサービス，インターネット利用者間の通信は，個人的な利用も多く， 個人情報保護について十分に考慮する必要がある． ENUMサービスで取り扱われるENUMユーザの個人情報および関連する情報について， その取り扱いに関する方針と取り扱い手続きを明確にする必要がある．
ENUMサービスが扱う情報は大きく3つに区分される:(1) DNSに登録される情報．具体的には NAPTRレコードと それに含まれるパ
ラメータ．
(2) WHOIS情報． インターネットの運用管理のために公開されるドメイン名の登録者情報， 登録者名，連絡先等．一般的に WHOIS と呼ばれる公開情報．
(3) 顧客情報．レジストリ/レジストラが保持する，登録管理のための情報，
登録者識別情報，課金のための情報．
それぞれの情報区分によって，その扱いの方針が異なる．
個人情報の扱いの原則として， 登録者に対して，それぞれの区分に対する，
情報収集の目的を 提示し，事前に了承を得る必要がある． すなわち，• 登録するNAPTR情報はDNSによって公開されること• 登録者の連絡先はWHOISによって公開される．WHOISの目的は- インターネットの分散運用管理のため- 登録者が登録情報を確認するため
公開情報以外の情報は，システム，取扱手続き上適切な管理が必要 他の目的での利用，流出を防止する仕組みが必要である． さらに， 年齢，性別，そのENUM研究グループ報告書

75

他 ENUM サービスを行ううえで必要のない個人情報に ついては，極力，収集，蓄積しないなどの配慮も必要である． 個人情報保護の動向，インター
ネットにおける個人情報の取扱に対する動向を 注目する必要がある．
以下，それぞれの区分について，さらに検討する．
DNS情報
DNSに登録される情報は，すべて公開される． 個人情報をできるだけ隠蔽させるために，NAPTR レコードに登録される URI に 個人を識別する情報を含めないなどの工夫が必要である．
た と え ば， mailto: の 情 報 に 対 し て， ユ ー ザ 山 田 さ ん を 連 想 さ せ る
mailto:yamada@exmaple.co.jp を登録するのではなく， ランダムなユーザ名
aci2hnwz とし， NAPTRとして mailto:aci2hnwz@exmaple.co.jp を登録， メー
ルサーバが aci2hnwz を yamada に対応させる． これにより，E.164番号に対応する ユーザが 山田さんであることを 隠蔽することができる．
WHOIS情報
WHOIS情報については， インターネットの分散管理を維持するための 登録
情報の公開の原則と， 個人情報の保護について，ICANNを中心に検討が進められている． この検討の状況をみながら， インターネット運用管理とユーザの個人情報の保護の双方の立場を満たす， 情報管理の方針を策定し，運用する必要がある．
顧客情報
登録者を認証するためのパスワード等の情報， 課金のための，銀行口座番
号やクレジットカード番号など， 公開する必要のない情報については， それを必要とする事業者内の担当者にだけアクセスを制限するといった 適切
な機密管理が必要である． さらに，外部から不用意に情報がアクセスされないような， システムのセキュリティ対策が必要である．

76

ENUM研究グループ報告書

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研究グループ報告書

77

7.3 セキュリティ対策
ENUMサービスはDNSをベースとするサービスである． したがって，ENUM
サービスのセキュリティを検討するにあたって， ENUM固有の課題， DNSに起因する課題， ENUMを含むコミュニケーションサービスに関する課題， イ
ンターネット上のネットワークシステムに起因する課題に， 区分して検討する必要がある．
これらの区分ごとに，対応方針，対策・調整を行うコミュニティが違うので，
この区分は重要である．
また，ENUMユーザに対して，リスクを事前の説明を行う必要がある． このリスクが高いサービスに関しては， 事前に説明し確認したユーザに，サービスを限定する必要がある．
ENUM固有の課題- 登録申請者の成りすまし- 登録データの改ざん，不適切な情報の登録- 網羅的検索- 登録システムへのDOS(サービス不能攻撃)
DNSに起因する課題- DNSクエリの傍聴とDNSレスポンスの改ざん・偽造- DNSサーバの成りすまし- ゾーン転送のエラー，ゾーンファイルの改ざん- キャッシュサーバの内容の偽造- DNSサーバへのDOS(サービス不能攻撃)
ENUMを含むコミュニケーションサービスに関する課題- 通信の傍受，改ざん- 成りすまし(発信者認証，発信者通知)

78

ENUM研究グループ報告書- 着信者認証- 迷惑メール，スパムメール- 輻輳対策- 通信相手，サーバへのDOS(サービス不能攻撃)
インターネット上のネットワークシステムに起因する課題- システム侵入と破壊，情報流出- 災害時対策

ENUM研究グループ報告書

797.3.1 ENUM固有の課題
登録申請者の成りすまし
登録者に成りすまして，ENUM 情報を登録したり，更新，抹消する行為である． これを防ぐには，登録者の認証，更新データの正当性のチェックを適切に おこなう必要がある．
また，このような事故が発生した場合，事故前の正しい状態にもどすための システム対応も重要である．
登録データの改ざん，不適切な情報の登録
本来，登録できない NAPTRレコードを登録したり，URIを登録する． 登
録者が本来登録できない他人のアドレスを登録するなど．
網羅的検索
ENUMの名前空間が 連続した番号のため，悪意な網羅的検索は頻発する可能性が高い． しかし， 現在のDNS技術では， DNSの網羅的検索は対応は困難である．
インターネット電話サービスでは，料金が定額であるケースがあることから 電子メールにおけるスパムメールのような，スパム電話のような， 迷惑電話が多発することが予想させる．
網羅的検索で，NAPTRに含まれるメールアドレスのリストも容易に 入手できてしまう．
WHOISについては，利用者を限定させる，アクセス容量規制を おこなうなどの対策が考えられるが本質的解決にはならない．
DNS，WHOISによって インターネット上に公開された情報はENUMサー
ビスにおいて網羅的な 検索が行われることを前提に，サービスを構築す

80

ENUM研究グループ報告書

る必要がある． インターネット電話の場合， SIPの発信者認証やアクセ
スコントロールの適切な運用が必要である．
登録システムへのDOS(サービス不能攻撃)
一般のインターネットサービスノードと同様に， DOSを受ける可能性がある． 登録システムは，DNSに比べてタイムクリティカルでないので，
通常のシステムのDOS検出および対策を行えばよい．

7.3.2 DNSに起因する課題
DNSサーバに対するセキュリティ問題は広くしられており， その対策として DNSSEC，TSIG などの技術開発が行われている． しかし，抜本的な解決は行われておらず， 運用によって問題の顕在化を防いでいるのが現状である． ENUMサービスを構築する際も，DNSの運用ノウハウを十分に理解したうえで， システムの構築・運用を行い， さらに，DNSSEC，TSIG等の技術開発を推進する必要がある．
以下，簡単に，DNSのセキュリティ上の課題を列挙する:

DNSクエリの傍聴とDNSレスポンスの改ざん・偽造
DNSクライアントとサーバの通信路を傍受し， クエリIDを入手し，このIDを用いて偽のレスポンスを返す．
DNSサーバの成りすまし
クライアントに偽のDNSサーバを設定させる．
ゾーン転送のエラー，ゾーンファイルの改ざん
プライマリサーバとセカンダリサーバの間のゾーンファイルの 転送を妨
害または改ざんする．

ENUM研究グループ報告書

81

キャッシュサーバの内容の偽造
キャッシュサーバに特殊なクエリを発し，キャッシュサーバの 内容を改ざんする． いわゆる 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 やユーザ組織のキャッシュサーバからの問い合わせのため， 各
ユーザの通信相手を特定するのは難しい．
しかし，ログについては適切な管理が必要である．

82

ENUM研究グループ報告書

成りすまし(発信者認証，発信者通知)
発信者のアドレス，電話 番号等を偽る，成りすましは， 適切な対策をとらなければ技術的に容易である．
通信の傍受，改ざんと同様である．
着信者認証
通信の傍受，改ざんと同様である．
迷惑メール，スパムメール
ENUMでは電話番号をキーにメールアドレスが知られてしまうため、迷惑メー ルが発生する可能性が考えられる。また網羅的検索の結果として、
スパム メールにつながる可能性も考えられる.
相手認証やアクセスコントロールは， この問題の現実的レベルで有効な手段である． サービスを構築する際には，このことを十分に配慮したう
えで， 相手認証やアクセスコントロール機能をユーザに提供する必要がある．
通信相手，サーバへのDOS(サービス不能攻撃)
通信を行う相手のサーバや端末，大量のパケット発信などによる DOS
は， サービス提供者やISPによる監視と適切な対応が必要となる．

7.3.4 インターネット上のネットワークシステムに起因する課題
ENUMサービスも一般的な インターネット上のネットワークシステムの持つシステム上の 課題をもつ．以下に代表的な例をあげる．
システム侵入と破壊，情報流出

ENUM研究グループ報告書

83

システムの脆弱性を狙った，システム侵入，破壊の可能性は常にある．
また，侵入後，非公開の登録データをアクセスしたり，改ざんする 可能性もある．
セキュリティポリシの設定と，ネットワークアクセスの制限， 脆弱性対策，監視体制など， 一般的なセキュリティ対策を十分にとる必要がある．
災害時対策
災害時のシステム破壊などを想定した， バックアップシステム等の体制が必要である．

84

ENUM研究グループ報告書

7.4 可用性の維持
ENUMサービスの可用性(availability)の維持が必要． ただし，登録変更サービ
スとDNSサービスでは，その要件は大きく異なる． パラメータは以下の通り:• 性能(レスポンスタイム)• 故障率• 災害時の対応• 輻輳の対策，DOS(サービス不能攻撃)の対応
サービスレベル(サービス品質)として各種パラメータを規定し，対策を実施す
る 必要がある．
ユーザENUMサービスにおいては，基本的には， インターネット上のサービスの一部なので， そのサービスレベルは従来のインターネット上のDNSサー
ビスの サービスレベルと同じ 考え方で設定し，実施すれば良い．
オペレータENUMサービスでは，そのサービス内容が， 通常のインターネッ
トサービスより上のサービスレベルを 設定する場合は，DNSサーバ(セカンダ
リサーバ，キャッシュサーバ)の 増設等の対策が必要となる．

ENUM研究グループ報告書

85

7.5 DNSの信頼性
DNSサービスの信頼性を向上させる手段として，DNSセカンダリサーバの設置がある． 特定のDNSゾーンを管理するDNSサーバを複数台配置する方法である． マスターデータを管理するサーバをプライマリサーバ， そのコピーをもつサーバをセカンダリサーバと呼ぶ．
レジストリデータの内容が更新されたとき， その内容をプライマリサーバに伝達する． プライマリサーバは変更があったことを，各セカンダリサーバに通知する． セカンダリサーバは，プライマリサーバに対してゾーン情報の転送要求をおこない その内容を更新し， プライマリサーバとセカンダリサーバ
間の情報を一致させる．
DNSのプロトコルの制約から，セカンダリサーバは 10台程度が上限である．
エニキャスト技術により，その台数を増やすことが可能であるが， 専用のIP
アドレス，AS番号の割り当てが必要である．

86

ENUM研究グループ報告書

8. 最後に2002年9月11日のグループ発足以来，ENUM 研究グループでは， ENUM 技術の理解を深めることを目的とし， ほぼ 1ヶ月に一度のペースでの研究会を行い，さらに分科会を開催し， ユーザENUM・オペレータENUM という形にENUM サービスを類型化し，検討を重ねてきた． また，制度面については，
総務省に設けた「電気通信番号に関する研究会」， 「ENUM 検討小グループ」と連係しながら検討を進めてきた． 検討の結果，ENUMに対する理解も高まり，多くの課題が明確になった．
ENUM はE.164 番号をドメイン名としてDNS に登録する技術として， IETF，
ITU-T等で国際的な標準化作業が進んできたが， 国内的には総務省「IPネット
ワーク技術に関する研究会」において IP電話の実装手段として紹介されたのを契機に幅広く注目を集めることとなった． 本研究グループも， この考え方をベースにスタートした． これは，本研究グループで定義するオペレータ
ENUMの範疇に入るアプリケーションである．
現在，IP 電話サービスの整備が進んでいるが， その相互接続方法について
は，IP電話事業者同士が連携して， もしくは単独で事業者間並びに固定網との相互接続の方法の検討を進めており， 現段階では，ENUMそのものに対する強いニーズが生まれているとは言いがたい状況である． 自ら登録するユー
ザENUMについても，そのニーズは必ずしも顕在化している とは言えない．
しかし，事業者同士のよりオープンなインターフェースによる相互接続の要求， インターネット電話の普及，E.164番号による電話以外のアプリケーショ
ン識別への 要求が高まることによって， また，海外のENUMの状況によっては， このENUM技術へのニーズが急速に高まってくることが考えられる．
ENUM技術をサービスとして構築・運用するには技術面，制度面，ビジネス面
での 多くの課題を解決する必要があり， これらの面から継続して検討していく必要がある．

ENUM研究グループ報告書

87

Appendix A. 電気通信番号
A.1 日本における番号計画
日本では，電気通信番号は，「電気通信事業法」に基づき， 総務省によって管理されており， その具体的な管理は「電気通信番号規則」によって定められている．
電気通信番号は，電気通信事業者に対して電気通信役務の提供のために 割り当てられる． 電気通信番号は番号の範囲によって，割り当て対象となる事業
種別， 識別の対象が規定されている．
主な電気通信番号としては次のようなものがある．

0ABCDEFGHJ- 固定端末系伝送路設備を識別するための電気通信番号．
- FGHJ を単位として事業者に割り当てられ，ABCDE にて事業者識別される．
- 通常，0AB-J番号と称される．

050CDEFGHJK- パケット交換網に接続される端末設備等に提供される音声伝送役務を識別するため の電気通信番号． ただし，総務大臣が特に必要と認めるときは，0AB-J番号が割り当てられる．
- GHJKを単位として事業者に割り当てられ，CDEFにて事業者識別される．
- IP電話(広義)での利用を目的とした番号である．
- 割り当てにあたっては一定の通信品質・信頼性の確保が必要とされる．

070CDEFGHJK- PHSに係る端末系伝送路設備を識別するための電気通信番号．
- GHJKを単位として事業者に割り当てられ，CDEFにて事業者識別される．

88

ENUM研究グループ報告書

080CDEFGHJK
090CDEFGHJK- 携帯電話に係る端末系伝送路設備を識別するための電気通信番号- FGHJKを単位として事業者に割り当てられ，CDEにて事業者識別される
そのほか，フリーフォン・着信課金サービス（0120DEFGHJ），分担課金 サービス（0570DEFGHJ）などの電気通信番号がある．
詳細は電気通信番号規則等を参照のこと．

A.2 電話番号の管理権限
電話番号（電気通信番号）は，対象となる設備を保有する電気通信事業者，
もしくは対象となる役務を提供する電気通信事業者に対し総務省から割り当てられ， 電気通信事業者により管理されている． 一方，ユーザENUMにおいては，NAPTRレコードにおける電話番号とURIとの関連付けは ユーザの意思に基づいて行われるため， 関連付けられたURIへの到達可否等の管理について
は， ユーザに委ねられるとの考えもある．
何れの場合においても，電話番号について管理が必要な案件については，
ENUMにおいても考慮が必要である．（例：番号逼迫等の理由による電話番号の変更など）

A.3 電気通信番号の他目的使用について
既存の電気通信番号を利用して「本来識別する役務や設備」以外の役務や ア
プリケーションを対応づけることに関して，制度面の整理が必要と思われる．
本来，その電気通信番号の割り当てを受けた事業者のサービスに影響を与 える可能性があるので，登録できる番号帯域に制限を設けたり，登録内容 について事業者が何らかの制限(登録方針)を設けることについて，その可 否も含めて検討が必要である．

ENUM研究グループ報告書

89☞ 割り当てを受けた事業者と登録するユーザの役割/責任/管理権限の明確化

A.4 ENUMのための電気通信番号の割り当てについて
ユーザENUMを展開した場合の，主にENUMのレコードを識別するための 電
気通信番号の割り当てについて検討を行う必要がある．
電気通信番号の逼迫のなか，安易な割り当ては出来ないが，音声役務，電 話
設備の識別を主眼とする，電気通信番号の割り当てについて，識別対象， 割り当ての管理運営制度について，再検討する必要がある．
上記のユーザENUMのレコードに用いられる電気通信番号の割り当ての検討が 不十分な段階において，技術的な検証等の目的により， ENUMの実験が必要と思われる状況においては，既存の電気通信番号に影響を与えない， 実験用の電気通信番号を付与する案も考えられる．
実験用の電気通信番号の割り当てができない場合には， 実験参加者に割り当てられた，既存の 電話番号のみを利用することになり，実験が限定されることも考えられる．

A.5 特番の扱い
ENUM における 110，118，119 のような緊急通報に関するいわゆる特番の扱いについて， 検討が必要である．ここでは，その解題を列挙するにとどめる．
インターネット電話で緊急通報の特番を考える場合，次の点に注目する必要がある:a) 国際的な名前空間での特番の扱いb) 発信者の位置に依存した名前解決の仕組み
c) 接続時の各種機能
緊急通報用の特番は国毎に決めるため，国際的には統一されていない． 例え

90

ENUM研究グループ報告書

ば，警察への通報は日本では 110 であるが，米国では 911 である． ENUMサービスはDNSを用いている．DNSはグローバルな名前空間を管理し， クエリの位置によらず同じ答えを返すため， 特番のような，発信者の国に依存した
名前管理は難しい．
さらに，特番は E.164 の番号体系ではないため， ENUM ツリー下の空間に
ENUMに緊急通信用の電話番号をどのように表現するか決める必要がある．
たとえば，0.1.1.1.8.e164.arpa. 導入するにしても，十分な検討が 必要である．
また，緊急通報は，その発信者の位置等に基づいた接続など各種機能が要求される． これらの機能について，ENUMだけを用いて実現することは難しい．

ENUM研究グループ報告書

ENUM研究グループ会員一覧
会員 (五十音順 敬称略)
• 一井 信吾• インターネットフォーラム• (株)インフォセック• NTT コミュニケーションズ(株)• 沖電気工業(株)• KDDI(株)• 後藤 滋樹• JENS(株)• (社)情報通信技術委員会• (社)テレコムサービス協会• (株)パワードコム• 日商エレクトロニクス(株)• ニフティ(株)• 日本サイバースペース(株)• 日本テレコム(株)• 日本電気(株)• 日本電信電話(株)• (社)日本ネットワークインフォメーションセンター• (株)日本レジストリサービス• ネットワンシステムズ(株)• フュージョン・コミュニケーションズ(株)• 富士通(株)• 三菱商事(株)91

92

ENUM研究グループ報告書

オブザーバ• 総務省 総合通信基盤局電気通信事業部電気通信技術システム課

事務局• (社)日本ネットワークインフォメーションセンター

ENUM研究グループ報告書

93(blank)