The Internet Engineering Task Force (IETF) currently outsources its supporting functions: Request for Comments (RFC) publication, secretarial support, and the registration and publication of Internet Protocol Parameters. The IETF protocol parameters function, widely known within the IETF as the Internet Assigned Numbers Authority (IANA), the RFC Editor, and IETF Secretariat all perform functions that are critical to the operation of the IETF.
This article describes the protocol parameters function as administered by IANA from the perspective of the IETF community: how the IETF uses IANA services and how a smoothly running protocol parameters registry service is critical to the IETF’s day-to-day functioning. It also indicates where IANA fits in the larger Internet governance arena and how its discussions can impact the IETF.
Background
The IETF community has long thought of IANA as an entity that exists by itself. In fact, IANA is more properly thought of as a set of functions covering the operation and management of a number of key Internet registries, which are places for officially recording values and ensuring that they are assigned properly and uniquely. Much like a register of deeds, IANA ensures that registrations are made only via authorized procedures, are documented clearly (e.g., purpose, contact information, etc.), and have followed appropriate policies.
At the highest level, IANA coordinates three classes of registries: domain names, number resources (e.g., IP addresses), and protocol assignments. It is important to note that there are (at least) two different views of who and what IANA is. To the IETF community, IANA is thought of mostly within the context of protocol assignments. This is not surprising, because for most IETFers, the only interaction they have with IANA involves protocol assignments. To the larger Internet community, the term IANA generally refers to all three functions, or possibly just domain names, since there has been so much new and highly visible activity in the domain name arena in the last decade.
The IANA functions are operated by the Internet Corporation for Assigned Names and Numbers (ICANN) under a no-cost contract with the U.S. Government. While ICANN has played a very prominent role in domain names, almost all protocol assignment discussions have been between the IETF and the IANA part of ICANN, outside of the ICANN spotlight.
The Need for Protocol Parameter Registries
Using protocol constants is basic to all protocols. For example, browsers access Web pages via the hypertext transfer protocol (HTTP) protocol. Packets carrying HTTP contain such protocol fields as the transmission control protocol (TCP) port numbers and Internet protocol (IP) addresses that identify the client and the HTTP server, protocol-type fields that show the packet carries IP (whether IPv4 or IPv6) and TCP (as opposed to user datagram protocol or UDP), etc. Many of these protocol fields have associated registries.
Individual protocols use their own registries. TCP, for example, has a registry for recording well-known port numbers. Registering port numbers makes it possible for all software to understand that HTTP servers can usually be found on servers at TCP port 80, whereas secure Internet message access protocol (IMAP) servers are found at port 993.
Most standards organizations make use of protocol registries, since they are so intimately tied to protocols. The Institute of Electrical and Electronics Engineers (IEEE), for instance, operates a registration authority for recording organizationally unique identifiers (OUIs) used in ethernet addresses.[1]
While the IETF could operate its own protocol parameters registry, it uses a separate organization—the IANA function operated by ICANN—for this purpose.
Example Protocol Usage
Dynamic host configuration protocol (DHCP) (RFC 2131 Dynamic Host Configuration Protocol) is a core IETF protocol used almost everywhere. When a device connects to the Internet, it uses DHCP to obtain an IP address and other such parameters as a default router and domain name system (DNS) server. The parameters exchanged via DHCP are encoded in DHCP options. Each option has its own assigned unique value, so that the option for a DNS server isn’t confused with the option denoting a default router. As with other IETF protocols, DHCP parameters are recorded in protocol parameter registries administered by IANA.[2] DHCP defines a number of individual registries in addition to option numbers; there are DHCP registries for message types (to distinguish different kinds of messages), status codes (for signaling different types of errors), etc.
Although DHCP is an “old” protocol (it dates back to the early 1990s), it continues to evolve and new options continue to be defined. Hence, it demonstrates the importance of protocol parameter registries. When someone proposes a new DHCP option, they write it up in an Internet Draft and (most likely) bring it to the IETF DHCP Working Group (WG) for discussion. If the proposal is accepted, it is refined in the WG and eventually sent to the IESG for approval and RFC publication.
At some point during the process, the proposed option needs a DHCP option code assigned to it. That is where IANA comes in. The IETF has defined a formal process for requesting protocol parameter assignments from IANA, a process that is intimately tied to the IETF standards process. In most cases, protocols and extensions are published in IETF RFCs. As a document is being finalized, it goes to the IETF for Last Call processing and to the IESG for formal approval. Any requests for IANA actions (e.g., to request a code point assignment) are usually made within an “IANA Considerations Section” of the document under review. As part of the IETF Last Call process, IANA reviews the document for actions, and verifies that any requests can be carried out. Once approved by the IESG, IANA carries out its actions and coordinates with the RFC Editor to make sure that any assigned option values appear in the published RFC.
The Details
New registries are typically created by protocol documents. Protocols define the fields in packet headers and the allowed values for those fields. Some fields contain enumerated types, in which specific values have well-defined meanings that will never change once defined and that all implementations will interpret the same way forever. For example, a security protocol might have a field denoting a specific encryption transform, with one value defined for Triple-DES. Once assigned, the value denoting the triple data encryption algorithm (Triple-DES) transform would always have the same meaning. Later, a new or otherwise different algorithm could be added (e.g., one based on the advanced encryption standard, or AES). It would be given its own distinct value. That way both could be supported simultaneously in an interoperable manner.
Once a registry has been created, future additions to it can be expected. To properly evaluate such future requests, governing policies are needed to define the criteria under which requests are to be granted. The IETF defines these policies for the protocol parameter registries.
The details of what policies make sense almost always depend on the specifics of the actual protocols using the registry. For example, some registries have a limited number of possible values (e.g., the 4-bit IP version field can represent only 16 distinct values), so assigning additional values must be done prudently. Other registries may be essentially unlimited in size (e.g., long text strings) and can be done with much less review. Also, some types of registries record values that can have a big impact on how a protocol works (e.g., defining a new message type). Such requests may warrant a more in-depth review, perhaps involving consultation with the IETF working group responsible for maintaining the protocol of interest.
The IANA functions for managing the Internet protocol parameter registries have existed since the dawn of the Internet. The formal processes for creating and managing registries were first documented in 1998 in RFC 2434’s Guidelines for Writing an IANA Considerations Section (later obsoleted by [RFC 5226]Guidelines for Writing an IANA Considerations Section in RFCs), and the IETF now has more than 15 years of operational experience in creating, using, and updating registries via the IANA Considerations Section framework.
RFC 5226 provides guidelines on how to create registries, how to populate those registries with initial values, etc. RFC 5226 also provides best practices on defining policies for governing future assignments to a registry. A number of predefined, “cookie-cutter” policies have been defined that handle many of the common cases. For example, the policy of “Standards Action” indicates that an assignment only happens via approval of a Standards Track document, whereas “First Come, First Served” denotes registries in which assignments are given out with little or no review.
Bottom Line
Having the protocol parameters function separate from the IETF has worked well in practice and works well today with ICANN executing that function. Many details have been formalized, beginning with theMemorandum of Understanding Concerning the Technical Work of IANA [RFC 2860] and Defining the Role and Function of IETF Protocol Parameter Registry Operators [RFC 6220], as well as yearly service-level agreements (SLAs) since 2006.[3] Performance reports called for in the SLAs can be found athttp://www.iana.org/performance/ietf-statistics.
The IETF and IANA worked closely together for years to develop the current system. In it, IANA performs an administrative function—fielding requests, processing them, and publishing the results. Matters of policy, including matters requiring technical evaluation of a specific request or what policies should govern assignments, reside squarely within the IETF. The close, day-to-day working relationship between IANA and the IETF has in practice resulted in a shared understanding of the respective roles of each entity. The current IETF/IANA relationship is strong and its maintenance will continue to require diligence going forward.
Where does the IETF fit into the Internet governance discussion? Any change to the current overall IANA functions could potentially impact the protocol parameters portion of IANA. Since the IETF depends on its smooth operation, it is critical that the IETF be engaged in any such discussion. The IETF has a unique need for the protocol parameters function and a unique view of IANA, and that view needs to be understood by the broader community in any Internet governance discussions related to IANA. This is particularly true when discussion of IANA (or ICANN) is really specific, for example, to DNS names, and does not apply to the protocol parameters function.
Conclusion
A properly operating protocol parameters function is critical to the IETF. The current relationship, in which ICANN operates IANA, has worked well for a number of years and continues to work well today. But given that IANA inevitably seems to come up in Internet governance discussions, the IETF must engage in such discussions so that its interests are not marginalized and the broader community fully appreciates the IETF/IANA relationship.