diff options
Diffstat (limited to 'doc/rfc/rfc5527.txt')
| -rw-r--r-- | doc/rfc/rfc5527.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc5527.txt b/doc/rfc/rfc5527.txt new file mode 100644 index 0000000..7e28415 --- /dev/null +++ b/doc/rfc/rfc5527.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group M. Haberler +Request for Comments: 5527 IPA +Category: Informational O. Lendl + enum.at + R. Stastny + Unaffiliated + May 2009 + + + Combined User and Infrastructure ENUM in the e164.arpa Tree + +Status 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 to BCP 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 2009 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. Interim Solution ................................................3 + 4. The Algorithm ...................................................4 + 5. Determining the Position of the Branch ..........................5 + 6. Transition to the Long-Term Solution ............................6 + 7. Examples ........................................................7 + 8. Security Considerations .........................................8 + 9. Acknowledgments .................................................9 + 10. References .....................................................9 + 10.1. Normative References ......................................9 + 10.2. Informative References ....................................9 + +1. 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 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 [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 + in Section 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 in Section 5. Finally, + Section 6 provides a way that implementations following the + procedures of Sections 4 and 5 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 in BCP 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 in RFC 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 Algorithm + + RFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS) + application according to RFC 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 in Section 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 straight RFC 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 done + + + +Haberler, 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 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. + + 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 in Section 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 2009 + + +9. 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. References + +10.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 2009 + + +Authors' 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.com + + + + + + + + + + + + + + + + + + + + +Haberler, et al. Informational [Page 10] + |