ENUM R. Stastny Internet-Draft Oefeg Intended status: Standards Track L. Conroy Expires: August 30, 2007 Siemens Roke Manor Research J. Reid DNS-MODA February 26, 2007 IANA Registration for Enumservice UNUSED Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Stastny, et al. Expires August 30, 2007 [Page 1] Internet-Draft IANA Registration Enumservice UNUSED February 2007 Abstract This document registers the Enumservice "unused" using the URI scheme "data:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ENUM Lookup Cases . . . . . . . . . . . . . . . . . . . . . . 6 3.1. ENUM Registration Cases . . . . . . . . . . . . . . . . . 6 3.2. ENUM Outcomes . . . . . . . . . . . . . . . . . . . . . . 6 3.3. "Default" Strategy on receiving response with RCODE=3 . . 7 3.4. The Problem . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. "ENUM only" query loop . . . . . . . . . . . . . . . . . . 8 4. The Proposed Solution . . . . . . . . . . . . . . . . . . . . 9 5. ENUM Service Registration - UNUSED . . . . . . . . . . . . . . 10 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Operational Guidance . . . . . . . . . . . . . . . . . . . . . 12 7.1. Provisioning Scenarios . . . . . . . . . . . . . . . . . . 12 7.2. Number Plans . . . . . . . . . . . . . . . . . . . . . . . 12 7.2.1. Fixed Number Length . . . . . . . . . . . . . . . . . 13 7.2.2. Variable Number length . . . . . . . . . . . . . . . . 13 7.3. Provisioning Techniques in ENUM Domains . . . . . . . . . 15 7.3.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . 15 7.3.2. "Closest Encloser" domains . . . . . . . . . . . . . . 15 7.4. Recommended Provisioning Strategies . . . . . . . . . . . 17 7.5. Client Behaviour . . . . . . . . . . . . . . . . . . . . . 18 7.5.1. Basic Client Behaviour . . . . . . . . . . . . . . . . 18 7.5.2. Advanced Client Behaviour . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Stastny, et al. Expires August 30, 2007 [Page 2] Internet-Draft IANA Registration Enumservice UNUSED February 2007 1. Introduction The Circuit Switched Network (CSN) of which the Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), and Public Land Mobile Network (PLMN) are part is designed to use E.164 numbers [1] as native global addresses. If a potential caller has an E.164 number, then to place a call using this address he or she needs a way to pass the request either directly or indirectly to systems "in" the CSN for them to forward. ENUM has introduced a mechanism to find other contact addresses when given an E.164 number. Thus, if the caller (or an agent somewhere in the call path) has access to the global DNS, they can use ENUM RFC 3761 [2] to find alternative contacts to the E.164 number and place the call using whatever system was indicated in those contacts. However, ENUM entries may not exist for a given E.164 number for two reasons. Either the assignee who is entitled to register an ENUM domain associated with the E.164 number they hold has chosen not to request this registration, or the number is not currently allocated or assigned for communications service. In either situation, the caller has no other information and so no alternative to placing the call via the system that uses E.164 numbers as global identifiers; at present, this is the CSN. Stastny, et al. Expires August 30, 2007 [Page 3] Internet-Draft IANA Registration Enumservice UNUSED February 2007 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, [3]. Definition: Block/Range Number A Block/Range Number consists of the country code digits concatenated with the set of digits used to identify the number range or block. Thus, for example, the "ENUM only" number range in Austria has a range number of +43780. An example number block that, at the time of writing, is allocated to the communications service provider BT in the UK is: +44179483, whilst an example of a number block that is not currently allocated is: +44179426. Definition: ENUM Domain A domain associated with an E.164 telephone number (using the domain name mapping algorithm specified in RFC 3761). Definition: Block/Range Domain A domain associated with a Block Number or Range Number, using the domain name mapping algorithm specified in RFC 3761. For example, the domain 0.8.7.3.4.e164.arpa. is the Range Domain associated with the Range Number +43780. Definition: Closest Encloser (from RFC 4592) The closest encloser is the node in the zone's tree of existing domain names that has the most labels matching the query name (consecutively, counting from the root label downward). Each match is a "label match" and the order of the labels is the same. Definition: Closest Encloser Re-query If an ENUM client receives a DNS response that indicates a Name Error (RCODE=3) and includes no relevant answers, then that response will include an SOA record in its authority section, showing the owner of the Closest Encloser, as specified in RFC 2308 [6]. Rather than quitting the current ENUM evaluation the client may choose to check for NAPTRs in that "closest encloser" domain. It can then use any NAPTRs it receives in this second response. It MUST not continue this process; if it does not receive a DNS response with No Error and with some valid NAPTRs in its query of the "closest encloser" domain, it MUST abandon its evaluation. Stastny, et al. Expires August 30, 2007 [Page 4] Internet-Draft IANA Registration Enumservice UNUSED February 2007 Note that this re-query is considered part of the initial ENUM evaluation, as if the client had received a non-terminal NAPTR resource record indicating a further DNS domain to be queried. Definition: "Backstop" NAPTR A "Backstop" NAPTR is defined as a NAPTR having the highest value of ORDER/PREFERENCE fields of all NAPTRs in the current Resource Record Set (RRSet). Using standard ENUM processing as defined in RFC 3761, it will be processed only if no other NAPTRs in that RRSet are used to exit this evaluation cycle. Stastny, et al. Expires August 30, 2007 [Page 5] Internet-Draft IANA Registration Enumservice UNUSED February 2007 3. ENUM Lookup Cases 3.1. ENUM Registration Cases Traditionally, communications service is provided via a network that uses telephone numbers as global addresses. Examples of such networks are the PSTN, ISDN and PLMN. ENUM registrations are normally allowed only to customers who receive communications service via a telephone number. There may or may not be an ENUM registration when such service is provided. An ENUM registration is usually not permitted when no customer receives service via the corresponding telephone number. When considering ENUM registrations associated with telephone numbers, there are six scenarios: 1. The number is not allocated to a service provider, 2. the number is not currently used by that provider for communications service for a customer, 3. the number is used to provide communications service to a customer and that customer has not chosen to maintain an ENUM registration associated with that number (or the National Regulatory Authority (NRA) responsible for these numbers does not allow ENUM registrations), 4. the number is used to provide communications service to a customer and that customer has an ENUM registration associated with that number. Communications service may alternatively be provided only by recourse to an ENUM lookup. Such numbers are known as "ENUM only" ranges. For these numbers there are two further possibilities: 5. There is an ENUM registration and that number may be used for communications service, 6. there is no ENUM registration and therefore the number is not used for communications service. 3.2. ENUM Outcomes Assuming properly configured name servers and protocol conformant software, an ENUM query on a domain associated with a telephone number may elicit one of several outcomes based on the DNS [4] Stastny, et al. Expires August 30, 2007 [Page 6] Internet-Draft IANA Registration Enumservice UNUSED February 2007 response. In uses cases 1,2,3,and 6, the DNS response will indicate Name Error (RCODE=3, commonly known as NXDOMAIN, signifying that the domain name referenced in the query does not exist). In use cases 4 and 5, the DNS response will indicate No Error (RCODE=0). There are three possibilities here: o There may be at least one usable NAPTR (meaning one in which the Enumservice is supported and the URI is resolved), in which case a communications attempt can be made. o Even though the DNS response indicates no error, there may not be any usable NAPTRs in that response. This may happen because the domain owner has chosen not to populate the zone with NAPTR records. This response (RCODE=0, Number of Answers=0) is also known as NOHOST, meaning that the queried name exists but not for the record type that was requested. o However, even if there are NAPTRs returned, none of the ones present may be usable. For example, the NAPTR RRSet may include only an "h323" Enumservice, whilst the client node is capable only of processing "sip" or "voice:tel" Enumservices. As it cannot know the case it has encountered, if the client receives a DNS response with no usable NAPTRs or one with RCODE=3, it must decide whether or not to attempt to place the call using other means. 3.3. "Default" Strategy on receiving response with RCODE=3 Not every customer has an ENUM registration if provided service via a network that uses telephone numbers natively, and until this is the case, a reasonable strategy has been to attempt to place the call via such a network if it receives an ENUM response with RCODE=3. This is especially true if the National Regulatory Authority has chosen not to permit ENUM registrations at all for the telephone numbers under its control. This may also be the chosen strategy if the client receives a response with RCODE=0 (No Error), but with no usable NAPTRs. 3.4. The Problem In the case of an ENUM client getting a DNS response with RCODE=3, the semantics of that reply are ambiguous. Is this case 1,2,3, or 6? It is useful for the client to know if this is case 3, as in this case the "default" strategy will succeed. In cases 1 and 2, trying Stastny, et al. Expires August 30, 2007 [Page 7] Internet-Draft IANA Registration Enumservice UNUSED February 2007 to place the call via a network that uses such numbers natively will result in that network returning an error. However, in case 6 even this cannot be guaranteed. Similarly, if the client finds no usable NAPTRs, is this case 4 or case 5? In the latter case the strategy will fail, whilst in the former case it will succeed. 3.5. "ENUM only" query loop However, for the "ENUM only" cases, there is a further problem. If the call is placed via a network that uses such numbers natively, it can be processed only via an ENUM lookup, and typically this will involve a gateway from that network performing the lookup and delivering the call onwards based on the response. If that gateway receives a response with RCODE=3 or one including no usable NAPTRs, then employing the "default" strategy (attempting the call via a network that uses these numbers natively) will cause a "loop". The call will be redirected to this network, where it will be routed to a gateway, this gateway will perform a lookup, will receive the same response, will attempt to place the call back to that network, and so on. Stastny, et al. Expires August 30, 2007 [Page 8] Internet-Draft IANA Registration Enumservice UNUSED February 2007 4. The Proposed Solution We propose an explicit indication of this "number unused" state. This uses a NAPTR in the zone associated with an unused telephone number, or at least in the "enclosing" zone, with an Enumservice called "unused" that should be taken as an assertion that the associated E.164 number is not assigned to a subscriber for communications service; it's an unused number. This NAPTR can also be used by a National Regulatory Authority (NRA) to indicate number blocks that it has reserved, and has not allocated to a service provider. It is a matter for individual countries whether or not they will support (or require) information giving the identity of the current "owner" of an E.164 number within their responsibility to be made available via IRIS/WHOIS. Thus it may not be possible to use these protocols to find out the entity responsible for a number or number range concerned, particularly where that number or range is not currently "in use". Since the registration and syntax of a terminal NAPTR for "E2U" Enumservices requires at least one URI scheme to be defined, we propose that the Enumservice "unused" will use a "data:" URI. The content provided in this "data:" URI is a national matter. Stastny, et al. Expires August 30, 2007 [Page 9] Internet-Draft IANA Registration Enumservice UNUSED February 2007 5. ENUM Service Registration - UNUSED Enumservice Name: "unused" Enumservice Type: "unused" Enumservice Subtypes: "data" URI Schemes: "data:" Functional Specification: The proposed solution in Section 4. Definition of expected action: If a NAPTR with this Enumservice is received and processed, it indicates that there are no possible communication methods that can be used to reach the end point. The queried E.164 number is currently not allocated, or unassigned to a subscriber for communications service. The recipient SHOULD treat this response as if they had received a "number not in service" indication from a terminating network. Note that the generated URI is not a potential target for any current call. The content of the data:URI [5] MUST NOT be used in normal call processing but only if there is a non-call related reason. Security considerations: see Section 8. Intended usage: COMMON Authors Lawrence Conroy, Richard Stastny, Jim Reid (for authors contact details see Authors' Addresses section). Any other information that the author deems interesting: Please see Section 7 for a discussion on choices for where to provision the Enumservice "unused" and its impact on "real world" performance. Stastny, et al. Expires August 30, 2007 [Page 10] Internet-Draft IANA Registration Enumservice UNUSED February 2007 6. Examples 1. Unassigned number $ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. 3.8.0 NAPTR 10 100 "u" "E2U+unused:data" "!^.*$!data:,unassigned!" . This indicates that the controller of the number block +441632960 does not provide telephony service via the number +441632960083; it is not assigned to a subscriber. 2. Unallocated number $ORIGIN 1.2.7.3.4.e164.arpa. * NAPTR 10 100 "u" "E2U+unused:data" "!^.*$!data:,unallocated!" This indicates that the number block +43721 is not allocated by the NRA to any service provider and therefore no number in this block provides any communication service. Stastny, et al. Expires August 30, 2007 [Page 11] Internet-Draft IANA Registration Enumservice UNUSED February 2007 7. Operational Guidance The goal of NAPTRs holding this Enumservice is to provide an explicit indication of the way in which an ENUM client should behave. It avoids ambiguity in the way that an ENUM client can interpret the response to its ENUM query. To provide a deterministic indication in all of the use cases listed in Section 3.1, one must consider potential national provisioning choices, kinds of telephone number plans in use, both primitive and advanced ENUM client behaviour, as well as the options open to a provider. This section covers the issues involved, and then proposes provisioning and client choices for each use case. 7.1. Provisioning Scenarios There are three main scenarios for provisioning. Which of these is used is a national matter. These are: 1. Domains associated with all numbers are provisioned, whether or not these are assigned or allocated. 2. Domains associated with all "in service" numbers are provisioned. Each subscriber may request delegation of the domain associated with his or her telephone number, but otherwise the service provider provisions the domain. 3. No domains are provisioned apart from those that subscribers choose to delegate, associated with the numbers through which they are provided service. There is a fourth possibility (provisioning only domains associated with numbers that are NOT in service), but this is not useful and is not employed anywhere. Another influence on these scenarios is the NRA's choice whether or not to permit information showing if a telephone number is "in service" to be publicly available through ENUM. Some NRAs have decided to permit assignees to register ENUM domains, but will not allow service providers to publish this information. 7.2. Number Plans When considering telephone numbers, there is a further layer of complexity; whether the numbers within a block/range of the number plan all have a fixed number length or may have a variable number length. Stastny, et al. Expires August 30, 2007 [Page 12] Internet-Draft IANA Registration Enumservice UNUSED February 2007 7.2.1. Fixed Number Length Many countries use fixed number length. In such a scheme, all valid telephone numbers within a given block/range have a defined length - within this block/range, the number of digits used for the subscriber number is fixed. Thus, for a given initial digit string, the length of the subsequent digit string together constituting a valid telephone number is known. All other digit strings are invalid. In this scenario, a block of telephone numbers will be allocated to a service provider, and that provider will in turn assign individual telephone numbers for services it provides to end customers. Telephone numbers are of a defined length whether or not they are allocated or assigned. For example, for the initial digit string "+44160649", the subsequent number string is three digits in length. However, for the initial digit string "+44160650", the subsequent string is four digits in length. In the first example, it is known that +44-1606-4900 or +44-1606- 490000 cannot be valid telephone numbers, as these have the wrong number of digits. Conversely, the telephone number +44-1606-500000 is potentially valid, whilst +44-1606-50000 is not. See "The National Numbering Scheme - Telephone Numbers Administered By Ofcom" for details of these examples, available at: 7.2.2. Variable Number length Some countries have variable number length within blocks/ranges. Here numbering blocks exist where the length of subscriber numbers may differ, and the length of each is only defined by individual assignment to the subscriber. The NRA responsible for the number range defines a minimum and maximum assigned number length for use in this number range. Typically, it allocates number blocks from within this range to providers, who will in turn assign telephone numbers to their customers. The subscriber can choose the length of his or her assigned telephone number within these bounds. The only restriction is that all these initial digit patterns representing telephone numbers are unique. For example, within the Range Number "+43-1-876", the NRA may have decided on an extra 2 to 4 digits as the minimum and maximum digit lengths for subscriber numbers. If it allocates the Block Number "+43-1-876" to a provider, then valid subscriber numbers within that block could be: Stastny, et al. Expires August 30, 2007 [Page 13] Internet-Draft IANA Registration Enumservice UNUSED February 2007 +43-1-876-22 +43-1-876-334 +43-1-876-3356 +43-1-876-3357 (note that whilst +43-1-876-22 is a valid subscriber number, +43-1-876-33 would not be, once any subscriber has chosen his or her (longer) number starting with that initial pattern. No assigned telephone number may be a prefix of another). As the subscriber chooses the length of the assigned number (within bounds chosen by the NRA from which this number block is allocated), it is not possible in advance for the provider to predict exactly what telephone numbers it will assign. All it can know is that, in each case, there is a variable length set of numbers with a common prefix, members of which are not currently assigned. How many members in that set reflect valid telephone numbers depends on future choices on number length by a customer or customers. For example, before the numbers +43-1-876-334, +43-1-876-3356, and +43-1-876-3357 are assigned, the service provider has no way to predict the number length its customers will require, and so what numbers will be assigned to them. This in turn means that the provider cannot decide which zones will be associated with assigned numbers. 7.2.2.1. Valid destination numbers with variable length Valid numbers depend both on the initial choice of a customer within bounds set by the NRA, and also on the subsequent choice of that customer in the destination numbers for which it will accept calls. The number assigned to a customer acts almost as a "prefix", with a range of potentially valid numbers all starting with that digit pattern. When a call is placed, the entire destination number is passed to the subscriber's system "in one go" at the start of the call. All of the dialled digits are usable for "Direct Dialling In" (DDI). The subscriber decides which destination numbers it will accept. It is not possible for anyone else to predict which of the potential range of these numbers starting with the assigned number pattern is effectively in service. The difference between fixed and variable length numbers is most obvious with companies that have a set of directly diallable extension numbers. For example, consider a company that has 9999 Stastny, et al. Expires August 30, 2007 [Page 14] Internet-Draft IANA Registration Enumservice UNUSED February 2007 such diallable numbers. In a fixed number plan this would imply that the company has been assigned 9999 subscriber numbers, whilst with an variable number plan the same company would have been assigned only 1 subscriber number. 7.3. Provisioning Techniques in ENUM Domains Where possible, the ideal is for each ENUM domain to have either a "usable" NAPTR or an "unused" NAPTR provisioned. In this way a client will never receive a DNS response with RCODE=3, or one with RCODE=0 but no answers. However, there are several scenarios where it is difficult or impossible to provision NAPTRs into domains tied to each potentially valid telephone number. This is particularly the case for countries that have open numbering plans. There are few possible alternatives to allow provisioning of NAPTRs that indicate how clients should process their ENUM requests. 7.3.1. Wildcards One approach is to use Wildcard NAPTR entries. Provisioning these is difficult, as wildcards do not operate as many expect. Originally mentioned in RFC 1034, RFC 4592 [7] gives a thorough description of wildcards, and defines a number of terms that are useful. ENUM associated domains typically include several empty non-terminal labels. Provisioning wildcards with such domain names has proved complex and prone to error. Where some domains are active and many are not within such a domain tree, it is necessary to provision several wildcards in order to cover the inactive domain space. As domains are activated and deactivated, this task requires a continuous re-evaluation of the wildcards needed and significant re- provisioning effort. 7.3.2. "Closest Encloser" domains A similar result but with much less provisioning effort (and risk of error) can be achieved using a standard feature of DNS used for negative caching. RFC 2308 describes negative caching. This is the mechanism by which a DNS server indicates to a resolver that the queried resource does not exist, and how the resolver should respond to this information. If a DNS response with RCODE=3 is returned (Name Error), it will normally have no answers, but at least the authority section will include a Start Of Authority (SOA) record identifying the "closest enclosing" domain from which the authoritative negative response was generated. If the Name Error was returned as a result of a CNAME or Stastny, et al. Expires August 30, 2007 [Page 15] Internet-Draft IANA Registration Enumservice UNUSED February 2007 DNAME referral (but the CNAME/DNAME target does not exist), the CNAME/DNAME will be present in the answer section, and the SOA indicates the "closest enclosing" domain for that target. 7.3.2.1. Provisioning in the "Closest Encloser" domain In the case of a DNS response with RCODE=3 and a non-empty answer section including a CNAME or DNAME (i.e. where a CNAME/DNAME target does not exist), the ENUM client has no choice but to "guess" and use its default behaviour. In the more typical scenario where there is no information at all for a domain, the presence of the SOA record in the DNS Name Error response opens another possibility. The provider (or NRA) responsible for this "closest encloser" domain can provision a NAPTR into it. Any ENUM client querying that domain will receive this NAPTR and can use it to determine the best way to proceed. This approach to provisioning and ENUM query behaviour solves a number of problems that are otherwise intractable. Notably, it can provide a solution to the ambiguity and potential failure caused by default behaviour on a client receiving a DNS response with no answers and RCODE=3 (Name Error). Finally, the "closest encloser" domain is likely to reflect a number block (and be associated with a block of telephone numbers). ENUM clients may collectively make many queries for non-existent domains tied to different telephone numbers within this block. If this does occur and ENUM clients use this "closest encloser" re-query approach, the response message from the common "closest encloser" domain is very likely to be present in a recursive resolver's cache. The query load to a DNS server authoritative for this domain will not be greatly increased, even in the face of many such ENUM requests. Stastny, et al. Expires August 30, 2007 [Page 16] Internet-Draft IANA Registration Enumservice UNUSED February 2007 7.4. Recommended Provisioning Strategies These strategies relate to the use cases introduced in Section 3.1. Case 1 The NRA that controls the unallocated range or block of numbers may provision a wildcard "unused" NAPTR in the Range or Block Domain. It should also provision a (non-wildcard) "unused" NAPTR in this domain. Wildcards do not match queries in that domain, so this second NAPTR is needed as well. Case 2 If all of the following conditions are true: * the NRA allows identification of unused numbers * all domains are provisioned (either by the provider or by the assignee, where a number is "in service") * it is possible to identify the ENUM domains that will at some point be valid (i.e. this is part of a closed number plan), then the provider can provision an "unused" NAPTR into each domain associated with a telephone number via which service is not currently provided. Otherwise the provider can do nothing to distinguish between cases 2 and 3. It should proceed as described next. Case 3 If all of the following conditions are true: * the NRA allows identification of "in service" numbers * all domains associated with "in service" numbers are provisioned (either by the provider or by the assignee) * it is possible to identify the ENUM domains that will at some point be valid (i.e. this is part of a closed number plan), then the provider can provision a default NAPTR into each domain associated with a telephone number for which the assignee has not requested registration. Stastny, et al. Expires August 30, 2007 [Page 17] Internet-Draft IANA Registration Enumservice UNUSED February 2007 As mentioned above, if these conditions are not all met, then the provider can do nothing to distinguish between cases 2 and 3. Otherwise, the provider should provision a default NAPTR into the Block Domain indicating the service it provides to numbers in this block. This default NAPTR will have an Enumservice appropriate to the communications service provided. For example, it could hold a "voice:tel" or "sip" (or "h323") Enumservice. Any ENUM client using the "closest encloser" re-query procedure will retrieve this NAPTR and can confirm that attempting to place the call as indicated is the correct strategy. Case 4 In this case, the assignee has requested registration of the domain associated with the telephone number by which he or she is provided communications service. The assignee should consider provisioning a "Backstop" NAPTR into the zone, particularly where this domain holder does not want ENUM clients to employ their default behaviour. For example, if the ENUM registrant does not want clients to attempt calls via the CSN, then it can provision a Backstop NAPTR with an "unused" Enumservice. Case 5 This is similar to case 4, but it is important that clients do not try to place a call via the CSN. Thus in this case the registrant should provision a "Backstop" NAPTR with an "unused" Enumservice into his or her zone. Case 6 This is similar to case 2 above, but it is important that ENUM clients do not attempt to place calls to these numbers via the CSN. So far, "ENUM only" number ranges have been issued only in regions with open number plans, so it is not possible for the NRA or provider to provision unused domains. The controller of this range or number block should provision an "unused" NAPTR in the Range or Block Domain. In so doing, ENUM clients using the "closest encloser" re-query procedure will retrieve this NAPTR and will know not to attempt to place the call via the CSN. 7.5. Client Behaviour 7.5.1. Basic Client Behaviour If an ENUM lookup for a number explicitly returns the "unused" NAPTR, the response indicates to the client that the number is known to ENUM Stastny, et al. Expires August 30, 2007 [Page 18] Internet-Draft IANA Registration Enumservice UNUSED February 2007 but there are no implicit communication end-points associated with it. The client can then signal an error to the application or end user instead of then trying and failing to terminate the call on the PSTN, which would have been the typical behaviour of an ENUM-aware VoIP/PSTN gateway if the ENUM lookup had returned an NXDOMAIN or NOHOST response. 7.5.2. Advanced Client Behaviour If an ENUM client receives a DNS response with RCODE=0 and some relevant (type=NAPTR) answers, it can use the enclosed NAPTRs to deliver (or dispose of) its communications attempt. If the response has no such answers, then it can "guess", by employing its default behaviour. However, what is it to do if it receives a response with RCODE=3 (indicating that the queried domain does not exist)? If an ENUM client receives a response with RCODE=3 (Name Error), that response packet will include an SOA record indicating the "closest encloser" domain to the non-existent resource. The ENUM client can abandon the ENUM request at this point and "guess" what its reaction should be, using its local knowledge or a default behaviour. As mentioned elsewhere, this choice may well be incorrect in several scenarios. However, it may instead send a DNS query for NAPTRs to the "closest encloser" domain indicated in the RCODE=3 response it has received (assuming that the response held no answers). If this new DNS query does not return a NAPTR, then the client has no choice but to abandon the ENUM evaluation. It MUST NOT continue to send DNS queries as part of this ENUM request. If, however, a NAPTR is returned in the response, it can use it to decide what action to take to dispose of the call that triggered the ENUM request. If this NAPTR is not supported by the ENUM client, then that client should abandon the communications attempt. An ENUM client employing this "closest encloser" re-query uses standard DNS queries and reacts to standard DNS responses. This procedure is optional, and a client using it sends at most two DNS queries. By using this technique (where the provider or NRA has provisioned its domains as recommended) the ENUM client can gain a clear idea of its "best" choices for delivering (or disposing of) a call. Based on knowledge published by the provider or NRA, a client can eliminate the "guesswork" that would otherwise be its only choice. Stastny, et al. Expires August 30, 2007 [Page 19] Internet-Draft IANA Registration Enumservice UNUSED February 2007 8. Security Considerations DNS does not make policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered to be open to the public. An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC [8] to these, is provided in [9]. Stastny, et al. Expires August 30, 2007 [Page 20] Internet-Draft IANA Registration Enumservice UNUSED February 2007 9. IANA Considerations This document requests registration of the "unused" Enumservice with the sub-type "unused:data" according to the guidelines and specifications in RFC 3761 [2] and the definitions in this document. This Enumservice is intended for use with the "data:" URI scheme. Stastny, et al. Expires August 30, 2007 [Page 21] Internet-Draft IANA Registration Enumservice UNUSED February 2007 10. Acknowledgments Thanks to Patrik Faltstrom, Michael Mealling and Peter Koch for their thorough feedback, and colleagues in ETSI TISPAN who helped to clarify the operational features during the development of [10]. Thanks also to the members of the ENUM working group for their wide ranging discussions. These have helped to indicate where changes were needed in this document to help explain what is an intrinsically difficult subject. Stastny, et al. Expires August 30, 2007 [Page 22] Internet-Draft IANA Registration Enumservice UNUSED February 2007 11. References 11.1. Normative References [1] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005. [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. [5] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998. 11.2. Informative References [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [7] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006. [8] Arends, R. and et al. , "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [9] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. [10] ETSI, "Minimum Requirements for Interoperability of ENUM Implementations", ETSI TS 102 172, January 2005. [11] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [12] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005. [13] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. Stastny, et al. Expires August 30, 2007 [Page 23] Internet-Draft IANA Registration Enumservice UNUSED February 2007 Authors' Addresses Richard Stastny Oefeg Postbox 147 1103 Vienna Austria Phone: +43-664-420-4100 Email: Richard.stastny@oefeg.at Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey United Kingdom Phone: +44-1794-833666 Email: lwc@roke.co.uk Jim Reid DNS-MODA 6 Langside Court Bothwell, SCOTLAND United Kingdom Phone: +44 1698 852881 Email: jim@dns-moda.org Stastny, et al. Expires August 30, 2007 [Page 24] Internet-Draft IANA Registration Enumservice UNUSED February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stastny, et al. Expires August 30, 2007 [Page 25]