Internet Architecture Board                            G. Huston, Editor
Internet Draft                                                April 2001
Document: draft-iab-arpa-00.txt
Category: BCP

           Management Guidelines & Operational Requirements for
               the Internet Infrastructure Domain ("ARPA")

Status of this Memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026 [4].

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups. Note that
     other groups may also distribute working documents as Internet-
     Drafts. Internet-Drafts are draft documents valid for a maximum of
     six months and may be updated, replaced, or obsoleted by other
     documents at any time. It is inappropriate to use Internet- Drafts
     as reference material or to cite them other than as "work in

     The list of current Internet-Drafts can be accessed at

     The list of Internet-Draft Shadow Directories can be accessed at


     This memo describes the management and operational requirements for
     the "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 has the responsibility, in cooperation with the
     Internet Corporation for Assigned Names and Numbers, to manage the
     domain name "ARPA". 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

Internet Architecture Board                                     [Page 1]

draft-iab-arpa-00.txt        ARPA Guidelines               28 April 2001

     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.

     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. The most common use of
     this mechanism to date 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. The domain name hierarchy used to hold these
     number-to-name mappings is placed into the DNS name hierarchy is the
     name location "in-addr.ARPA". 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

2. The "ARPA" domain

     The Internet Architecture Board (IAB), in cooperation with the
     Internet Corporation for Assigned Names and Numbers (ICANN), is
     currently responsible for undertaking the role to manage 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 documented in an RFC.

     This domain is termed an "infrastructure domain", as its role is to
     support the operating infrastructure of the Internet. In particular,

Internet Architecture Board                                     [Page 2]

draft-iab-arpa-00.txt        ARPA Guidelines               28 April 2001

     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

     "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. 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 progress of the protocol standard from internet-draft to
     Proposed Standard shall include consideration of the IANA
     Considerations section and a recommendation to 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 critically
     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.

     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

Internet Architecture Board                                     [Page 3]

draft-iab-arpa-00.txt        ARPA Guidelines               28 April 2001

     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 RFC2870 in relation to the operation of the
     root servers shall also apply to the operation of the "ARPA"

     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

3. Delegation of "ARPA" Sub-Domains

     As of the time of the preparation of this document, the ARPA domain
     is used for the sub-domains "in-addr.ARPA" and "e164.ARPA". 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 authority.

     The IAB shall only recommend the creation of "ARPA" sub-domains
     corresponding to protocol entities in the case that the delegation,
     and the hierarchical name structure is described by an IETF
     Standards Track document [4], and this inclusion within the "ARPA"
     domain is explicitly recommended in the "IANA Considerations"
     section of that document.

     If the appropriate protocol management authority is willing and able
     to operate a set of name servers that are in conformance with the
     requirements described in this document, the IAB MAY request the
     IANA to delegate the sub-domain to that authority.  If the delegated
     authority is not in a position to operate a set of name servers in
     conformance with these requirements, the IAB shall designate a
     server operator to undertake this function, and shall instruct the
     server operator to undertake further sub-delegation of protocol
     elements in accordance with the instructions of the delegated

4. Current Status of "ARPA"

     Currently, the "ARPA" zone is located on the same set of servers as
     the root servers, and the zone in managed in accordance with these

     The IPv4 reverse address domain, "in-addr.ARPA" is delegated to the
     IANA. The "in-addr.ARPA" zone is currently located on the same set
     of servers as the root servers. Sub-delegations within this

Internet Architecture Board                                     [Page 4]

draft-iab-arpa-00.txt        ARPA Guidelines               28 April 2001

     hierarchy are undertaken in accordance with the IANA's address
     allocation practices.

     The process to undertake sub-delegations of the "e164.ARPA" domain
     are described in Section 4 of RFC 2916 [6], which notes the
     provision that names within this zone are to be delegated to parties
     according to ITU recommendation E.164.

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".

6. Security Considerations

     The security considerations as documented in RFC2870 [5], and any
     successors to that document shall apply to the operation of the
     "ARPA" servers.

     The security considerations specific to the E164 subdomain are
     documented in Section 5 of RFC 2916 [6].

     Any new subdomain delegation MUST adequately document any security
     considerations specific to the information stored therein.

7. IANA Considerations

     As noted in Section 3, 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 the MoU between the IETF and
     ICANN concerning the IANA. [3]


     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.


     [1] Mockapetris, P., "Domain names - concepts and facilities",
         STD13, RFC 1034, November 1987.

     [2] Mockapetris, P., "Domain names - implementation and

Internet Architecture Board                                     [Page 5]

draft-iab-arpa-00.txt        ARPA Guidelines               28 April 2001

         specification", STD 13, RFC 1035, November 1987.

     [3] Carpenter,B., Baker, F., Roberrts, M., "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",
         BCP9, RFC2026, October 1996.

     [5] Bush, R., Karrenberg, D., Kosters, M., Plzak, R., "Root Name
         Server Operational Requirements", BCP 40, RFC 2870, June 2000.

     [6] Falstrom, P., "E.164 number and DNS", RFC 2916, September 2000.


     Internet Architecture Board
     Geoff Huston, Editor

Internet Architecture Board                                     [Page 6]

draft-iab-arpa-00.txt        ARPA Guidelines               28 April 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-
addrARPA.  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.

                                       Karen Rose
                                       Purchase Order Technical Representative

Internet Architecture Board                                     [Page 7]

draft-iab-arpa-00.txt        ARPA Guidelines               28 April 2001

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

    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


    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Internet Architecture Board                                     [Page 8]