From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5526.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc5526.txt (limited to 'doc/rfc/rfc5526.txt') diff --git a/doc/rfc/rfc5526.txt b/doc/rfc/rfc5526.txt new file mode 100644 index 0000000..5702e48 --- /dev/null +++ b/doc/rfc/rfc5526.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group J. Livingood +Request for Comments: 5526 Comcast Cable Communications +Category: Informational P. Pfautz + AT&T + R. Stastny + Unaffiliated + April 2009 + + + The E.164 to Uniform Resource Identifiers (URI) + Dynamic Delegation Discovery System (DDDS) Application + for Infrastructure ENUM + +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. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + +Livingood, et al. Informational [Page 1] + +RFC 5526 Infrastructure ENUM April 2009 + + +Abstract + + This document defines the use case for Infrastructure ENUM and + proposes its implementation as a parallel namespace to "e164.arpa", + as defined in RFC 3761, as the long-term solution to the problem of + allowing carriers to provision DNS records for telephone numbers + independently of those provisioned by end users (number assignees). + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. Zone Apex for Infrastructure ENUM ...............................3 + 4. IANA Considerations .............................................3 + 5. Security and Privacy Considerations .............................4 + 6. Acknowledgements ................................................4 + 7. Normative References ............................................4 + +1. Introduction + + ENUM (E.164 Number Mapping [1]) is a system that transforms E.164 + numbers [2] into domain names and then uses the DNS (Domain Name + Service) [3] to discover NAPTR records that specify what services are + available for a specific domain name. + + ENUM as originally defined was based on the end-user opt-in + principle. While this has great potential to foster new services and + end-user choices in the long term, the current requirements for + IP-based interconnection of Voice over IP (VoIP) domains require the + provisioning of large numbers of allocated or served (hosted) numbers + of a participating service provider, without the need for individual + users to opt-in. This way, service providers can provision their own + ENUM information that is separate, distinct, and likely to be + different from what an end-user may provision. This is particularly + important if Infrastructure ENUM is used for number-portability + applications, for example, which an end-user would be unlikely + interested in provisioning but which a service provider would likely + find essential. + + In addition, while it is possible that service providers could + mandate that their users opt-into e164.arpa through end-user contract + terms and conditions, there are substantial downsides to such an + approach. Thus, for all these reasons and many others, ENUM for + end-user provisioning is ill-suited for use by service providers for + the interconnection of VoIP domains. + + + + + + +Livingood, et al. Informational [Page 2] + +RFC 5526 Infrastructure ENUM April 2009 + + + As VoIP evolves and becomes pervasive, E.164-addressed telephone + calls need not necessarily traverse the Public Switched Telephone + Network (PSTN). Therefore, VoIP service providers have an interest + in using ENUM on a so-called "Infrastructure" basis in order to keep + VoIP traffic on IP networks on an end-to-end basis, both within and + between service provider domains. This requires a means of + identifying a VoIP point of interconnection to which calls addressed + to a given E.164 number may be delivered; Infrastructure ENUM + provides this means. Calls that can originate and terminate on IP + networks, and do not have to traverse the PSTN, will require fewer or + no points of transcoding, and can also involve additional IP network + services that are not possible on the PSTN, among other benefits. + + Requirements for Infrastructure ENUM are provided in [4]. + +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, RFC 2119 [5]. + +3. Zone Apex for Infrastructure ENUM + + This document proposes that Infrastructure ENUM be implemented by + means of a parallel namespace to e164.arpa dedicated to + Infrastructure ENUM, in a domain that is yet to be determined. Use + of a parallel namespace allows carriers and end-users to control + their ENUM registrations independently, without forcing one to work + through the other. + + Infrastructure ENUM Tier 2 resource records in the Infrastructure + ENUM tree will be controlled by the service provider that is + providing services to a given E.164 number, generally referred to in + various countries as the "carrier-of-record" (see [4]). The + definition of a carrier-of-record for a given E.164 number is a + national matter or is defined by the entity controlling the numbering + space. + + See also Section 3, "Requirements for Infrastructure ENUM", of [4]. + +4. IANA Considerations + + IANA has created a registry for Enumservices as originally specified + in RFC 2916 and revised in RFC 3761. Enumservices registered with + IANA are valid for Infrastructure ENUM as well as end-user ENUM. + + + + + + +Livingood, et al. Informational [Page 3] + +RFC 5526 Infrastructure ENUM April 2009 + + +5. Security and Privacy Considerations + + This document proposes a new zone apex for ENUM to meet the + requirements of Infrastructure ENUM. The over-the-network protocol + of ENUM is unchanged by the addition of an apex and, as such, the + Security Considerations of RFC 3761 [1] still apply. Specific + considerations related to the security of an Infrastructure ENUM apex + are given in more detail in Section 4, "Security Considerations", of + [4]. + + Infrastructure ENUM registrations proposed by this document should + resolve to service provider points-of-interconnection rather than to + end-user equipment. Service providers need to take appropriate + measures to protect their end-user customers from unwanted + communications as with other types of interconnections. + +6. Acknowledgements + + The authors wish to thank Lawrence Conroy, Patrik Faltstrom, Michael + Haberler, Otmar Lendl, Steve Lind, Alexander Mayrhofer, Jim Reid, and + Richard Shockey for their helpful discussions of this document and + the concept of Infrastructure ENUM. + +7. 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] ITU-T, "The International Public Telecommunication Number Plan", + Recommendation E.164, February 2005. + + [3] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [4] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC + 5067, November 2007. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + + +Livingood, et al. Informational [Page 4] + +RFC 5526 Infrastructure ENUM April 2009 + + +Authors' Addresses + + Jason Livingood + Comcast Cable Communications + 1500 Market Street + Philadelphia, PA 19102 + USA + + Phone: +1-215-981-7813 + EMail: jason_livingood@cable.comcast.com + + + Penn Pfautz + AT&T + 200 S. Laurel Ave + Middletown, NJ 07748 + USA + + Phone: +1-732-420-4962 + EMail: ppfautz@att.com + + + Richard Stastny + Anzbachgasse 43 + 1140 Vienna + Austria + + Phone: +43-664-420-4100 + EMail: richard.stastny@gmail.com + + + + + + + + + + + + + + + + + + + + + + +Livingood, et al. Informational [Page 5] + -- cgit v1.2.3