summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2916.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2916.txt')
-rw-r--r--doc/rfc/rfc2916.txt563
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]
+