Summary

  • RFC 791 made the eight-bit Protocol field a selector for the next-level protocol, but delegated the meanings of its values to the separate Assigned Numbers system.
  • RFC 3232 replaced obsolete periodic RFC snapshots with IANA's online database; RFC 5237 later tightened allocation policy around a finite 256-value namespace.

An IPv4 receiver cannot learn the meaning of every payload merely by looking at the payload. Before it can hand the data to TCP, UDP, ICMP, or another next-level protocol, it needs an agreed selector. RFC 791 put that selector in an eight-bit field named Protocol. The field says what comes next. It does not contain a name, a versioned schema, or instructions for finding an implementation.

That small design choice divided the control surface in two. The IPv4 header fixed the location and width of the field. A separate authority assigned meanings to its possible values. RFC 791 explicitly sent readers to Assigned Numbers rather than freezing a complete table into the Internet Protocol specification. The packet carried a number; the community maintained the dictionary.

A fixed octet with an external vocabulary

The separation mattered because wire formats and protocol inventories change at different speeds. Rewriting IPv4 whenever a new next-level protocol received a number would have entangled the stable base header with a growing operational catalogue. A separate assignment table let the octet remain parseable while its vocabulary evolved.

The field is only eight bits wide. That produces 256 possible bit patterns, not an unlimited naming system. A value can direct a receiver toward a protocol handler, but it does not negotiate whether that handler exists. It does not identify an application in the way a transport port may do. It does not authenticate the encapsulated data or guarantee that a middlebox will permit it. It is a globally coordinated demultiplexing instruction whose usefulness depends on sender, receiver, documentation and registry agreeing on the same meaning.

The original publication machinery reflected the Internet's earlier administrative scale. RFC 3232 records that from November 1977 through October 1994, IANA periodically issued tables of protocol-parameter assignments as RFCs titled Assigned Numbers. The final document in that sequence, RFC 1700, was an October 1994 snapshot with Standard status.

When the snapshot stopped being the authority

A snapshot ages the moment the underlying namespace changes. By 2002, RFC 3232 could state what operations had already made true since 1994: the series of Assigned Numbers RFCs had been replaced by an online IANA database. It formally made RFC 1700 Historic and warned that the old table was incomplete and, in some cases, wrong.

This was not a change to the IPv4 packet. No field became wider, and no router had to consult a website for each datagram. The shift changed where current coordination truth lived. Implementers and standards authors could still cite stable specifications, but the authoritative set of assignments could be maintained without minting a new archival RFC snapshot after every registry change.

The distinction is easy to miss because both an RFC and a registry can look like lists. Their temporal roles differ. A standards document records a protocol rule at a defined publication point. A live registry records the present assignment state of a namespace whose entries can be added or revised under published policy. RFC 3232 made that division explicit for Internet protocol parameters.

Scarcity turned registration into policy

Moving the table online did not make the namespace abundant. RFC 5237 returned to the Protocol field in 2008 and noted that 55 percent of its 256 values were already in use. New protocols still needed numbers, including experiments and work outside the IETF standards track, but assignments could not be made needlessly.

The document therefore treated allocation as a judgement about shared infrastructure. Relevant questions included whether a stable public specification existed, whether a real constituency wanted to use it, whether an assignment duplicated an existing purpose, and whether a Protocol number was the right mechanism rather than, for example, a TCP port. It retained Standards Action and IESG Approval, while removing an Expert Review route associated with nondisclosure arrangements. For this limited public namespace, the specification argued that reviewable public documentation should accompany allocation.

That policy does more than keep a tidy list. A globally visible number can enter kernels, packet analyzers, security appliances, standards and operational procedures. Once deployed, reclaiming or reinterpreting it can impose coordination costs far beyond the registry entry itself. The finite field turns each allocation into a small piece of durable interoperability infrastructure.

What the registry does not solve

An authoritative online table cannot force implementations to follow it. The cited RFCs do not measure how quickly software adopted new assignments, how consistently middleboxes forwarded unfamiliar values, or how often private conventions collided with public use. A current registry reduces ambiguity at the coordination source; it does not eliminate lag, filtering or ossification at the network edge.

Nor is the Protocol value a proof about the payload. It declares the intended next-level interpretation. A receiver may lack support, apply policy, or reject malformed data after demultiplexing. Those outcomes sit outside the eight-bit field's promise.

The durable lesson is architectural. IPv4's Protocol field survived without becoming self-describing because its stable syntax was paired with a maintained public vocabulary. The octet stayed fixed. Authority over its meanings moved from periodic documentary snapshots to a live registry, and allocation rules became more explicit as the namespace filled. Longevity came not from freezing every answer in 1981, but from deciding which part of the system was allowed to change.

Sources