ENUM -- Telephone Number Mapping M. Haberler
Working Group IPA
Internet-Draft O. Lendl
Intended status: Informational enum.at
Expires: April 24, 2008 R. Stastny
Oefeg
October 22, 2007
Combined User and Infrastructure ENUM in the e164.arpa tree
draft-ietf-enum-combined-08
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 April 24, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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. This interim solution will be
deprecated after approval and implementation of the long-term
solution.
Haberler, et al. Expires April 24, 2008 [Page 1]
Internet-Draft Combined User and Infrastructure ENUM October 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Interim Solution . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Determing the Position of the Branch . . . . . . . . . . . . . 5
6. Transition to the long-term Solution . . . . . . . . . . . . . 7
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Haberler, et al. Expires April 24, 2008 [Page 2]
Internet-Draft Combined User and Infrastructure ENUM October 2007
1. Introduction
ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that transforms
E.164 numbers [2] into domain names and then queries the DNS (Domain
Name Service) [3] for NAPTR (Naming Authority Pointer) records [4] to
look up which services are available for a specific domain name.
ENUM as defined in RFC 3761 (User-ENUM) is not well suited for the
purpose of interconnection by carriers and voice service providers,
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 RFC
3761 [1] by the carrier-of-record [8] (voice service provider) for a
specific E.164 number [2] to publish a mapping of this telephone
number to one or more Uniform Resource Identifiers (URIs) [5].
Other voice service providers can query the DNS for this mapping and
use the resulting URIs as input into their call routing algorithm.
These URIs are 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 techniques for other
applications under a different, internationally agreed apex (instead
of e164.arpa) is straightforward on the technical side. This process
of defining the Dynamic Delegation Discovery System (DDDS) [4]
application for Infrastructure ENUM is work in progress [9]. This is
called the long term solution.
This document presents an interim solution for Infrastructure ENUM
and a mechanism for transitioning to a long-term solution. The
interim solution is based on establishing a branch in the e164.arpa
tree, which resolvers may locate by following the algorithm described
in Section 4. The location of the branch is dependent upon country
code length, and thus resolvers must determine the position of the
branch based on the method described in Section 5. Finally,
Section 6 provides a way that implementations following the
procedures of Section 4 and 5 may be seamlessly redirected to the
long-term solution, when it becomes available.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Haberler, et al. Expires April 24, 2008 [Page 3]
Internet-Draft Combined User and Infrastructure ENUM October 2007
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [6].
3. Interim Solution
The agreements to establish the long-term solution 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 when the long-term solution becomes available. It is
therefore also required that the Interim Solution includes a smooth
migration path to the long-term solution.
It is also required that existing ENUM clients querying User ENUM as
defined in RFC 3761 [1] continue to work without any modification.
Because of various reasons (e.g. potentially different delegation
points, different reliability requirements, use of DNS wildcards),
sharing a single domain name between the user itself and the
respective carrier for a number is not possible. Hence, a different
domain name must be used to store infrastructure ENUM information.
In order to avoid the delays associated with the long term solution,
the existing delegations and agreements around e164.arpa need to be
leveraged.
The method most easily fulfilling the requirements is to branch off
the e164.arpa tree into a subdomain at the country code delegation
level below e164.arpa, and deploy an Infrastructure ENUM subtree
underneath without touching User ENUM semantics at all.
This allows countries using a dedicated country code to introduce the
Interim Solution as a national matter by the concerned National
Regulation Authority (NRA). The governing body of a shared country
code and the owner of a global network code can also chose to
implement this solution within their area of responsibility.
Under this approach, ITU-T (International Telecommunication Union /
Telecommunication Standardization Sector) and IETF (IAB) involvement
is only lightweight, e.g. to recommend the proper algorithm defined
here to enable international interoperability.
4. The Algorithm
RFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS)
application according to RFC 3401 [4]. As such, ENUM defines the
Haberler, et al. Expires April 24, 2008 [Page 4]
Internet-Draft Combined User and Infrastructure ENUM October 2007
following components of the DDDS algorithm:
1. Application Unique String
2. First Well Known Rule
3. Expected Output
4. Valid Databases
The "Valid Databases" part contains the transformation of a E.164
telephone number into a domain name. Section 2.4 of RFC 3761 uses
the following four step algorithm for this:
1. Remove all characters with the exception of the digits.
2. Put dots (".") between each digit.
3. Reverse the order of the digits.
4. Append the string ".e164.arpa" to the end.
The Interim Solution for Infrastructure ENUM uses a modified version
of this algorithm:
1. Determine the proper POSITION parameter for this E.164 number
according to the algorithm in Section 5.
2. Build an ordered list of single-digit strings from all digits
appearing in the telephone number. All non-digit characters are
ignored.
3. Insert a string consisting of "i" after POSITION strings into
this list. If the list of strings was shorter than POSITION
elements, then report an error.
4. Reverse the order of the list.
5. Append the string "e164.arpa" to the end of the list.
6. Create a single domain-name by joining the list together with
dots (".") between each string.
This is the only point where the interim Infrastructure ENUM solution
differs from straight RFC 3761 ENUM. All other parts of User-ENUM,
including the enumservices registrations, apply to I-ENUM as well.
5. Determing the Position of the Branch
In order to allow for the deployment of this Interim Solution
independently of IAB/ITU-T/RIPE-NCC negotiations the branching label
"i" cannot be inserted in the Tier-0 zone (i.e. the e164.arpa zone
itself) managed currently by RIPE NCC. This condition acts as a
Haberler, et al. Expires April 24, 2008 [Page 5]
Internet-Draft Combined User and Infrastructure ENUM October 2007
lower bound on the choice of the POSITION parameter.
For international E.164-numbers for geographic areas ([2] 6.2.1) and
for international E.164-numbers for global services ([2] 6.2.2) the
most sensible choice for POSITION is number of digits in the country
code of the number in question. This places the branch directly
under the country code level within the e164.arpa ENUM tree.
For international E.164-number for networks ([2] 6.2.3) the
appropriate choice for POSITION is the combined length of the CC
(Country Code) and IC (Identification Code) fields.
For international E.164-number for groups of countries ([2] 6.2.4)
the value for POSITION is 4.
The authoritative source for up-to-date country code and network
Identity Code allocations is a published by ITU-T as a complement to
the recommendation E.164 [2]. The current version of this complement
is available from ITU website under "ITU-T / Service Publications".
Please note that country code 1 of the North American Numbering Plan
(NANP) does not fall under the ITU classification of "groups of
countries", but is a "shared country code" for a geographic area.
The POSITION parameter for the NANP is thus 1.
As of 2007, the POSITION value for a specific E.164 number can be
determined with the following algorithm:
o If the number starts with 1 or 7 then POSITION is 1
o If the number is in one of the following 2-digit country codes:
20, 27, 30-34, 36, 39, 40, 41, 43-49, 51-58, 60-66, 81, 82, 84,
86, 90-95, or 98, then POSITION is 2.
o If the number starts with 388 or 881, then POSITION is 4
o If the number starts with 878 or 882, then POSITION is 5
o If the number starts with 883 and the next digit is < 5, then
POSITION is 6
o If the number starts with 883 and the next digit is >= 5, then
POSITION is 7
o In all other cases, POSITION is 3.
Figure 1
Given the fact that the ITU-T 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 list of existing 1- and 2-digit country codes
can be considered very stable. The only problem may be a country
Haberler, et al. Expires April 24, 2008 [Page 6]
Internet-Draft Combined User and Infrastructure ENUM October 2007
split as happened recently e.g. to Yugoslavia.
Regarding network codes, the ITU-T has up to 2007 only allocated one
and two digit ICs. Assignments of three and four digit ICs started
in May 2007 in the +883 country code. A further change in the ITU-T
policy in this respect will need to be reflected in the above
algorithm.
6. Transition to the long-term Solution
The proposed long-term solution for Infrastructure ENUM [9] is the
establishment of a new zone apex for that tree. This apex will play
the same role as "e164.arpa" does for User-ENUM.
It is unrealistic to assume that all countries and all ENUM clients
will manage to migrate from the Interim Solution to the long-term
solution at single point in time. It is thus necessary to plan for
an incremental transition.
In order to achieve this, clients using the interim solution need to
be redirected to the long-term I-ENUM tree for all country codes
which have already switched to the long-term solution. This SHOULD
be done by placing DNAME [7] records at the branch (the "i") label
pointing to the appropriate domain name in the long-term I-ENUM tree.
All descendants at that branch label location where the DNAME record
is inserted MUST be removed as required by Section 3 of RFC 2672.
Therefore ALL entities involved in making or answering DNS queries
for I-ENUM MUST fully support the DNAME record type and its
semantics. In particular, entities involved in I-ENUM lookups MUST
correctly handle responses containing synthesized CNAMEs that may be
generated as a consequence of DNAME processing by any other element
in resolution, typically an iterative mode resolving name server.
These entities MUST also apply adequate measures to detect loops and
prevent non-terminating resolutions because of improperly configured
DNAME records or combinations of DNAME and CNAME records.
The domain name for the branch location and its DNAME record SHOULD
be removed once the transition to the long-term solution is completed
and all entities involved in I-ENUM have migrated to the new zone
apex for I-ENUM.
7. Examples
These are two examples of how E.164 numbers translate to to
Infrastructure ENUM domains according to the Interim Solution.
Haberler, et al. Expires April 24, 2008 [Page 7]
Internet-Draft Combined User and Infrastructure ENUM October 2007
+1 21255501234 4.3.2.1.0.5.5.5.2.1.2.i.1.e164.arpa
+44 2079460123 3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa
Here is the list of the intermediate steps for the second example to
visualize how the algorithm as defined in Section 4 operates on "+44
2079460123":
1. "+44 2079460123" is within a 2-digit country code, thus POSITION
is 2.
2. The list of strings is
("4","4","2","0","7","9","4","6","0","1","2","3").
3. POSITION is 2, thus "i" is inserted between the second and the
third string, yielding:
("4","4","i","2","0","7","9","4","6","0","1","2","3")
4. Reversing the list gives:
("3","2","1","0","6","4","9","7","0","2","i","4","4")
5. Appending "e164.arpa" yields:
("3","2","1","0","6","4","9","7","0","2","i","4","4","e164.arpa")
6. Concatenation with dots: "3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa"
After the introduction of the long term Infrastructure ENUM solution
using for example "ienum.example.net" as the new apex for I-ENUM, the
administrators of +44 can implement a smooth transition by putting
the following DNAME record in their zone:
i.4.4.e164.arpa. IN DNAME 4.4.ienum.example.net.
This way, clients using the interim I-ENUM solution end up querying
the same tree as clients implementing the long-term solution.
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
Haberler, et al. Expires April 24, 2008 [Page 8]
Internet-Draft Combined User and Infrastructure ENUM October 2007
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
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 either anonymized
UserIDs or the E.164 number itself in the user-part of the URI, such
as in sip:+441632960084@example.com .
9. IANA considerations
None.
10. Acknowledgments
We gratefully acknowledge suggestions and improvements by Jason
Livingood and Tom Creighton of Comcast, Penn Pfautz of ATT, Lawrence
Conroy of Roke Manor Research, Jim Reid, and Alexander Mayrhofer of
enum.at.
11. References
11.1. Normative References
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[2] ITU-T, "The International Public Telecommunication Number Plan",
Recommendation E.164, February 2005.
[3] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
Haberler, et al. Expires April 24, 2008 [Page 9]
Internet-Draft Combined User and Infrastructure ENUM October 2007
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
August 1999.
11.2. Informative References
[8] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements",
draft-ietf-enum-infrastructure-enum-reqs-04 (work in progress),
May 2007.
[9] Livingood, J., "The E.164 to Uniform Resource Identifiers (URI)
Dynamic Delegation Discovery System (DDDS) Application for
Infrastructure ENUM", draft-ietf-enum-infrastructure-06 (work in
progress), July 2007.
Authors' Addresses
Michael Haberler
Internet Foundation Austria
Karlsplatz 1/2/9
Wien 1010
Austria
Phone: +43 664 4213465
Email: mah@inode.at
URI: http://www.nic.at/ipa/
Otmar Lendl
enum.at GmbH
Karlsplatz 1/2/9
Wien A-1010
Austria
Phone: +43 1 5056416 33
Email: otmar.lendl@enum.at
URI: http://www.enum.at/
Haberler, et al. Expires April 24, 2008 [Page 10]
Internet-Draft Combined User and Infrastructure ENUM October 2007
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, et al. Expires April 24, 2008 [Page 11]
Internet-Draft Combined User and Infrastructure ENUM October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Haberler, et al. Expires April 24, 2008 [Page 12]
