idnits 2.17.1 draft-ietf-enum-unused-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 471. 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 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 29, 2008) is 5844 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM R. Stastny 3 Internet-Draft Oefeg 4 Intended status: Standards Track L. Conroy 5 Expires: September 30, 2008 RMRL 6 J. Reid 7 DNS-MODA 8 March 29, 2008 10 IANA Registration for Enumservice UNUSED 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 30, 2008. 38 Abstract 40 This document registers the Enumservice "unused" using the URI scheme 41 "http:" as per the IANA registration process defined in the ENUM 42 specification, RFC 3761. This Enumservice may be used to indicate 43 that the E.164 number (or E.164 number range) tied to the domain in 44 which the enclosing NAPTR is published is not allocated or assigned 45 for communications service. When such an indication is provided, an 46 ENUM client can detect calls that will fail "early". 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Background: ENUM Lookup Cases . . . . . . . . . . . . . . . . 5 53 3.1. ENUM Registration Cases . . . . . . . . . . . . . . . . . 5 54 3.2. ENUM Outcomes . . . . . . . . . . . . . . . . . . . . . . 6 55 3.3. "Default" Strategy on receiving response with RCODE=3 . . 6 56 3.4. The Problem . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.5. "ENUM only" query loop . . . . . . . . . . . . . . . . . . 7 58 4. The Proposed Solution . . . . . . . . . . . . . . . . . . . . 8 59 5. ENUM Service Registration - UNUSED . . . . . . . . . . . . . . 9 60 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 66 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 68 Intellectual Property and Copyright Statements . . . . . . . . . . 16 70 1. Introduction 72 The Circuit Switched Network (CSN) of which the Public Switched 73 Telephone Network (PSTN), Integrated Services Digital Network (ISDN), 74 and Public Land Mobile Network (PLMN) are part is designed to use 75 E.164 numbers [E164] as native global addresses. If a potential 76 caller has an E.164 number, then to place a call using this address 77 he or she needs a way to pass the request either directly or 78 indirectly to systems "in" the CSN for them to forward. 80 ENUM ("E.164 Number Mapping") has introduced a mechanism to find 81 other contact addresses when given an E.164 number. Thus, if the 82 caller (or an agent somewhere in the call path) has access to the 83 global Domain Name System (DNS), they can use ENUM as described in 84 RFC 3761 [RFC3761] to find alternative contacts to the E.164 number 85 and place the call using whatever system was indicated in those 86 contacts. In its intended use, an ENUM query would return a set of 87 NAPTR ("Naming Authority Pointer") resource records [RFC3403], and 88 these would be processed to select the appropriate communications 89 contact choices. Each communications contact is held in a URI 90 ("Universal Resource Indicator") generated from the contents of a 91 NAPTR. 93 However, ENUM entries may not exist for a given E.164 number for two 94 reasons. Either the assignee who is entitled to register an ENUM 95 domain associated with the E.164 number they hold has chosen not to 96 request this registration, or the number is not currently allocated 97 or assigned for communications service. 99 In either situation, the caller has no other information and so no 100 alternative to placing the call via the system that uses E.164 101 numbers as global identifiers; at present, this is the CSN. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 3. Background: ENUM Lookup Cases 111 This section describes the problems that arise where the ENUM system 112 does not hold full information on all telephone numbers and clients 113 display typical behaviour. The proposed solution to the problems 114 described here is covered in Section 4 and in the unused Enumservice 115 registration in Section 5. 117 3.1. ENUM Registration Cases 119 Traditionally, communications service is provided via a network that 120 uses telephone numbers as global addresses. Examples of such 121 networks are the PSTN, ISDN and PLMN. 123 ENUM registrations are normally allowed only to customers who receive 124 communications service via a telephone number. There may or may not 125 be an ENUM registration when such service is provided. An ENUM 126 registration is usually not permitted when no customer receives 127 service via the corresponding telephone number. 129 When considering ENUM registrations associated with telephone 130 numbers, there are six scenarios: 132 1. The number is not allocated to a service provider, 134 2. the number is not currently used by that provider for 135 communications service for a customer, 137 3. the number is used to provide communications service to a 138 customer and either that customer has not chosen to maintain an 139 ENUM registration associated with that number, or the National 140 Regulatory Authority (NRA) responsible for these numbers does not 141 allow ENUM registrations, 143 4. the number is used to provide communications service to a 144 customer and that customer has an ENUM registration associated 145 with that number. 147 Communications service may alternatively be provided only by recourse 148 to an ENUM lookup. Such numbers are known as "ENUM only" ranges. 150 For these numbers there are two further possibilities: 152 5. There is an ENUM registration and that number may be used for 153 communications service, 155 6. there is no ENUM registration and therefore the number is not used 156 for communications service. 158 3.2. ENUM Outcomes 160 Assuming properly configured name servers and protocol conformant 161 software, an ENUM query on a domain associated with a telephone 162 number may elicit one of several outcomes based on the DNS [RFC1034] 163 response. 165 In uses cases 1,2,3,and 6, the DNS response will indicate Name Error 166 (RCODE=3, commonly known as NXDOMAIN, signifying that the domain name 167 referenced in the query does not exist). 169 In use cases 4 and 5, the DNS response will indicate No Error 170 (RCODE=0). There are three possibilities here: 172 o There may be at least one usable NAPTR (meaning one in which the 173 Enumservice is supported and the URI is resolved), in which case a 174 communications attempt can be made. 176 o Even though the DNS response indicates no error, there may not be 177 any usable NAPTRs in that response. This may happen because the 178 domain owner has chosen not to populate the zone with NAPTR 179 records. This response (RCODE=0, Number of Answers=0) is also 180 known as NOHOST, meaning that the queried name exists but not for 181 the record type that was requested. 183 o However, even if there are NAPTRs returned, none of the ones 184 present may be usable. For example, the NAPTR RRSet may include 185 only an "h323" Enumservice, whilst the client node is capable only 186 of processing "sip" or "voice:tel" Enumservices. 188 As it cannot know the case it has encountered, if the client receives 189 a DNS response with no usable NAPTRs or one with RCODE=3, it must 190 decide whether or not to attempt to place the call using other means. 192 3.3. "Default" Strategy on receiving response with RCODE=3 194 Not every customer has an ENUM registration if provided service via a 195 network that uses telephone numbers natively, and until this is the 196 case, a reasonable strategy has been to attempt to place the call via 197 such a network if it receives an ENUM response with RCODE=3. This is 198 especially true if the National Regulatory Authority has chosen not 199 to permit ENUM registrations at all for the telephone numbers under 200 its control. 202 This may also be the chosen strategy if the client receives a 203 response with RCODE=0 (No Error), but with no usable NAPTRs. 205 3.4. The Problem 207 In the case of an ENUM client getting a DNS response with RCODE=3, 208 the semantics of that reply are ambiguous. Is this case 1,2,3, or 6? 209 It is useful for the client to know if this is case 3, as in this 210 case the "default" strategy will succeed. In cases 1 and 2, trying 211 to place the call via a network that uses such numbers natively will 212 result in that network returning an error. However, in case 6 even 213 this cannot be guaranteed. 215 Similarly, if the client finds no usable NAPTRs, is this case 4 or 216 case 5? In the latter case the strategy will fail, whilst in the 217 former case it will succeed. 219 3.5. "ENUM only" query loop 221 However, for the "ENUM only" cases, there is a further problem. If 222 the call is placed via a network that uses such numbers natively, it 223 can be processed only via an ENUM lookup, and typically this will 224 involve a gateway from that network performing the lookup and 225 delivering the call onwards based on the response. If that gateway 226 receives a response with RCODE=3 or one including no usable NAPTRs, 227 then employing the "default" strategy (attempting the call via a 228 network that uses these numbers natively) will cause a "loop". The 229 call will be redirected to this network, where it will be routed to a 230 gateway, this gateway will perform a lookup, will receive the same 231 response, will attempt to place the call back to that network, and so 232 on. 234 4. The Proposed Solution 236 We propose an explicit indication of this "number unused" state (as 237 described in points 1,2, and 6 in Section 3.1). This uses a NAPTR in 238 the zone associated with an unused telephone number, with an 239 Enumservice called "unused" that should be taken as an assertion that 240 the associated E.164 number is not assigned to a subscriber for 241 communications service; it's an unused number. 243 This NAPTR can also be used by a National Regulatory Authority (NRA) 244 to indicate number blocks that it has reserved, and has not allocated 245 to a service provider. 247 It is a matter for individual countries whether or not they will 248 support (or require) information giving the identity of the current 249 "owner" of an E.164 number within their responsibility to be made 250 available via IRIS/WHOIS. Thus it may not be possible to use these 251 protocols to find out the entity responsible for a number or number 252 range concerned, particularly where that number or range is not 253 currently "in use". 255 Since the registration and syntax of a terminal NAPTR for "E2U" 256 Enumservices requires at least one URI scheme to be defined, we 257 propose that the Enumservice "unused" will use an "http:" URI. The 258 content referenced in this "http:" URI is a national matter. For 259 example, it may be used to refer to a resource providing additional 260 information about the reason for the existence of this record, and/or 261 (where required by the competent regulatory authority) the identity 262 of the entity responsible for this number. 264 5. ENUM Service Registration - UNUSED 266 Enumservice Name: "unused" 268 Enumservice Type: "unused" 270 Enumservice Subtypes: "data" 272 URI Schemes: "http:" 274 Functional Specification: The proposed solution in Section 4. 276 Definition of expected action: 278 When an ENUM lookup for a number explicitly returns the "unused" 279 NAPTR, the response indicates to the client that the number is 280 known to ENUM but there are no implicit communication end-points 281 associated with it. The client can then signal an error to the 282 application or end user instead of then trying and failing to 283 terminate the call on the PSTN, which would have been the typical 284 behaviour of an ENUM-aware VoIP/PSTN gateway if the ENUM lookup 285 had returned a DNS response indicating NXDOMAIN or NOHOST. 287 Thus, if a NAPTR with this Enumservice is received and processed, 288 it indicates that there are no possible communication methods that 289 can be used to reach the end point. The queried E.164 number is 290 currently not allocated, or unassigned to a subscriber for 291 communications service. 293 The recipient SHOULD treat this response as if they had received a 294 "number not in service" indication from a terminating network. 296 Note that the generated URI is not a potential target for any 297 current call. The content referred to in the "http:" URI 298 [RFC2616] MUST NOT be used in normal call processing but only if 299 there is a non-call related reason. 301 Security considerations: see Section 7. 303 Intended usage: COMMON 305 Authors 307 Lawrence Conroy, Richard Stastny, Jim Reid (for authors contact 308 details see Authors' Addresses section). 310 Any other information that the author deems interesting: None 312 6. Examples 314 1. Unassigned number 316 $ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. 317 3.8.0 NAPTR 10 100 "u" "E2U+unused:http" 318 "!^.*$!http://www.nra.example/static/numbering/ 319 cupid.htm?cupid=001!" . 321 This indicates that the controller of the number block +441632960 322 does not provide telephony service via the number +441632960083; 323 it is not assigned to a subscriber. 325 2. Unallocated number 327 $ORIGIN 0.6.9.4.5.1.1.4.4.e164.arpa. 328 * NAPTR 10 100 "u" "E2U+unused:http" 329 "!^.*$!http://www.nra.example/static/numbering/ 330 sabc.htm?SABC=1154!" 332 This indicates that the number block +441154960 is not allocated 333 by the NRA to any service provider and therefore no number in 334 this block provides any communication service. 336 7. Security Considerations 338 DNS does not make policy decisions about the records that it shares 339 with an inquirer. All DNS records must be assumed to be available to 340 all inquirers at all times. The information provided within an ENUM 341 record set must therefore be considered to be open to the public. 343 An analysis of threats specific to the dependence of ENUM on the DNS, 344 and the applicability of DNSSEC ("Domain Name Security") [RFC4035] to 345 these, is provided in [RFC3833]. 347 8. IANA Considerations 349 This document requests registration of the "unused" Enumservice with 350 the sub-type "unused:http" according to the guidelines and 351 specifications in RFC 3761 [RFC3761] and the definitions in this 352 document. This Enumservice is intended for use with the "http:" URI 353 scheme. 355 9. Acknowledgements 357 Thanks to Patrik Faltstrom, Michael Mealling and Peter Koch for their 358 thorough feedback, and colleagues in ETSI TISPAN who helped to 359 clarify the operational features during the development of 360 [ETSI-TS102172]. Thanks also to the members of the ENUM working 361 group for their wide ranging discussions. These have helped to 362 indicate where changes were needed in this document to help explain 363 what is an intrinsically difficult subject. Finally, thanks to Alex 364 Mayrhofer for his useful document review, picking up the remaining 365 issues. 367 10. References 369 10.1. Normative References 371 [E164] ITU-T, "The International Public Telecommunication Number 372 Plan", Recommendation E.164, February 2005. 374 [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 375 RFC 1034, November 1987. 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", RFC 2119, BCP 14, March 1997. 380 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 381 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 382 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 384 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 385 Part Three: The Domain Name System (DNS) Database", 386 RFC 3403, October 2002. 388 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 389 Resource Identifiers (URI) Dynamic Delegation Discovery 390 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 392 10.2. Informative References 394 [ETSI-TS102172] 395 ETSI, "Minimum Requirements for Interoperability of ENUM 396 Implementations", ETSI TS 102 172, January 2005. 398 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 399 Name System (DNS)", RFC 3833, August 2004. 401 [RFC4035] Arends, R. and et al. , "Protocol Modifications for the 402 DNS Security Extensions", RFC 4035, March 2005. 404 Authors' Addresses 406 Richard Stastny 407 Oefeg 408 Postbox 147 409 1103 Vienna 410 Austria 412 Phone: +43-664-420-4100 413 Email: Richard.stastny@oefeg.at 415 Lawrence Conroy 416 Siemens Roke Manor Research 417 Roke Manor 418 Romsey 419 United Kingdom 421 Phone: +44-1794-833666 422 Email: lwc@roke.co.uk 424 Jim Reid 425 DNS-MODA 426 6 Langside Court 427 Bothwell, SCOTLAND 428 United Kingdom 430 Phone: +44 1698 852881 431 Email: jim@dns-moda.org 433 Full Copyright Statement 435 Copyright (C) The IETF Trust (2008). 437 This document is subject to the rights, licenses and restrictions 438 contained in BCP 78, and except as set forth therein, the authors 439 retain all their rights. 441 This document and the information contained herein are provided on an 442 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 443 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 444 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 445 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 446 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 447 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 449 Intellectual Property 451 The IETF takes no position regarding the validity or scope of any 452 Intellectual Property Rights or other rights that might be claimed to 453 pertain to the implementation or use of the technology described in 454 this document or the extent to which any license under such rights 455 might or might not be available; nor does it represent that it has 456 made any independent effort to identify any such rights. Information 457 on the procedures with respect to rights in RFC documents can be 458 found in BCP 78 and BCP 79. 460 Copies of IPR disclosures made to the IETF Secretariat and any 461 assurances of licenses to be made available, or the result of an 462 attempt made to obtain a general license or permission for the use of 463 such proprietary rights by implementers or users of this 464 specification can be obtained from the IETF on-line IPR repository at 465 http://www.ietf.org/ipr. 467 The IETF invites any interested party to bring to its attention any 468 copyrights, patents or patent applications, or other proprietary 469 rights that may cover technology that may be required to implement 470 this standard. Please address the information to the IETF at 471 ietf-ipr@ietf.org.