ENUM -- Telephone Number Mapping M. Haberler Working Group IPA Internet-Draft R. Stastny Intended status: Informational Oefeg Expires: July 28, 2007 January 24, 2007 Combined User and Infrastructure ENUM in the e164.arpa tree draft-ietf-enum-combined-04 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 July 28, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice until the long-term solution is approved. This interim solution will be deprecated after approval of the long-term solution. Haberler & Stastny Expires July 28, 2007 [Page 1] Internet-Draft Combined User and Infrastructure ENUM January 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Interim Solution . . . . . . . . . . . . . . . . . . . . . . . 3 4. Introducing a branch into the e164.arpa tree . . . . . . . . . 4 5. Defining the Infrastructure ENUM branch location . . . . . . . 4 6. Locating the ENUM branch location record . . . . . . . . . . . 5 7. Example for the location of the EBL . . . . . . . . . . . . . 6 8. Recommended resolver behaviour . . . . . . . . . . . . . . . . 7 9. Security considerations . . . . . . . . . . . . . . . . . . . 8 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Interoperability considerations . . . . . . . . . . . . . . . 9 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 13.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Haberler & Stastny Expires July 28, 2007 [Page 2] Internet-Draft Combined User and Infrastructure ENUM January 2007 1. Introduction ENUM (E.164 Number Mapping, RFC 3761 [2]) is a system that transforms E.164 numbers [3] into domain names and then uses DNS (Domain Name Service) [6] services like delegation through Name Server (NS) records and NAPTR (Naming Authority Pointer) records [4] to look up which services are available for a specific domain name. ENUM as defined in RFC 3761 (User-ENUM) is not well suited for the purpose of interconnection by carriers and voice service providers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. Infrastructure ENUM is defined as the use of the technology in RFC 3761 [2] by the carrier-of-record [8] (Voice service provider) for a specific E.164 number [3] to map a telephone number into an Uniform Resource Identifier (URI) [5]. This URI maps to a specific point of interconnection to the service provider's network that could enable the originating party to establish communication with the associated terminating party. This URI 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 [8]. Using the same E.164 number to domain mapping techniques for other applications under a different, internationally agreed apex (instead of e164.arpa) is straightforward on the technical side. Establishing the international agreements necessary to delegate the country-code level subdomains under the new apex is non-trivial and time- consuming. This process of defining the Dynamic Delegation Discovery System (DDDS) [4] application for Infrastructure ENUM is work in progress [9]. This is called the long term solution. 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, RFC 2119 [1]. 3. Interim Solution As stated above, the agreements to establish the long-term solution may take some time. It was therefore decided to develop an Interim Solution that can be used by individual countries to implement an Haberler & Stastny Expires July 28, 2007 [Page 3] Internet-Draft Combined User and Infrastructure ENUM January 2007 interoperable Infrastructure ENUM tree immediately. The Interim Solution will be deprecated upon approval (loosely timed) of the long-term solution. It is therefore also required that the Interim Solution includes a smooth migration path to the long-term solution. It is also required that existing ENUM clients querying User ENUM as defined in RFC 3761 [2] continue to work without any modification. Because of various reasons, sharing a single domain name between the user itself and the respective carrier for a number is not possible. Hence, a different domain name must be used to store infrastructure ENUM information. The method most easily fulfilling this is to branch off the e164.arpa tree into a subdomain at or somewhere below the country code delegation level below e164.arpa, and deploy an Infrastructure ENUM subtree underneath without touching User ENUM semantics at all. 4. Introducing a branch into the e164.arpa tree A convention is needed how, given a fully qualified E.164 number [3], a resolver can determine the location of the Infrastructure ENUM subdomain for this country. In order to avoid the delays associated with the long term solution, the existing delegations and agreements around e164.arpa need to be leveraged for the discovery algorithm. Under this approach, ITU-T and IETF (IAB) involvement is only lightweight, e.g. to recommend the proper algorithm defined here to enable international interoperability. This allows to introduce the Interim Solution as a national matter by the concerned National Regulation Authority (NRA) or as a regional opt-in within in a given Numbering Plan Area (NPA) such as the North American NPA. Beyond the setup phase, an NRA need not be involved operationally - it is sufficient to establish a convention linking the national definition of a carrier of record to the credentials for write access to the Infrastructure ENUM tree. 5. Defining the Infrastructure ENUM branch location [7] specifies an extension to the ENUM DDDS application which adds an extra mapping step using a DNS resource record (ENUM Branch Location - EBL) to the E.164 to domain-name translation algorithm. Haberler & Stastny Expires July 28, 2007 [Page 4] Internet-Draft Combined User and Infrastructure ENUM January 2007 The decision where to place the Infrastructure ENUM tree is a national or group-of-countries decision. The EBL affecting the translation of any E.164 number thus needs to reside under the e164.arpa tree for the country code of that number. [7] specifies a DNS resource record (ENUM Branch Location - EBL) and an algorithm to branch the ENUM DNS tree for specific use-cases with the following parameters: 1. the name of EBL use-case, 2. a SEPARATOR, 3. a POSITION, 4. an APEX. These parameters can be used to describe the tree shape for the Interim Solution of Infrastructure ENUM as follows: o The national or group-of-countries decision about the location of the Infrastructure ENUM branch is documented in the e164.arpa tree by inserting an EBL resource record into a subdomain at the country code level. o The EBL subdomain label for the Infrastructure ENUM use-case MUST be "infrastructure". This EBL carries the above mentioned three values for maximum flexibility: 1. the branching label (SEPARATOR) to be inserted into the ENUM domain to branch off to the Infrastructure ENUM sub-tree. This MAY be an empty (zero-length) string which means no label will be inserted. 2. an insertion POSITION, indicating after which digit this label (SEPARATOR) should be inserted. A value of 0 means to the right of all digits. 3. an APEX indicating what domain MUST replace "e164.arpa" for this application. "e164.arpa" MAY also be replaced by itself. o A resolver looking for an Infrastructure ENUM domain needs to retrieve this EBL once during first resolution within a country code. This is described in Section 6. o The construction of the FQDN is described in [7] the recommended resolver behavior in Section 8. 6. Locating the ENUM branch location record This section specifies the EBL location for the use-case "Infrastructure ENUM". The EBL records for Infrastructure ENUM Haberler & Stastny Expires July 28, 2007 [Page 5] Internet-Draft Combined User and Infrastructure ENUM January 2007 SHOULD be positioned at the level of individual country codes as assigned by ITU-T, and MUST use the subdomain label "infrastructure". The only remaining a-priori knowledge an Infrastructure ENUM resolver needs to have is the current list of country codes, or an equivalent method to determine where the country code in the number ends. To prime the country code extraction algorithm, the current scheme to determine country code length as follows could be employed: 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. Figure 1 Given the fact that the ITU-T recently allocated only 3-digit country codes, there are no more spare 1- and 2-digit country codes and existing 1- and 2-digit country codes are extremely unlikely to be recovered, the above 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 happened recently e.g. to Yugoslavia. If a branch location record is not found according to this table (for instance, in the unlikely case the ITU-T allocates a country code not according to these rules), it is still possible to determine the branch location record by "iterating down" the tree digit-by-digit. Such a fallback strategy would rely on the assumption that there is never a branch location record inserted above the country code zone, for which there would be no use in the first place. It seems unlikely that inspection of more than the first five digits will be required to locate the branch location record under any realistic numbering administrative partitioning. 7. Example for the location of the EBL This example shows the location of the EBL records for the use-case "Infrastructure ENUM" defined in this document. It defines that the EBL resides at "infrastructure"..e164.arpa. Thus for example: infrastructure.3.4.e164.arpa. IN EBL 2 "i" e164.arpa. infrastructure.1.e164.arpa. IN EBL 4 "i" example.com. infrastructure.9.4.e164.arpa. IN EBL 0 "" e164.foo. Haberler & Stastny Expires July 28, 2007 [Page 6] Internet-Draft Combined User and Infrastructure ENUM January 2007 These records indicate how the transformation from E.164 number to ENUM domains for the application "Infrastructure ENUM" should be done for numbers in country code +43, +1, and +49. A detailed example for the intermediate steps necessary is given in [7]. This leads to the following mappings: +43 15056416 6.1.4.6.5.0.5.1.i.3.4.e164.arpa +1 5551234567 7.6.5.4.3.2.1.i.5.5.5.1.example.com +49 891234567 7.6.5.4.3.2.1.9.8.9.4.e164.foo The last example for CC +49 also shows how the migration to the long term solution can be accomplished. This assumes that the apex for the long-term solution is "e164.foo". 8. Recommended resolver behaviour An User ENUM resolver as per RFC 3761 need not be aware of any Infrastructure ENUM conventions at all. A combined User and Infrastructure ENUM resolver shall behave as follows: The input to the resolver routine shall be: 1. the E.164 number in fully qualified (international) format, 2. a mode parameter indicating whether resolution should follow User ENUM or Infrastructure ENUM rules (for instance, a null value for defaulting to User ENUM, or 'infrastructure' for Infrastructure ENUM semantics). 3. optionally a table or algorithm to easily detect country codes (Section 6), 4. any other parameters 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: o if the mode parameter indicates a User ENUM search, proceed as per RFC 3761. o If the mode parameter indicates an Infrastructure ENUM query: * determine country code length. * consult table if an EBL record for this country code was already retrieved since resolver boot time. * if not: + Retrieve the EBL record from the 'infrastructure' subdomain of the country code zone, and store the country code and associated EBL values in an EBL table. + Optionally fallback for irregular country code not covered by the CC extraction algorithm (Figure 1) if the last step fails, iterate over the number up to five digits and try to Haberler & Stastny Expires July 28, 2007 [Page 7] Internet-Draft Combined User and Infrastructure ENUM January 2007 retrieve the EBL record in the 'infrastructure' subdomain each time, again storing the country code and associated EBL values if successful. + If both attempts fail, use the triple ("", 0, "e164.arpa") as default. This corresponds to the RFC 3671 "golden tree" * Construct a domain name according to the algorithm given in Section 5. * Search the DNS for any ENUM NAPTR records for the resulting domain name. It is assumed that the location of the Infrastructure ENUM tree for each country will be rather static. Extensive caching of discovered EBL records is thus recommended. 9. Security considerations Privacy issues have been raised regarding unwarranted disclosure of user information by publishing Infrastructure 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 Infrastructure 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, whether serviced or not, or listed or unlisted, will prevent mining attempts for such number attributes. The result would be that the information in the public DNS would mirror number range allocation information, but not more. Infrastructure ENUM will not tell you more than you can get by just dialing numbers. The URI pointing to the destination network of the Carrier of Record should also not disclose any privacy information about the identity of end-user. It is therefore recommended to use either anonymized UserIDs or the E.164 number itself in the user-part of the URI, such as in sip:+441632960084@example.com . The usage of the Branch Location record conveys only static setup information under a country code subtree of e164.arpa. The intended use of DNS Security Extensions (DNSSEC) within ENUM will prove Haberler & Stastny Expires July 28, 2007 [Page 8] Internet-Draft Combined User and Infrastructure ENUM January 2007 authenticity of the conveyed value. 10. IANA considerations None. 11. Interoperability considerations An application using the combined resolver needs to indicate which information is requested - User or Infrastructure ENUM, or both. A user-ENUM-only resolver need not be aware of the Infrastructure ENUM subtree and no changes with respect to RFC 3761 semantics are required. A resolver desiring to retrieve Infrastructure ENUM or both types of records needs to be aware of the conventions laid out in this draft. When the long-term solution is adopted, each country using the interim solution may decide on its own when to migrate to the long- term solution. The EBL records for this country would then be changed to the values "position=0", "seperator="" and "apex=example.com" (whatever is defined). When finally all countries have migrated, the EBL records may be removed. 12. Acknowledgements We gratefully acknowledge suggestions and improvements by Jason Livingood and Tom Creighton of Comcast, Penn Pfautz of ATT, Lawrence Conroy of Roke Manor Research, and Alexander Mayrhofer and Otmar Lendl of enum.at. 13. References 13.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. Haberler & Stastny Expires July 28, 2007 [Page 9] Internet-Draft Combined User and Infrastructure ENUM January 2007 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [6] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [7] Lendl, O., "The ENUM Branch Location Record", draft-ietf-enum-branch-location-record-02 (work in progress), December 2006. 13.2. Informative References [8] Lind, S. and P. Pfautz, "Infrastrucure ENUM Requirements", draft-ietf-enum-infrastructure-enum-reqs-03 (work in progress), August 2006. [9] Livingood, J., "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM", draft-ietf-enum-infrastructure-04 (work in progress), January 2007. Authors' Addresses Michael Haberler Internet Foundation Austria Waehringerstrasse 3/19 Wien A-1090 Austria Phone: +43 664 4213465 Email: mah@inode.at URI: http://www.nic.at/ipa/ Haberler & Stastny Expires July 28, 2007 [Page 10] Internet-Draft Combined User and Infrastructure ENUM January 2007 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 July 28, 2007 [Page 11] Internet-Draft Combined User and Infrastructure ENUM January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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). Haberler & Stastny Expires July 28, 2007 [Page 12]