ENUM P. Pfautz Internet-Draft AT&T Expires: December 5, 2005 S. Lind AT&T Labs T. Creighton Comcast Cable Communications June 3, 2005 IANA Carrier/User enumservice Registration draft-pfautz-lind-enum-carrier-user-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 5, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry to support end user and carrier services with independent name Pfautz, et al. Expires December 5, 2005 [Page 1] Internet-Draft User/Carrier ENUM June 2005 servers holding the terminal NAPTR (Naming Authority Pointer) records identifying the communication services for each. The to-be- registered enumservices make use of non-terminal NAPTR records and DDDS (Dynamic Delegation Discovery System) replacement to achieve this end. Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. User and Carrier Non-Terminal NAPTRs . . . . . . . . . . . . . 4 3. ENUM Service Registration for Carrier ENUM . . . . . . . . . . 4 4. ENUM Service Registration for User ENUM . . . . . . . . . . . 5 5. Control of Records in Tier 1 . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 9 Pfautz, et al. Expires December 5, 2005 [Page 2] Internet-Draft User/Carrier ENUM June 2005 1. Introduction Work on the implementation of ENUM RFC3761 [2] in the ITU [3] and various national bodies [4] to date has been based on a tiered architecture with a Tier 0 registry, authoritative for the domain e164.arpa, containing NS records delegating domains corresponding to country codes (e.g., 1.e164.arpa) to a Tier 1 registry containing NS records that in turn delegate domains associated with individual E.164 numbers in a given country code. A Tier 1 registry in these instances contains NS records that point to the Tier 2 that contains the actual NATPR records for a given E.164 number[3]. Implementation of these architectures has tended to assume an end user focus with number assignees proactively and uniquely controlling whether their numbers are registered into ENUM and being able to select the Tier 2 registry that contains the actual NATPR records. As the GSTN is seen to evolve towards an application on an underlying IP network, carriers have become increasingly interested in using ENUM for interconnection, i.e., to provide information, such as a SIP address of record, about where interconnecting carriers should direct calls to a number which the carrier serves, even where the customer's ultimate connection to the carrier's network and the customer's premise equipment may not be IP-based. Also, as VoIP carriers proliferate there is an understandable desire to be able to connect calls between users of such services without going through the circuit switched GSTN. These needs have led to proposals for separate "carrier" or "infrastructure" ENUM based on a root other than e164.arpa or to suggestions that carriers be able to populate NAPTR records in their own Tier 2 if the number assignee does not choose to register or in the number assignee's Tier 2 if the assignee selects a Tier 2 provider other than that used by the carrier by which the number is served in the GSTN. The difficulties with such proposals are that they either require construction of a separate parallel tree or complicate provisioning and may not support carrier grade service. In the first case, a separate tree raises issues about who would be allowed to populate information into it and who would have the ability to access information. In the second case, for example, if the number assignee selects a Tier 2 other than the one chosen by the carrier that serves their number in the GSTN, the carrier would need to find a way to provision its NAPTRs into that Tier 2 which may also not meet carrier reliability needs. Further, obtaining user consent for registration, while essential for applications that may open vulnerabilities to an end user, is burdensome where all numbers must be registered for effective interconnection of carriers and may be unnecessary where registration only involves association of E.164 numbers with carrier Pfautz, et al. Expires December 5, 2005 [Page 3] Internet-Draft User/Carrier ENUM June 2005 network elements rather than the end user directly. 2. User and Carrier Non-Terminal NAPTRs As discussed above, ENUM implementation has been based on a tiered architecture with Tier 1 containing NS records that point to the Tier 2 that contains the actual NATPR records for a given E.164 number[3]. It is here proposed that, instead of using NS records to delegate to a Tier 2 name server, the DDDS substitution capability be employed to allow non-terminal NAPTR records to generate new DNS queries for terminal NAPTRs to different domains based on the enumservice designation of "carrier" or "user." Section 1.3 of RFC 3761 ("Application of local policy") states "there are ... cases (non- terminal Rules) where two different Rules both match the given Application Unique String... For example, by using a non-terminal NAPTR a given set of numbers is sent to some private-dialing-plan- specific zone." Section 2.4 ("Flags") states "If this [the terminal "u" ] flag is not present then this Rule is non-terminal. If a Rule is non-terminal then clients MUST use the key produced by this Rewrite Rule as the new key in the DDDS loop (i.e., causing the client to query for new NAPTR records at the domain name that is the result of this Rule)." Because the object of the query to Tier 1 is to obtain a domain name to query rather than a URI, we use the Replacement field of the NAPTR rather than the Regexp as described in RFC 3403 RFC3403 [5]. Thus records for a number in Tier 1 might look like: $Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa. IN NAPTR 100 50 "" "E2U+user" "" 9.0.3.5.7.6.8.7.9.4.1.joesenum.com IN NAPTR 100 50 "" "E2U+carrier" "" 9.0.3.5.7.6.8.7.9.4.1.telco.net The first record would result in a query to the nameserver designated by the end user assignee of the E.164 number and the second to the nameserver designated by the carrier of record in the GSTN for the E.164 number. Note that as the Tier 1 NAPTRs are non-terminal, neither contains a specific communication protocol type in the enumservice spec (e.g., "sip"). NAPTR records for acutal communication services would only be provided in the corresponding user or carrier name server where the NAPTR records are terminal and would include the enumservice specs such as for SIP, i.e., "E2U+sip". 3. ENUM Service Registration for Carrier ENUM As defined in RFC3761 [2], the following is a template for the registration of the enumservice specified in this document. Pfautz, et al. Expires December 5, 2005 [Page 4] Internet-Draft User/Carrier ENUM June 2005 ENUMservice Name: "E2U+carrier" Type(s) "carrier" Subtypes: N/A URI Schemes(s) N/A Functional Specification: see Section 2 Security Considerations: see Section 6 Intended Usage: COMMON Author: Penn Pfautz (ppfautz@att.com) Any other information the author deems interesting: This ENUMservice is only to be used with non-terminal NAPTR records. See Section 5. 4. ENUM Service Registration for User ENUM As defined in RFC3761 [2], the following is a template for the registration of the enumservice specified in this document. ENUMservice Name: "E2U+user" Type(s) "user" Subtypes: N/A URI Schemes(s) N/A Functional Specification: see Section 2 Security Considerations: see Section 6 Intended Usage: COMMON Author: Penn Pfautz (ppfautz@att.com) Any other information the author deems interesting: This ENUMservice is only to be used with non-terminal NAPTR records. See Section 5. 5. Control of Records in Tier 1 Although two records are populated in Tier 1, the lines of authority for each are clear. The E2U+user record is controlled by, and only populated at the request of, the end user assignee of the E.164 Pfautz, et al. Expires December 5, 2005 [Page 5] Internet-Draft User/Carrier ENUM June 2005 number. The assignee has the right to select a registrar and a name server ("Tier 2") provider of their choice in a competitive enivronment. The E2U+carrier record, on the other hand, is controlled by the GSTN carrier of record for the E.164 number (i.e., the service provider who has been allocated the block of numbers in which the number in question is contained or to which the number has been ported). Both end users and carriers may populate different NAPTR records in their respective domains. In such cases the client originating the ENUM query will be responsible for obtaining all (or as many as possible) ENUM records and for deciding which records to make use of in initiating communication. 6. Security Considerations Existing security considerations for ENUM detailed in RFC3761 [2] still apply. Note that some registration validation issues concerning end user ENUM may not apply to carrier ENUM. Where the Tier 1 registry is able to identify the carrier serving a number e.g., based on industry data for number block assignments and number portability, registration might be more easily automated and a separate registrar not required. Some parties have expressed concern that a carrier ENUM could compromise end user privacy by making it possible for others to identify unlisted or unpublished numbers based on their registration in ENUM. This can be avoided if carriers register all of the their allocated (as opposed to assigned) numbers. Unassigned numbers should be provisioned to route to the carrier's network in the same fashion as assigned numbers and only then provide an indication that they are unassigned. In that way, carrier registration of a number in ENUM provides no more information about status of a number than could be obtained by dialing it. 7. IANA Considerations This document registers the 'E2U+carrier' and 'E2U+user' enumservices under the enumservice registry described in the IANA considerations in RFC 3761. Details of the registration are given in sections 3 and 4. 8. Acknowledgements The authors wish to thank Rich Shockey and Patrik Faltstrom for their helpful discussion on this topic. Pfautz, et al. Expires December 5, 2005 [Page 6] Internet-Draft User/Carrier ENUM June 2005 9. 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] International Telecommunications Union, "Supplement 3 to Recommendation E.164: Operational and administrative issues associated with national implementations of the ENUM functions", 2004. [4] ENUM Forum, "ENUM Forum Specifications for US Implementation of ENUM, Document 6000_1 0", March 2003. [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. Authors' Addresses Penn Pfautz AT&T 200 S. Laurel Ave Middletown, NJ 07748 USA Email: ppfautz@att.com Steven Lind AT&T Labs 180 Park Ave Florham Park, NJ 07932-0971 USA Email: slind@att.com Pfautz, et al. Expires December 5, 2005 [Page 7] Internet-Draft User/Carrier ENUM June 2005 Tom Creighton Comcast Cable Communications 1500 Market Street Philadelphia, PA 19102 USA Email: tom_creighton@cable.comcast.com Pfautz, et al. Expires December 5, 2005 [Page 8] Internet-Draft User/Carrier ENUM June 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 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. Pfautz, et al. Expires December 5, 2005 [Page 9] Internet-Draft User/Carrier ENUM June 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Pfautz, et al. Expires December 5, 2005 [Page 10]