ENUM -- Telephone Number Mapping M. Haberler Working Group IPA Internet-Draft R. Stastny Expires: April 24, 2006 Oefeg October 21, 2005 Combined User and Carrier ENUM in the e164.arpa tree draft-haberler-carrier-enum-01 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 April 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract ENUM as defined now in RFC3761 [1] is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes a minimally invasive scheme to provide both end-user and carrier data Haberler & Stastny Expires April 24, 2006 [Page 1] Internet-Draft Combined User and Carrier ENUM October 2005 in ENUM. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Carrier of Record . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Introducing a branch into the e164.arpa tree . . . . . . . . 4 5. Resolver behaviour options and the Carrier ENUM branch location . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Recommended resolver behaviour . . . . . . . . . . . . . . . 7 7. Zone file examples . . . . . . . . . . . . . . . . . . . . . 8 8. The Branch Location Record . . . . . . . . . . . . . . . . . 11 9. Security considerations . . . . . . . . . . . . . . . . . . 12 10. IANA considerations . . . . . . . . . . . . . . . . . . . . 13 11. Interoperability considerations . . . . . . . . . . . . . . 13 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1 Normative References . . . . . . . . . . . . . . . . . . 14 13.2 Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . 15 Haberler & Stastny Expires April 24, 2006 [Page 2] Internet-Draft Combined User and Carrier ENUM October 2005 1. Introduction ENUM as defined in RFC3761 is based on the end-user opt-in principle. While this has great potential to foster new services and end-user choice in the long-term, the current requirements for IP-based interconnection of carriers and VoIP Service Providers require the provisioning of all allocated or served (hosted) numbers of a participating carrier of record. Also, an interconnection scenario through Carrier ENUM typically implies underlying closed user arrangements where URIs are used in authenticated context, an assumption which cannot reasonably be imposed on User ENUM entries. While in principle solutions like compulsory opt-in through terms and conditions for end users are conceivable, there are substantial downsides to such an approach. ENUM for end-user provisioning remains an ill-suited solution for the PoI (point-of-interconnect) information discovery problem. Both from an OPEX (Operational Expenditure) perspective as well as overall resolution rates achievable through a given approach, a combined ENUM tree both for end-users and carrier of record ENUM stands to be superior over a forest of disparate private trees now as well as long-term. Also, as a common infrastructure easily supports both usage scenarios, a combined approach will support the end-user ENUM vision by driving down the average cost per number. Lastly, any later convergence between ENUM for end-users and carriers of record will be significantly easier and cheaper, thus benefiting users as well as carriers. For the rest of the document the terms User ENUM and Carrier ENUM will be used to distinguish between the two approaches. 2. The Carrier of Record In User ENUM, the entity or person having the right-to-use in a number has the sole discretion about the content of the associated domain and thus the zone content. Within a Carrier ENUM namespace, we use the term "carrier of record" for the entity having that discretion. This right typically lies with a service provider authorized to issue E.164 numbers for the provisioning of PSTN service under the authority of a National Regulatory Authority (NRA), but generally exhibits one or more of the following properties: o it has been assigned one or more national number ranges by an NRA. o it has been assigned a number range directly by the ITU, for instance a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878). Haberler & Stastny Expires April 24, 2006 [Page 3] Internet-Draft Combined User and Carrier ENUM October 2005 o it can be the recipient of a number porting operation. o it provides a PSTN point-of-interconnect for the number. Carrier ENUM is understood to mean a form of ENUM where such entitites have exclusive discretion about zone content. 3. Requirements A solution for combined User and Carrier ENUM within the e164.arpa tree should meet the following requirements: o A single DNS lookup should suffice to resolve any given number in the public DNS in both scenarios. o It should leave User ENUM resolution semantics and tree shape intact, i.e. requiring no wholesale changes to existing User ENUM resolvers or tree layout. o Additional functionality should only be imposed on carrier ENUM resolvers. o It should work with both closed and open numbering plans without resorting to wildcard records in the non-user controlled part of the DNS, both to avoid associated semantic problems as well as keeping the route to DNSSEC deployment open. o It should not require the introduction of new constructs within existing standards, such as new types or changed semantics of NAPTR records. o It should be possible to introduce the scheme in a timely manner, supporting current carrier needs. Consequently, it is desirable to deploy the scheme without re-opening already settled questions of roles, responsibilities and international coordination, and in particular the country code delegation process. o It should meet all reasonable privacy concerns about visibility of information an end user has no control over, for example discovery of unlisted numbers, or inadvertent disclosure of user identity. o It should keep the option open for other types of closed-user- group type applications, which might not naturally fit into the - predominantly voice oriented - Carrier ENUM scenario. Note in particular that we assume all entries to properly resolve in the public DNS, both user and carrier. Usage restrictions on Carrier ENUM records are to be handled at the URI level, and not by restriction on the visibility of entries in the public DNS. 4. Introducing a branch into the e164.arpa tree The method most easily fulfilling the abovementioned requirements is to branch off the e164.arpa tree into a subdomain at a given point, and deploy a Carrier ENUM subtree underneath without touching User ENUM semantics at all. For readability, we will use the 'carrier' Haberler & Stastny Expires April 24, 2006 [Page 4] Internet-Draft Combined User and Carrier ENUM October 2005 subdomain from now on, while in practice a single character subdomain like 'c' will suffice. For interoperability it is desirable to have that branch sit in a commonly agreed, or easily discoverable place. Several options for this branch location exist, among them are: o above the country code delegation level, e.g. '4.9.7.1.carrier.e164.arpa', alternatively: o somewhere below the country code delegation level, e.g. '4.9.7.carrier.1.e164.arpa' or 'carrier.4.9.7.1.e164.arpa'. In the first case, heavy involvement of ITU-T, RIPE as well as the applicable NRAs (National Regulatory Authorities) is needed during the setup phase. Also, reopening the discussion of the interim procedures already agreed is a tedious process, as is the adaptation of the current delegation mechanism. However, no changes to resolver semantics are required as this approach amounts to just a different apex definition for the resolver. Therefore the remainder of this paper addresses only the second scenario. This approach, putting aside significant process and timing concerns, appears to be an easier to manage long-term approach to tree naming. In the second case issues could be resolved as a national matter, or as a regional opt-in within in a given Numbering Plan Area such as the North American NPA. However, a convention is needed how, given a fully qualified E.164 [2] number, a resolver can determine the location of the carrier subdomain. However, ITU-T and IETF (IAB) involvement is only lightweight, e.g. to recommend the proper algorithm defined here to enable international interoperability. 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 Carrier ENUM tree. We believe the choice among the above options should not be predetermined for maximum flexibility and left to national or regional environments to decide. This suggests a method for Carrier ENUM resolution which can deal at runtime with whatever the decision for a country code, or a group of countries, happens to be. 5. Resolver behaviour options and the Carrier ENUM branch location A Carrier ENUM resolver thus needs to determine the place applicable in a given number to search for the 'carrier' subdomain for international interoperability, regardless what the national or group-of-countries setup decision was. Haberler & Stastny Expires April 24, 2006 [Page 5] Internet-Draft Combined User and Carrier ENUM October 2005 We propose a mechanism to discover this boundary dynamically for any given shape as follows: o the national or group-of-countries decision about subdomain location is documented in the e164.arpa tree proper by inserting a special DNS record into the country code zone. This branch location record (Section 8) (BLR) carries an integer value which points to the level in the tree where the carrier subtree branches off. Implementation options for the BLR are disussed below. o a resolver looking for a Carrier ENUM domain needs to retrieve this BLR once during first resolution within a country code, caching the result in a local table for later reuse. o while constructing the FQDN, the 'carrier' label is inserted at the position indicated by the BLR's integer value. For the abovementioned tree shape options (Section 4), the corresponding branch location record values in the 1.e164.arpa zone would be as follows: +---------------------------+-----------------+ | shape | branch location | +---------------------------+-----------------+ | 4.9.7.1.carrier.e164.arpa | 0 | | 4.9.7.carrier.1.e164.arpa | 1 | | carrier.4.9.7.1.e164.arpa | 4 | +---------------------------+-----------------+ Figure 1 The only remaining a-priori knowledge a Carrier ENUM resolver should 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 algorithm, the 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. Given the fact that the ITU 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 that way (for instance, in the unlikely case the ITU allocates a country code not according to Haberler & Stastny Expires April 24, 2006 [Page 6] Internet-Draft Combined User and Carrier ENUM October 2005 these rules), it is still possible to determine the branch location record by "iterating down" the tree. 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. 6. Recommended resolver behaviour A User ENUM resolver as per RFC3761 need not be aware of any Carrier ENUM conventions at all. A combined User and Carrier ENUM resolver shall behave as follows: The input to the resolver routine shall be: 1. the called number in fully qualified E.164 (international) format, 2. a 'subtree' parameter indicating whether the search should proceed in the User ENUM tree, or in the subtree indicated by the parameter (example: 'carrier' to indicate Carrier ENUM resolution, or a null value for defaulting to User ENUM resolution), 3. optionally a table or algorithm to easily detect country codes (Section 5), 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: 1. if the subtree parameter indicates a User ENUM search, proceed as per RFC3761. 2. If the subtree parameter indicates a Carrier ENUM query: 1. determine country code length. 2. consult cache table if a branch location for this country code was already retrieved since resolver boot time. 3. if not: retrieve the branch location record from the country code zone, and store the country code/branch location pair in the cache table. ("iterating down" - optional fallback for irregular country code) if the last step fails, iterate over the number up to five digits and try to retrieve the branch location record each time, again storing the country code/ branch location pair in the cache table if successful. Haberler & Stastny Expires April 24, 2006 [Page 7] Internet-Draft Combined User and Carrier ENUM October 2005 if both attempts fail, return failure and indicate NXDOMAIN. 4. (valid branch location found): insert the carrier label accordingly while creating the inverted dotted domain name. 5. search the DNS for any NAPTR records for the given number. It is assumed that already discovered branch location values are stored in a cache table of country code/branch location pairs. 7. Zone file examples Example 1 - carrier subtree branches of right under the country code +43 level, zone files for country code zone and carrier subtree zone. The BLR happens to be at the same level as the carrier subtree. Since they use the same name, the BLR needs to be below the zone cut in the carrier.3.4.e164.arpa zone. Note there is no change in the e164.arpa zone in this case, the carrier subtree can be introduced by nationally without further external interaction. Haberler & Stastny Expires April 24, 2006 [Page 8] Internet-Draft Combined User and Carrier ENUM October 2005 ; +43 country code zone $ORIGIN 3.4.e164.arpa. @ NS ns1.enum.at. @ NS ns2.enum.at. ; carrier subtree starts here carrier IN NS ns1-ce.enum.at. carrier IN NS ns2-ce.enum.at. ; BLR is at the same label, thus in the subdomain. ; top of +43 Carrier subtree zone $ORIGIN carrier.3.4.e164.arpa. @ NS ns1-ce.enum.at. @ NS ns2-ce.enum.at. ; Branch location record - value 2 ; meaning carrier subtree starts in CC zone: @ BLR 2 ; Carrier ENUM NAPTR example for +43(1)23456 6.5.4.3.2.1 NAPTR 100 10 "u" "E2U+sip" "!^(.*)$!sip:\\1@telco.at!" . Figure 2 Example 2 - country code +7 opted for carrier subtree under 7.carrier.e164.arpa, which is documented by the BLR with value 0 in the 7.e164.arpa zone. This implies consent with ITU and RIPE. Haberler & Stastny Expires April 24, 2006 [Page 9] Internet-Draft Combined User and Carrier ENUM October 2005 $ORIGIN 7.e164.arpa. @ NS ns1.enum.ru. @ NS ns2.enum.ru. ; ; Branch location record - value 0, meaning carrier tree ; starts in carrier.e164.arpa: c IN BLR 0 ; top of Carrier subtree zone $ORIGIN 7.carrier.e164.arpa. @ NS ns1-ce.enum.ru. @ NS ns2-ce.enum.ru. ; Carrier ENUM NAPTR example for +7(90)12345 5.4.3.2.1.0.9 NAPTR 100 10 "u" "E2U+sip" "!^(.*)$!sip:\\1@foo.ru!" . Figure 3 Example 3 - country code +1 opted for carrier subtree under +1 (NPA), i.e. 4 digits into the number. This would imply one zone per NPA. We show an example for the 794 NPA. This scenario, again, can be introduced without ITU and RIPE involvement. Haberler & Stastny Expires April 24, 2006 [Page 10] Internet-Draft Combined User and Carrier ENUM October 2005 $ORIGIN 1.e164.arpa. @ NS ns1.cc1enum.ca. @ NS ns2.cc1enum.ca. ; ; Branch location record - value 4 carrier BLR 4 ; delegation for 794 NPA - User ENUM 4.9.7 IN NS ns1-ue.cc1enum.org. 4.9.7 IN NS ns2-ue.cc1enum.org. ; delegation for 794 NPA - Carrier ENUM carrier.4.9.7 IN NS ns1-ce.cc1enum.org. carrier.4.9.7 IN NS ns2-ce.cc1enum.org. ; Carrier subtree for +1 794 NPA $ORIGIN carrier.4.9.7.1.e164.arpa @ NS ns1-ce.cc1enum.org. @ NS ns2-ce.cc1enum.org. ; Carrier ENUM NAPTR example for +1(794) 123 4567 7.6.5.4.3.2.1 NAPTR 100 10 "u" "E2U+sip" "!^(.*)$!sip:\\1@foo.com!" . Figure 4 8. The Branch Location Record The BLR is located below the country code level and conveys the name and location of a specific subtree. It has the same name as the Haberler & Stastny Expires April 24, 2006 [Page 11] Internet-Draft Combined User and Carrier ENUM October 2005 subtree branch label (thus both 'carrier' in the Carrier ENUM resolution context) and returns an integer value, indicating the position in the number where the subtree branch label is inserted while constructing the FQDN. We envisage several implementation options, such as: o a new DNS Resource Record (as used in the zone file examples above) o a NAPTR record with a new service definition for that purpose. o for trial purposes, a TXT record carrying the branch location as an integer value in the string argument. While technically equivalent, we believe the NAPTR option to be the most flexible. We solicit suggestions for the final choice. Note that this scheme is extensible: if, for example, it would be considered useful to create trees for other resolution contexts than carrier ENUM, that could be done by introducing another label. One such example could be the 'carrier default registration' (number range allocation information) recently suggested by the UK ENUM group. 9. Security considerations Privacy issues have been raised regarding unwarranted disclosure of user information by publishing Carrier 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 Carrier 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. Carrier 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 in the user-part of Haberler & Stastny Expires April 24, 2006 [Page 12] Internet-Draft Combined User and Carrier ENUM October 2005 the SIP URI either anonymized UserIDs or the E.164 number itself, such as sip:441632960084@example.telco.com . The definition of a new RR type or a new enumservice does not introduce security problems into the DNS. Usage of the Branch Location record conveys only static setup information under a country code subtree of e164.arpa. The intended use of DNSSEC within ENUM will prove authenticity of the conveyed value. 10. IANA considerations The following parameters need to be registered with IANA: 1. The name of the Carrier ENUM subdomain, for example 'carrier' (or 'c' for brevity). In the future other labels could be registered for different purposes. 2. According to RFC 3761, the IETF requested IANA to delegate the E164.ARPA domain following instructions provided by the IAB. Names within this zone are to be delegated to parties according to the ITU-T Recommendation E.164. If the second option outlined in this proposal is accepted, there will be no changes requested of IANA with respect to the E164.ARPA domain. However, if the first option outlined in this document is accepted, this would require IETF to request IANA to create a new sub-domain CARRIER.E164.ARPA. 3. for the branch location record, an RR type or NAPTR service defintion. 11. Interoperability considerations A resolver needs to indicate which information is requested - User or Carrier ENUM, or both. A user-ENUM-only resolver need not be aware of the carrier subtree and no changes with respect to RFC3761 semantics are required. A resolver desiring to retrieve Carrier ENUM or both types of records needs to be aware of the conventions laid out in this draft. 12. Acknowledgements We gratefully acknowledge suggestions and improvements by Jason Livingood and Tom Creighton of Comcast, Penn Pfautz of ATT, of Lawrence Conroy of Roke Manor Research, and Alexander Mayrhofer and Otmar Lendl of enum.at. 13. References Haberler & Stastny Expires April 24, 2006 [Page 13] Internet-Draft Combined User and Carrier ENUM October 2005 13.1 Normative References [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. 13.2 Informative References [2] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. Authors' Addresses Michael Haberler Internet Foundation Austria Waehringerstrasse 3/19 Wien A-1090 Austria Phone: +43 664 4213465 Email: mah@eunet.at URI: http://www.nic.at/ipa/ 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 April 24, 2006 [Page 14] Internet-Draft Combined User and Carrier ENUM October 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Haberler & Stastny Expires April 24, 2006 [Page 15]