idnits 2.17.1 draft-haberler-carrier-enum-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 433. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 23, 2006) is 6517 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3761 (ref. '2') (Obsoleted by RFC 6116, RFC 6117) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. '4') ** Obsolete normative reference: RFC 2396 (ref. '5') (Obsoleted by RFC 3986) == Outdated reference: A later version (-02) exists of draft-lendl-enum-branch-location-record-01 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-04) exists of draft-ietf-enum-infrastructure-enum-reqs-02 == Outdated reference: A later version (-07) exists of draft-ietf-enum-infrastructure-00 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 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 R. Stastny 5 Expires: December 25, 2006 Oefeg 6 June 23, 2006 8 Combined User and Infrastructure ENUM in the e164.arpa tree 9 draft-haberler-carrier-enum-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of 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 December 25, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This memo defines an interim solution for Infrastructure ENUM to 43 allow a combined User and Infrastructure ENUM implementation in 44 e164.arpa as a national choice until the long-term solution is 45 approved. This interim solution will be deprecated after deployment 46 of the long-term solution. 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Interim Solution . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Introducing a branch into the 164.arpa tree . . . . . . . . . 4 58 5. Defining the Infrastructure ENUM branch location . . . . . . . 4 60 6. Finding the ENUM branch location record . . . . . . . . . . . 5 62 7. Recommended resolver behaviour . . . . . . . . . . . . . . . . 6 64 8. Security considerations . . . . . . . . . . . . . . . . . . . 7 66 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 68 10. Interoperability considerations . . . . . . . . . . . . . . . 8 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 12.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 77 Intellectual Property and Copyright Statements . . . . . . . . . . 11 79 1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in BCP 14, RFC2119 [1]. 85 Note: The ENUM WG decided at IETF#64 to prefer the term 86 Infrastructure ENUM. Therefore, this document uses the term 87 Infrastructure ENUM as synonymous to Carrier ENUM. 89 2. Introduction 91 ENUM (E.164 Number Mapping, RFC 3761 [2]) is a system that transforms 92 E.164 numbers [3] into domain names and then uses DNS (Domain Name 93 Service) [6] services like delegation through NS records and NAPTR 94 (Naming Authority Pointer) records [4] to look up which services are 95 available for a specific domain name. 97 ENUM as defined in RFC3761 (User-ENUM) is not well suited for the 98 purpose of interconnection by carriers, as can be seen by the use of 99 various private tree arrangements based on ENUM mechanisms. 101 Infrastructure ENUM is defined as the use of the technology in 102 RFC3761 [2] by the carrier-of-record [8] (Voice service provider) for 103 a specific E.164 [3] number to map a telephone number into an URI [5] 104 that identifies a specific point of interconnection to that service 105 provider's network that could enable the originating party to 106 establish communication with the associated terminating party. It is 107 separate from any URIs that the end-user who registers his E.164 108 number in ENUM may wish to associate with that E.164 number. 110 The requirements, terms and definitions for Infrastructure ENUM are 111 defined in [8]. 113 Using the same E.164 number to domain mapping technique for other 114 applications under a different, internationally agreed apex (instead 115 of e164.arpa) is straightforward on the technical side. Establishing 116 the international agreements necessary to delegate the country-code 117 level subdomains under the new apex is non-trivial and time- 118 consuming. This process of defining the Dynamic Delegation Discovery 119 System DDDS [4] application for Infrastructure ENUM in "ie164.arpa" 120 is under way [9]. This is called the "proper" long term solution. 122 3. Interim Solution 124 As stated above, the agreements to establish the long-term solution 125 may take some time. It was therefore decided to develop an interim 126 solution that can be used by individual countries to implement an 127 interoperable Infrastructure ENUM tree immediately. The Interim 128 solution will be deprecated upon approval (loosely timed) of the 129 "proper" long-term solution. 131 Is is therefore also required that the Interim solution is compatible 132 with the "right" long-term solution to allow for easy migration. 134 4. Introducing a branch into the 164.arpa tree 136 A convention is needed how, given a fully qualified E.164 [3] number, 137 a resolver can determine the location of the Infrastructure ENUM 138 subdomain for this country. Under this approach, ITU-T and IETF 139 (IAB) involvement is only lightweight, e.g. to recommend the proper 140 algorithm defined here to enable international interoperability. 142 This allows to introduce the Interim solution as a national matter by 143 the concerned NRA or as a regional opt-in within in a given Numbering 144 Plan Area such as the North American NPA. 146 Beyond the setup phase, an NRA need not be involved operationally - 147 it is sufficient to establish a convention linking the national 148 definition of a carrier of record to the credentials for write access 149 to the Infrastructure ENUM tree. 151 The method most easily fulfilling the above mentioned requirements is 152 to branch off the e164.arpa tree into a subdomain at or somewhere 153 below the country code delegation level below e164.arpa, and deploy 154 an Infrastructure ENUM subtree underneath without touching User ENUM 155 semantics at all. 157 5. Defining the Infrastructure ENUM branch location 159 The decision where to place the Infrastructure ENUM tree below 160 e164.arpa is a national or group-of-countries decision. To branch 161 off the e164.arpa tree for a given country code, a DNS label is 162 inserted at a specific position into the ENUM fully qualified domain 163 name (FQDN). 165 For international interoperability, an Infrastructure ENUM resolver 166 needs to determine for a given country code 168 1. the name of the label to be inserted 169 2. the position where to insert the label in an Infrastructure ENUM 170 domain name for a given country code 171 3. a convention how to discover these parameters. 173 We propose a mechanism to discover these parameters dynamically for 174 any given tree shape as follows: 176 o the national or group-of-countries decision about subdomain 177 location is documented in the e164.arpa tree proper by inserting a 178 special DNS resource record at the country code level, called ENUM 179 Branch Location Record (EBL) [7], into a subdomain in the country 180 code zone. In case of the Infrastructure ENUM application, this 181 subdomain name will be "infrastructure". This ENUM Branch 182 Location Record carries three values for maximum flexibility: 183 o 184 1. the branching label to be inserted into the ENUM domain to 185 branch off to the application-specific tree. This may be an 186 empty (zero-length) string. 187 2. an insertion position, indicating after which digit this label 188 should be inserted into the ENUM domain to branch off to the 189 application-specific tree. A value of 0 means "after all 190 digits". 191 3. an apex: indicating what domain should replace "e164.arpa" for 192 this application. 193 o a resolver looking for an Infrastructure ENUM domain needs to 194 retrieve this EBL once during first resolution within a country 195 code. 196 o while constructing the FQDN, the branching label as retrieved from 197 the EBL resource record is inserted at the insertion position 198 (also as per EBL) and finally the apex is appended. Labels, 199 digits and apex are separated by dots as usual. A zero-length 200 branching label is not inserted at all. 202 6. Finding the ENUM branch location record 204 The only remaining a-priori knowledge a Infrastructure ENUM resolver 205 should have is the current list of country codes, or an equivalent 206 method to determine where the country code in the number ends. 208 To prime the country code extraction algorithm, the current scheme to 209 determine country code length as follows could be employed: 211 o 3 digits is the default length of a country code. 212 o country codes 1 and 7 are a single digit. 214 o the following country codes are two digits: 20, 27, 30-34, 36, 39, 215 40, 41, 43-49, 51-58, 60-66, 81, 82, 84, 86, 90-95, 98. 217 Figure 1 219 Given the fact that the ITU recently allocated only 3-digit country 220 codes, there are no more spare 1- and 2-digit country codes and 221 existing 1- and 2-digit country codes are extremely unlikely to be 222 recovered, the above table consisting of the existing 1- and 2-digit 223 country codes can be considered very stable. The only problem may be 224 a country split as happened recently e.g. to Yugoslavia. 226 If a branch location record is not found according to this table (for 227 instance, in the unlikely case the ITU allocates a country code not 228 according to these rules), it is still possible to determine the 229 branch location record by "iterating down" the tree digit-by-digit. 230 Such a fallback strategy would rely on the assumption that there is 231 never a branch location record inserted above the country code zone, 232 for which there would be no use in the first place. 234 It seems unlikely that inspection of more than the first five digits 235 will be required to locate the branch location record under any 236 realistic numbering administrative partitioning. 238 7. Recommended resolver behaviour 240 A User ENUM resolver as per RFC 3761 need not be aware of any 241 Infrastructure ENUM conventions at all. A combined User and 242 Infrastructure ENUM resolver shall behave as follows: 244 The input to the resolver routine shall be: 245 1. the called number in fully qualified E.164 (international) 246 format, 247 2. a mode parameter indicating wether resolution should follow User 248 ENUM or Infrastructure ENUM rules (for instance, a null value for 249 defaulting to User ENUM, or 'infrastructure' for Infrastructure 250 ENUM semantics). 251 3. optionally a table or algorithm to easily detect country codes 252 (Section 6), 253 4. any other parameters used to drive the search, for instance an 254 enumservice type. These parameters are outside the scope of this 255 draft. 257 The resolver shall proceed as follows: 258 o if the mode parameter indicates a User ENUM search, proceed as per 259 RFC3761. 261 o If the mode parameter indicates an Infrastructure ENUM query: 262 * determine country code length. 263 * consult table if an EBL record for this country code was 264 already retrieved since resolver boot time. 265 * if not: 266 retrieve the EBL record from the 'infrastructure' subdomain 267 of the country code zone, and store the country code and 268 associated EBL values in an EBL table. 269 optional fallback for irregular country code not covered by 270 the CC extraction algorithm: (Figure 1) if the last step 271 fails, iterate over the number up to five digits and try to 272 retrieve the EBL record in the 'infrastructure' subdomain 273 each time, again storing the country code and associated EBL 274 values in the cache if successful. 275 if both attempts fail, return NXDOMAIN. 276 * valid EBL record found: if the branching label is non-zero 277 length, insert it at the insertion position in the FQDN and add 278 a trailing dot, add the remaining digits and dots, and append 279 the apex. 280 * search the DNS for any ENUM NAPTR records for the resulting 281 domain name. 283 It is assumed that already discovered EBL values are stored in a 284 cache table of country code and already discovered EBL parameters. 286 8. Security considerations 288 Privacy issues have been raised regarding unwarranted disclosure of 289 user information by publishing Infrastructure ENUM information in the 290 public DNS, for instance the use for harvesting of numbers in 291 service, or unlisted numbers. 293 Given that number range allocation is public information, we believe 294 the easiest way to cope with such concerns is to fully unroll 295 allocated number ranges in the Infrastructure ENUM subtree, wherever 296 such privacy concerns exist. Whether a number is served or not would 297 be exposed by the carrier of record when an attempt is made to 298 contact the corresponding URI. We assume this to be an authenticated 299 operation, which would not leak information to unauthorized parties. 301 Entering all numbers in an allocated number range, whether serviced 302 or not, or listed or unlisted, will prevent mining attempts for such 303 number attributes. 305 The result would be that the information in the public DNS would 306 mirror number range allocation information, but not more. 307 Infrastructure ENUM will not tell you more than you can get by just 308 dialing numbers. 310 The URI pointing to the destination network of the Carrier of Record 311 should also not disclose any privacy information about the identity 312 of end-user, it is therefore recommended to use in the user-part of 313 the SIP URI either anonymized UserIDs or the E.164 number itself, 314 such as sip:441632960084@example.com . 316 The definition of a new resource record (RR) type or a new 317 enumservice does not introduce security problems into the DNS. Usage 318 of the Branch Location record conveys only static setup information 319 under a country code subtree of e164.arpa. The intended use of DNS 320 Security Extensions (DNSSEC) within ENUM will prove authenticity of 321 the conveyed value. 323 9. IANA considerations 325 None 327 10. Interoperability considerations 329 An application using the combined resolver needs to indicate which 330 information is requested - User or Infrastructure ENUM, or both. A 331 user-ENUM-only resolver need not be aware of the Infrastructure ENUM 332 subtree and no changes with respect to RFC3761 semantics are 333 required. A resolver desiring to retrieve Infrastructure ENUM or 334 both types of records needs to be aware of the conventions laid out 335 in this draft. 337 When the "proper" long-term solution is adopted, each country using 338 the interim solution may decide on its own when to migrate to the 339 long-term solution. The EBL records for this country would then be 340 changed to the values "insertion position=0", "branching label=''" 341 and "apex=ie164.arpa". When finally all countries have migrated, the 342 EBL records may be removed. 344 11. Acknowledgements 346 We gratefully acknowledge suggestions and improvements by Jason 347 Livingood and Tom Creighton of Comcast, Penn Pfautz of ATT, Lawrence 348 Conroy of Roke Manor Research, and Alexander Mayrhofer and Otmar 349 Lendl of enum.at. 351 12. References 352 12.1. Normative References 354 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 355 Levels", BCP 14, RFC 2119, March 1997. 357 [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 358 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 359 Application (ENUM)", RFC 3761, April 2004. 361 [3] ITU-T, "The International Public Telecommunication Number Plan", 362 Recommendation E.164, May 1997. 364 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 365 One: The Comprehensive DDDS", RFC 3401, October 2002. 367 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 368 Resource Identifiers (URI): Generic Syntax", RFC 2396, 369 August 1998. 371 [6] Mockapetris, P., "Domain names - concepts and facilities", 372 STD 13, RFC 1034, November 1987. 374 [7] Lendl, O., "The ENUM Branch Location Record", 375 draft-lendl-enum-branch-location-record-01 (work in progress), 376 May 2006. 378 12.2. Informative References 380 [8] Lind, S. and P. Pfautz, "Infrastrucure ENUM Requirements", 381 draft-ietf-enum-infrastructure-enum-reqs-02 (work in progress), 382 April 2006. 384 [9] Livingood, J., "The E.164 to Uniform Resource Identifiers (URI) 385 Dynamic Delegation Discovery System (DDDS) Application for 386 Infrastructure ENUM", draft-ietf-enum-infrastructure-00 (work in 387 progress), April 2006. 389 Authors' Addresses 391 Michael Haberler 392 Internet Foundation Austria 393 Waehringerstrasse 3/19 394 Wien A-1090 395 Austria 397 Phone: +43 664 4213465 398 Email: mah@inode.at 399 URI: http://www.nic.at/ipa/ 401 Richard Stastny 402 Oefeg 403 Postbox 147 404 Vienna A-1030 405 Austria 407 Phone: +43 664 420 4100 408 Email: richard.stastny@oefeg.at 409 URI: http://www.oefeg.at 411 Intellectual Property Statement 413 The IETF takes no position regarding the validity or scope of any 414 Intellectual Property Rights or other rights that might be claimed to 415 pertain to the implementation or use of the technology described in 416 this document or the extent to which any license under such rights 417 might or might not be available; nor does it represent that it has 418 made any independent effort to identify any such rights. Information 419 on the procedures with respect to rights in RFC documents can be 420 found in BCP 78 and BCP 79. 422 Copies of IPR disclosures made to the IETF Secretariat and any 423 assurances of licenses to be made available, or the result of an 424 attempt made to obtain a general license or permission for the use of 425 such proprietary rights by implementers or users of this 426 specification can be obtained from the IETF on-line IPR repository at 427 http://www.ietf.org/ipr. 429 The IETF invites any interested party to bring to its attention any 430 copyrights, patents or patent applications, or other proprietary 431 rights that may cover technology that may be required to implement 432 this standard. Please address the information to the IETF at 433 ietf-ipr@ietf.org. 435 Disclaimer of Validity 437 This document and the information contained herein are provided on an 438 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 439 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 440 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 441 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 442 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 443 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 445 Copyright Statement 447 Copyright (C) The Internet Society (2006). This document is subject 448 to the rights, licenses and restrictions contained in BCP 78, and 449 except as set forth therein, the authors retain all their rights. 451 Acknowledgment 453 Funding for the RFC Editor function is currently provided by the 454 Internet Society.