doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc5527.txt b/doc/rfc/rfc5527.txt
new file mode 100644
index 0000000..7e28415
--- /dev/null
+++ b/doc/rfc/rfc5527.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                        M. Haberler
+Request for Comments: 5527                                           IPA
+Category: Informational                                         O. Lendl
+                                                                 enum.at
+                                                              R. Stastny
+                                                            Unaffiliated
+                                                                May 2009
+
+
+      Combined User and Infrastructure ENUM in the e164.arpa Tree
+
+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.
+
+Abstract
+
+   This memo defines an interim solution for Infrastructure ENUM in
+   order to allow a combined User and Infrastructure ENUM implementation
+   in e164.arpa as a national choice.  This interim solution will be
+   deprecated after implementation of the long-term solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haberler, et al.             Informational                      [Page 1]
+
+RFC 5527         Combined User and Infrastructure ENUM          May 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................3
+   3. Interim Solution ................................................3
+   4. The Algorithm ...................................................4
+   5. Determining the Position of the Branch ..........................5
+   6. Transition to the Long-Term Solution ............................6
+   7. Examples ........................................................7
+   8. Security Considerations .........................................8
+   9. Acknowledgments .................................................9
+   10. References .....................................................9
+      10.1. Normative References ......................................9
+      10.2. Informative References ....................................9
+
+1.  Introduction
+
+   ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms
+   E.164 numbers [E164] into domain names and then queries the DNS
+   (Domain Name Service) [RFC1034] for NAPTR (Naming Authority Pointer)
+   records [RFC3401] in order to look up which services are available
+   for a specific domain name.
+
+   ENUM, as defined in RFC 3761 (User ENUM), is not well suited for the
+   purpose of interconnection by carriers and voice-service providers,
+   as can be seen by the use of various private tree arrangements based
+   on ENUM mechanisms.
+
+   Infrastructure ENUM is defined as the use of the technology in RFC
+   3761 [RFC3761] by the carrier-of-record (voice service provider)
+   [RFC5067] for a specific E.164 number [E164] in order to publish a
+   mapping of this telephone number to one or more Uniform Resource
+   Identifiers (URIs) [RFC3986].
+
+   Other voice service providers can query the DNS for this mapping and
+   use the resulting URIs as input into their call-routing algorithm.
+   These URIs are separate from any URIs that the end-user who registers
+   an E.164 number in ENUM may wish to associate with that E.164 number.
+
+   The requirements, terms, and definitions for Infrastructure ENUM are
+   defined in [RFC5067].
+
+   Using the same E.164 number to domain mapping techniques for other
+   applications under a different, internationally agreed-upon apex
+   (instead of e164.arpa) is straightforward on the technical side.
+   This process of defining the Dynamic Delegation Discovery System
+   (DDDS) [RFC3401] application for Infrastructure ENUM is defined in
+   [RFC5526].  This is the long-term solution.
+
+
+
+Haberler, et al.             Informational                      [Page 2]
+
+RFC 5527         Combined User and Infrastructure ENUM          May 2009
+
+
+   This document presents an interim solution for Infrastructure ENUM
+   and a mechanism for transitioning to the long-term solution.  The
+   interim solution is based on establishing a branch in the e164.arpa
+   tree, which resolvers may locate by following the algorithm described
+   in Section 4.  The location of the branch is dependent upon country-
+   code length, and thus resolvers must determine the position of the
+   branch based on the method described in Section 5.  Finally,
+   Section 6 provides a way that implementations following the
+   procedures of Sections 4 and 5 may be seamlessly redirected to the
+   long-term solution, when it becomes available.
+
+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
+   [RFC2119].
+
+3.  Interim Solution
+
+   The agreements to establish the long-term solution may take some
+   time.  It was therefore decided to develop an interim solution that
+   can be used by individual countries to implement an interoperable
+   Infrastructure ENUM tree immediately.  The interim solution will be
+   deprecated when the long-term solution [RFC5526] is deployed.  It is
+   therefore also required that the interim solution includes a smooth
+   migration path to the long-term solution.
+
+   It is also required that existing ENUM clients querying User ENUM as
+   defined in RFC 3761 [RFC3761] continue to work without any
+   modification.
+
+   Because of various reasons (e.g., potentially different delegation
+   points, different reliability requirements, and use of DNS
+   wildcards), sharing a single domain name between the user itself and
+   the respective carrier for a given number is not possible.  Hence, a
+   different domain name must be used to store infrastructure ENUM
+   information.
+
+   In order to avoid the delays associated with the long-term solution,
+   the existing delegations and agreements around e164.arpa need to be
+   leveraged.
+
+   The method most easily fulfilling the requirements is to branch off
+   the e164.arpa tree into a subdomain at the country-code delegation
+   level below e164.arpa and deploy an Infrastructure ENUM subtree
+   underneath, without touching User ENUM semantics at all.
+
+
+
+
+Haberler, et al.             Informational                      [Page 3]
+
+RFC 5527         Combined User and Infrastructure ENUM          May 2009
+
+
+   This allows countries using a dedicated country code to introduce the
+   interim solution as a national matter to the concerned National
+   Regulation Authority (NRA).  The governing body of a shared country
+   code and the owner of a global network code can also choose to
+   implement this solution within their area of responsibility.
+
+   Under this approach, ITU-T (International Telecommunication Union /
+   Telecommunication Standardization Sector), IETF, and IAB involvement
+   is only lightweight, e.g., to recommend the proper algorithm defined
+   here to enable international interoperability.
+
+4.  The Algorithm
+
+   RFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS)
+   application according to RFC 3401 [RFC3401].  As such, ENUM defines
+   the following components of the DDDS algorithm:
+
+   1.  Application Unique String
+
+   2.  First Well-Known Rule
+
+   3.  Expected Output
+
+   4.  Valid Databases
+
+   The "Valid Databases" part contains the transformation of an E.164
+   telephone number into a domain name.  Section 2.4 of RFC 3761 uses
+   the following 4-step algorithm for this:
+
+   1.  Remove all characters with the exception of the digits.
+
+   2.  Put dots (".") between each digit.
+
+   3.  Reverse the order of the digits.
+
+   4.  Append the string ".e164.arpa" to the end.
+
+   The interim solution for Infrastructure ENUM uses a modified version
+   of this algorithm:
+
+   1.  Determine the proper POSITION parameter for this E.164 number
+       according to the algorithm in Section 5 of this document.
+
+   2.  Build an ordered list of single-digit strings from all digits
+       appearing in the telephone number.  All non-digit characters are
+       ignored.
+
+
+
+
+
+Haberler, et al.             Informational                      [Page 4]
+
+RFC 5527         Combined User and Infrastructure ENUM          May 2009
+
+
+   3.  Insert a string consisting of "i" into this list, after POSITION
+       strings.  If the list of strings was shorter than POSITION
+       elements, then report an error.
+
+   4.  Reverse the order of the list.
+
+   5.  Append the string "e164.arpa" to the end of the list.
+
+   6.  Create a single domain name by joining the list together with
+       dots (".") between each string.
+
+   This is the only point where the interim Infrastructure ENUM (I-ENUM)
+   solution differs from straight RFC 3761 ENUM.  All other parts of
+   User ENUM, including the enumservices registrations, apply to I-ENUM
+   as well.
+
+5.  Determining the Position of the Branch
+
+   In order to allow for the deployment of this interim solution
+   independent of IAB/ITU-T/RIPE-NCC negotiations, the branching label
+   "i" cannot be inserted in the Tier-0 zone (i.e., the e164.arpa zone
+   itself) currently managed by RIPE NCC.  This condition acts as a
+   lower bound on the choice of the POSITION parameter.
+
+   For international E.164-numbers for geographic areas (Section 6.2.1
+   of [E164]) and for international E.164-numbers for global services
+   (Section 6.2.2 of [E164]), the most sensible choice for POSITION is
+   the number of digits in the country code of the number in question.
+   This places the branch directly under the country-code level within
+   the e164.arpa ENUM tree.
+
+   For international E.164-number for networks (Section 6.2.3 of
+   [E164]), the appropriate choice for POSITION is the combined length
+   of the CC (Country Code) and IC (Identification Code) fields.
+
+   For international E.164-number for groups of countries (Section 6.2.4
+   of [E164]), the value for POSITION is 4.
+
+   The authoritative source for up-to-date country code and network
+   Identification Code allocations is published by the ITU-T as a
+   complement to the recommendation E.164 [E164].  The current version
+   of this complement is available from the ITU website under "ITU-T /
+   Service Publications".
+
+   Please note that country code 1 of the North American Numbering Plan
+   (NANP) does not fall under the ITU classification of "groups of
+   countries", but is a "shared country code" for a geographic area.
+   Thus, the POSITION parameter for the NANP is 1.
+
+
+
+Haberler, et al.             Informational                      [Page 5]
+
+RFC 5527         Combined User and Infrastructure ENUM          May 2009
+
+
+   As of 2007, the POSITION value for a specific E.164 number can be
+   determined with the following algorithm:
+
+   o  If the number starts with 1 or 7, then POSITION is 1.
+
+   o  If the number is in one of the following 2-digit country codes,
+      then POSITION is 2: 20, 27, 30-34, 36, 39, 40, 41, 43-49, 51-58,
+      60-66, 81, 82, 84, 86, 90-95, or 98.
+
+   o  If the number starts with 388 or 881, then POSITION is 4.
+
+   o  If the number starts with 878 or 882, then POSITION is 5.
+
+   o  If the number starts with 883 and the next digit is < 5, then
+      POSITION is 6.
+
+   o  If the number starts with 883 and the next digit is >= 5, then
+      POSITION is 7.
+
+   o  In all other cases, POSITION is 3.
+
+   Given the fact that the ITU-T recently allocated only 3-digit country
+   codes, there are no more spare 1- and 2-digit country codes and
+   existing 1- and 2-digit country codes are extremely unlikely to be
+   recovered, the above list of existing 1- and 2-digit country codes
+   can be considered very stable.  The only problem may be for a country
+   that has split, as happened recently, for example, to Yugoslavia.
+
+   Regarding network codes, up to 2007, the ITU-T has only allocated 1-
+   and 2-digit ICs.  Assignments of 3- and 4-digit ICs started in May
+   2007 in the +883 country code.  Any further change in the ITU-T
+   policy in this respect will need to be reflected in the above
+   algorithm.
+
+6.  Transition to the Long-Term Solution
+
+   The proposed long-term solution for Infrastructure ENUM [RFC5526] is
+   the establishment of a new zone apex for that tree.  This apex will
+   play the same role as "e164.arpa" does for User ENUM.
+
+   It is unrealistic to assume that all countries and all ENUM clients
+   will manage to migrate from the interim solution to the long-term
+   solution at a single point in time.  It is thus necessary to plan for
+   an incremental transition.
+
+   In order to achieve this, clients using the interim solution need to
+   be redirected to the long-term I-ENUM tree for all country codes that
+   have already switched to the long-term solution.  This SHOULD be done
+
+
+
+Haberler, et al.             Informational                      [Page 6]
+
+RFC 5527         Combined User and Infrastructure ENUM          May 2009
+
+
+   by placing DNAME [RFC2672] records at the branch (the "i") label
+   pointing to the appropriate domain name in the long-term I-ENUM tree.
+   All descendants at that branch label location where the DNAME record
+   is inserted MUST be removed, as required by Section 3 of RFC 2672.
+
+   Therefore, ALL entities involved in making or answering DNS queries
+   for I-ENUM MUST fully support the DNAME record type and its
+   semantics.  In particular, entities involved in I-ENUM lookups MUST
+   correctly handle responses containing synthesized CNAMEs that may be
+   generated as a consequence of DNAME processing by any other element
+   in resolution, typically an iterative mode resolving name server.
+
+   These entities MUST also apply adequate measures to detect loops and
+   prevent non-terminating resolutions because of improperly configured
+   DNAME records or combinations of DNAME and CNAME records.
+
+   Note: Some caching name server implementations are known to handle
+   DNAMEs incorrectly.  In the worst case, such bugs could stay
+   undetected until a country transitions to the long-term solution.
+   Therefore, ensuring full DNAME support from the start (and carefully
+   testing that it actually works) is important.
+
+   The domain name for the branch location and its DNAME record SHOULD
+   be removed once the transition to the long-term solution is completed
+   and all entities involved in I-ENUM have migrated to the new zone
+   apex for I-ENUM.
+
+7.  Examples
+
+   These are two examples of how E.164 numbers translate to
+   Infrastructure ENUM domains according to the interim solution.
+
+   +1 21255501234          4.3.2.1.0.5.5.5.2.1.2.i.1.e164.arpa
+   +44 2079460123          3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa
+
+   Here is the list of the intermediate steps for the second example to
+   visualize how the algorithm defined in Section 4 operates on "+44
+   2079460123":
+
+   1.  "+44 2079460123" is within a 2-digit country code; thus, POSITION
+       is 2.
+
+   2.  The list of strings is
+       ("4","4","2","0","7","9","4","6","0","1","2","3")
+
+   3.  POSITION is 2; thus, "i" is inserted between the second and the
+       third string, yielding:
+       ("4","4","i","2","0","7","9","4","6","0","1","2","3")
+
+
+
+Haberler, et al.             Informational                      [Page 7]
+
+RFC 5527         Combined User and Infrastructure ENUM          May 2009
+
+
+   4.  Reversing the list gives:
+       ("3","2","1","0","6","4","9","7","0","2","i","4","4")
+
+   5.  Appending "e164.arpa" yields:
+       ("3","2","1","0","6","4","9","7","0","2","i","4","4","e164.arpa")
+
+   6.  Concatenation with dots yields:
+       "3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa"
+
+   After the introduction of the long-term Infrastructure ENUM solution,
+   using, for example, "ienum.example.net" as the new apex for I-ENUM,
+   the administrators of +44 can implement a smooth transition by
+   putting the following DNAME record in their zone:
+
+   i.4.4.e164.arpa.    IN DNAME 4.4.ienum.example.net.
+
+   This way, clients using the interim I-ENUM solution end up querying
+   the same tree as clients implementing the long-term solution.
+
+8.  Security Considerations
+
+   Privacy issues have been raised regarding the unwarranted disclosure
+   of user information that would result from publishing Infrastructure
+   ENUM information in the public DNS.  For instance, such disclosure
+   could be used for harvesting numbers in service or obtaining unlisted
+   numbers.
+
+   Given that number-range allocation is public information, we believe
+   the easiest way to cope with such concerns is to fully unroll
+   allocated number ranges in the Infrastructure ENUM subtree, wherever
+   such privacy concerns exist.  Whether or not a number is served would
+   be exposed by the carrier-of-record when an attempt is made to
+   contact the corresponding URI.  We assume this to be an authenticated
+   operation, which would not leak information to unauthorized parties.
+
+   Entering all numbers in an allocated number range, whether serviced
+   or not, or whether listed or unlisted, will prevent mining attempts
+   for such number attributes.
+
+   The result will be that the information in the public DNS will mirror
+   number-range allocation information, but no more.  Infrastructure
+   ENUM will not tell you more than you can get by just dialing numbers.
+
+   The URI pointing to the destination network of the carrier-of-record
+   should also not disclose any privacy information about the identity
+   of the end-user.  It is therefore recommended to use either
+   anonymized UserIDs or the E.164 number itself in the user part of the
+   URI, such as in sip:+441632960084@example.com.
+
+
+
+Haberler, et al.             Informational                      [Page 8]
+
+RFC 5527         Combined User and Infrastructure ENUM          May 2009
+
+
+9.  Acknowledgments
+
+   We gratefully acknowledge suggestions and improvements by Jason
+   Livingood and Tom Creighton of Comcast, Penn Pfautz of AT&T, Lawrence
+   Conroy of Roke Manor Research, Jim Reid, and Alexander Mayrhofer of
+   enum.at.
+
+10.  References
+
+10.1.  Normative References
+
+   [E164]     ITU-T, "The International Public Telecommunication Number
+              Plan", Recommendation E.164, February 2005.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
+              RFC 2672, August 1999.
+
+   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
+              Part One: The Comprehensive DDDS", RFC 3401, October 2002.
+
+   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
+              Resource Identifiers (URI) Dynamic Delegation Discovery
+              System (DDDS) Application (ENUM)", RFC 3761, April 2004.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, January 2005.
+
+10.2.  Informative References
+
+   [RFC5067]  Lind, S. and P. Pfautz, "Infrastructure ENUM
+              Requirements", RFC 5067, November 2007.
+
+   [RFC5526]  Livingood, J., Pfautz, P., and R. Stastny, "The E.164 to
+              Uniform Resource Identifiers (URI) Dynamic Delegation
+              Discovery System (DDDS) Application for Infrastructure
+              ENUM", RFC 5526, April 2007.
+
+
+
+
+
+
+
+
+Haberler, et al.             Informational                      [Page 9]
+
+RFC 5527         Combined User and Infrastructure ENUM          May 2009
+
+
+Authors' Addresses
+
+   Michael Haberler
+   Internet Foundation Austria
+   Karlsplatz 1/2/9
+   Wien  1010
+   Austria
+
+   Phone: +43 664 4213465
+   EMail: ietf@mah.priv.at
+   URI:   http://www.nic.at/ipa/
+
+   Otmar Lendl
+   enum.at GmbH
+   Karlsplatz 1/2/9
+   Wien  A-1010
+   Austria
+
+   Phone: +43 1 5056416 33
+   EMail: otmar.lendl@enum.at
+   URI:   http://www.enum.at/
+
+
+   Richard Stastny
+   Unaffiliated
+   Anzbachgasse 43
+   1140 Vienna
+   Austria
+
+   Phone: +43 664 420 4100
+   EMail: richardstastny@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haberler, et al.             Informational                     [Page 10]
+