IANA

What is IANA, how does it work, how is it related to the IETF, and how has it evolved over time?

Protocols need a common vocabulary to communicate in an interoperable manner. For example, the TCP port number 80 denotes HTTP service. Most IETF protocols used in the Internet make use of registries in some form, either in using constant or well-known values, or communicating with addresses or names assigned through a registry. These registries are naturally critical to the operation of the Internet. Consequently, their management must be done in a predictable, stable and secure manner.

IETF relies on IANA registries of protocol parameters: protocol numbers, port numbers, TLVs, MIME types, and so on. The role of the IETF is to set the policy on how allocations in these spaces can be made. The role of an operator performing the IANA function is then to make the actual allocations, following the policy, and maintain a public web site that shows what values have been allocated. Thus, IETF sets policy which the IANA operator implements. In addition, Internet Architecture Board (IAB) is responsible for the oversight of the IANA function. This role includes appeals, selection of the registry operator, and keeping the overall framework up to date.

This system has served the Internet well, but has also evolved quite a bit over time. As part of the formation of the Internet Corporation for Assigned Names and Numbers (ICANN) and transfer of functions to it, the US Department of Commerce awarded ICANN a contract to perform the IANA function. That contract still exists, but it is important to understand the role that the Internet community has taken on in running the system. For instance, 2000, the IETF and ICANN signed a contract about the protocol parameters aspect of the IANA function (RFC 2860) and specified the role of the IAB in its oversight (RFC 2850). Service-level agreements have been written on a yearly basis since 2007; these agreements specify expected service levels and detailed operational procedures. A more detailed specification of the role of the operators that perform protocol parameter IANA function was written in 2011 (RFC 6220). IANA reviews all drafts that are up for approval, making sure that the IANA policy specified in them is understandable and implementable.

I think that the system works remarkably well today. For instance, requests related to IETF standards process – such as IANA review of drafts – are fulfilled quickly. Statistics are used to track the process. I think that the system has grown up, just like the Internet itself. IANA function continues to be a professionally managed operation that keeps improving itself, and is supported by documented procedures and agreements.

Note that IANA handles two other important registries beyond protocol parameters. They are the top-level registry for IP addresses, and coordinate the allocation of the unicast address space further to Regional Internet Registries (RIRs), such as RIPE or ARIN. The RIR community sets the actual allocation policies. IANA is also the registry for top-level domain names. Domain-name policies are set by ICANN.

And the evolution of the system continues. As the Internet continues to support even more applications and technology, the system needs to do more. And we need to ensure that the overall framework continues to match what the global Internet needs. In my view, this means further evolution towards the central elements in the above RFCs, i.e., normal contract relationship, supported by relevant specifications and community processes. Of course, the details and those specifications continue to change. IAB’s oversight role is important here. For instance, Olaf Kolkman has written a new draft for the IAB’s IANA evolution program. This informational draft explains the oversight-policy-implementation framework as it applies to not just protocol numbers but also addresses and top-level domain names. Documenting this model is helpful to ensure that we all understand what roles different parties have in the overall system, and also helps to discover areas where further work is needed. I know Olaf and the IAB would be grateful for feedback; please use the internetgovtech@iab.org list for discussion.

The IETF also needs to ensure that various policies governing IANA allocations are well specified. In addition to doing this for new protocols, we also have to maintain old number spaces and their rules and definitions as the practices evolve. For instance, we recently went through the Internet numbers registry system to make sure its definition is up to date. See RFC 7020 and draft-housley-number-registries (currently in last call). Please help review ongoing revisions and tell us if you have identified something that needs an update.

All these operations and the work supporting them is thanks to many committed professionals and volunteers at IANA, at the IAB IANA evolution program, and at the IETF. In particular, many volunteers are serving as expert reviewers of allocation requests. Thank you all for this work.