Internet DRAFT - draft-pfautz-lind-enum-carrier-user
draft-pfautz-lind-enum-carrier-user
ENUM P. Pfautz
Internet-Draft AT&T
Expires: December 5, 2005 S. Lind
AT&T Labs
T. Creighton
Comcast Cable Communications
June 3, 2005
IANA Carrier/User enumservice Registration
draft-pfautz-lind-enum-carrier-user-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 December 5, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document registers, pursuant to the guidelines in RFC 3761,
tElephone NUmber Mapping (ENUM) services to allow a single registry
to support end user and carrier services with independent name
Pfautz, et al. Expires December 5, 2005 [Page 1]
Internet-Draft User/Carrier ENUM June 2005
servers holding the terminal NAPTR (Naming Authority Pointer) records
identifying the communication services for each. The to-be-
registered enumservices make use of non-terminal NAPTR records and
DDDS (Dynamic Delegation Discovery System) replacement to achieve
this end.
Conventions used in this document
RFC2119 [1] provides the interpretations for the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. User and Carrier Non-Terminal NAPTRs . . . . . . . . . . . . . 4
3. ENUM Service Registration for Carrier ENUM . . . . . . . . . . 4
4. ENUM Service Registration for User ENUM . . . . . . . . . . . 5
5. Control of Records in Tier 1 . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 9
Pfautz, et al. Expires December 5, 2005 [Page 2]
Internet-Draft User/Carrier ENUM June 2005
1. Introduction
Work on the implementation of ENUM RFC3761 [2] in the ITU [3] and
various national bodies [4] to date has been based on a tiered
architecture with a Tier 0 registry, authoritative for the domain
e164.arpa, containing NS records delegating domains corresponding to
country codes (e.g., 1.e164.arpa) to a Tier 1 registry containing NS
records that in turn delegate domains associated with individual
E.164 numbers in a given country code. A Tier 1 registry in these
instances contains NS records that point to the Tier 2 that contains
the actual NATPR records for a given E.164 number[3]. Implementation
of these architectures has tended to assume an end user focus with
number assignees proactively and uniquely controlling whether their
numbers are registered into ENUM and being able to select the Tier 2
registry that contains the actual NATPR records. As the GSTN is seen
to evolve towards an application on an underlying IP network,
carriers have become increasingly interested in using ENUM for
interconnection, i.e., to provide information, such as a SIP address
of record, about where interconnecting carriers should direct calls
to a number which the carrier serves, even where the customer's
ultimate connection to the carrier's network and the customer's
premise equipment may not be IP-based. Also, as VoIP carriers
proliferate there is an understandable desire to be able to connect
calls between users of such services without going through the
circuit switched GSTN.
These needs have led to proposals for separate "carrier" or
"infrastructure" ENUM based on a root other than e164.arpa or to
suggestions that carriers be able to populate NAPTR records in their
own Tier 2 if the number assignee does not choose to register or in
the number assignee's Tier 2 if the assignee selects a Tier 2
provider other than that used by the carrier by which the number is
served in the GSTN.
The difficulties with such proposals are that they either require
construction of a separate parallel tree or complicate provisioning
and may not support carrier grade service. In the first case, a
separate tree raises issues about who would be allowed to populate
information into it and who would have the ability to access
information. In the second case, for example, if the number assignee
selects a Tier 2 other than the one chosen by the carrier that serves
their number in the GSTN, the carrier would need to find a way to
provision its NAPTRs into that Tier 2 which may also not meet carrier
reliability needs. Further, obtaining user consent for registration,
while essential for applications that may open vulnerabilities to an
end user, is burdensome where all numbers must be registered for
effective interconnection of carriers and may be unnecessary where
registration only involves association of E.164 numbers with carrier
Pfautz, et al. Expires December 5, 2005 [Page 3]
Internet-Draft User/Carrier ENUM June 2005
network elements rather than the end user directly.
2. User and Carrier Non-Terminal NAPTRs
As discussed above, ENUM implementation has been based on a tiered
architecture with Tier 1 containing NS records that point to the Tier
2 that contains the actual NATPR records for a given E.164 number[3].
It is here proposed that, instead of using NS records to delegate to
a Tier 2 name server, the DDDS substitution capability be employed to
allow non-terminal NAPTR records to generate new DNS queries for
terminal NAPTRs to different domains based on the enumservice
designation of "carrier" or "user." Section 1.3 of RFC 3761
("Application of local policy") states "there are ... cases (non-
terminal Rules) where two different Rules both match the given
Application Unique String... For example, by using a non-terminal
NAPTR a given set of numbers is sent to some private-dialing-plan-
specific zone." Section 2.4 ("Flags") states "If this [the terminal
"u" ] flag is not present then this Rule is non-terminal. If a Rule
is non-terminal then clients MUST use the key produced by this
Rewrite Rule as the new key in the DDDS loop (i.e., causing the
client to query for new NAPTR records at the domain name that is the
result of this Rule)."
Because the object of the query to Tier 1 is to obtain a domain name
to query rather than a URI, we use the Replacement field of the NAPTR
rather than the Regexp as described in RFC 3403 RFC3403 [5]. Thus
records for a number in Tier 1 might look like:
$Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa.
IN NAPTR 100 50 "" "E2U+user" "" 9.0.3.5.7.6.8.7.9.4.1.joesenum.com
IN NAPTR 100 50 "" "E2U+carrier" "" 9.0.3.5.7.6.8.7.9.4.1.telco.net
The first record would result in a query to the nameserver designated
by the end user assignee of the E.164 number and the second to the
nameserver designated by the carrier of record in the GSTN for the
E.164 number. Note that as the Tier 1 NAPTRs are non-terminal,
neither contains a specific communication protocol type in the
enumservice spec (e.g., "sip"). NAPTR records for acutal
communication services would only be provided in the corresponding
user or carrier name server where the NAPTR records are terminal and
would include the enumservice specs such as for SIP, i.e., "E2U+sip".
3. ENUM Service Registration for Carrier ENUM
As defined in RFC3761 [2], the following is a template for the
registration of the enumservice specified in this document.
Pfautz, et al. Expires December 5, 2005 [Page 4]
Internet-Draft User/Carrier ENUM June 2005
ENUMservice Name: "E2U+carrier"
Type(s) "carrier"
Subtypes: N/A
URI Schemes(s) N/A
Functional Specification: see Section 2
Security Considerations: see Section 6
Intended Usage: COMMON
Author: Penn Pfautz (ppfautz@att.com)
Any other information the author deems interesting: This ENUMservice
is only to be used with non-terminal NAPTR records. See Section 5.
4. ENUM Service Registration for User ENUM
As defined in RFC3761 [2], the following is a template for the
registration of the enumservice specified in this document.
ENUMservice Name: "E2U+user"
Type(s) "user"
Subtypes: N/A
URI Schemes(s) N/A
Functional Specification: see Section 2
Security Considerations: see Section 6
Intended Usage: COMMON
Author: Penn Pfautz (ppfautz@att.com)
Any other information the author deems interesting: This ENUMservice
is only to be used with non-terminal NAPTR records. See Section 5.
5. Control of Records in Tier 1
Although two records are populated in Tier 1, the lines of authority
for each are clear. The E2U+user record is controlled by, and only
populated at the request of, the end user assignee of the E.164
Pfautz, et al. Expires December 5, 2005 [Page 5]
Internet-Draft User/Carrier ENUM June 2005
number. The assignee has the right to select a registrar and a name
server ("Tier 2") provider of their choice in a competitive
enivronment. The E2U+carrier record, on the other hand, is
controlled by the GSTN carrier of record for the E.164 number (i.e.,
the service provider who has been allocated the block of numbers in
which the number in question is contained or to which the number has
been ported).
Both end users and carriers may populate different NAPTR records in
their respective domains. In such cases the client originating the
ENUM query will be responsible for obtaining all (or as many as
possible) ENUM records and for deciding which records to make use of
in initiating communication.
6. Security Considerations
Existing security considerations for ENUM detailed in RFC3761 [2]
still apply. Note that some registration validation issues
concerning end user ENUM may not apply to carrier ENUM. Where the
Tier 1 registry is able to identify the carrier serving a number
e.g., based on industry data for number block assignments and number
portability, registration might be more easily automated and a
separate registrar not required.
Some parties have expressed concern that a carrier ENUM could
compromise end user privacy by making it possible for others to
identify unlisted or unpublished numbers based on their registration
in ENUM. This can be avoided if carriers register all of the their
allocated (as opposed to assigned) numbers. Unassigned numbers
should be provisioned to route to the carrier's network in the same
fashion as assigned numbers and only then provide an indication that
they are unassigned. In that way, carrier registration of a number
in ENUM provides no more information about status of a number than
could be obtained by dialing it.
7. IANA Considerations
This document registers the 'E2U+carrier' and 'E2U+user' enumservices
under the enumservice registry described in the IANA considerations
in RFC 3761. Details of the registration are given in sections 3 and
4.
8. Acknowledgements
The authors wish to thank Rich Shockey and Patrik Faltstrom for their
helpful discussion on this topic.
Pfautz, et al. Expires December 5, 2005 [Page 6]
Internet-Draft User/Carrier ENUM June 2005
9. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[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] International Telecommunications Union, "Supplement 3 to
Recommendation E.164: Operational and administrative issues
associated with national implementations of the ENUM functions",
2004.
[4] ENUM Forum, "ENUM Forum Specifications for US Implementation of
ENUM, Document 6000_1 0", March 2003.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
Authors' Addresses
Penn Pfautz
AT&T
200 S. Laurel Ave
Middletown, NJ 07748
USA
Email: ppfautz@att.com
Steven Lind
AT&T Labs
180 Park Ave
Florham Park, NJ 07932-0971
USA
Email: slind@att.com
Pfautz, et al. Expires December 5, 2005 [Page 7]
Internet-Draft User/Carrier ENUM June 2005
Tom Creighton
Comcast Cable Communications
1500 Market Street
Philadelphia, PA 19102
USA
Email: tom_creighton@cable.comcast.com
Pfautz, et al. Expires December 5, 2005 [Page 8]
Internet-Draft User/Carrier ENUM June 2005
Intellectual Property Statement
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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Pfautz, et al. Expires December 5, 2005 [Page 9]
Internet-Draft User/Carrier ENUM June 2005
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Pfautz, et al. Expires December 5, 2005 [Page 10]
