Movatterモバイル変換

Network Working Group                                        M. HaberlerRequest for Comments: 5527                                           IPACategory: Informational                                         O. Lendl                                                                 enum.at                                                              R. Stastny                                                            Unaffiliated                                                                May 2009Combined User and Infrastructure ENUM in the e164.arpa TreeStatus of This Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Copyright Notice   Copyright (c) 2009 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents in effect on the date of   publication of this document (http://trustee.ietf.org/license-info).   Please review these documents carefully, as they describe your rights   and restrictions with respect to this document.Abstract   This memo defines an interim solution for Infrastructure ENUM in   order to allow a combined User and Infrastructure ENUM implementation   in e164.arpa as a national choice.  This interim solution will be   deprecated after implementation of the long-term solution.Haberler, et al.             Informational                      [Page 1]

RFC 5527         Combined User and Infrastructure ENUM          May 2009Table of Contents1. Introduction ....................................................22. Terminology .....................................................33. Interim Solution ................................................34. The Algorithm ...................................................45. Determining the Position of the Branch ..........................56. Transition to the Long-Term Solution ............................67. Examples ........................................................78. Security Considerations .........................................89. Acknowledgments .................................................910. References .....................................................910.1. Normative References ......................................910.2. Informative References ....................................91.  Introduction   ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms   E.164 numbers [E164] into domain names and then queries the DNS   (Domain Name Service) [RFC1034] for NAPTR (Naming Authority Pointer)   records [RFC3401] in order to look up which services are available   for a specific domain name.   ENUM, as defined inRFC 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 inRFC3761 [RFC3761] by the carrier-of-record (voice service provider)   [RFC5067] for a specific E.164 number [E164] in order to publish a   mapping of this telephone number to one or more Uniform Resource   Identifiers (URIs) [RFC3986].   Other voice service providers can query the DNS for this mapping and   use the resulting URIs as input into their call-routing algorithm.   These URIs are separate from any URIs that the end-user who registers   an 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 [RFC5067].   Using the same E.164 number to domain mapping techniques for other   applications under a different, internationally agreed-upon apex   (instead of e164.arpa) is straightforward on the technical side.   This process of defining the Dynamic Delegation Discovery System   (DDDS) [RFC3401] application for Infrastructure ENUM is defined in   [RFC5526].  This is the long-term solution.Haberler, et al.             Informational                      [Page 2]

RFC 5527         Combined User and Infrastructure ENUM          May 2009   This document presents an interim solution for Infrastructure ENUM   and a mechanism for transitioning to the long-term solution.  The   interim solution is based on establishing a branch in the e164.arpa   tree, which resolvers may locate by following the algorithm described   inSection 4.  The location of the branch is dependent upon country-   code length, and thus resolvers must determine the position of the   branch based on the method described inSection 5.  Finally,Section 6 provides a way that implementations following the   procedures of Sections4 and5 may be seamlessly redirected to the   long-term solution, when it becomes available.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 inBCP 14,RFC 2119   [RFC2119].3.  Interim Solution   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 interoperable   Infrastructure ENUM tree immediately.  The interim solution will be   deprecated when the long-term solution [RFC5526] is deployed.  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 inRFC 3761 [RFC3761] continue to work without any   modification.   Because of various reasons (e.g., potentially different delegation   points, different reliability requirements, and use of DNS   wildcards), sharing a single domain name between the user itself and   the respective carrier for a given number is not possible.  Hence, a   different domain name must be used to store infrastructure ENUM   information.   In order to avoid the delays associated with the long-term solution,   the existing delegations and agreements around e164.arpa need to be   leveraged.   The method most easily fulfilling the requirements is to branch off   the e164.arpa tree into a subdomain at the country-code delegation   level below e164.arpa and deploy an Infrastructure ENUM subtree   underneath, without touching User ENUM semantics at all.Haberler, et al.             Informational                      [Page 3]

RFC 5527         Combined User and Infrastructure ENUM          May 2009   This allows countries using a dedicated country code to introduce the   interim solution as a national matter to the concerned National   Regulation Authority (NRA).  The governing body of a shared country   code and the owner of a global network code can also choose to   implement this solution within their area of responsibility.   Under this approach, ITU-T (International Telecommunication Union /   Telecommunication Standardization Sector), IETF, and IAB involvement   is only lightweight, e.g., to recommend the proper algorithm defined   here to enable international interoperability.4.  The AlgorithmRFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS)   application according toRFC 3401 [RFC3401].  As such, ENUM defines   the following components of the DDDS algorithm:   1.  Application Unique String   2.  First Well-Known Rule   3.  Expected Output   4.  Valid Databases   The "Valid Databases" part contains the transformation of an E.164   telephone number into a domain name.Section 2.4 of RFC 3761 uses   the following 4-step algorithm for this:   1.  Remove all characters with the exception of the digits.   2.  Put dots (".") between each digit.   3.  Reverse the order of the digits.   4.  Append the string ".e164.arpa" to the end.   The interim solution for Infrastructure ENUM uses a modified version   of this algorithm:   1.  Determine the proper POSITION parameter for this E.164 number       according to the algorithm inSection 5 of this document.   2.  Build an ordered list of single-digit strings from all digits       appearing in the telephone number.  All non-digit characters are       ignored.Haberler, et al.             Informational                      [Page 4]

RFC 5527         Combined User and Infrastructure ENUM          May 2009   3.  Insert a string consisting of "i" into this list, after POSITION       strings.  If the list of strings was shorter than POSITION       elements, then report an error.   4.  Reverse the order of the list.   5.  Append the string "e164.arpa" to the end of the list.   6.  Create a single domain name by joining the list together with       dots (".") between each string.   This is the only point where the interim Infrastructure ENUM (I-ENUM)   solution differs from straightRFC 3761 ENUM.  All other parts of   User ENUM, including the enumservices registrations, apply to I-ENUM   as well.5.  Determining the Position of the Branch   In order to allow for the deployment of this interim solution   independent of IAB/ITU-T/RIPE-NCC negotiations, the branching label   "i" cannot be inserted in the Tier-0 zone (i.e., the e164.arpa zone   itself) currently managed by RIPE NCC.  This condition acts as a   lower bound on the choice of the POSITION parameter.   For international E.164-numbers for geographic areas (Section 6.2.1   of [E164]) and for international E.164-numbers for global services   (Section 6.2.2 of [E164]), the most sensible choice for POSITION is   the number of digits in the country code of the number in question.   This places the branch directly under the country-code level within   the e164.arpa ENUM tree.   For international E.164-number for networks (Section 6.2.3 of   [E164]), the appropriate choice for POSITION is the combined length   of the CC (Country Code) and IC (Identification Code) fields.   For international E.164-number for groups of countries (Section 6.2.4   of [E164]), the value for POSITION is 4.   The authoritative source for up-to-date country code and network   Identification Code allocations is published by the ITU-T as a   complement to the recommendation E.164 [E164].  The current version   of this complement is available from the ITU website under "ITU-T /   Service Publications".   Please note that country code 1 of the North American Numbering Plan   (NANP) does not fall under the ITU classification of "groups of   countries", but is a "shared country code" for a geographic area.   Thus, the POSITION parameter for the NANP is 1.Haberler, et al.             Informational                      [Page 5]

RFC 5527         Combined User and Infrastructure ENUM          May 2009   As of 2007, the POSITION value for a specific E.164 number can be   determined with the following algorithm:   o  If the number starts with 1 or 7, then POSITION is 1.   o  If the number is in one of the following 2-digit country codes,      then POSITION is 2: 20, 27, 30-34, 36, 39, 40, 41, 43-49, 51-58,      60-66, 81, 82, 84, 86, 90-95, or 98.   o  If the number starts with 388 or 881, then POSITION is 4.   o  If the number starts with 878 or 882, then POSITION is 5.   o  If the number starts with 883 and the next digit is < 5, then      POSITION is 6.   o  If the number starts with 883 and the next digit is >= 5, then      POSITION is 7.   o  In all other cases, POSITION is 3.   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 list of existing 1- and 2-digit country codes   can be considered very stable.  The only problem may be for a country   that has split, as happened recently, for example, to Yugoslavia.   Regarding network codes, up to 2007, the ITU-T has only allocated 1-   and 2-digit ICs.  Assignments of 3- and 4-digit ICs started in May   2007 in the +883 country code.  Any further change in the ITU-T   policy in this respect will need to be reflected in the above   algorithm.6.  Transition to the Long-Term Solution   The proposed long-term solution for Infrastructure ENUM [RFC5526] is   the establishment of a new zone apex for that tree.  This apex will   play the same role as "e164.arpa" does for User ENUM.   It is unrealistic to assume that all countries and all ENUM clients   will manage to migrate from the interim solution to the long-term   solution at a single point in time.  It is thus necessary to plan for   an incremental transition.   In order to achieve this, clients using the interim solution need to   be redirected to the long-term I-ENUM tree for all country codes that   have already switched to the long-term solution.  This SHOULD be doneHaberler, et al.             Informational                      [Page 6]

RFC 5527         Combined User and Infrastructure ENUM          May 2009   by placing DNAME [RFC2672] records at the branch (the "i") label   pointing to the appropriate domain name in the long-term I-ENUM tree.   All descendants at that branch label location where the DNAME record   is inserted MUST be removed, as required bySection 3 of RFC 2672.   Therefore, ALL entities involved in making or answering DNS queries   for I-ENUM MUST fully support the DNAME record type and its   semantics.  In particular, entities involved in I-ENUM lookups MUST   correctly handle responses containing synthesized CNAMEs that may be   generated as a consequence of DNAME processing by any other element   in resolution, typically an iterative mode resolving name server.   These entities MUST also apply adequate measures to detect loops and   prevent non-terminating resolutions because of improperly configured   DNAME records or combinations of DNAME and CNAME records.   Note: Some caching name server implementations are known to handle   DNAMEs incorrectly.  In the worst case, such bugs could stay   undetected until a country transitions to the long-term solution.   Therefore, ensuring full DNAME support from the start (and carefully   testing that it actually works) is important.   The domain name for the branch location and its DNAME record SHOULD   be removed once the transition to the long-term solution is completed   and all entities involved in I-ENUM have migrated to the new zone   apex for I-ENUM.7.  Examples   These are two examples of how E.164 numbers translate to   Infrastructure ENUM domains according to the interim solution.   +1 21255501234          4.3.2.1.0.5.5.5.2.1.2.i.1.e164.arpa   +44 2079460123          3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa   Here is the list of the intermediate steps for the second example to   visualize how the algorithm defined inSection 4 operates on "+44   2079460123":   1.  "+44 2079460123" is within a 2-digit country code; thus, POSITION       is 2.   2.  The list of strings is       ("4","4","2","0","7","9","4","6","0","1","2","3")   3.  POSITION is 2; thus, "i" is inserted between the second and the       third string, yielding:       ("4","4","i","2","0","7","9","4","6","0","1","2","3")Haberler, et al.             Informational                      [Page 7]

RFC 5527         Combined User and Infrastructure ENUM          May 2009   4.  Reversing the list gives:       ("3","2","1","0","6","4","9","7","0","2","i","4","4")   5.  Appending "e164.arpa" yields:       ("3","2","1","0","6","4","9","7","0","2","i","4","4","e164.arpa")   6.  Concatenation with dots yields:       "3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa"   After the introduction of the long-term Infrastructure ENUM solution,   using, for example, "ienum.example.net" as the new apex for I-ENUM,   the administrators of +44 can implement a smooth transition by   putting the following DNAME record in their zone:   i.4.4.e164.arpa.    IN DNAME 4.4.ienum.example.net.   This way, clients using the interim I-ENUM solution end up querying   the same tree as clients implementing the long-term solution.8.  Security Considerations   Privacy issues have been raised regarding the unwarranted disclosure   of user information that would result from publishing Infrastructure   ENUM information in the public DNS.  For instance, such disclosure   could be used for harvesting numbers in service or obtaining 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 or not a number is served 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 whether listed or unlisted, will prevent mining attempts   for such number attributes.   The result will be that the information in the public DNS will mirror   number-range allocation information, but no 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 the 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.Haberler, et al.             Informational                      [Page 8]

RFC 5527         Combined User and Infrastructure ENUM          May 20099.  Acknowledgments   We gratefully acknowledge suggestions and improvements by Jason   Livingood and Tom Creighton of Comcast, Penn Pfautz of AT&T, Lawrence   Conroy of Roke Manor Research, Jim Reid, and Alexander Mayrhofer of   enum.at.10.  References10.1.  Normative References   [E164]     ITU-T, "The International Public Telecommunication Number              Plan", Recommendation E.164, February 2005.   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",              STD 13,RFC 1034, November 1987.   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997.   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",RFC 2672, August 1999.   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)              Part One: The Comprehensive DDDS",RFC 3401, October 2002.   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform              Resource Identifiers (URI) Dynamic Delegation Discovery              System (DDDS) Application (ENUM)",RFC 3761, April 2004.   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform              Resource Identifier (URI): Generic Syntax", STD 66,RFC 3986, January 2005.10.2.  Informative References   [RFC5067]  Lind, S. and P. Pfautz, "Infrastructure ENUM              Requirements",RFC 5067, November 2007.   [RFC5526]  Livingood, J., Pfautz, P., and R. Stastny, "The E.164 to              Uniform Resource Identifiers (URI) Dynamic Delegation              Discovery System (DDDS) Application for Infrastructure              ENUM",RFC 5526, April 2007.Haberler, et al.             Informational                      [Page 9]

RFC 5527         Combined User and Infrastructure ENUM          May 2009Authors' Addresses   Michael Haberler   Internet Foundation Austria   Karlsplatz 1/2/9   Wien  1010   Austria   Phone: +43 664 4213465   EMail: ietf@mah.priv.at   URI:http://www.nic.at/ipa/   Otmar Lendl   enum.at GmbH   Karlsplatz 1/2/9   Wien  A-1010   Austria   Phone: +43 1 5056416 33   EMail: otmar.lendl@enum.at   URI:http://www.enum.at/   Richard Stastny   Unaffiliated   Anzbachgasse 43   1140 Vienna   Austria   Phone: +43 664 420 4100   EMail: richardstastny@gmail.comHaberler, et al.             Informational                     [Page 10]