GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5067

Network Working Group S. Lind Request for Comments: 5067 AT&T Labs Category: Informational P. Pfautz

                                                                  AT&T
                                                         November 2007
                  Infrastructure ENUM Requirements

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Abstract

 This document provides requirements for "infrastructure" or "carrier"
 ENUM (E.164 Number Mapping), defined as the use of RFC 3761
 technology to facilitate interconnection of networks for E.164 number
 addressed services, in particular but not restricted to VoIP (Voice
 over IP.)

Table of Contents

 1.  Infrastructure ENUM . . . . . . . . . . . . . . . . . . . . . . 1
   1.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . 1
   1.2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . 2
 2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
 3.  Requirements for Infrastructure ENUM  . . . . . . . . . . . . . 3
 4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
 5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
 6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5

1. Infrastructure ENUM

1.1. Definition

 Infrastructure ENUM is defined as the use of the technology in RFC
 3761 [1] by the carrier-of-record (as defined below) for a specific
 E.164 number [2] to publish the mapping of the E.164 number into a
 URI [3] that identifies a specific point of interconnection to that
 service provider's network.  It is separate from any URIs that the
 end user, who registers their E.164 number, may wish to associate
 with that E.164 number.

Lind & Pfautz Informational [Page 1] RFC 5067 Infrastructure ENUM Requirements November 2007

 "Infrastructure ENUM" is distinguished from "End User ENUM", defined
 in RFC3761 [1], in which the entity or person having the right to use
 a number has the sole discretion about the content of the associated
 domain and thus the zone content.  From a domain registration
 perspective, the end user number assignee is thus the registrant.
 Within the infrastructure ENUM namespace, we use the term "carrier-
 of-record" for the entity having discretion over the domain and zone
 content and acting as the registrant.  The "carrier-of-record" is:
 o The Service Provider to which the E.164 number was allocated for
 end user assignment, whether by the National Regulatory Authority
 (NRA) or the International Telecommunication Union (ITU), for
 instance, a code under "International Networks" (+882) or "Universal
 Personal Telecommunications (UPT)" (+878) or,
 o if the number is ported, the service provider to which the number
 was ported, or
 o where numbers are assigned directly to end users, the service
 provider that the end user number assignee has chosen to provide a
 Public Switched Telephone Network/Public Land Mobile Network (PSTN/
 PLMN) point-of-interconnect for the number.
 It is understood that the definition of carrier-of-record within a
 given jurisdiction is subject to modification by national
 authorities.

1.2. Background

 Voice service providers use E.164 numbers currently as their main
 naming and routing vehicle.  Infrastructure ENUM in e164.arpa or
 another publicly available tree allows service providers to link
 Internet-based resources such as URIs to E.164 numbers.  This allows
 service providers, in addition to interconnecting via the PSTN/PLMN
 (or exclusively), to peer via IP-based protocols.  Service providers
 may announce all E.164 numbers or number ranges they host, regardless
 of whether the final end user device is on the Internet, on IP-based
 open or closed Next Generation Networks (NGNs), or on the PSTN or
 PLMN, provided that an access point of some type to the destination
 service provider's network is available on the Internet.  There is
 also no guarantee that the originating service provider querying
 infrastructure ENUM is able to access the ingress network element of
 the destination provider's network.  Additional peering and
 accounting agreements requiring authentication may be necessary.  The
 access provided may also be to a shared network of a group of
 providers, resolving the final destination network within the shared
 network.

Lind & Pfautz Informational [Page 2] RFC 5067 Infrastructure ENUM Requirements November 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, RFC2119 [4].

3. Requirements for Infrastructure ENUM

 1.  Infrastructure ENUM SHALL provide a means for a provider to
     populate DNS resource records (RRs) for the E.164 numbering
     resources for which it is the carrier-of-record in a single
     common publicly accessible namespace.  The single common
     namespace ultimately designated may or may not be the same as
     that designated for End User ENUM (e164.arpa.)  The Fully-
     Qualified Domain Name (FQDN) in the resulting resource records
     will not necessarily belong to or identify the carrier-of-record.
 2.  Queries of infrastructure ENUM fully qualified domain names MUST
     return a result, even if the result is Refused (RCODE = 5).
     Queries must not be rejected without response, e.g., based on
     access control lists.
 3.  Infrastructure ENUM SHALL support RRs providing a URI that can
     identify a point of interconnection for delivery to the carrier-
     of-record of communications addressed to the E.164 number.
 4.  Infrastructure ENUM SHOULD be able to support an Internet
     Registry Information Service (IRIS) [5] capability that allows
     qualified parties to obtain information regarding the E.164
     numbering resources and the corresponding carrier-of-record.
     Determination of what information, if any, shall be available
     which parties for geographic numbers is a national matter.
 5.  Implementation of infrastructure ENUM MUST NOT restrict the
     ability of an end user, in a competitive environment, to choose a
     Registrar and/or name server provider for End User ENUM
     registrations.
 6.  The domain name chosen for infrastructure ENUM and any parent
     domains MUST be hosted on name servers that have performance
     characteristics and supporting infrastructure that is comparable
     to those deployed for the Internet root name servers.  Those name
     servers for infrastructure ENUM should be configured and operated
     according to the guidelines described in [6].
 7.  Infrastructure ENUM MUST meet all reasonable privacy concerns
     about visibility of information over which an end user has no
     control.  It should, for example, support mechanisms to prevent

Lind & Pfautz Informational [Page 3] RFC 5067 Infrastructure ENUM Requirements November 2007

     discovery of unlisted numbers by comparison of ENUM registrations
     against directory listings, or inadvertent disclosure of user
     identity.
 8.  Proposed implementations of infrastructure ENUM SHOULD:
     A.  Minimize changes required to existing requirements that are
         part of RFC 3761.
     B.  Work with open as well as closed numbering plans.
     C.  Not require additional functionality of resolvers at large
         though they may require additional functionality in service
         provider resolvers that would make use of infrastructure
         ENUM.
     D.  Minimize the number of lookups required to obtain as many
         NAPTR (Naming Authority Pointer) records (end user and
         infrastructure) as possible.
     E.  Minimize knowledge of the numbering plan required of
         resolvers making use of Infrastructure ENUM.
     F.  Maximize synergies with End User ENUM.
     G.  Support interworking with private ENUM trees.  (In this
         context, a private ENUM tree is one that is not under
         e164.arpa or whatever namespace is chosen for infrastructure
         ENUM but uses instead a privately held domain.)

4. Security Considerations

 Existing security considerations for ENUM (detailed in [1]) still
 apply.  Since infrastructure ENUM involves carriers where RFC 3761
 mainly considered indviduals, implementations meeting these
 requirements SHOULD reconsider the RFC 3761 security model given this
 difference in actors concerned.  Note that some registration
 validation issues concerning End User ENUM may not apply to
 infrastructure ENUM.  Where the Tier 1 registry is able to identify
 the provider 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 an infrastructure 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 providers register all of the their
 allocated (as opposed to assigned) numbers.  Unassigned numbers

Lind & Pfautz Informational [Page 4] RFC 5067 Infrastructure ENUM Requirements November 2007

 should be provisioned to route to the provider's network in the same
 fashion as assigned numbers and only then provide an indication that
 they are unassigned.  In that way, provider registration of a number
 in ENUM provides no more information about the status of a number
 than could be obtained by dialing it.
 Implementers should take care to avoid inadvertent disclosure of user
 identities, for example, in the URIs returned in response to
 infrastructure ENUM queries.

5. IANA Considerations

 This document includes no actions to be taken by IANA.  The
 architecture ultimately chosen to meet the requirements may require
 IANA actions.

6. Normative References

 [1]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
      Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
      Application (ENUM)", RFC 3761, April 2004.
 [2]  International Telecommunication Union-Telecommunication
      Standardization Sector, "The International Public
      Telecommunication Numbering Plan", Recommendation E.164",
      February 2005.
 [3]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
      Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
      January 2005.
 [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [5]  Newton, A. and M. Sanz, "IRIS: The Internet Registry Information
      Service (IRIS) Core Protocol", RFC 3981, January 2005.
 [6]  Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name
      Server Operational Requirements", BCP 40, RFC 2870, June 2000.

Lind & Pfautz Informational [Page 5] RFC 5067 Infrastructure ENUM Requirements November 2007

Authors' Addresses

 Steven Lind
 AT&T Labs
 180 Park Ave
 Florham Park, NJ  07932-0971
 USA
 EMail: sdlind@att.com
 Penn Pfautz
 AT&T
 200 S. Laurel Ave
 Middletown, NJ  07748
 USA
 EMail: ppfautz@att.com

Lind & Pfautz Informational [Page 6] RFC 5067 Infrastructure ENUM Requirements November 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.

Lind & Pfautz Informational [Page 7]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5067.txt · Last modified: 2007/11/17 02:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki