doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc2916.txt b/doc/rfc/rfc2916.txt
new file mode 100644
index 0000000..53bb897
--- /dev/null
+++ b/doc/rfc/rfc2916.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                        P. Faltstrom
+Request for Comments: 2916                             Cisco Systems Inc.
+Category: Standards Track                                  September 2000
+
+
+                          E.164 number and DNS
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document discusses the use of the Domain Name System (DNS) for
+   storage of E.164 numbers.  More specifically, how DNS can be used for
+   identifying available services connected to one E.164 number.
+   Routing of the actual connection using the service selected using
+   these methods is not discussed.
+
+1. Introduction
+
+   Through transformation of E.164 numbers into DNS names and the use of
+   existing DNS services like delegation through NS records, and use of
+   NAPTR [1] records in DNS [2] [3], one can look up what services are
+   available for a specific domain name in a decentralized way with
+   distributed management of the different levels in the lookup process.
+
+1.1 Terminology
+
+   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
+   in this document are to be interpreted as described in RFC2119 [4].
+
+2. E.164 numbers and DNS
+
+   The domain "e164.arpa" is being populated in order to provide the
+   infrastructure in DNS for storage of E.164 numbers.  In order to
+   facilitate distributed operations, this domain is divided into
+   subdomains.  Holders of E.164 numbers which want to be listed in DNS
+
+
+
+
+
+Faltstrom                   Standards Track                     [Page 1]
+
+RFC 2916                  E.164 number and DNS            September 2000
+
+
+   should contact the appropriate zone administrator in order to be
+   listed, by examining the SOA resource record associated with the
+   zone, just like in normal DNS operations.
+
+   Of course, as with other domains, policies for such listings will be
+   controlled on a subdomain basis and may differ in different parts of
+   the world.
+
+   To find the DNS names for a specific E.164 number, the following
+   procedure is to be followed:
+
+  1.  See that the E.164 number is written in its full form, including
+      the countrycode IDDD.  Example: +46-8-9761234
+
+  2.  Remove all non-digit characters with the exception of the leading
+      '+'.  Example: +4689761234
+
+  3.  Remove all characters with the exception of the digits.  Example:
+      4689761234
+
+  4.  Put dots (".") between each digit.  Example: 4.6.8.9.7.6.1.2.3.4
+
+  5.  Reverse the order of the digits.  Example: 4.3.2.1.6.7.9.8.6.4
+
+  6.  Append the string ".e164.arpa" to the end.  Example:
+      4.3.2.1.6.7.9.8.6.4.e164.arpa
+
+2.1 Special note about the '+'
+
+   The '+' is kept in stage 2 in section 2 to flag that the number which
+   the regular expression is operating on is a E.164 number.  Future
+   work will be needed to determine how other numbering plans (such as
+   closed ones) might be identified.  It is possible, but not definite,
+   that they would use a similar mechanism as the one described in this
+   document.
+
+3. Fetching URIs given an E.164 number
+
+   For a record in DNS, the NAPTR record is used for identifying
+   available ways of contacting a specific node identified by that name.
+   Specifically, it can be used for knowing what services exists for a
+   specific domain name, including phone numbers by the use of the
+   e164.arpa domain as described above.
+
+   The identification is using the NAPTR resource record defined for use
+   in the URN resolution process, but it can be generalized in a way
+   that suits the needs specified in this document.
+
+
+
+
+Faltstrom                   Standards Track                     [Page 2]
+
+RFC 2916                  E.164 number and DNS            September 2000
+
+
+   It is the string which is the result of step 2 in section 2 above
+   which is input to the NAPTR algorithm.
+
+3.1 The NAPTR record
+
+   The key fields in the NAPTR RR are order, preference, service, flags,
+   regexp, and replacement.  For a detailed description, see:
+
+   o  The order field specifies the order in which records MUST be
+      processed when multiple NAPTR records are returned in response to
+      a single query.
+
+   o  The preference field specifies the order in which records SHOULD
+      be processed when multiple NAPTR records have the same value of
+      "order".
+
+   o  The service field specifies the resolution protocol and resolution
+      service(s) that will be available if the rewrite specified by the
+      regexp or replacement fields is applied.
+
+   o  The flags field contains modifiers that affect what happens in the
+      next DNS lookup, typically for optimizing the process.
+
+   o  The regexp field is one of two fields used for the rewrite rules,
+      and is the core concept of the NAPTR record.
+
+   o  The replacement field is the other field that may be used for the
+      rewrite rule.
+
+   Note that the client applies all the substitutions and performs all
+   lookups, they are not performed in the DNS servers.  Note that URIs
+   are stored in the regexp field.
+
+3.1.1 Specification for use of NAPTR Resource Records
+
+   The input is an E.164 encoded telephone number.  The output is a
+   Uniform Resource Identifier in its absolute form according to the
+   'absoluteURI' production in the Collected ABNF found in RFC2396 [5]
+
+   An E.164 number, without any characters but leading '+' and digits,
+   (result of step 2 in section 2 above) is the input to the NAPTR
+   algorithm.
+
+   The service supported for a call is E2U.
+
+
+
+
+
+
+
+Faltstrom                   Standards Track                     [Page 3]
+
+RFC 2916                  E.164 number and DNS            September 2000
+
+
+3.1.2 Specification of Service E2U (E.164 to URI)
+
+   * Name: E.164 to URI
+   * Mnemonic: E2U
+   * Number of Operands: 1
+   * Type of Each Operand: First operand is an E.164 number.
+   * Format of Each Operand: First operand is the E.164 number in the
+     form as specified in step 2 in section 2 in this document.
+   * Algorithm: Opaque
+   * Output: One or more URIs
+   * Error Conditions:
+      o E.164 number not in the numbering plan
+      o E.164 number in the numbering plan, but no URIs exist for
+        that number
+      o Service unavailable
+
+   * Security Considerations:
+      o Malicious Redirection
+        One of the fundamental dangers related to any service such
+        as this is that a malicious entry in a resolver's database
+        will cause clients to resolve the E.164 into the wrong URI.
+        The possible intent may be to cause the client to retrieve
+        a resource containing fraudulent or damaging material.
+      o Denial of Service
+        By removing the URI to which the E.164 maps, a malicious
+        intruder may remove the client's ability to access the
+        resource.
+
+   This operation is used to map a one E.164 number to a list of URIs.
+   The first well-known step in the resolution process is to remove all
+   non-digits apart from the leading '+' from the E.164 number as
+   described in step 1 and 2 in section 2 of this document.
+
+3.2 Examples
+
+3.2.1 Example 1
+
+$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
+   IN NAPTR 100 10 "u" "sip+E2U"    "!^.*$!sip:info@tele2.se!"     .
+   IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!"  .
+
+   This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is
+   preferably contacted by SIP, and secondly by SMTP.
+
+   In both cases, the next step in the resolution process is to use the
+   resolution mechanism for each of the protocols, (SIP and SMTP) to
+   know what node to contact for each.
+
+
+
+
+Faltstrom                   Standards Track                     [Page 4]
+
+RFC 2916                  E.164 number and DNS            September 2000
+
+
+3.2.2 Example 2
+
+$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
+  IN NAPTR  10 10 "u" "sip+E2U"     "!^.*$!sip:paf@swip.net!"    .
+  IN NAPTR 102 10 "u" "mailto+E2U"  "!^.*$!mailto:paf@swip.net!" .
+  IN NAPTR 102 10 "u" "tel+E2U"     "!^.*$!tel:+4689761234!"     .
+
+   Note that the preferred method is to use the SIP protocol, but the
+   result of the rewrite of the NAPTR record is a URI (the "u" flag in
+   the NAPTR record).  In the case of the protocol SIP, the URI might be
+   a SIP URI, which is resolved as described in RFC 2543 [6].  In the
+   case of the "tel" URI scheme [7], the procedure is restarted with
+   this new E.164 number.  The client is responsible for loop detection.
+
+   The rest of the resolution of the routing is done as described above.
+
+3.2.3 Example 3
+
+   $ORIGIN 6.4.e164.arpa.
+   * IN NAPTR 100 10 "u" "ldap+E2U" "!^+46(.*)$!ldap://ldap.se/cn=01!" .
+
+   We see in this example that information about all E.164 numbers in
+   the 46 countrycode (for Sweden) exists in an LDAP server, and the
+   search to do is specified by the LDAP URI [8].
+
+4. IANA Considerations
+
+   This memo requests that the IANA delegate the E164.ARPA domain
+   following instructions to be provided by the IAB.  Names within this
+   zone are to be delegated to parties according to the ITU
+   recommendation E.164.  The names allocated should be hierarchic in
+   accordance with ITU Recommendation E.164, and the codes should
+   assigned in accordance with that Recommendation.
+
+   Delegations in the zone e164.arpa (not delegations in delegated
+   domains of e164.arpa) should be done after Expert Review, and the
+   IESG will appoint a designated expert.
+
+5. Security Considerations
+
+   As this system is built on top of DNS, one can not be sure that the
+   information one get back from DNS is more secure than any DNS query.
+   To solve that, the use of DNSSEC [9] for securing and verifying zones
+   is to be recommended.
+
+
+
+
+
+
+
+Faltstrom                   Standards Track                     [Page 5]
+
+RFC 2916                  E.164 number and DNS            September 2000
+
+
+   The caching in DNS can make the propagation time for a change take
+   the same amount of time as the time to live for the NAPTR records in
+   the zone that is changed. The use of this in an environment where
+   IP-addresses are for hire (for example, when using DHCP [11]) must
+   therefore be done very carefully.
+
+   There are a number of countries (and other numbering environments) in
+   which there are multiple providers of call routing and number/name-
+   translation services.  In these areas, any system that permits users,
+   or putative agents for users, to change routing or supplier
+   information may provide incentives for changes that are actually
+   unauthorized (and, in some cases, for denial of legitimate change
+   requests).  Such environments should be designed with adequate
+   mechanisms for identification and authentication of those requesting
+   changes and for authorization of those changes.
+
+6. Acknowledgements
+
+   Support and ideas have come from people at Ericsson, Bjorn Larsson
+   and the group which implemented this scheme in their lab to see that
+   it worked.  Input has also come from ITU-T SG2, Working Party 1/2
+   (Numbering, Routing, Global Mobility and Service Definition), the
+   ENUM working group in the IETF, John Klensin and Leif Sunnegardh.
+
+References
+
+   [1]  Mealling, M. and R. Daniel, "The Naming Authority Pointer
+        (NAPTR) DNS Resource Record", RFC 2915, September 2000.
+
+   [2]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [3]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
+        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
+        1998.
+
+   [6]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
+        "SIP: Session Initiation Protocol", RFC 2543, March 1999.
+
+   [7]  Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
+        2000.
+
+
+
+
+Faltstrom                   Standards Track                     [Page 6]
+
+RFC 2916                  E.164 number and DNS            September 2000
+
+
+   [8]  Howes, T. and M. Smith, "An LDAP URL Format", RFC 1959, June
+        1996.
+
+   [9]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [10] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+        specifying the location of services (DNS SRV)", RFC 2782,
+        February 2000.
+
+   [11] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+        March 1997.
+
+Author's Address
+
+   Patrik Faltstrom
+   Cisco Systems Inc
+   170 W Tasman Drive SJ-13/2
+   San Jose CA 95134
+   USA
+
+   EMail: paf@cisco.com
+   URI:   http://www.cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom                   Standards Track                     [Page 7]
+
+RFC 2916                  E.164 number and DNS            September 2000
+
+
+Appendix A. Scenario
+
+   Say that the content of the e164.arpa zone is the following:
+
+   $ORIGIN e164.arpa.
+   6.4 IN NS ns.regulator-e164.example.se.
+
+   The regulator has in turn given a series of 10000 numbers to the
+   telco with the name Telco-A. The regulator because of that has in
+   his DNS.
+
+   $ORIGIN 6.4.e164.arpa.
+   6.7.9.8 IN NS ns.telco-a.example.se.
+
+   A user named Sven Svensson has from Telco A got the phone number
+   +46-8-9761234. The user gets the service of running DNS from the
+   company Redirection Service.  Sven Svensson has asked Telco A to
+   point out Redirection Service as the authoritative source for
+   information about the number +46-8-9761234.  Telco A because of this
+   puts in his DNS the following.
+
+   $ORIGIN 6.7.9.8.6.4.e164.arpa.
+   4.3.2.1 IN NS ns.redirection-service.example.se.
+
+   Sven Svensson has already plain telephony from Telco A, but also a
+   SIP service from the company Sip Service which provides Sven with
+   the SIP URI "sip:sven@sips.se".  The ISP with the name
+   ISP A runs email and webpages for Sven, under the email address
+   sven@ispa.se, and URI http://svensson.ispa.se.
+
+   The DNS for the redirection service because of this contains the
+   following.
+
+   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
+    IN NAPTR 10 10 "u" "sip+E2U"    "!^.*$!sip:sven@sips.se!"        .
+    IN NAPTR 10 10 "u" "mailto+E2U" "!^.*$!mailto:sven@ispa.se!"     .
+    IN NAPTR 10 10 "u" "http+E2U"   "!^.*$!http://svensson.ispa.se!" .
+    IN NAPTR 10 10 "u" "tel+E2U"    "!^.*$!tel:+46-8-9761234!"       .
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom                   Standards Track                     [Page 8]
+
+RFC 2916                  E.164 number and DNS            September 2000
+
+
+   A user, John Smith, want to contact Sven Svensson, he to start with
+   only has the E.164 number of Sven, i.e. +46-8-9761234.  He takes the
+   number, and enters the number in his communication client, which
+   happen to know how to handle the SIP protocol.  The client removes
+   the dashes, and ends up with the E.164 number +4689761234.  That is
+   what is used in the algorithm for NAPTR records, which is as
+   follows.
+
+   The client converts the E.164 number into the domain name
+   4.3.2.1.6.7.9.8.6.4.e164.arpa., and queries for NAPTR records for
+   this domainname.  Using DNS mechanisms which includes following the
+   NS record referrals, the following records are returned:
+
+   $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
+    IN NAPTR 10 10 "u" "sip+E2U"    "!^.*$!sip:sven@sips.se"        .
+    IN NAPTR 10 10 "u" "mailto+E2U" "!^.*$!mailto:sven@ispa.se"     .
+    IN NAPTR 10 10 "u" "http+E2U"   "!^.*$!http://svensson.ispa.se" .
+    IN NAPTR 10 10 "u" "tel+E2U"    "!^.*$!tel:+46-8-9761234"       .
+
+   Because the client knows sip, the first record above is selected,
+   and the regular expression "!^.*$!sip:sven@sips.se" is applied to
+   the original string, "+4689761234". The output is "sip:sven@sips.se"
+   which is used according to SIP resolution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom                   Standards Track                     [Page 9]
+
+RFC 2916                  E.164 number and DNS            September 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom                   Standards Track                    [Page 10]
+