One document matched: draft-ietf-enum-unused-00.txt
ENUM R. Stastny
Internet-Draft Oefeg
Intended status: Standards Track L. Conroy
Expires: July 15, 2007 Siemens Roke Manor Research
J. Reid
DNS-MODA
January 11, 2007
IANA Registration for Enumservice UNUSED
<draft-ietf-enum-unused-00.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 July 15, 2007.
Copyright Notice
Copyright (C) The Internet Trust (2006).
Stastny, et al. Expires July 15, 2007 [Page 1]
Internet-Draft IANA Registration Enumservice UNUSED January 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. Closed Numbering Plans . . . . . . . . . . . . . . . . 13
7.2.2. Open Number Plans . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 19
7.5.1. Basic Client Behaviour . . . . . . . . . . . . . . . . 19
7.5.2. Advanced Client Behaviour . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Stastny, et al. Expires July 15, 2007 [Page 2]
Internet-Draft IANA Registration Enumservice UNUSED January 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 July 15, 2007 [Page 3]
Internet-Draft IANA Registration Enumservice UNUSED January 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. 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, it must abandon
its evaluation.
Stastny, et al. Expires July 15, 2007 [Page 4]
Internet-Draft IANA Registration Enumservice UNUSED January 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 July 15, 2007 [Page 5]
Internet-Draft IANA Registration Enumservice UNUSED January 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 July 15, 2007 [Page 6]
Internet-Draft IANA Registration Enumservice UNUSED January 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
A DNS response with RCODE=3 is 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
Stastny, et al. Expires July 15, 2007 [Page 7]
Internet-Draft IANA Registration Enumservice UNUSED January 2007
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 July 15, 2007 [Page 8]
Internet-Draft IANA Registration Enumservice UNUSED January 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 July 15, 2007 [Page 9]
Internet-Draft IANA Registration Enumservice UNUSED January 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 July 15, 2007 [Page 10]
Internet-Draft IANA Registration Enumservice UNUSED January 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 July 15, 2007 [Page 11]
Internet-Draft IANA Registration Enumservice UNUSED January 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 subsrcibers
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 this is a "closed" or "open" numbering plan.
Stastny, et al. Expires July 15, 2007 [Page 12]
Internet-Draft IANA Registration Enumservice UNUSED January 2007
7.2.1. Closed Numbering Plans
In many countries closed numbering plans are in use. In such a
scheme, all valid telephone numbers have a defined length - 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 these scenarios, 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.
7.2.1.1. Fixed Number Plans
Some regions go farther, and select a fixed number plan. This is a
closed number plan in which there is only one valid pattern and digit
string length. For example, in the North American Numbering Plan
(NANP) all area codes are three digits long and all subscriber
numbers are seven digits long, for example tel:+1-555-1234567. That
is, there is a one digit CC digit string, followed by a three digit
"area code" string, and the rest of any valid number will have seven
digits. Digit strings starting with "+1" that have a different
length are known to be invalid. Typically, these number plans are
associated with fixed dialling plans (meaning that the full number
must be dialled regardless of the calling and called numbers.
7.2.2. Open Number Plans
Some countries have open numbering plans. 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
Stastny, et al. Expires July 15, 2007 [Page 13]
Internet-Draft IANA Registration Enumservice UNUSED January 2007
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:
+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 is not).
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 in an open number plan
Within an open number plan, 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
Stastny, et al. Expires July 15, 2007 [Page 14]
Internet-Draft IANA Registration Enumservice UNUSED January 2007
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 open and closed numbering plans is most
obvious with companies that have a set of directly diallable
extension numbers. For example, consider a company that has 9999
such diallable numbers.
In a closed number plan this would imply that the company has been
assigned 9999 subscriber numbers, whilst with an open 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 [6] 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
Stastny, et al. Expires July 15, 2007 [Page 15]
Internet-Draft IANA Registration Enumservice UNUSED January 2007
negative caching. RFC 3208 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 MUST
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
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 using this "closest encloser" re-query approach may make many
queries for non-existent domains tied to different telephone numbers
within this block. If this does occur, the response message from
their common "closest encloser" domain is very likely to be present
in a 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 July 15, 2007 [Page 16]
Internet-Draft IANA Registration Enumservice UNUSED January 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 July 15, 2007 [Page 17]
Internet-Draft IANA Registration Enumservice UNUSED January 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 provision a
"Backstop" NAPTR into the zone, particularly where the 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.
Stastny, et al. Expires July 15, 2007 [Page 18]
Internet-Draft IANA Registration Enumservice UNUSED January 2007
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
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
Stastny, et al. Expires July 15, 2007 [Page 19]
Internet-Draft IANA Registration Enumservice UNUSED January 2007
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 July 15, 2007 [Page 20]
Internet-Draft IANA Registration Enumservice UNUSED January 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 [7] to these, is provided in [8].
Stastny, et al. Expires July 15, 2007 [Page 21]
Internet-Draft IANA Registration Enumservice UNUSED January 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 July 15, 2007 [Page 22]
Internet-Draft IANA Registration Enumservice UNUSED January 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 [9].
Stastny, et al. Expires July 15, 2007 [Page 23]
Internet-Draft IANA Registration Enumservice UNUSED January 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] Lewis, E., "The Role of Wildcards in the Domain Name System",
RFC 4592, July 2006.
[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.
[10] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC 2308, March 1998.
[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 July 15, 2007 [Page 24]
Internet-Draft IANA Registration Enumservice UNUSED January 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 July 15, 2007 [Page 25]
Internet-Draft IANA Registration Enumservice UNUSED January 2007
Full Copyright Statement
Copyright (C) The Internet Society (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 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 July 15, 2007 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-24 01:14:37 |