Internet Architecture Board G. Huston, Editor
Internet Draft May 2001
Document: draft-iab-arpa-01.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
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments on this draft should be directed to iab@iab.org.
Abstract
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
Internet Architecture Board [Page 1]
draft-iab-arpa-01.txt ARPA Guidelines 9 May 2001
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.
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.
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.
Internet Architecture Board [Page 2]
draft-iab-arpa-01.txt ARPA Guidelines 9 May 2001
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,
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.
Internet Architecture Board [Page 3]
draft-iab-arpa-01.txt ARPA Guidelines 9 May 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 RFC2870 in relation to the operation of the
root servers shall also apply to the operation of the "ARPA"
servers.
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
The ARPA domain is used for the sub-domains "in-addr.ARPA" [1],
"ip6.ARPA" [6] and "e164.ARPA" [7]. 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 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 entity 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 entity. If the delegated
entity 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
entity.
4. Current Status of "ARPA"
Currently, the "ARPA" zone is located on the same set of servers as
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
Internet Architecture Board [Page 4]
draft-iab-arpa-01.txt ARPA Guidelines 9 May 2001
the root servers in accord with the RFC 2870 recommendation for
exclusive use of those servers. [5]
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
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]
As part of the ENUM activity in using E.164 numbering on the
Internet, the process to undertake sub-delegations of the
"e164.ARPA" domain are described in Section 4 of RFC 2916 [7] [8],
which notes the provision that names within this DNS 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", and consideration should be
given to migrating them into "ARPA" as and when appropriate.
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 [7].
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 MoU between the IETF and ICANN
concerning the IANA. [3]
Internet Architecture Board [Page 5]
draft-iab-arpa-01.txt ARPA Guidelines 9 May 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.
References
[1] Mockapetris, P., "Domain names - concepts and facilities",
STD13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Carpenter,B., Baker, F., Roberts, 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] Bush, R., "Delegation of IP6.ARPA", internet draft work in
progress, draft-ymbk-ip6-arpa-delegation-02.txt, March 2001.
[7] Falstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[8] Blane, P., "Liaison to IETF/ISOC on ENUM", RFC 3026, January
2001.
Author
Internet Architecture Board
Geoff Huston, Editor
iab@iab.org
Internet Architecture Board [Page 6]
draft-iab-arpa-01.txt ARPA Guidelines 9 May 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
Internet Architecture Board [Page 7]
draft-iab-arpa-01.txt ARPA Guidelines 9 May 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
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.
Internet Architecture Board [Page 8]
