Registry Allocation: First Come, First Served and Its Failure Modes

A protocol needs numbers that must be unique across all implementations: message type codes, option identifiers, port numbers, enterprise numbers, language tags, MIME media types. Someone has to hand them out, and the allocator’s policy is a technical decision with the same standing as the framing rules, because it determines how quickly a protocol can be extended, and by whom.

For the Internet protocols, that someone was historically one person. The structure that resulted is a registry, and the registry’s rules are now written into the specifications that use it.

The registry as a committed data structure

A registry is a table with one row per assigned value and a policy attached to the whole table. The policy states who may request an assignment, what information the request must contain, whether review by a designated expert is required, and whether the assignment is permanent.

The important property is not the table but its permanence. A code point once allocated cannot be reallocated, because deployed implementations may still emit it, and a reallocation would make an old device’s traffic mean something new. Registries are therefore append-only. Deprecated values remain listed with a reference to the document that deprecated them, and the registry grows monotonically for the life of the protocol.

That append-only rule has a direct cost: allocation exhausts space rather than reusing it. An eight-bit field offers 256 values, and the registry for that field will reach 256 rows and never shrink. Protocols that anticipate long life either widen the field at design time or reserve a bulk-transfer mechanism for group assignments, and the choice between those two is a design decision made once and paid for decades later.

First come, first served and its consequences

The simplest policy is first come, first served: an assignment is made to whoever asks first, with no technical review. The rationale is speed. A protocol designer who needs an option code should not have to convene a review board, and a registry that adds friction to allocation makes extension expensive and therefore discourages it.

The consequence is that the namespace becomes a claim-staking ground. Two effects follow.

The first is squatting. A value assigned to an experiment that was never deployed consumes a slot forever. The registry records the assignment and the reference, and the reference may be a document that expired without becoming a standard. There is no reclamation procedure, because reclamation would break the append-only guarantee that makes allocation safe.

The second is premature commitment. A designer who wants a specific small numeric code has an incentive to request it before the design is settled, because the code may be taken later. This inverts the intended order: allocation is meant to follow design, and first-come allocation rewards allocation before design. In a protocol with a handful of conventional code values, the ordinary values fill first, and later extensions are pushed into the numerically awkward range.

Where a namespace is small and contested, policy escalates. The standard policy ladder runs from private use and experimental ranges, through first come, first served, to specification required, to standards action. Each step up costs the requester more and buys the namespace more protection. A field with 65,536 values can afford first come, first served; a field with 16 cannot.

How a request becomes a row

The mechanics are worth stating because the resulting registry entries are the ground truth against which an implementation is written.

A specification that creates or extends a registry carries an assignment-considerations section — historically titled “IANA Considerations”, after the function that performed the work. That section names the registry, states the allocation policy, and enumerates the initial assignments. The document is the instruction set; the registry is the record. When the two disagree, the registry reflects later decisions, because assignments continue after publication.

The IANA function itself was described in RFC 2860, a memorandum of understanding between the Internet Society and ICANN that set out the technical work: allocating values in protocol registries and maintaining the resulting tables. The document is short, and its significance is that it separated the clerical function — maintaining unique numbers — from the policy function of deciding what should be standard.

RFC 8126 later consolidated the policy vocabulary that specifications are expected to use, defining the named policies and the review requirements each implies. A specification that does not cite one of these named policies leaves its registry’s future undecided, and the undecided case resolves by precedent rather than by rule.

The domain name system’s registry is the same shape at a different scale. RFC 1591 described the structure and delegation of the top level: a designated manager for each top-level domain, operating the registry, with the delegation recorded centrally. Delegation there is a governance act rather than a technical one, and the disputes it generated are political rather than numeric. The technical lesson transfers anyway: a namespace with a central record and a policy for adding rows is a registry, whether the rows are sixteen-bit codes or two-letter labels.

Non-transferability and the persistence problem

Registrations are generally not transferable. A code point belongs to the specification that requested it, not to the company that wrote the specification, and a company that abandons a protocol does not thereby release its numbers. This prevents a market in code points, which would otherwise appear immediately: a scarce identifier with commercial value is an asset, and assets get traded.

The persistence also creates a maintenance obligation with no owner. The registry function must outlive every organization that has ever requested an assignment from it, because the numbers remain in use as long as any deployed device emits them. Bodies therefore separate the registry’s continuity from the protocol’s relevance: the registry is maintained for protocols that no working group is developing, and a decommissioned protocol’s numbers stay allocated indefinitely. In practice this means the registry’s size reflects the total number of experiments ever run, not the number of live standards. The broader problem of retiring a specification that products still implement is treated in the account of errata and withdrawal.

Where the model breaks

Two conditions defeat the registry model.

The first is a namespace too large to enumerate but too small to ignore. A 32-bit identifier space cannot be preregistered row by row; it is allocated by algorithm or by an authority that issues blocks. Block allocation reintroduces the problem the registry solved, at a level up: the block holder decides who gets sub-blocks, by rules the parent may not have specified.

The second is a namespace whose contents must be resolvable at runtime, which pushes allocation into the naming system and out of the specification. That shift is where the registry’s technical role becomes a policy role, and where the dispute over who may add rows becomes a dispute about the network itself. The relationship between specification authority and implementation authority in that setting is the subject of the analysis of de jure and de facto standards.

For an implementer, the operational rule is simple and often violated: read the registry, not the specification, when determining what a numeric value means today. The specification states what the value meant when the document was approved. The registry states what it means now, including the values added afterwards and the values deprecated in their favour.