ENUM R. Stastny
Internet-Draft Oefeg
Expires: December 6, 2006 June 4, 2006
IANA Registration for an Enumservice to Hint to E.164 Resolution
Namespaces (ERN)
<draft-stastny-enum-ern-00.txt>
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 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document registers the Enumservice type "ern" and subtype "http"
using the URI scheme 'http', as well as the subtype "urn" using the
URI scheme 'urn' as per the IANA registration process defined in the
ENUM specification RFC 3761. This Enumservice is used to provide a
hint in ENUM to an E.164 Resolution Namespace a service provider
chooses to populate with E.164 numbers to be shared within a limited
group of other service providers.
Stastny Expires December 6, 2006 [Page 1]
Internet-Draft Enumservice ERN June 2006
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5
5. E.164 Resolution Namespaces . . . . . . . . . . . . . . . . . 5
6. ENUM Service Registrations - ern . . . . . . . . . . . . . . . 6
6.1. "http" Subtype . . . . . . . . . . . . . . . . . . . . . . 6
6.2. "urn" Subtype . . . . . . . . . . . . . . . . . . . . . . 7
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Providing hints to two different namespaces . . . . . . . 7
7.2. Providing a hint to e164.arpa . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Stastny Expires December 6, 2006 [Page 2]
Internet-Draft Enumservice ERN 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].
2. Introduction
Infrastructure ENUM is defined as the use of the technology in
RFC3761 [2] by the carrier-of-record (Voice service provider) for a
specific E.164 [3] number to map a telephone number into an URI [4]
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 [5], the DDDS application for Infrastructure ENUM in
"e164.arpa" is specified in [6].
Voice service providers use E.164 numbers currently as their main
naming and routing vehicle. Infrastructure ENUM in "ie164.arpa"
allows service providers to link Internet based resources such as
URIs to E.164 numbers. This allows service providers in addition to
interconnecting via the PSTN/PLMN (or exclusively) to peer via IP-
based protocols. Service providers may announce all E.164 numbers or
number ranges they host, regardless of whether the final end-user
device is on the Internet, on IP-based open or closed Next Generation
Networks (NGNs) or on the PSTN/PLMN/ISDN, provided an access (e.g.,
Session Border Controller (SBC) or gateway) to the destination
service provider's network is available on the Internet.
3. The Problem
The Infrastructure ENUM requirements in [5] state the following:
"There is also no guarantee that the originating service provider
querying Infrastructure ENUM is able to access the ingress network
element of the destination provider's network. Additional peering
and accounting agreements requiring authentication may be necessary.
The access provided may also be to a shared network of a group of
providers, resolving the final destination network within the shared
network.
Stastny Expires December 6, 2006 [Page 3]
Internet-Draft Enumservice ERN June 2006
1. Infrastructure ENUM SHALL provide a means for a provider to
populate DNS resource records (RRs) for the E.164 numbering
resources for which it is the carrier-of-record in a single
common publicly accessible namespace. The single common
namespace ultimately designated may or may not be the same as
that designated for user ENUM (e164.arpa.)
2. Queries of infrastructure ENUM fully qualified domain names MUST
return a result, even if the result is NXDOMAIN. Queries must
not be rejected, e.g., based on access control lists.
3. Infrastructure ENUM SHALL support RRs providing a URI that can
identify a point of interconnection for delivery to the carrier-
of-record of communications addressed to the E.164 number."
Particularly these requirements are currently preventing some voice
service providers to publish their data in Infrastructure ENUM. Some
may not want do provide a point of interconnection on the public
Internet at all, whilst some do not even want to publish a list of
numbers they host.
To avoid the problems mentioned above, voice service providers are
joining private groups of providers providing E.164 resulution
namespaces (ERN) based on different technologies, e.g. ENUM, SIP
redirect and others. Currently many such groups have been
established.
These solutions have two serious drawbacks: a service provider
participating in one specific private ERN group will never be able to
resolve ALL E.164 numbers that a subscriber may dial, using only the
resolution available within a particular private ERN group.
Conversely, access to a given service provider's resources or
customers may be available only via a limited number of other service
providers rather than directly to all participating providers within
an ERN group, and possibly not at all to providers outside that ERN
group.
Almost by definition, these schemes are limited in scope. To
increase the reachability via IP-networks for voice and other real-
time services, a service provider is forced to participate in more
then one of these private ERN groups.
This has also a drawback for originating service providers, because
they now have to query in sequence or in parallel all private ERN
groups they are participating to find by chance one where the
destination network hosting the dialed number is also participating.
This is not very efficient.
Stastny Expires December 6, 2006 [Page 4]
Internet-Draft Enumservice ERN June 2006
4. Proposed Solution
It is proposed to give service providers not willing to enter URIs
into the system defined in Infrastructure ENUM [6] the optional
possibility to enter hints into Infrastructure ENUM in which private
ERN groups they are participating.
This would reduce the number of queries an originating network has to
do to a maximum of two:
1. A query in Infrastructure ENUM to find out in which private ERN
groups the destination network participates.
2. If a match is found, the originating network now directly queries
the private ERN in which it and the destination hosting providers
both participate and can be sure to get a positive response. If
more than one match is found, it is the choice of the originating
service provider which private ERN it uses to query the E.164
number. If no match is found, the PSTN must be used or the call
cannot be established.
This does not prevent the destination network entering a NAPTR with a
normal enumservice e.g. SIP, pointing directly to an AoR or to an
ingress point of the destination network. It is again the choice of
the originating network how to establish the call.
Note: the proposed Enumservice ERN merely hints at the E.164
Resolution namespace that may help to resolve a given number. It
does define at the same time which peering federation is used to
establish the call. Whilst these groups may include the same
members, the relationship between these members and the roles of the
groups are quite different. Whilst groups that share resolution
namespaces are related to ENUM, Peering federations are a topic for
other Working Groups and are out of scope of the ENUM WG.
The main purpose of the Enumservice "ern" is to enhance the
efficiency of the mapping of E.164 numbers to URIs and also to be a
common anchor for all private E.164 Resolution Namespaces.
5. E.164 Resolution Namespaces
An E.164 Resolution Namespace is an agreed upon method between a
defined group of VoIP service providers used to map E.164 numbers to
URIs. Typical examples are private ENUM trees, but also other
mapping methods and databases may be used.
This document does not define what these methods are and how the
members of the group access the E.164 resolution namespace. There is
Stastny Expires December 6, 2006 [Page 5]
Internet-Draft Enumservice ERN June 2006
no requirement to make these methods public.
A specific E.164 resolution namespace SHALL be identified either as
URN or as "http:" URI.
For the purpose of the Enumservice "ern" the identifiers of the
namespace are opaque strings in the form of domain names. The only
operations performed on these identifiers are string comparisons.
The domain name in the URI is never queried in the DNS directly.
It is up to entity controlling the E.164 resolution namespace to
define an unique domain name or reqister a unique URN for its
interpretation of the E.164 namespace. The entity responsible may
also define additional labels to provide additional information the
private group considers of interest, e.g. a service provider ID
(SPID). The administration of these additional labels is an internal
matter of the group using the namespace.
Whilst it is possible for multiple ERNs to exist, there is of course
a common "standard" namespace that may be used; the ENUM namespace
defined in RFC 3761. Thus a fixed definition for this namespace
allows a provider to indicate that a particular number (or range) can
be resolved using the standard ENUM technique. To support this
choice, the E.164 resolution namespace named "urn:ietf:rfc:3761"
stands for the E.164 resolution namespace in e164.arpa as defined in
RFC 3761.
6. ENUM Service Registrations - ern
6.1. "http" Subtype
Enumservice Name: "ern"
Enumservice Type: "ern"
Enumservice Subtype: "http"
URI Schemes: "http"
Functional Specification:
This Enumservice indicates that the mapping of the E.164 number
queried in ENUM can be resolved in the private E.164 Resolution
Namespace uniquely identified by the domain name given in the
"http" URI. For the purpose of the Enumservice "ern:http" the
identifiers of the namespace are opaque strings in the form of
domain names. The only operations performed on these identifiers
are case insensitive string comparisons. The domain name in the
Stastny Expires December 6, 2006 [Page 6]
Internet-Draft Enumservice ERN June 2006
URI is never queried in the DNS directly.
Security Considerations: see Section 8
Intended Usage: COMMON
Authors: Richard Stastny (see 'Authors' section for contact details)
6.2. "urn" Subtype
Enumservice Name: "ern"
Enumservice Type: "ern"
Enumservice Subtype: "urn"
URI Schemes: "urn"
Functional Specification:
This Enumservice indicates that the mapping of the E.164 number
queried in ENUM can be resolved in the private E.164 Resolution
Namespace uniquely identified by the namespace given in the URN.
To hint that the "standard" ENUM technique may be used, the E.164
resolution namespace named "urn:ietf:rfc:3761" may be used. This
stands for the E.164 resolution namesspace in e164.arpa as defined
in RFC 3761.
Security Considerations: see Section 8
Intended Usage: COMMON
Authors: Richard Stastny (see 'Authors' section for contact details)
7. Examples
7.1. Providing hints to two different namespaces
The service provider hosting the number +441632960048 participates in
two different E.164 resolution namespaces and hints at this by
placing the following entries in Infrastructure ENUM. The preferred
namespace is namespace1.example
$ORIGIN 4.8.0.0.6.9.2.3.6.1.4.4.ie164.arpa.
IN NAPTR 10 100 "u" "E2U+ern:http"
"!^.*$!http:\/\/namespace1.example!" .
Stastny Expires December 6, 2006 [Page 7]
Internet-Draft Enumservice ERN June 2006
IN NAPTR 10 200 "u" "E2U+ern:http"
"!^.*$!http:\/\/SP1234.namespace2.example!" .
The second record shows that the provider have resolution entries in
namespace2.
Note: In this case, namespace2 is partitioned, and each provider uses
its internal identifier as the name of its partition within that
space. With this partitioned structure, the identity of the service
provider may be published within Infrastructure ENUM. As already
mentioned, the internal structure of the namespace is a matter for
the group sharing the resolution name space; the URI is used only as
an opaque identifier to that name space.
7.2. Providing a hint to e164.arpa
If an E.164 number is only defined within e164.arpa, e.g. for the
number range +43780xxxxxx, the whole number block is hinted to
e164.arpa.
$ORIGIN 0.8.7.3.4.ie164.arpa.
* IN NAPTR 10 100 "u" "E2U+ern:urn"
"!^.*$!urn:ietf:rfc:3761!" .
This hint is useful to point from Infrastructure ENUM or other E.164
namespaces to "e164.arpa" for number ranges or numbers that are only
defined in "e164.arpa" to avoid duplication of data.
8. Security Considerations
One of the prime intentions of the Enumservice "ern" is to cover
security and privacy concerns service providers may have in using
other Enumservices in Infrastructure ENUM, e.g. providing SIP URIs
containing AoRs or ingress points to their network.
The minimum information disclosed in using the Enumservice "ern" is
the identification of the private E.164 Resolution Namespace(s) used.
In addition, a provider may choose to provide his own identification
within the given E.164 Resolution Namespace
An analysis of threats specific to the dependence of ENUM on the DNS
is provided in RFC3761 [2].
Stastny Expires December 6, 2006 [Page 8]
Internet-Draft Enumservice ERN June 2006
9. IANA Considerations
This memo requests registration of the "ern" Enumservice according to
the definitions in this document and RFC3761 [2].
10. Acknowledgements
Many thanks to Lawrence Conroy for his valuable input.
11. References
11.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] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
11.2. Informative References
[5] Lind, S. and P. Pfautz, "Infrastrucure ENUM Requirements",
draft-ietf-enum-infrastructure-enum-reqs-02 (work in progress),
April 2006.
[6] 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.
Stastny Expires December 6, 2006 [Page 9]
Internet-Draft Enumservice ERN June 2006
Author's Address
Richard Stastny
Oefeg
Postbox 147
1103 Vienna
Austria
Phone: +43-664-420-4100
Email: Richard.stastny@oefeg.at
Stastny Expires December 6, 2006 [Page 10]
Internet-Draft Enumservice ERN 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.
Stastny Expires December 6, 2006 [Page 11]