IANA Registration for Enumservice UNUSED
<draft-ietf-enum-unused-03.txt>

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 May 1, 2008.

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
2.  Terminology
3.  Background: ENUM Lookup Cases
    3.1.  ENUM Registration Cases
    3.2.  ENUM Outcomes
    3.3.  "Default" Strategy on receiving response with RCODE=3
    3.4.  The Problem
    3.5.  "ENUM only" query loop
4.  The Proposed Solution
5.  ENUM Service Registration - UNUSED
6.  Examples
7.  Security Considerations
8.  IANA Considerations
9.  Acknowledgements
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

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 [refs.E164] (ITU-T, “The International Public Telecommunication Number Plan,” February 2005.) 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 ("E.164 Number Mapping") 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 Domain Name System (DNS), they can use ENUM as described in RFC 3761 (Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” April 2004.) [refs.RFC3761] to find alternative contacts to the E.164 number and place the call using whatever system was indicated in those contacts. In its intended use, an ENUM query would return a set of NAPTR ("Naming Authority Pointer") resource records [refs.RFC3403] (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database,” October 2002.), and these would be processed to select the appropriate communications contact choices. Each communications contact is held in a URI ("Universal Resource Indicator") generated from the contents of a NAPTR.

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.

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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [refs.RFC2119].

3.  Background: ENUM Lookup Cases

This section describes the problems that arise where the ENUM system does not hold full information on all telephone numbers and clients display typical behaviour. The proposed solution to the problems described here is covered in Section 4 (The Proposed Solution) and in the unused Enumservice registration in Section 5 (ENUM Service Registration - UNUSED).

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 either 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 [refs.RFC1034] (Mockapetris, P., “DOMAIN NAMES - CONCEPTS AND FACILITIES,” November 1987.) 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:

• 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.
• 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.
• 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 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.

4.  The Proposed Solution

We propose an explicit indication of this "number unused" state (as described in points 1,2, and 6 in Section 3.1 (ENUM Registration Cases)). This uses a NAPTR in the zone associated with an unused telephone number, 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. For example, it may be used to provide additional information about the reason for the existence of this record, or (where required by the competent regulatory authority) the identity of the entity responsible for this number.

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 (The Proposed Solution).

Definition of expected action:

When an ENUM lookup for a number explicitly returns the "unused" NAPTR, the response indicates to the client that the number is known to ENUM 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 a DNS response indicating NXDOMAIN or NOHOST.

Thus, 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 (Masinter, L., “The "data" URL scheme,” August 1998.) [refs.RFC2397] MUST NOT be used in normal call processing but only if there is a non-call related reason.

Security considerations: see Section 7 (Security Considerations).

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: None

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 0.6.9.4.5.1.1.4.4.e164.arpa.
   * NAPTR 10 100 "u" "E2U+unused:data"
       "!^.*$!data:,unallocated!"
   
   This indicates that the number block +441154960 is not allocated by the NRA to any service provider and therefore no number in this block provides any communication service.

7.  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 ("Domain Name Security") (Arends, R. and et al. , “Protocol Modifications for the DNS Security Extensions,” March 2005.) [refs.RFC4035] to these, is provided in [refs.RFC3833] (Atkins, D. and R. Austein, “Threat Analysis of the Domain Name System (DNS),” August 2004.).

8.  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 [refs.RFC3761] (Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” April 2004.) and the definitions in this document. This Enumservice is intended for use with the "data:" URI scheme.

9.  Acknowledgements

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 [refs.ETSI‑TS102172] (ETSI, “Minimum Requirements for Interoperability of ENUM Implementations,” January 2005.). 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. Finally, thanks to Alex Mayrhofer for his useful document review, picking up the remaining issues.

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © 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.