One document matched: draft-haberler-carrier-enum-00.txt
ENUM -- Telephone Number Mapping M. Haberler
Working Group IPA
Internet-Draft R. Stastny
Expires: January 9, 2006 Oefeg
July 8, 2005
Combined User and Carrier ENUM in the e164.arpa tree
draft-haberler-carrier-enum-00
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 January 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
ENUM as defined now in RFC3761 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. A combined end-
user and carrier ENUM tree solution would leverage the ENUM
infrastructure in e164.arpa, increase resolution rates, and decrease
the cost per registered telephone number. This document describes a
minimally invasive scheme to provide both end-user and carrier data
Haberler & Stastny Expires January 9, 2006 [Page 1]
Internet-Draft Combined User and Carrier ENUM July 2005
in ENUM.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introducing a branch into the e164.arpa tree . . . . . . . . 4
4. Resolver behavior options and the Carrier ENUM boundary . . 5
5. Recommended resolver behavior . . . . . . . . . . . . . . . 7
6. Security considerations . . . . . . . . . . . . . . . . . . 7
7. IANA considerations . . . . . . . . . . . . . . . . . . . . 8
8. Interoperability considerations . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1 Normative References . . . . . . . . . . . . . . . . . . 8
10.2 Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10
Haberler & Stastny Expires January 9, 2006 [Page 2]
Internet-Draft Combined User and Carrier ENUM July 2005
1. Introduction
ENUM as defined in RFC3761 is based on the end-user opt-in principle.
While this has great potential to foster new services and end-user
choice in the long-term, the current requirements for IP-based
interconnection of carriers and IP Telephony Service Providers
require the provisioning of all allocated or served (hosted) numbers
of a participating carrier of record. Also, an interconnection
scenario through Carrier ENUM typically implies underlying closed
user arrangements where URIs are used in authenticated context, an
assumption which cannot reasonably be imposed on User ENUM entries.
While in principle solutions like compulsory opt-in through terms and
conditions for end users are conceivable, there are substantial
downsides to such an approach. ENUM for end-user provisioning
remains an ill-suited solution for the PoI (point-of-interconnect)
information discovery problem.
Both from an OPEX (Operational Expenditure) perspective as well as
overall resolution rates achievable through a given approach, a
combined ENUM tree both for end-users and carrier of record ENUM
stands to be superior over a forest of disparate private trees now as
well as long-term. Also, as a common infrastructure easily supports
both usage scenarios, a combined approach will support the end-user
ENUM vision by driving down the average cost per number. Lastly, any
later convergence between ENUM for end-users and carriers of record
will be significantly easier and cheaper, thus benefitting users as
well as carriers. For the rest of the document the terms User ENUM
and Carrier ENUM will be used to distinguish between the two
approaches.
2. Requirements
A solution for combined User and Carrier ENUM within the e164.arpa
tree should meet the following requirements:
o A single DNS lookup should suffice to resolve any given number in
the public DNS in both scenarios.
o It should leave User ENUM resolution semantics and tree shape
intact, i.e. requiring no wholesale changes to existing User ENUM
resolvers or tree layout.
o Additional functionality should only be imposed on carrier
resolvers.
o It should work with both closed and open number plans without
resorting to wildcard records in the non-user controlled part of
the DNS, both to avoid associated semantic problems as well as
keeping the route to DNSSEC deployment open.
Haberler & Stastny Expires January 9, 2006 [Page 3]
Internet-Draft Combined User and Carrier ENUM July 2005
o It should not require the introduction of new constructs within
existing standards, such as new types or changed semantics of
NAPTR records.
o It should be possible to introduce the scheme in a timely manner,
supporting current carrier needs. Consequently, it is desirable
to deploy the scheme without re-opening already settled questions
of roles, responsibilites and international coordination, and in
particular the country code delegation process.
o It should meet all reasonable privacy concerns about visibility of
information an end user has no control over, for example discovery
of unlisted numbers, or inadvertent disclosure of user identity.
o It should keep the option open for other types of closed-user-
group type applications, which might not naturally fit into the -
predominantly voice oriented - Carrier ENUM scenario.
Note in particular that we assume all entries to properly resolve in
the public DNS, both user and carrier. Usage restrictions on Carrier
ENUM records are to be handled at the URI level, and not by
restriction on the visibility of entries in the public DNS.
3. Introducing a branch into the e164.arpa tree
The method most easily fulfilling the abovementioned requirements is
to branch off the e164.arpa tree into a subdomain at a given point,
and deploy a Carrier ENUM subtree underneath without touching User
ENUM semantics at all. For readability, we will use the 'carrier'
subdomain from now on, while in practice a single character subdomain
like 'c' will suffice.
For interoperability it is desirable to have that branch sit in a
commonly agreed, or easily discoverable place. Several options for
this branch location exist, among them are:
o above the country code delegation level, e.g.
'4.9.7.1.carrier.e164.arpa', alternatively:
o somewhere below the country code delegation level, e.g.
'4.9.7.carrier.1.e164.arpa'.
In the first case, heavy involvement of ITU-T, RIPE as well as the
applicable NRAs (National Regulatory Authorities) is needed. Also,
reopening the discussion of the interim procedures already agreed is
a tedious process, as is the adaptation of the current delegation
mechanism. However, no changes to resolver semantics are required as
this approach amounts to just a different apex definition for the
resolver. Therefore the remainder of this paper addresses only the
second scenario. This approach, putting aside significant process
and timing concerns, appears to be an easier to manage long-term
approach to tree naming.
Haberler & Stastny Expires January 9, 2006 [Page 4]
Internet-Draft Combined User and Carrier ENUM July 2005
In the second case issues could be resolved as a national matter, or
as a regional opt-in within in a given Numbering Plan Area such as
the North American NPA. However, a convention is needed how, given a
fully qualified E.164 [2] number, a resolver can determine the
location of the carrier subdomain.
The involvement of the NRA is needed in all cases since the
definition of the proper carrier of record follows national
telecommunications law. In the second case however, ITU-T and IETF
(IAB) involvement is only lightweight, e.g. to recommend the proper
algorithm defined here to enable international interoperability.
4. Resolver behavior options and the Carrier ENUM boundary
Whatever choice is taken, a Carrier ENUM resolver needs to determine
the place applicable in a given number to search for the 'carrier'
subdomain for international interoperability. To determine the
subdomain location, the following schemes could be used:
o a convention whereas the subdomain is always located right below
the country code delegation level, e.g.
'4.9.7.carrier.1.e164.arpa',
o a per-country or per-NPA decision about the subdomain location,
for instance 'carrier.4.9.7.1.e164.arpa'.
The first option would enable a fixed table-based mapping in the
resolver from country codes to subdomain location. Given the fact
that the ITU recently allocated only 3-digit country codes, there is
no more spare 1- and 2-digit country codes and existing 1- and
2-digit country codes are extremely unlikely to be be recovered, a
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
happend recently e.g. to Yugoslavia. The current scheme to determine
country code length is as follows:
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.
While easily implemented, this method precludes some national
options, for instance to move their Carrier ENUM tree under
carrier.e164.arpa, or have the subdomain location deeper in the tree,
for instance under a numbering plan spanning several countries, right
under the number plan area (NPA) level, e.g.
'carrier.4.9.7.1.e164.arpa' .
In practice, current regional co-operative number plan areas such as
North America partition the number plan at the 4th digit (thus the
"number plan area code" +1444 is discrete from the "number plan area
Haberler & Stastny Expires January 9, 2006 [Page 5]
Internet-Draft Combined User and Carrier ENUM July 2005
code" +1443). This partitioning may be reflected in routing choices
within the PSTN, so a PSTN routing choice can be made by inspection
of the first 4 digits of the E.164 number.
For flexibility, some PSTN routing choices may be made by examining a
further digit, so that, for example, +87810 could be treated
differently from +87811, and might be routed to a different
interconnection point. This would reflect a difference between the
administration controlling these two number spaces. It seems
unlikely that further inspection would be required even in the medium
to long term, so that an algorithm that inspects the first 5 digits
will suffice to detect the boundary for Carrier ENUM space within the
global ENUM space for any realistic numbering administrative
partitioning.
Therefore, we suggest a more flexible approach which subsumes all of
the above scenerios. It is based on a table of well-known subdomain
locations for those countries or NPAs which have opted in to this
scheme. This Carrier ENUM subdomain location table would look as
follows:
+--------------+---------+
| country code | location|
+--------------+---------+
| 43 | 2 |
| 1 | 4 |
+--------------+---------+
Figure 1
The interpretation would be as follows:
o Country codes 43 and 1 have opted to use a combined User and
Carrier ENUM tree under e164.arpa.
o Country code 43 (Austria) has opted to locate the carrier subtree
right under the country code, therefore to be found two digits
into the number. Example:
'5.6.4.3.1.2.4.4.6.6.carrier.3.4.e164.arpa'.
o The +1 NPA has decided to locate the subdomain after country code
plus NPA, i.e. 4 digits into the number. Example:
'1.5.6.5.4.3.4.carrier.1.7.5.1.e164.arpa' .
This table would be found at a fixed location registered with IANA
and retrieved by Carrier ENUM resolvers from time to time. We could
imagine other methods to distribute this - fairly static -
information, for instance eventually in the DNS itself, and encourage
suggestions how this could be done.
Haberler & Stastny Expires January 9, 2006 [Page 6]
Internet-Draft Combined User and Carrier ENUM July 2005
5. Recommended resolver behavior
A User ENUM resolver as per RFC3761 need not be aware of any Carrier
ENUM conventions at all. A combined User and Carrier 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 'subtree' parameter indicating wether the search should proceed
in the User ENUM tree, or in the subtree indicated by the
parameter (example: 'c' standing for carrier, or a null value for
defaulting to User ENUM resolution),
3. access to the subdomain location table,
4. any other paramters 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:
1. if the subtree parameter indicates a User ENUM search, proceed as
per RFC3761.
2. If the subtree parameter indicates a Carrier ENUM query:
1. determine whether or not the country code is contained in the
subdomain table. If not, indicate failure.
2. If it is, retrieve the subdomain location parameter for the
given country code and insert the subdomain accordingly while
creating the inverted dotted domain name.
3. search the DNS for any NAPTR records for the given number.
6. Security considerations
Privacy issues have been raised regarding unwarranted disclosure of
user information by publishing Carrier 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 Carrier 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, wether serviced or
not, or listed or unlisted, will prevent mining attempts for such
number attributes.
Haberler & Stastny Expires January 9, 2006 [Page 7]
Internet-Draft Combined User and Carrier ENUM July 2005
The result would be that the information in the public DNS would
mirror number range allocation information, but not more. Carrier
ENUM will not tell you more than you can get by just dialing numbers.
7. IANA considerations
The following parameters need to be registered with IANA:
1. The name of the Carrier ENUM subdomain, for example 'c'. In the
future other labels could be registered for different purposes.
2. According to RFC 3761, the IETF requested IANA to delegate the
E164.ARPA domain following instructions provided by the IAB.
Names within this zone are to be delegated to parties according
to the ITU-T Recommendation E.164. If the first option outlined
in this proposal is accepted, there will be no changes requested
of IANA with respect to the E164.ARPA domain. However, if the
second option outlined in this document is accepted, this would
require IETF to request IANA to create a new sub-domain
C.E164.ARPA.
3. the URI and format of the subdomain location table.
8. Interoperability considerations
A resolver needs to indicate which information is requested - User or
Carrier ENUM, or both. A user-ENUM-only resolver need not be aware
of the carrier subtree and no changes with respect to RFC3761
semantics are required. A resolver desiring to retrieve Carrier ENUM
or both types of records needs to be aware of the conventions laid
out in this draft.
9. Acknowledgements
We gratefully acknowledge suggestions and improvements by Jason
Livingood and Tom Creighton of Comcast, Penn Pfautz of ATT, and
Lawrence Conroy of Roke Manor Research.
10. References
10.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.
10.2 Informative References
[2] ITU-T, "The International Public Telecommunication Number Plan",
Recommendation E.164, May 1997.
Haberler & Stastny Expires January 9, 2006 [Page 8]
Internet-Draft Combined User and Carrier ENUM July 2005
Authors' Addresses
Michael Haberler
Internet Foundation Austria
Waehringerstrasse 3/19
Wien A-1090
Austria
Phone: +43 664 4213465
Email: mah@eunet.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 January 9, 2006 [Page 9]
Internet-Draft Combined User and Carrier ENUM July 2005
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 (2005). 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 January 9, 2006 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 04:18:24 |