Combined User and Infrastructure ENUM in the e164.arpa tree

ENUM (E.164 Number Mapping, RFC 3761) is a system that transforms E.164 numbers into domain names and then queries the DNS (Domain Name Service) for NAPTR (Naming Authority Pointer) records 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 by the carrier-of-record (voice service provider) for a specific E.164 number to publish a mapping of this telephone number to one or more Uniform Resource Identifiers (URIs). 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 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 . 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. This process of defining the Dynamic Delegation Discovery System (DDDS) application for Infrastructure ENUM is work in progress . This is called the long term solution. This document presents an interim solution for Infrastructure ENUM and a mechanism for transitioning to a 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 in . 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 in . Finally, provides a way that implementations following the procedures of and 5 may be seamlessly redirected to the long-term solution, when it becomes available.

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.

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 becomes available. 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 continue to work without any modification. Because of various reasons (e.g. potentially different delegation points, different reliability requirements, use of DNS wildcards), 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. 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. This allows countries using a dedicated country code to introduce the Interim Solution as a national matter by the concerned National Regulation Authority (NRA). The governing body of a shared country code and the owner of a global network code can also chose to implement this solution within their area of responsibility. Under this approach, ITU-T (International Telecommunication Union / Telecommunication Standardization Sector) and IETF (IAB) involvement is only lightweight, e.g. to recommend the proper algorithm defined here to enable international interoperability.

RFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS) application according to RFC 3401. As such, ENUM defines the following components of the DDDS algorithm: Application Unique String First Well Known Rule Expected Output Valid Databases The "Valid Databases" part contains the transformation of a E.164 telephone number into a domain name. Section 2.4 of RFC 3761 uses the following four step algorithm for this: Remove all characters with the exception of the digits. Put dots (".") between each digit. Reverse the order of the digits. Append the string ".e164.arpa" to the end. The Interim Solution for Infrastructure ENUM uses a modified version of this algorithm: Determine the proper POSITION parameter for this E.164 number according to the algorithm in . Build an ordered list of single-digit strings from all digits appearing in the telephone number. All non-digit characters are ignored. Insert a string consisting of "i" after POSITION strings into this list. If the list of strings was shorter than POSITION elements, then report an error. Reverse the order of the list. Append the string "e164.arpa" to the end of the list. 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 solution differs from straight RFC 3761 ENUM. All other parts of User-ENUM, including the enumservices registrations, apply to I-ENUM as well.

In order to allow for the deployment of this Interim Solution independently 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) managed currently 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 ( 6.2.1) and for international E.164-numbers for global services ( 6.2.2) the most sensible choice for POSITION is 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 ( 6.2.3) 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 ( 6.2.4) the value for POSITION is 4. The authoritative source for up-to-date country code and network Identity Code allocations is a published by ITU-T as a complement to the recommendation E.164 . The current version of this complement is available from 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. The POSITION parameter for the NANP is thus 1. As of 2007, the POSITION value for a specific E.164 number can be determined with the following algorithm:

If the number starts with 1 or 7 then POSITION is 1 If the number is in one of the following 2-digit country codes: 20, 27, 30-34, 36, 39, 40, 41, 43-49, 51-58, 60-66, 81, 82, 84, 86, 90-95, or 98, then POSITION is 2. If the number starts with 388 or 881, then POSITION is 4 If the number starts with 878 or 882, then POSITION is 5 If the number starts with 883 and the next digit is < 5, then POSITION is 6 If the number starts with 883 and the next digit is >= 5, then POSITION is 7 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 a country split as happened recently e.g. to Yugoslavia. Regarding network codes, the ITU-T has up to 2007 only allocated one and two digit ICs. Assignments of three and four digit ICs started in May 2007 in the +883 country code. A further change in the ITU-T policy in this respect will need to be reflected in the above algorithm.

The proposed long-term solution for Infrastructure ENUM 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 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 which have already switched to the long-term solution. This SHOULD be done by placing DNAME 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 by Section 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. 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.

These are two examples of how E.164 numbers translate to 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 as defined in operates on "+44 2079460123": "+44 2079460123" is within a 2-digit country code, thus POSITION is 2. The list of strings is ("4","4","2","0","7","9","4","6","0","1","2","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") Reversing the list gives: ("3","2","1","0","6","4","9","7","0","2","i","4","4") Appending "e164.arpa" yields: ("3","2","1","0","6","4","9","7","0","2","i","4","4","e164.arpa") Concatenation with dots: "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.

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 .

None.

We gratefully acknowledge suggestions and improvements by Jason Livingood and Tom Creighton of Comcast, Penn Pfautz of ATT, Lawrence Conroy of Roke Manor Research, Jim Reid, and Alexander Mayrhofer of enum.at.