idnits 2.17.1 draft-ietf-enum-combined-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2009) is 5531 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM -- Telephone Number Mapping M. Haberler 3 Working Group IPA 4 Internet-Draft O. Lendl 5 Intended status: Informational enum.at 6 Expires: September 6, 2009 R. Stastny 7 Oefeg 8 March 5, 2009 10 Combined User and Infrastructure ENUM in the e164.arpa tree 11 draft-ietf-enum-combined-09 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 6, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This memo defines an interim solution for Infrastructure ENUM to 50 allow a combined User and Infrastructure ENUM implementation in 51 e164.arpa as a national choice. This interim solution will be 52 deprecated after approval and implementation of the long-term 53 solution. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Interim Solution . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Determing the Position of the Branch . . . . . . . . . . . . . 6 67 6. Transition to the long-term Solution . . . . . . . . . . . . . 7 69 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8. Security considerations . . . . . . . . . . . . . . . . . . . 9 73 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 11.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 ENUM (E.164 Number Mapping, RFC 3761 [RFC3761]) is a system that 86 transforms E.164 numbers [refs.E164] into domain names and then 87 queries the DNS (Domain Name Service) [RFC1034] for NAPTR (Naming 88 Authority Pointer) records [RFC3401] to look up which services are 89 available for a specific domain name. 91 ENUM as defined in RFC 3761 (User-ENUM) is not well suited for the 92 purpose of interconnection by carriers and voice service providers, 93 as can be seen by the use of various private tree arrangements based 94 on ENUM mechanisms. 96 Infrastructure ENUM is defined as the use of the technology in RFC 97 3761 [RFC3761] by the carrier-of-record [RFC5067] (voice service 98 provider) for a specific E.164 number [refs.E164] to publish a 99 mapping of this telephone number to one or more Uniform Resource 100 Identifiers (URIs) [RFC3986]. 102 Other voice service providers can query the DNS for this mapping and 103 use the resulting URIs as input into their call routing algorithm. 104 These URIs are separate from any URIs that the end-user who registers 105 his E.164 number in ENUM may wish to associate with that E.164 106 number. 108 The requirements, terms and definitions for Infrastructure ENUM are 109 defined in [RFC5067]. 111 Using the same E.164 number to domain mapping techniques for other 112 applications under a different, internationally agreed apex (instead 113 of e164.arpa) is straightforward on the technical side. This process 114 of defining the Dynamic Delegation Discovery System (DDDS) [RFC3401] 115 application for Infrastructure ENUM is work in progress 116 [I-D.ietf-enum-infrastructure]. This is called the long term 117 solution. 119 This document presents an interim solution for Infrastructure ENUM 120 and a mechanism for transitioning to a long-term solution. The 121 interim solution is based on establishing a branch in the e164.arpa 122 tree, which resolvers may locate by following the algorithm described 123 in Section 4. The location of the branch is dependent upon country 124 code length, and thus resolvers must determine the position of the 125 branch based on the method described in Section 5. Finally, 126 Section 6 provides a way that implementations following the 127 procedures of Section 4 and 5 may be seamlessly redirected to the 128 long-term solution, when it becomes available. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in BCP 14, RFC 2119 135 [RFC2119]. 137 3. Interim Solution 139 The agreements to establish the long-term solution may take some 140 time. It was therefore decided to develop an Interim Solution that 141 can be used by individual countries to implement an interoperable 142 Infrastructure ENUM tree immediately. The Interim Solution will be 143 deprecated when the long-term solution becomes available. It is 144 therefore also required that the Interim Solution includes a smooth 145 migration path to the long-term solution. 147 It is also required that existing ENUM clients querying User ENUM as 148 defined in RFC 3761 [RFC3761] continue to work without any 149 modification. 151 Because of various reasons (e.g. potentially different delegation 152 points, different reliability requirements, use of DNS wildcards), 153 sharing a single domain name between the user itself and the 154 respective carrier for a number is not possible. Hence, a different 155 domain name must be used to store infrastructure ENUM information. 157 In order to avoid the delays associated with the long term solution, 158 the existing delegations and agreements around e164.arpa need to be 159 leveraged. 161 The method most easily fulfilling the requirements is to branch off 162 the e164.arpa tree into a subdomain at the country code delegation 163 level below e164.arpa, and deploy an Infrastructure ENUM subtree 164 underneath without touching User ENUM semantics at all. 166 This allows countries using a dedicated country code to introduce the 167 Interim Solution as a national matter by the concerned National 168 Regulation Authority (NRA). The governing body of a shared country 169 code and the owner of a global network code can also chose to 170 implement this solution within their area of responsibility. 172 Under this approach, ITU-T (International Telecommunication Union / 173 Telecommunication Standardization Sector) and IETF (IAB) involvement 174 is only lightweight, e.g. to recommend the proper algorithm defined 175 here to enable international interoperability. 177 4. The Algorithm 179 RFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS) 180 application according to RFC 3401 [RFC3401]. As such, ENUM defines 181 the following components of the DDDS algorithm: 183 1. Application Unique String 184 2. First Well Known Rule 185 3. Expected Output 186 4. Valid Databases 188 The "Valid Databases" part contains the transformation of a E.164 189 telephone number into a domain name. Section 2.4 of RFC 3761 uses 190 the following four step algorithm for this: 192 1. Remove all characters with the exception of the digits. 193 2. Put dots (".") between each digit. 194 3. Reverse the order of the digits. 195 4. Append the string ".e164.arpa" to the end. 197 The Interim Solution for Infrastructure ENUM uses a modified version 198 of this algorithm: 200 1. Determine the proper POSITION parameter for this E.164 number 201 according to the algorithm in Section 5. 203 2. Build an ordered list of single-digit strings from all digits 204 appearing in the telephone number. All non-digit characters are 205 ignored. 207 3. Insert a string consisting of "i" after POSITION strings into 208 this list. If the list of strings was shorter than POSITION 209 elements, then report an error. 211 4. Reverse the order of the list. 213 5. Append the string "e164.arpa" to the end of the list. 215 6. Create a single domain-name by joining the list together with 216 dots (".") between each string. 218 This is the only point where the interim Infrastructure ENUM solution 219 differs from straight RFC 3761 ENUM. All other parts of User-ENUM, 220 including the enumservices registrations, apply to I-ENUM as well. 222 5. Determing the Position of the Branch 224 In order to allow for the deployment of this Interim Solution 225 independently of IAB/ITU-T/RIPE-NCC negotiations the branching label 226 "i" cannot be inserted in the Tier-0 zone (i.e. the e164.arpa zone 227 itself) managed currently by RIPE NCC. This condition acts as a 228 lower bound on the choice of the POSITION parameter. 230 For international E.164-numbers for geographic areas ([refs.E164] 231 6.2.1) and for international E.164-numbers for global services 232 ([refs.E164] 6.2.2) the most sensible choice for POSITION is number 233 of digits in the country code of the number in question. This places 234 the branch directly under the country code level within the e164.arpa 235 ENUM tree. 237 For international E.164-number for networks ([refs.E164] 6.2.3) the 238 appropriate choice for POSITION is the combined length of the CC 239 (Country Code) and IC (Identification Code) fields. 241 For international E.164-number for groups of countries ([refs.E164] 242 6.2.4) the value for POSITION is 4. 244 The authoritative source for up-to-date country code and network 245 Identity Code allocations is a published by ITU-T as a complement to 246 the recommendation E.164 [refs.E164]. The current version of this 247 complement is available from ITU website under "ITU-T / Service 248 Publications". 250 Please note that country code 1 of the North American Numbering Plan 251 (NANP) does not fall under the ITU classification of "groups of 252 countries", but is a "shared country code" for a geographic area. 253 The POSITION parameter for the NANP is thus 1. 255 As of 2007, the POSITION value for a specific E.164 number can be 256 determined with the following algorithm: 258 o If the number starts with 1 or 7 then POSITION is 1 259 o If the number is in one of the following 2-digit country codes: 260 20, 27, 30-34, 36, 39, 40, 41, 43-49, 51-58, 60-66, 81, 82, 84, 261 86, 90-95, or 98, then POSITION is 2. 262 o If the number starts with 388 or 881, then POSITION is 4 263 o If the number starts with 878 or 882, then POSITION is 5 264 o If the number starts with 883 and the next digit is < 5, then 265 POSITION is 6 266 o If the number starts with 883 and the next digit is >= 5, then 267 POSITION is 7 269 o In all other cases, POSITION is 3. 271 Figure 1 273 Given the fact that the ITU-T recently allocated only 3-digit country 274 codes, there are no more spare 1- and 2-digit country codes and 275 existing 1- and 2-digit country codes are extremely unlikely to be 276 recovered, the above list of existing 1- and 2-digit country codes 277 can be considered very stable. The only problem may be a country 278 split as happened recently e.g. to Yugoslavia. 280 Regarding network codes, the ITU-T has up to 2007 only allocated one 281 and two digit ICs. Assignments of three and four digit ICs started 282 in May 2007 in the +883 country code. A further change in the ITU-T 283 policy in this respect will need to be reflected in the above 284 algorithm. 286 6. Transition to the long-term Solution 288 The proposed long-term solution for Infrastructure ENUM 289 [I-D.ietf-enum-infrastructure] is the establishment of a new zone 290 apex for that tree. This apex will play the same role as "e164.arpa" 291 does for User-ENUM. 293 It is unrealistic to assume that all countries and all ENUM clients 294 will manage to migrate from the Interim Solution to the long-term 295 solution at single point in time. It is thus necessary to plan for 296 an incremental transition. 298 In order to achieve this, clients using the interim solution need to 299 be redirected to the long-term I-ENUM tree for all country codes 300 which have already switched to the long-term solution. This SHOULD 301 be done by placing DNAME [RFC2672] records at the branch (the "i") 302 label pointing to the appropriate domain name in the long-term I-ENUM 303 tree. All descendants at that branch label location where the DNAME 304 record is inserted MUST be removed as required by Section 3 of RFC 305 2672. 307 Therefore ALL entities involved in making or answering DNS queries 308 for I-ENUM MUST fully support the DNAME record type and its 309 semantics. In particular, entities involved in I-ENUM lookups MUST 310 correctly handle responses containing synthesized CNAMEs that may be 311 generated as a consequence of DNAME processing by any other element 312 in resolution, typically an iterative mode resolving name server. 313 These entities MUST also apply adequate measures to detect loops and 314 prevent non-terminating resolutions because of improperly configured 315 DNAME records or combinations of DNAME and CNAME records. 317 Note: Some caching name server implementations are known to handle 318 DNAMEs incorrectly. In the worst case, such bugs could stay 319 undetected until some country transitions to the long-term solution. 320 Therefore, ensuring full DNAME support from the start (and carefully 321 testing that it actually works) is important. 323 The domain name for the branch location and its DNAME record SHOULD 324 be removed once the transition to the long-term solution is completed 325 and all entities involved in I-ENUM have migrated to the new zone 326 apex for I-ENUM. 328 7. Examples 330 These are two examples of how E.164 numbers translate to to 331 Infrastructure ENUM domains according to the Interim Solution. 333 +1 21255501234 4.3.2.1.0.5.5.5.2.1.2.i.1.e164.arpa 334 +44 2079460123 3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa 336 Here is the list of the intermediate steps for the second example to 337 visualize how the algorithm as defined in Section 4 operates on "+44 338 2079460123": 340 1. "+44 2079460123" is within a 2-digit country code, thus POSITION 341 is 2. 343 2. The list of strings is 344 ("4","4","2","0","7","9","4","6","0","1","2","3"). 346 3. POSITION is 2, thus "i" is inserted between the second and the 347 third string, yielding: 348 ("4","4","i","2","0","7","9","4","6","0","1","2","3") 350 4. Reversing the list gives: 351 ("3","2","1","0","6","4","9","7","0","2","i","4","4") 353 5. Appending "e164.arpa" yields: 354 ("3","2","1","0","6","4","9","7","0","2","i","4","4","e164.arpa") 356 6. Concatenation with dots: "3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa" 358 After the introduction of the long term Infrastructure ENUM solution 359 using for example "ienum.example.net" as the new apex for I-ENUM, the 360 administrators of +44 can implement a smooth transition by putting 361 the following DNAME record in their zone: 363 i.4.4.e164.arpa. IN DNAME 4.4.ienum.example.net. 365 This way, clients using the interim I-ENUM solution end up querying 366 the same tree as clients implementing the long-term solution. 368 8. Security considerations 370 Privacy issues have been raised regarding unwarranted disclosure of 371 user information by publishing Infrastructure ENUM information in the 372 public DNS, for instance the use for harvesting of numbers in 373 service, or unlisted numbers. 375 Given that number range allocation is public information, we believe 376 the easiest way to cope with such concerns is to fully unroll 377 allocated number ranges in the Infrastructure ENUM subtree, wherever 378 such privacy concerns exist. Whether a number is served or not would 379 be exposed by the carrier of record when an attempt is made to 380 contact the corresponding URI. We assume this to be an authenticated 381 operation, which would not leak information to unauthorized parties. 383 Entering all numbers in an allocated number range, whether serviced 384 or not, or listed or unlisted, will prevent mining attempts for such 385 number attributes. 387 The result would be that the information in the public DNS would 388 mirror number range allocation information, but not more. 389 Infrastructure ENUM will not tell you more than you can get by just 390 dialing numbers. 392 The URI pointing to the destination network of the Carrier of Record 393 should also not disclose any privacy information about the identity 394 of end-user. It is therefore recommended to use either anonymized 395 UserIDs or the E.164 number itself in the user-part of the URI, such 396 as in sip:+441632960084@example.com . 398 9. IANA considerations 400 None. 402 10. Acknowledgments 404 We gratefully acknowledge suggestions and improvements by Jason 405 Livingood and Tom Creighton of Comcast, Penn Pfautz of ATT, Lawrence 406 Conroy of Roke Manor Research, Jim Reid, and Alexander Mayrhofer of 407 enum.at. 409 11. References 411 11.1. Normative References 413 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 414 Resource Identifiers (URI) Dynamic Delegation Discovery 415 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 417 [refs.E164] 418 ITU-T, "The International Public Telecommunication Number 419 Plan", Recommendation E.164, February 2005. 421 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 422 STD 13, RFC 1034, November 1987. 424 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 425 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 427 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 428 Resource Identifier (URI): Generic Syntax", STD 66, 429 RFC 3986, January 2005. 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 435 RFC 2672, August 1999. 437 11.2. Informative References 439 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 440 Requirements", RFC 5067, November 2007. 442 [I-D.ietf-enum-infrastructure] 443 Livingood, J., "The E.164 to Uniform Resource Identifiers 444 (URI) Dynamic Delegation Discovery System (DDDS) 445 Application for Infrastructure ENUM", 446 draft-ietf-enum-infrastructure-07 (work in progress), 447 December 2007. 449 Authors' Addresses 451 Michael Haberler 452 Internet Foundation Austria 453 Karlsplatz 1/2/9 454 Wien 1010 455 Austria 457 Phone: +43 664 4213465 458 Email: mah@inode.at 459 URI: http://www.nic.at/ipa/ 461 Otmar Lendl 462 enum.at GmbH 463 Karlsplatz 1/2/9 464 Wien A-1010 465 Austria 467 Phone: +43 1 5056416 33 468 Email: otmar.lendl@enum.at 469 URI: http://www.enum.at/ 471 Richard Stastny 472 Oefeg 473 Postbox 147 474 Vienna A-1030 475 Austria 477 Phone: +43 664 420 4100 478 Email: richard.stastny@oefeg.at 479 URI: http://www.oefeg.at