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.
AbstractThis 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]  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. For example, the IP address 188.8.131.52 can be associated with the domain name "www.iab.org." by creating the DNS entry 184.108.40.206.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. 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.
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 . 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 , with administration of the sub-domain undertaken in accordance with the provisions described in this document.
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  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 , this arrangement is likely to change in the future. 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. 1], "ip6.arpa"  and "e164.arpa" . 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 .
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  . The "e164.arpa" domain is used to map E.164 style phone numbers into URIs. This mechanism is defined in RFC 2916 . RFC 2916 notes that the provision that names within this DNS zone are to be delegated to parties according to ITU recommendation E.164 . RFC 3026  describes the overall liaison arrangements between the IETF and ITU-T about the use of this domain. RFC 2870 , 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 . Any new subdomain delegation must adequately document any security considerations specific to the information stored therein. 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 .
 Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.  Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.  Carpenter, B., Baker, F. and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000.  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC2026, October 1996.  Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000.  Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.  Bush, R., "Delegation of IP6.arpa", BCP 49, RFC 3152, August 2001.  Blane, P., "Liaison to IETF/ISOC on ENUM", RFC 3026, January 2001.  Falstrom, P., "E.164 number and DNS", RFC 2916, September 2000.  ITU-T Recommendation E.164/I.331 (05/97): The International Public Telecommunication Numbering Plan. 1997.
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.