Movatterモバイル変換

Network Working Group                                            S. LindRequest for Comments: 5067                                     AT&T LabsCategory: Informational                                        P. Pfautz                                                                    AT&T                                                           November 2007Infrastructure ENUM RequirementsStatus 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 ofRFC 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 Contents1.  Infrastructure ENUM . . . . . . . . . . . . . . . . . . . . . .11.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . . .11.2.  Background  . . . . . . . . . . . . . . . . . . . . . . . .22.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .33.  Requirements for Infrastructure ENUM  . . . . . . . . . . . . .34.  Security Considerations . . . . . . . . . . . . . . . . . . . .45.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .56.  Normative References  . . . . . . . . . . . . . . . . . . . . .51.  Infrastructure ENUM1.1.  Definition   Infrastructure ENUM is defined as the use of the technology inRFC3761 [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   inRFC3761 [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 20072.  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 inBCP 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 preventLind & 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 ofRFC 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 whereRFC 3761   mainly considered indviduals, implementations meeting these   requirements SHOULD reconsider theRFC 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 numbersLind & 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 2007Authors' 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.comLind & Pfautz                Informational                      [Page 6]

RFC 5067            Infrastructure ENUM Requirements       November 2007Full Copyright Statement   Copyright (C) The IETF Trust (2007).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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]