WDIFF

draft-ietf-enum-combined-04.txt --> draft-ietf-enum-combined-05.txt

ENUM -- Telephone Number Mapping M. Haberler
Working Group IPA
Internet-Draft R. Stastny
Intended status: Informational Oefeg
Expires: July 28, December 15, 2007 January 24, June 13, 2007

Combined User and Infrastructure ENUM in the e164.arpa tree
draft-ietf-enum-combined-04
draft-ietf-enum-combined-05

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 July 28, December 15, 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 until the long-term solution is
approved. This interim solution will be deprecated after approval of
the long-term solution.

Haberler & Stastny Expires July 28, December 15, 2007 [Page 1]

Internet-Draft Combined User and Infrastructure ENUM January June 2007

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3

3. Interim Solution . . . . . . . . . . . . . . . . . . . . . . . 3

4. Introducing a branch into Leveraging the e164.arpa tree infrastructure . . . . . . . . . . . 4

5. Defining Locating the Infrastructure ENUM branch location . . . Branch . . . . 4

6. Locating the ENUM branch location record . . . . . . . 4

6. Position of the IEBL Record . . . . 5

7. Example for the location of the EBL . . . . . . . . . . . . . 6

8. 5

7. Recommended resolver behaviour . . . . . . . . . . . . . . . . 7

9. 6

8. Security considerations . . . . . . . . . . . . . . . . . . . 8

10. 7

9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9

11. 8

10. Interoperability considerations . . . . . . . . . . . . . . . 9

12. 8

11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9

13.

12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
13.1.
12.1. Normative References . . . . . . . . . . . . . . . . . . 9
13.2.
12.2. Informative References . . . . . . . . . . . . . . . . . 10 9

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12 11

Haberler & Stastny Expires July 28, December 15, 2007 [Page 2]

Internet-Draft Combined User and Infrastructure ENUM January June 2007

1. 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 Name Server (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 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 [2] by the carrier-of-record [8] (Voice service provider) for a
specific E.164 number [3] to map a telephone number into an one or more
Uniform Resource Identifier (URI) Identifiers (URIs) [5]. This URI maps

These URIs will be used to a derive specific point points of interconnection to
into the service provider's network that could enable the originating
party to establish communication with the associated terminating
party. This URI is These URIs are separate from any URIs that the end-
user 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. 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 is work in
progress [9]. This is called the long term solution.

2. 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, RFC 2119 [1].

3. Interim Solution

As stated above, the agreements to establish the long-term solution

Haberler & Stastny Expires December 15, 2007 [Page 3]

Internet-Draft Combined User and Infrastructure ENUM June 2007

may take some time. It was therefore decided to develop an Interim
Solution that can be used by individual countries to implement an

Haberler & Stastny Expires July 28, 2007 [Page 3]

Internet-Draft Combined User and Infrastructure ENUM January 2007
interoperable Infrastructure ENUM tree immediately. The Interim
Solution will be deprecated upon approval (loosely timed) of the
long-term solution. 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 [2] continue to work without any modification.

Because of various reasons, 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.

The method most easily fulfilling this 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.

4. Introducing a branch into Leveraging the e164.arpa tree infrastructure

A convention is needed how, given a fully qualified E.164 number [3],
a resolver can determine the location of the Infrastructure ENUM
subdomain
domain for this country. number. In order to avoid the delays associated with
the long term solution, the existing delegations and agreements
around e164.arpa need to be leveraged for the discovery algorithm.

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 National Regulation Authority (NRA) or as a regional
opt-in within in a given Numbering Plan Area (NPA) 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.

5. Defining Locating the Infrastructure ENUM branch location Branch

[7] specifies an extension to the ENUM DDDS application which adds an
extra mapping step using a DNS resource record (ENUM Branch Location
- EBL) to the E.164 to domain-name translation algorithm. (Infrastructure ENUM

Haberler & Stastny Expires July 28, December 15, 2007 [Page 4]

Internet-Draft Combined User and Infrastructure ENUM January June 2007

Branch Location - IEBL) to the E.164 to domain-name translation
algorithm.

The decision where to place the Infrastructure ENUM tree is a
national or group-of-countries decision. The EBL IEBL affecting the
translation of any E.164 number thus needs to reside under the
e164.arpa tree for the country code of that number.

[7] specifies a DNS resource record (ENUM Branch Location - EBL) and
an algorithm to branch the ENUM DNS tree for specific use-cases with

The IEBL contains the following parameters:
1. the name of EBL use-case,
2. a SEPARATOR,
3.
2. a POSITION,
4.
3. an APEX.

These

Together, these three parameters can be used to describe the tree shape for the
Interim Solution of a
country's Infrastructure ENUM as follows: tree according to the Interim Solution.
These parameters provide enough flexibility to describe setups
ranging from branches under e164.arpa at NPA level, branches at
country-code level, independent trees per country, and also the long-
term solution.

o Existence of the IEBL Record: The national or group-of-countries group-of-country's
decision about the location of to implement the Infrastructure ENUM branch Interim Solution is documented in the
e164.arpa tree by inserting an EBL IEBL resource record into a subdomain at the country
code level.

o The EBL subdomain SEPARATOR: This branching label for the Infrastructure ENUM use-case MUST will be "infrastructure". This EBL carries the above mentioned three
values for maximum flexibility:

1. the branching label (SEPARATOR) to be inserted into inserted into the ENUM
domain to branch off to from the User-ENUM tree into the
Infrastructure ENUM sub-tree. This MAY be an empty (zero-length)
string which means no label will be inserted.
2. an insertion POSITION,

o POSITION: A number indicating after which digit this label
(SEPARATOR) should be inserted. A value of 0 means to the right
of all digits.
3. an APEX

o APEX: A domain name indicating what domain MUST replace replaces "e164.arpa"
for this application. "e164.arpa" MAY also be replaced by itself.

o A resolver looking The IEBL record is extremely well suited for an caching: The layout
of a country's Infrastructure ENUM domain needs to
retrieve this EBL once during first resolution within a country
code. This setup is described in Section 6.

o The construction very static
information, allowing large TTLs on the IEBL records. Overall,
the number of possible IEBL records in the FQDN DNS is described in [7] bounded by the recommended
resolver behavior
number of countries, which in Section 8. combination means very high cache
hit rates.

6. Locating the ENUM branch location record

This section specifies the EBL location for Position of the use-case
"Infrastructure ENUM". IEBL Record

The EBL records record for Infrastructure ENUM (IEBL), as defined in [7]), is

Haberler & Stastny Expires July 28, December 15, 2007 [Page 5]

Internet-Draft Combined User and Infrastructure ENUM January June 2007

SHOULD be positioned

stored in the DNS at the country code level within the e164.arpa ENUM
tree.

If a country or group-of-countries decides to implement the interim
solution for Infrastructure ENUM, then it SHALL put an IEBL record at
the level of individual country codes as assigned by ITU-T, and MUST use ITU-T.

The same algorithm applies for non-geographic country codes (global
services, e.g. +800, +878, +808 or networks, e.g. +882): If I-ENUM is
introduced for these numbers, the subdomain label "infrastructure". IEBL record SHALL be stored at
X.Y.Z.e164.arpa, even if the Tier-1 delegation is not at that level
in the ENUM tree.

The only remaining a-priori knowledge an Infrastructure ENUM resolver
needs to 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

The authoritative source for up-to-date country code extraction algorithm, allocations is
published by ITU-T as complement to the recommendation E.164 [3].
The current scheme to
determine version of this complement is available from ITU website
under "ITU-T / Service Publications".

As of 2007, the country code length as follows could can be employed: determined with the
following simple algorithm:

o 3 digits is the default length of a country code.
o country codes 1 and 7 are a single digit.
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-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 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-T 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. Example for the location of the EBL

This example shows the location of the EBL records for the use-case
"Infrastructure ENUM" defined in this document. It defines that the
EBL resides at "infrastructure".<reverse-country-code>.e164.arpa.
Thus for example:

infrastructure.3.4.e164.arpa. IN EBL 2 "i" e164.arpa.
infrastructure.1.e164.arpa. IN EBL 4 "i" example.com.
infrastructure.9.4.e164.arpa. IN EBL 0 "" e164.foo.

Haberler & Stastny Expires July 28, 2007 [Page 6]

Internet-Draft Combined User and Infrastructure ENUM January 2007

These records indicate how the transformation from E.164 number to
ENUM domains for the application "Infrastructure ENUM" should be done
for numbers in country code +43, +1, and +49. A detailed example for
the intermediate steps necessary is given in [7].

This leads to the following mappings:

+43 15056416 6.1.4.6.5.0.5.1.i.3.4.e164.arpa
+1 5551234567 7.6.5.4.3.2.1.i.5.5.5.1.example.com
+49 891234567 7.6.5.4.3.2.1.9.8.9.4.e164.foo

The last example for CC +49 also shows how the migration to the long
term solution

Examples can be accomplished. This assumes that the apex for
the long-term solution is "e164.foo".

8. found in [7]

7. Recommended resolver behaviour

An 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:

Haberler & Stastny Expires December 15, 2007 [Page 6]

Internet-Draft Combined User and Infrastructure ENUM June 2007

The input to the resolver routine shall be:
1. the E.164 number in fully qualified (international) format,
2. a mode parameter indicating whether 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). rules,
3. optionally a table or algorithm to easily detect calculate country codes code lengths
(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 If the mode parameter indicates a User ENUM search, proceed as per
RFC 3761.
o If the mode parameter indicates an Infrastructure ENUM query:
* determine Determine country code length. length, and thus the location of the
IEBL record.
* consult table if an EBL record Check for this country code was
already retrieved since resolver boot time. a cached IEBL lookup result.
* if not:
+ If no cached result is present:

Retrieve the EBL IEBL record from the 'infrastructure' subdomain
of the country code zone, and store
the country code and
associated EBL values result in an EBL table.
+ Optionally fallback for irregular country code not covered
by the CC extraction algorithm (Figure 1) if the last step
fails, iterate over a cache. For positive result, normal DNS caching
semantics apply. For negative results, it is RECOMMENDED that
the number up to five digits and try to

Haberler & Stastny Expires July 28, 2007 [Page 7]

Internet-Draft Combined User and Infrastructure ENUM January 2007

retrieve the EBL record in the 'infrastructure' subdomain
each time, again storing client sets the country code and associated EBL
values if successful.
+ caching timeout to 24 hours.
* If both attempts fail, use no IEBL is present at the triple ("", 0, "e164.arpa")
as default. This corresponds to calculated position in the RFC 3671 "golden tree" DNS,
return an error.
* Construct If an IEBL was found, construct a domain name according to the
algorithm given in
Section 5. [7].
* Search the DNS for any ENUM NAPTR records for the resulting
domain name.

It is assumed that the location of the Infrastructure ENUM tree for
each country will be rather static. Extensive caching of discovered
EBL
IEBL records (and their absence) is thus recommended.

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

Haberler & Stastny Expires December 15, 2007 [Page 7]

Internet-Draft Combined User and Infrastructure ENUM June 2007

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 .

The 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

Haberler & Stastny Expires July 28, 2007 [Page 8]

Internet-Draft Combined User and Infrastructure ENUM January 2007
authenticity of the conveyed value.

10.

9. IANA considerations

None.

11.

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 RFC 3761 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 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 IEBL records for this country would then be
changed to the values "position=0", "seperator="" "separator="" and
"apex=example.com" (whatever is defined). When finally all countries
have migrated, the EBL IEBL records may be removed.

12.

Haberler & Stastny Expires December 15, 2007 [Page 8]

Internet-Draft Combined User and Infrastructure ENUM June 2007

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.

13.

12. References

13.1.

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, February 2005.

Haberler & Stastny Expires July 28, 2007 [Page 9]

Internet-Draft Combined User and Infrastructure ENUM January 2007

[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 Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.

[6] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.

[7] Lendl, O., "The ENUM Branch Location Record",
draft-ietf-enum-branch-location-record-02
draft-ietf-enum-branch-location-record-03 (work in progress),
December 2006.

13.2.
June 2007.

12.2. Informative References

[8] Lind, S. and P. Pfautz, "Infrastrucure "Infrastructure ENUM Requirements",
draft-ietf-enum-infrastructure-enum-reqs-03
draft-ietf-enum-infrastructure-enum-reqs-04 (work in progress),
August 2006.
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-04 draft-ietf-enum-infrastructure-05 (work in
progress), January 2007.

Haberler & Stastny Expires December 15, 2007 [Page 9]

Internet-Draft Combined User and Infrastructure ENUM June 2007

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/

Haberler & Stastny Expires July 28, 2007 [Page 10]

Internet-Draft Combined User and Infrastructure ENUM January 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 & Stastny Expires July 28, December 15, 2007 [Page 11] 10]

Internet-Draft Combined User and Infrastructure ENUM January June 2007

Full Copyright Statement

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 & Stastny Expires July 28, December 15, 2007 [Page 12] 11]

----