ENUM -- Telephone Number Mapping M. Haberler
Working Group IPA
Internet-Draft R. Stastny
Expires: December 25, 2006 Oefeg
June 23, 2006
Combined User and Infrastructure ENUM in the e164.arpa tree
draft-haberler-carrier-enum-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 25, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo defines an interim solution for Infrastructure ENUM to
allow a combined User and Infrastructure ENUM implementation in
e164.arpa as a national choice until the long-term solution is
approved. This interim solution will be deprecated after deployment
of the long-term solution.
Haberler & Stastny Expires December 25, 2006 [Page 1]
Internet-Draft Combined User and Infrastructure ENUM June 2006
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Interim Solution . . . . . . . . . . . . . . . . . . . . . . . 3
4. Introducing a branch into the 164.arpa tree . . . . . . . . . 4
5. Defining the Infrastructure ENUM branch location . . . . . . . 4
6. Finding the ENUM branch location record . . . . . . . . . . . 5
7. Recommended resolver behaviour . . . . . . . . . . . . . . . . 6
8. Security considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Interoperability considerations . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Haberler & Stastny Expires December 25, 2006 [Page 2]
Internet-Draft Combined User and Infrastructure ENUM June 2006
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC2119 [1].
Note: The ENUM WG decided at IETF#64 to prefer the term
Infrastructure ENUM. Therefore, this document uses the term
Infrastructure ENUM as synonymous to Carrier ENUM.
2. Introduction
ENUM (E.164 Number Mapping, RFC 3761 [2]) is a system that transforms
E.164 numbers [3] into domain names and then uses DNS (Domain Name
Service) [6] services like delegation through NS records and NAPTR
(Naming Authority Pointer) records [4] to look up which services are
available for a specific domain name.
ENUM as defined in RFC3761 (User-ENUM) is not well suited for the
purpose of interconnection by carriers, as can be seen by the use of
various private tree arrangements based on ENUM mechanisms.
Infrastructure ENUM is defined as the use of the technology in
RFC3761 [2] by the carrier-of-record [8] (Voice service provider) for
a specific E.164 [3] number to map a telephone number into an URI [5]
that identifies a specific point of interconnection to that service
provider's network that could enable the originating party to
establish communication with the associated terminating party. It is
separate from any URIs that the end-user who registers his E.164
number in ENUM may wish to associate with that E.164 number.
The requirements, terms and definitions for Infrastructure ENUM are
defined in [8].
Using the same E.164 number to domain mapping technique for other
applications under a different, internationally agreed apex (instead
of e164.arpa) is straightforward on the technical side. Establishing
the international agreements necessary to delegate the country-code
level subdomains under the new apex is non-trivial and time-
consuming. This process of defining the Dynamic Delegation Discovery
System DDDS [4] application for Infrastructure ENUM in "ie164.arpa"
is under way [9]. This is called the "proper" long term solution.
3. Interim Solution
As stated above, the agreements to establish the long-term solution
Haberler & Stastny Expires December 25, 2006 [Page 3]
Internet-Draft Combined User and Infrastructure ENUM June 2006
may take some time. It was therefore decided to develop an interim
solution that can be used by individual countries to implement an
interoperable Infrastructure ENUM tree immediately. The Interim
solution will be deprecated upon approval (loosely timed) of the
"proper" long-term solution.
Is is therefore also required that the Interim solution is compatible
with the "right" long-term solution to allow for easy migration.
4. Introducing a branch into the 164.arpa tree
A convention is needed how, given a fully qualified E.164 [3] number,
a resolver can determine the location of the Infrastructure ENUM
subdomain for this country. Under this approach, ITU-T and IETF
(IAB) involvement is only lightweight, e.g. to recommend the proper
algorithm defined here to enable international interoperability.
This allows to introduce the Interim solution as a national matter by
the concerned NRA or as a regional opt-in within in a given Numbering
Plan Area such as the North American NPA.
Beyond the setup phase, an NRA need not be involved operationally -
it is sufficient to establish a convention linking the national
definition of a carrier of record to the credentials for write access
to the Infrastructure ENUM tree.
The method most easily fulfilling the above mentioned requirements is
to branch off the e164.arpa tree into a subdomain at or somewhere
below the country code delegation level below e164.arpa, and deploy
an Infrastructure ENUM subtree underneath without touching User ENUM
semantics at all.
5. Defining the Infrastructure ENUM branch location
The decision where to place the Infrastructure ENUM tree below
e164.arpa is a national or group-of-countries decision. To branch
off the e164.arpa tree for a given country code, a DNS label is
inserted at a specific position into the ENUM fully qualified domain
name (FQDN).
For international interoperability, an Infrastructure ENUM resolver
needs to determine for a given country code
1. the name of the label to be inserted
Haberler & Stastny Expires December 25, 2006 [Page 4]
Internet-Draft Combined User and Infrastructure ENUM June 2006
2. the position where to insert the label in an Infrastructure ENUM
domain name for a given country code
3. a convention how to discover these parameters.
We propose a mechanism to discover these parameters dynamically for
any given tree shape as follows:
o the national or group-of-countries decision about subdomain
location is documented in the e164.arpa tree proper by inserting a
special DNS resource record at the country code level, called ENUM
Branch Location Record (EBL) [7], into a subdomain in the country
code zone. In case of the Infrastructure ENUM application, this
subdomain name will be "infrastructure". This ENUM Branch
Location Record carries three values for maximum flexibility:
o
1. the branching label to be inserted into the ENUM domain to
branch off to the application-specific tree. This may be an
empty (zero-length) string.
2. an insertion position, indicating after which digit this label
should be inserted into the ENUM domain to branch off to the
application-specific tree. A value of 0 means "after all
digits".
3. an apex: indicating what domain should replace "e164.arpa" for
this application.
o a resolver looking for an Infrastructure ENUM domain needs to
retrieve this EBL once during first resolution within a country
code.
o while constructing the FQDN, the branching label as retrieved from
the EBL resource record is inserted at the insertion position
(also as per EBL) and finally the apex is appended. Labels,
digits and apex are separated by dots as usual. A zero-length
branching label is not inserted at all.
6. Finding the ENUM branch location record
The only remaining a-priori knowledge a Infrastructure ENUM resolver
should have is the current list of country codes, or an equivalent
method to determine where the country code in the number ends.
To prime the country code extraction algorithm, the current scheme to
determine country code length as follows could be employed:
o 3 digits is the default length of a country code.
o country codes 1 and 7 are a single digit.
Haberler & Stastny Expires December 25, 2006 [Page 5]
Internet-Draft Combined User and Infrastructure ENUM June 2006
o the following country codes are two digits: 20, 27, 30-34, 36, 39,
40, 41, 43-49, 51-58, 60-66, 81, 82, 84, 86, 90-95, 98.
Figure 1
Given the fact that the ITU recently allocated only 3-digit country
codes, there are no more spare 1- and 2-digit country codes and
existing 1- and 2-digit country codes are extremely unlikely to be
recovered, the above table consisting of the existing 1- and 2-digit
country codes can be considered very stable. The only problem may be
a country split as happened recently e.g. to Yugoslavia.
If a branch location record is not found according to this table (for
instance, in the unlikely case the ITU allocates a country code not
according to these rules), it is still possible to determine the
branch location record by "iterating down" the tree digit-by-digit.
Such a fallback strategy would rely on the assumption that there is
never a branch location record inserted above the country code zone,
for which there would be no use in the first place.
It seems unlikely that inspection of more than the first five digits
will be required to locate the branch location record under any
realistic numbering administrative partitioning.
7. Recommended resolver behaviour
A User ENUM resolver as per RFC 3761 need not be aware of any
Infrastructure ENUM conventions at all. A combined User and
Infrastructure ENUM resolver shall behave as follows:
The input to the resolver routine shall be:
1. the called number in fully qualified E.164 (international)
format,
2. a mode parameter indicating wether resolution should follow User
ENUM or Infrastructure ENUM rules (for instance, a null value for
defaulting to User ENUM, or 'infrastructure' for Infrastructure
ENUM semantics).
3. optionally a table or algorithm to easily detect country codes
(Section 6),
4. any other parameters used to drive the search, for instance an
enumservice type. These parameters are outside the scope of this
draft.
The resolver shall proceed as follows:
o if the mode parameter indicates a User ENUM search, proceed as per
RFC3761.
Haberler & Stastny Expires December 25, 2006 [Page 6]
Internet-Draft Combined User and Infrastructure ENUM June 2006
o If the mode parameter indicates an Infrastructure ENUM query:
* determine country code length.
* consult table if an EBL record for this country code was
already retrieved since resolver boot time.
* if not:
retrieve the EBL record from the 'infrastructure' subdomain
of the country code zone, and store the country code and
associated EBL values in an EBL table.
optional fallback for irregular country code not covered by
the CC extraction algorithm: (Figure 1) if the last step
fails, iterate over the number up to five digits and try to
retrieve the EBL record in the 'infrastructure' subdomain
each time, again storing the country code and associated EBL
values in the cache if successful.
if both attempts fail, return NXDOMAIN.
* valid EBL record found: if the branching label is non-zero
length, insert it at the insertion position in the FQDN and add
a trailing dot, add the remaining digits and dots, and append
the apex.
* search the DNS for any ENUM NAPTR records for the resulting
domain name.
It is assumed that already discovered EBL values are stored in a
cache table of country code and already discovered EBL parameters.
8. Security considerations
Privacy issues have been raised regarding unwarranted disclosure of
user information by publishing Infrastructure ENUM information in the
public DNS, for instance the use for harvesting of numbers in
service, or unlisted numbers.
Given that number range allocation is public information, we believe
the easiest way to cope with such concerns is to fully unroll
allocated number ranges in the Infrastructure ENUM subtree, wherever
such privacy concerns exist. Whether a number is served or not would
be exposed by the carrier of record when an attempt is made to
contact the corresponding URI. We assume this to be an authenticated
operation, which would not leak information to unauthorized parties.
Entering all numbers in an allocated number range, whether serviced
or not, or listed or unlisted, will prevent mining attempts for such
number attributes.
The result would be that the information in the public DNS would
mirror number range allocation information, but not more.
Infrastructure ENUM will not tell you more than you can get by just
Haberler & Stastny Expires December 25, 2006 [Page 7]
Internet-Draft Combined User and Infrastructure ENUM June 2006
dialing numbers.
The URI pointing to the destination network of the Carrier of Record
should also not disclose any privacy information about the identity
of end-user, it is therefore recommended to use in the user-part of
the SIP URI either anonymized UserIDs or the E.164 number itself,
such as sip:441632960084@example.com .
The definition of a new resource record (RR) type or a new
enumservice does not introduce security problems into the DNS. Usage
of the Branch Location record conveys only static setup information
under a country code subtree of e164.arpa. The intended use of DNS
Security Extensions (DNSSEC) within ENUM will prove authenticity of
the conveyed value.
9. IANA considerations
None
10. Interoperability considerations
An application using the combined resolver needs to indicate which
information is requested - User or Infrastructure ENUM, or both. A
user-ENUM-only resolver need not be aware of the Infrastructure ENUM
subtree and no changes with respect to RFC3761 semantics are
required. A resolver desiring to retrieve Infrastructure ENUM or
both types of records needs to be aware of the conventions laid out
in this draft.
When the "proper" long-term solution is adopted, each country using
the interim solution may decide on its own when to migrate to the
long-term solution. The EBL records for this country would then be
changed to the values "insertion position=0", "branching label=''"
and "apex=ie164.arpa". When finally all countries have migrated, the
EBL records may be removed.
11. Acknowledgements
We gratefully acknowledge suggestions and improvements by Jason
Livingood and Tom Creighton of Comcast, Penn Pfautz of ATT, Lawrence
Conroy of Roke Manor Research, and Alexander Mayrhofer and Otmar
Lendl of enum.at.
12. References
Haberler & Stastny Expires December 25, 2006 [Page 8]
Internet-Draft Combined User and Infrastructure ENUM June 2006
12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[3] ITU-T, "The International Public Telecommunication Number Plan",
Recommendation E.164, May 1997.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[6] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[7] Lendl, O., "The ENUM Branch Location Record",
draft-lendl-enum-branch-location-record-01 (work in progress),
May 2006.
12.2. Informative References
[8] Lind, S. and P. Pfautz, "Infrastrucure ENUM Requirements",
draft-ietf-enum-infrastructure-enum-reqs-02 (work in progress),
April 2006.
[9] Livingood, J., "The E.164 to Uniform Resource Identifiers (URI)
Dynamic Delegation Discovery System (DDDS) Application for
Infrastructure ENUM", draft-ietf-enum-infrastructure-00 (work in
progress), April 2006.
Haberler & Stastny Expires December 25, 2006 [Page 9]
Internet-Draft Combined User and Infrastructure ENUM June 2006
Authors' Addresses
Michael Haberler
Internet Foundation Austria
Waehringerstrasse 3/19
Wien A-1090
Austria
Phone: +43 664 4213465
Email: mah@inode.at
URI: http://www.nic.at/ipa/
Richard Stastny
Oefeg
Postbox 147
Vienna A-1030
Austria
Phone: +43 664 420 4100
Email: richard.stastny@oefeg.at
URI: http://www.oefeg.at
Haberler & Stastny Expires December 25, 2006 [Page 10]
Internet-Draft Combined User and Infrastructure ENUM June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Haberler & Stastny Expires December 25, 2006 [Page 11]