TOC 
ENUMR. Stastny
Internet-DraftOefeg
Intended status: Standards TrackL. Conroy
Expires: May 1, 2008RMRL
 J. Reid
 DNS-MODA
 October 29, 2007


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




 TOC 

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.



 TOC 

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



 TOC 

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



 TOC 

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.


 TOC 

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:

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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



 TOC 

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.


 TOC 

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



 TOC 

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.



 TOC 

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.



 TOC 

10.  References



 TOC 

10.1. Normative References

[refs.E164] ITU-T, “The International Public Telecommunication Number Plan,” Recommendation E.164, February 2005.
[refs.RFC1034] Mockapetris, P., “DOMAIN NAMES - CONCEPTS AND FACILITIES,” RFC 1034, November 1987.
[refs.RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, BCP 14, March 1997.
[refs.RFC2397] Masinter, L., “The "data" URL scheme,” RFC 2397, August 1998.
[refs.RFC3403] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database,” RFC 3403, October 2002.
[refs.RFC3761] Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” RFC 3761, April 2004.


 TOC 

10.2. Informative References

[refs.ETSI-TS102172] ETSI, “Minimum Requirements for Interoperability of ENUM Implementations,” ETSI TS 102 172, January 2005.
[refs.RFC3833] Atkins, D. and R. Austein, “Threat Analysis of the Domain Name System (DNS),” RFC 3833, August 2004.
[refs.RFC4035] Arends, R. and et al. , “Protocol Modifications for the DNS Security Extensions,” RFC 4035, March 2005.


 TOC 

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


 TOC 

Full Copyright Statement

Intellectual Property