doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc3172.txt b/doc/rfc/rfc3172.txt
new file mode 100644
index 0000000..0f86295
--- /dev/null
+++ b/doc/rfc/rfc3172.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                  G. Huston, Editor
+Request for Comments: 3172                                           IAB
+BCP: 52                                                   September 2001
+Category: Best Current Practice
+
+
+          Management Guidelines & Operational Requirements for
+         the Address and Routing Parameter Area Domain ("arpa")
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This memo describes the management and operational requirements for
+   the address and routing parameter area ("arpa") domain.  The "arpa"
+   domain is used to support a class of infrastructural identifier
+   spaces, providing a distributed database that translates elements of
+   a structured name space derived from a protocol family to service
+   names.  The efficient and reliable operation of this DNS space is
+   essential to the integrity of operation of various services within
+   the Internet.  The Internet Architecture Board (IAB) has the
+   responsibility, in cooperation with the Internet Corporation for
+   Assigned Names and Numbers (ICANN), to manage the "arpa" domain.
+   This document describes the principles used by the IAB in undertaking
+   this role.
+
+1. Introduction
+
+   The Domain Name System (DNS) [1] [2] is predominately used to
+   translate a structured textual identifier into a protocol-specific
+   value.  It uses the structure embedded within a hierarchical
+   identifier space to create a distributed database, where every node
+   within the database corresponds to a node within the name structure.
+   The most prevalent role of the DNS is to store a set of name to
+   address translations, allowing a domain name to be translated to an
+   IP address.  The DNS is also used to store a number of other
+   translations from hierarchically structured identifier spaces into
+   target values of various types.
+
+
+
+
+
+Huston                   Best Current Practice                  [Page 1]
+
+RFC 3172                    arpa Guidelines               September 2001
+
+
+   The DNS is also capable of supporting a translation in the opposite
+   direction, from protocol values to the names of service entities.
+   One approach in using the DNS in this fashion has been to transform
+   protocol values into a hierarchically structured identifier space,
+   and then use these transformed protocol value names as a DNS lookup
+   key into the appropriate DNS name hierarchy.  A common use of this
+   mechanism has been the reverse of the name to address lookup,
+   allowing for an IPv4 address to be used to look up a matching domain
+   name.  For example, the IP address 128.9.160.55 can be associated
+   with the domain name "www.iab.org." by creating the DNS entry
+   55.160.9.128.in-addr.arpa." and mapping this entry, via a DNS PTR
+   record, to the value "www.iab.org.".
+
+   The resolution of protocol objects into service names is used by a
+   number of applications to associate services with a particular
+   protocol object.  The correct and efficient operation of these
+   applications is dependent on the correct and efficient operation of
+   the associated "arpa" domain name servers.
+
+2. The "arpa" domain
+
+   The "arpa" domain was originally established as part of the initial
+   deployment of the DNS, to provide a transition mechanism from the
+   Host Tables that were common in the ARPANET, as well as a home for
+   the IPv4 reverse mapping domain.  During 2000, the abbreviation was
+   redesignated to "Address and Routing Parameter Area" in the hope of
+   reducing confusion with the earlier network name.
+
+   The Internet Architecture Board (IAB), in cooperation with the
+   Internet Corporation for Assigned Names and Numbers (ICANN), is
+   currently responsible for managing the Top Level Domain (TLD) name
+   "arpa".  This arrangement is documented in Appendix A.  This domain
+   name provides the root of the name hierarchy of the reverse mapping
+   of IP addresses to domain names.  More generally, this domain name
+   undertakes a role as  a limited use domain for Internet
+   infrastructure applications, by providing a name root for the mapping
+   of particular protocol values to names of service entities.  This
+   domain name provides a name root for the mapping of protocol values
+   into lookup keys to retrieve operationally critical protocol
+   infrastructure data records or objects for the Internet.
+
+   The IAB may add other infrastructure uses to the "arpa" domain in the
+   future.  Any such additions or changes will be in accordance with the
+   procedures documented in Section 2.1 and Section 3 of this document.
+
+
+
+
+
+
+
+Huston                   Best Current Practice                  [Page 2]
+
+RFC 3172                    arpa Guidelines               September 2001
+
+
+   This domain is termed an "infrastructure domain", as its role is to
+   support the operating infrastructure of the Internet.  In particular,
+   the "arpa" domain is not to be used in the same manner (e.g., for
+   naming hosts) as other generic Top Level Domains are commonly used.
+
+   The operational administration of this domain, in accordance with the
+   provisions described in this document, shall be performed by the IANA
+   under the terms of the MoU between the IAB and ICANN concerning the
+   IANA [3].
+
+2.1 Criteria for "arpa" Sub-domains
+
+   The "arpa" sub-domains are used for those protocol object sets
+   defined as part of the Internet Standards Process [4], and are
+   recommended to be managed as infrastructure protocol objects.
+   Normally, the recommendation is to be made in the "IANA
+   Considerations" section of the Internet Standard protocol
+   specification.  The recommendation should include the manner in which
+   protocol objects are to be mapped into lookup keys, and
+   recommendations to IANA concerning the operation of the "arpa" sub-
+   domain in conjunction with the recommendations concerning the
+   operation of the protocol object registry itself.
+
+   The IESG consideration of a document which proposes the use of an
+   "arpa" sub-domain shall include consideration of the "IANA
+   Considerations" section.  If the document is approved, the IESG will
+   ask the IAB to request the IANA to add the corresponding protocol
+   object sub-domain domain to the "arpa" domain, in accordance with RFC
+   2860 [3], with administration of the sub-domain undertaken in
+   accordance with the provisions described in this document.
+
+2.2 "arpa" Name Server Requirements
+
+   As this domain is part of the operationally critical infrastructure
+   of the Internet, the stability, integrity and efficiency of the
+   operation of this domain is a matter of importance for all Internet
+   users.
+
+   The "arpa" domain is positioned as a top level domain in order to
+   avoid potential operational instabilities caused by multiple DNS
+   lookups spanning several operational domains that would be required
+   to locate the servers of each of the parent names of a more deeply
+   nested infrastructure name.  The maximal lookup set for "arpa" is a
+   lookup of the name servers for the "arpa" domain from a root server,
+   and the query agent is then provided with a list of authoritative
+   "arpa" name servers.
+
+
+
+
+
+Huston                   Best Current Practice                  [Page 3]
+
+RFC 3172                    arpa Guidelines               September 2001
+
+
+   The efficient and correct operation of the "arpa" domain is
+   considered to be sufficiently critical that the operational
+   requirements for the root servers apply to the operational
+   requirements of the "arpa" servers.  All operational requirements
+   noted in RFC 2870 [5] as they apply to the operational requirements
+   of the root servers shall apply to the operation of the "arpa"
+   servers.  Any revision to RFC 2870 in relation to the operation of
+   the root servers shall also apply to the operation of the "arpa"
+   servers.
+
+   Many of the servers that are authoritative for the root zone (or the
+   "." zone)  also currently serve as authoritative for the "arpa" zone.
+   As noted in RFC 2870 [5], this arrangement is likely to change in the
+   future.
+
+3. Delegation of "arpa" Sub-Domains
+
+   While the decision as to which protocol elements are loaded into the
+   "arpa" domain, and the hierarchical structure of such protocol
+   elements, remains within the role of the IAB, the role of managing
+   the sub-domain may be delegated by the IAB to an appropriate protocol
+   management entity.
+
+   The IAB shall only recommend the creation of "arpa" sub-domains
+   corresponding to protocol entities where:
+
+   -  the delegation, and the hierarchical name structure, is described
+      by an IETF Standards Track document [4], and
+
+   -  the use of the "arpa" domain is explicitly recommended in the
+      "IANA Considerations" section of that document.
+
+   The "IANA Considerations" section should include the name of the
+   subdomain, the rules for how the subdomain is to be administered, and
+   the criteria for entries within the subdomain.
+
+4. Current Status of "arpa"
+
+   The "arpa" domain is used for the sub-domains "in-addr.arpa" [1],
+   "ip6.arpa" [7] and "e164.arpa" [8].
+
+   Currently, the "arpa" zone is located on a subset of the root
+   servers, and the zone is managed in accordance with these
+   specifications.  The IAB is working with ICANN, IANA, and the
+   regional registries to move "arpa" and "in-addr.arpa" records from
+   the root servers in accord with the RFC 2870 recommendation for
+   exclusive use of those servers [5].
+
+
+
+
+Huston                   Best Current Practice                  [Page 4]
+
+RFC 3172                    arpa Guidelines               September 2001
+
+
+   The IPv4 reverse address domain, "in-addr.arpa" is delegated to the
+   IANA.  The "in-addr.arpa" zone is currently located on the same same
+   subset of the root servers  as "arpa".  Sub-delegations within this
+   hierarchy are undertaken in accordance with the IANA's address
+   allocation practices.
+
+   The "ip6.arpa" IPv6 reverse address domain uses a method of
+   delegation that is the same as is used for "in-addr.arpa", where the
+   "ip6.arpa" domain is delegated to the IANA, and names within this
+   zone further delegated to the regional IP registries in accordance
+   with the delegation of IPv6 address space to those registries [6]
+   [7].
+
+   The "e164.arpa" domain is used to map E.164 style phone numbers into
+   URIs.  This mechanism is defined in RFC 2916 [9].  RFC 2916 notes
+   that the provision that names within this DNS zone are to be
+   delegated to parties according to ITU recommendation E.164 [10].  RFC
+   3026 [8] describes the overall liaison arrangements between the IETF
+   and ITU-T about the use of this domain.
+
+5. Infrastructure domains elsewhere in the DNS tree
+
+   Any infrastructure domains that are located elsewhere in the DNS tree
+   than as sub-domains of "arpa", for historical or other reasons,
+   should adhere to all of the requirements established in this document
+   for sub-domains of "arpa", and consideration should be given to
+   migrating them into "arpa" as and when appropriate.
+
+6. Security Considerations
+
+   The security considerations as documented in RFC 2870 [5], and any
+   successors to that document, apply to the operation of the "arpa"
+   servers.
+
+   The security considerations specific to the E.164 subdomain are
+   documented in Section 5 of RFC 2916 [9].
+
+   Any new subdomain delegation must adequately document any security
+   considerations specific to the information stored therein.
+
+7. IANA Considerations
+
+   As noted in section 3 of this document, the IAB may request the IANA
+   to delegate the sub-domains of "arpa" in accordance with the "IANA
+   Considerations" section of an IETF Standards Track document.  This
+   request falls under the scope of section 4 of the MoU between the
+   IETF and ICANN concerning the IANA [3].
+
+
+
+
+Huston                   Best Current Practice                  [Page 5]
+
+RFC 3172                    arpa Guidelines               September 2001
+
+
+Acknowledgements
+
+   This document is a document of the IAB, and the editor acknowledges
+   the contributions of the members of the IAB in the preparation of the
+   document.  In addition, suggestions have been incorporated from Scott
+   Bradner.
+
+References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of
+        Understanding Concerning the Technical Work of the Internet
+        Assigned Numbers Authority", RFC 2860, June 2000.
+
+   [4]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC2026, October 1996.
+
+   [5]  Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root Name
+        Server Operational Requirements", BCP 40, RFC 2870, June 2000.
+
+   [6]  Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6
+        Address Aggregation and Renumbering", RFC 2874, July 2000.
+
+   [7]  Bush, R., "Delegation of IP6.arpa", BCP 49, RFC 3152, August
+        2001.
+
+   [8]  Blane, P., "Liaison to IETF/ISOC on ENUM", RFC 3026, January
+        2001.
+
+   [9] Falstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
+
+   [10] ITU-T Recommendation E.164/I.331 (05/97): The International
+        Public Telecommunication Numbering Plan. 1997.
+
+Author's Address
+
+   Internet Architecture Board
+   Geoff Huston, Editor
+
+   iab@iab.org
+
+
+
+
+
+
+Huston                   Best Current Practice                  [Page 6]
+
+RFC 3172                    arpa Guidelines               September 2001
+
+
+Appendix A
+
+   April 28, 2000
+
+   Mr. Louis Touton
+   Vice-President, Secretary, and General Counsel
+   Internet Corporation for Assigned Names and Numbers
+   4676 Admiralty Way, Suite 330
+   Marina del Rey, CA 90292
+
+   Re:   Purchase Order No. 40SBNT067020:
+         Administration of the arpa Top Level Domain
+
+   Dear Mr. Touton:
+
+   As noted in your organization's quotation of February 2, 2000, the
+   arpa Top Level Domain (TLD) exists in the root zone of the domain
+   name system as a limited use domain currently consisting of one
+   record, in-addr.arpa.  On April 14, 2000, the Defense Advanced
+   Research Projects Agency (DARPA), formerly known as the Advanced
+   Research Projects Agency (ARPA), officially signaled its
+   disassociation with the arpa domain and its understanding the domain
+   would be used by the Internet Corporation for Assigned Names (ICANN)
+   and Numbers and the Internet Architecture Board (IAB) for additional
+   Internet infrastructure uses.
+
+   In keeping with the DARPA understanding, we believe that the arpa
+   domain should be made available for this specific, limited purpose.
+   The Department of Commerce considers this an Internet Assigned
+   Numbers Authority (IANA) function and has requested that the WHOIS
+   entry for the arpa domain reflect IANA as the registrant.
+
+   Purchase Order No. 40SBNT067020 provides that "[ICANN] will perform
+   other IANA functions as needed upon request of DOC." As such, the
+   Department of Commerce requests that, as part of the IANA functions,
+   ICANN undertake administration of the arpa TLD in cooperation with
+   the Internet technical community under the guidance of the IAB, as a
+   limited use domain for Internet infrastructure applications,
+   including the migration of Internet infrastructure applications that
+   currently reside in the .int TLD.  Further, as indicated by DARPA,
+   the arpa TLD string should be given a different expansion such as
+   "Address and Routing Parameter Area" to avoid any implication that
+   DARPA has operational responsibility for the domain.
+
+   If you have any questions, please do not hesitate to contact me.
+
+                              Sincerely, Karen Rose
+                              Purchase Order Technical Representative
+
+
+
+Huston                   Best Current Practice                  [Page 7]
+
+RFC 3172                    arpa Guidelines               September 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston                   Best Current Practice                  [Page 8]
+