One document matched: draft-ietf-enum-unused-03.txt
Differences from draft-ietf-enum-unused-02.txt
ENUM R. Stastny
Internet-Draft Oefeg
Intended status: Standards Track L. Conroy
Expires: April 30, 2008 RMRL
J. Reid
DNS-MODA
October 28, 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 April 30, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Stastny, et al. Expires April 30, 2008 [Page 1]
Internet-Draft IANA Registration Enumservice UNUSED October 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. Background: ENUM Lookup Cases . . . . . . . . . . . . . . . . 5
3.1. ENUM Registration Cases . . . . . . . . . . . . . . . . . 5
3.2. ENUM Outcomes . . . . . . . . . . . . . . . . . . . . . . 6
3.3. "Default" Strategy on receiving response with RCODE=3 . . 6
3.4. The Problem . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. "ENUM only" query loop . . . . . . . . . . . . . . . . . . 7
4. The Proposed Solution . . . . . . . . . . . . . . . . . . . . 8
5. ENUM Service Registration - UNUSED . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Stastny, et al. Expires April 30, 2008 [Page 2]
Internet-Draft IANA Registration Enumservice UNUSED October 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 ("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 [2] 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 [3], 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.
Stastny, et al. Expires April 30, 2008 [Page 3]
Internet-Draft IANA Registration Enumservice UNUSED October 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 RFC 2119 [4].
Stastny, et al. Expires April 30, 2008 [Page 4]
Internet-Draft IANA Registration Enumservice UNUSED October 2007
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 and in the unused Enumservice
registration in Section 5.
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,
Stastny, et al. Expires April 30, 2008 [Page 5]
Internet-Draft IANA Registration Enumservice UNUSED October 2007
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 [5]
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
Stastny, et al. Expires April 30, 2008 [Page 6]
Internet-Draft IANA Registration Enumservice UNUSED October 2007
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.
Stastny, et al. Expires April 30, 2008 [Page 7]
Internet-Draft IANA Registration Enumservice UNUSED October 2007
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). 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.
Stastny, et al. Expires April 30, 2008 [Page 8]
Internet-Draft IANA Registration Enumservice UNUSED October 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:
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 [6] MUST NOT be used in
normal call processing but only if there is a non-call related
reason.
Security considerations: see Section 7.
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
Stastny, et al. Expires April 30, 2008 [Page 9]
Internet-Draft IANA Registration Enumservice UNUSED October 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 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.
Stastny, et al. Expires April 30, 2008 [Page 10]
Internet-Draft IANA Registration Enumservice UNUSED October 2007
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") [7] to
these, is provided in [8].
Stastny, et al. Expires April 30, 2008 [Page 11]
Internet-Draft IANA Registration Enumservice UNUSED October 2007
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 [2] and the definitions in this document.
This Enumservice is intended for use with the "data:" URI scheme.
Stastny, et al. Expires April 30, 2008 [Page 12]
Internet-Draft IANA Registration Enumservice UNUSED October 2007
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 [9].
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.
Stastny, et al. Expires April 30, 2008 [Page 13]
Internet-Draft IANA Registration Enumservice UNUSED October 2007
10. References
10.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] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
[6] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998.
10.2. Informative References
[7] Arends, R. and et al. , "Protocol Modifications for the DNS
Security Extensions", RFC 4035, March 2005.
[8] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
[9] ETSI, "Minimum Requirements for Interoperability of ENUM
Implementations", ETSI TS 102 172, January 2005.
Stastny, et al. Expires April 30, 2008 [Page 14]
Internet-Draft IANA Registration Enumservice UNUSED October 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 April 30, 2008 [Page 15]
Internet-Draft IANA Registration Enumservice UNUSED October 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 April 30, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 01:13:12 |