RFC 3172

RFC 3172 is here, bestie! 📜💖 This one's a BCP (Best Current Practice, BCP 52) from September 2001, written by G. Huston as Editor for the IAB. The title is Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa") 🎀. It's filed under Category: Best Current Practice, and the header doesn't list anything it obsoletes or updates ✨.

Status of This Memo 🌸

This document specifies an Internet Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements 🫶. Distribution of this memo is unlimited, so share it with everyone 💅.

Copyright Notice 💜

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract 🦋

Okay so this memo is all about how the "arpa" domain gets managed and what it needs to operate well 🔥. The "arpa" domain supports a class of infrastructural identifier spaces. It's basically a distributed database that turns pieces of a structured name space, which comes from a protocol family, into service names 🧚. Keeping this DNS space running efficiently and reliably is seriously essential, because so many Internet services depend on it 😭. The Internet Architecture Board (IAB) is responsible for managing "arpa", working together with the Internet Corporation for Assigned Names and Numbers (ICANN) 👑. This document walks through the principles the IAB follows while doing that job ✨.

1. Introduction ✨

Let's start with the basics! The Domain Name System (DNS) [1] [2] is mostly used to take a structured textual identifier and translate it into a protocol-specific value 🍓. It works by using the structure of a hierarchical identifier space to build a distributed database, and every node in that database lines up with a node in the name structure 🌈. The biggest thing DNS does is store name-to-address translations, so a domain name can be turned into an IP address 💖. It also stores plenty of other translations, taking values from hierarchically structured identifier spaces and turning them into target values of different types 🫧.

DNS can also go the other way, from protocol values to the names of service entities 🔄. One way to do this is to transform protocol values into a hierarchically structured identifier space, and then use those transformed names as a DNS lookup key in the right DNS name hierarchy 🧩. The most common version of this is the reverse of name-to-address lookup, where an IPv4 address is used to find its matching domain name 🔍. For example, the IP address 128.9.160.55 can be linked to the domain name www.iab.org. by creating the DNS entry 55.160.9.128.in-addr.arpa. and mapping that entry, through a DNS PTR record, to the value www.iab.org. 🎀.

Lots of applications use the resolution of protocol objects into service names to connect services to a specific protocol object 🦋. These applications only work correctly and efficiently if the "arpa" domain name servers they depend on also work correctly and efficiently 😤💅.

2. The "arpa" domain 🌷

The "arpa" domain was first set up as part of the initial DNS rollout 🌱. It gave people a way to move away from the Host Tables that were common on the ARPANET, and it became home to the IPv4 reverse mapping domain 🏠. In 2000, the abbreviation was given a new meaning, "Address and Routing Parameter Area," in the hope of cutting down on confusion with the old network name 🫶.

The IAB, working with ICANN, is currently responsible for managing the Top Level Domain (TLD) "arpa" 👑. That arrangement is written up in Appendix A. This domain is the root of the name hierarchy used for reverse mapping of IP addresses to domain names 🔄. It's also a limited-use domain for Internet infrastructure applications, serving as a name root for mapping particular protocol values to the names of service entities 🧚. Put simply, it's the root for turning protocol values into lookup keys so people can fetch operationally critical protocol infrastructure data records or objects for the Internet 💜.

The IAB may add other infrastructure uses to "arpa" in the future 🔮. Any additions or changes like that shall follow the procedures in Section 2.1 and Section 3 of this document 📋.

This domain is called an "infrastructure domain," because its job is to support the Internet's operating infrastructure 🏗️. So the "arpa" domain is not to be used the same way as other generic Top Level Domains are commonly used, like for naming hosts 🙅‍♀️.

Day to day, the IANA handles the operational administration of this domain, following the rules in this document 🎀. That work happens 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 protocol object sets that are defined as part of the Internet Standards Process [4] 🌸. They're recommended to be managed as infrastructure protocol objects 🦋. Usually, that recommendation is made in the "IANA Considerations" section of the Internet Standard protocol specification 📜. The recommendation should say how protocol objects get mapped into lookup keys, and it should include recommendations to IANA about running the "arpa" sub-domain alongside the recommendations for running the protocol object registry itself 🧠.

When the IESG looks at a document that proposes an "arpa" sub-domain, it shall consider the document's "IANA Considerations" section 👀. If the document gets approved, the IESG will ask the IAB to request that the IANA add the matching protocol object sub-domain to the "arpa" domain, following RFC 2860 [3] 🎉. The sub-domain's administration will then follow the provisions in this document 💅.

2.2 "arpa" Name Server Requirements 🛡️

This domain is part of the Internet's operationally critical infrastructure, so how stable, intact, and efficient it is matters to every Internet user 🫶.

"arpa" sits at the top level so it can avoid operational instability 🌊. Without that, lookups would have to bounce across several operational domains just to find the servers for each parent name of a deeply nested infrastructure name 😵‍💫. The biggest lookup "arpa" ever needs is asking a root server for the name servers of the "arpa" domain. After that, the query agent gets a list of authoritative "arpa" name servers 📋.

The "arpa" domain is so critical that the operational requirements for root servers also apply to "arpa" servers 🔥. Every operational requirement in RFC 2870 [5] that applies to root servers shall also apply to the operation of "arpa" servers 💪. Any revision to RFC 2870 related to root server operation shall also apply to "arpa" servers 🔄.

A lot of the servers that are authoritative for the root zone (the "." zone) also serve as authoritative for the "arpa" zone right now 🌐. As RFC 2870 [5] points out, this setup is likely to change in the future 🦋.

References ✨

okay bestie, here's the reading list the whole spec is built on 📚

• [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 🖊️

Here's who to message about it, iab-style:

Internet Architecture Board
Geoff Huston, Editor

iab@iab.org

Appendix A 💌

This appendix is a real letter, and it's giving official paperwork energy. Here it is, complete, with every detail intact. 🫶

April 28, 2000

Here's the address block, verbatim:

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

The subject line is: Re: Purchase Order No. 40SBNT067020: Administration of the arpa Top Level Domain 🔥

Dear Mr. Touton, ✨

So, as your organization's quotation of February 2, 2000 already noted, the arpa Top Level Domain (TLD) lives in the root zone of the domain name system as a limited use domain. Right now it only has one record, which is in-addr.arpa. Then, on April 14, 2000, the Defense Advanced Research Projects Agency (DARPA), formerly known as the Advanced Research Projects Agency (ARPA), officially signaled that it was stepping away from the arpa domain. It also understood that 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. 💅

Following that DARPA understanding, we believe the arpa domain should be made available for this specific, limited purpose. 🎀 The Department of Commerce sees this as an Internet Assigned Numbers Authority (IANA) function, and it has asked that the WHOIS entry for the arpa domain show IANA as the registrant. 🌸

Purchase Order No. 40SBNT067020 says that "[ICANN] will perform other IANA functions as needed upon request of DOC." 🧚 So the Department of Commerce is requesting that, as part of the IANA functions, ICANN take on administration of the arpa TLD. This should happen in cooperation with the Internet technical community under the guidance of the IAB, as a limited use domain for Internet infrastructure applications. That includes migrating the Internet infrastructure applications that currently live in the .int TLD. 🦋 And since DARPA pointed it out, the arpa TLD string should get a different expansion, such as "Address and Routing Parameter Area," so nobody thinks DARPA is still running the show operationally. 👑

If you have any questions, please do not hesitate to contact me. 💖

Here's the signature block:

Sincerely, Karen Rose
Purchase Order Technical Representative

Full Copyright Statement 🌈

Okay, the legal bit, and I'm keeping every word of it because it matters. ⭐

Copyright (C) The Internet Society (2001). All Rights Reserved. 💜

So basically, this document and its translations can be copied and shared with others. You can also make derivative works that comment on or explain it, or help with implementing it, and you can prepare, copy, publish and distribute those too, in whole or in part, with no restriction of any kind. The one catch is that the above copyright notice and this paragraph have to be included on every single copy and derivative work. 🔒 However, this document itself can't be modified in any way, which means you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exception is when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process have to be followed. Translating it into languages other than English is also allowed. 🌍

The limited permissions above are perpetual, and the Internet Society or its successors or assigns will not revoke them. ♾️

Last but not least, the disclaimer: this document and the information in it are 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. 💖