    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]