ENUM R. Stastny
Internet-Draft Oefeg
Intended status: Standards Track December 1, 2006
Expires: June 4, 2007
IANA Registration for an Enumservice to Hint to E.164 Resolution
Namespaces (ERN)
<draft-stastny-enum-ern-01.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 June 4, 2007.
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 June 4, 2007 [Page 1]
Internet-Draft Enumservice ERN December 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5
5. E.164 Resolution Namespaces . . . . . . . . . . . . . . . . . 6
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 June 4, 2007 [Page 2]
Internet-Draft Enumservice ERN December 2006
1. Introduction
Infrastructure ENUM is defined as the use of the technology in
RFC3761 [2] by the Carrier-of-Record and/or Voice Service Provider
(VSP) for a specific E.164 number [3] to map this telephone number
into a 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 is
specified in [6].
Voice Service Providers (VSPs) use E.164 numbers currently as their
main naming and routing vehicle. Infrastructure ENUM 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/ISDN/PLMN 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.
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, RFC2119 [1].
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 June 4, 2007 [Page 3]
Internet-Draft Enumservice ERN December 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.) The FQDN in the
resulting resource records will not necessarily belong to or
identify the carrier-of-record.
2. Queries of infrastructure ENUM fully qualified domain names MUST
return a result, even if the result is NXDOMAIN (RCODE=3).
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 (VSPs)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, VSPs are joining private
groups of providers providing E.164 resulution namespaces (ERN) based
on various technologies, e.g. ENUM, SIP redirect and others.
Currently many such groups have been established.
These solutions have two serious drawbacks: a VSP 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 June 4, 2007 [Page 4]
Internet-Draft Enumservice ERN December 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.
In doing so, they need not to give away their identity and the
ingress point to their network. The ingress point may not even be
reachable via the public Internet. The only information they provide
is the name of the private ERN where this information can be
retrieved.
This would reduce in turn the number of queries an originating
network has to do to a maximum of two:
1. A query in the (public) 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. In addition, the originating service provider
can be sure to get a positive response on this second query. 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/ISDN/PLMN must be used or
the call cannot be established.
This does not prevent the destination network to enter a NAPTR only
or in addition into Infrastructure ENUM 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 not 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.
Stastny Expires June 4, 2007 [Page 5]
Internet-Draft Enumservice ERN December 2006
5. E.164 Resolution Namespaces
An E.164 Resolution Namespace (ERN) is an agreed upon method between
a defined group of VSPs 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 accesses the E.164 resolution namespace. There
is 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"
Stastny Expires June 4, 2007 [Page 6]
Internet-Draft Enumservice ERN December 2006
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
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
Stastny Expires June 4, 2007 [Page 7]
Internet-Draft Enumservice ERN December 2006
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!" .
IN NAPTR 10 200 "u" "E2U+ern:http"
"!^.*$!http:\/\/SP1234.namespace2.example!" .
The second record shows that the provider has 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
Stastny Expires June 4, 2007 [Page 8]
Internet-Draft Enumservice ERN December 2006
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].
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, February 2005.
[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-03 (work in progress),
August 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-03 (work in
progress), November 2006.
Stastny Expires June 4, 2007 [Page 9]
Internet-Draft Enumservice ERN December 2006
Author's Address
Richard Stastny
Oefeg
Postbox 147
1103 Vienna
Austria
Phone: +43-664-420-4100
Email: Richard.stastny@oefeg.at
Stastny Expires June 4, 2007 [Page 10]
Internet-Draft Enumservice ERN December 2006
Full 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.
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.
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).
Stastny Expires June 4, 2007 [Page 11]