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) 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]