Summary

  • RFC 2042 reserved BGP attribute type value 255 for development. An attribute intended for Internet use was to be documented in an RFC, assigned a unique type code by IANA, and then updated in both documentation and code.
  • The memo explicitly rejected public/private and Internet/OSI partitions of the attribute space. A sighting of 255 therefore proves neither a vendor-private allocation nor interoperability, deployment, adoption, security, compatibility or authorization.

The most useful word in RFC 2042 is not reserved. It is development.

Reserved values are often treated as if they were parcels of addressable territory: a number appears unavailable to ordinary registrations, so an observer assumes that whoever uses it owns a secluded corner of the protocol. RFC 2042 establishes almost the opposite arrangement. Value 255 was a common temporary badge. Every new BGP attribute could use it while being developed. The badge distinguished unfinished work from an assigned public identity, but it did not distinguish one experiment from another.

That makes 255 intentionally unsuitable as a lasting namespace. If two laboratories test unrelated attribute formats, both can place the same type octet on the wire. The payload following that octet may have incompatible length, flags and semantics. Within a controlled test, prior agreement can tell each implementation what 255 means. Outside that context, the number supplies no such answer. Collision is not a defect in the placeholder; it is the reason the placeholder must not escape its development boundary.

A short memo about crossing a boundary

RFC 2042 was published in January 1997 as an Informational document. It is now classified by the RFC Editor in the Legacy stream, and the IETF Datatracker warns that it is not endorsed by the IETF and has no formal standing in the IETF standards process. Those status details matter. The memo records a historical coordination mechanism; it should not be inflated into a modern standards mandate.

Its scope is exceptionally narrow. RFC 1771, the BGP-4 specification then in force, described the path-attribute machinery and the attributes known at the time. RFC 2042 asks how a new attribute type becomes identifiable beyond a developer's own environment.

The answer is a sequence, not a permission bit. During development, use 255. For actual Internet use, document the attribute in an RFC and obtain a unique type code from IANA. Then replace the development value in the documentation and in the code base with the authorized number.

The order captures a release boundary. Documentation states what the attribute is supposed to mean. Registration prevents two public meanings from claiming the same number. Updating the implementation connects that public identity to executable code. None of the three can safely be inferred from the other two.

RFC 2042 also says what the mechanism was not designed to do. There was no intention to divide the code space into public and private sections, or into Internet, OSI and other protocol families. That sentence closes off a tempting retrospective story. The number 255 was not a vendor extension code, an enterprise range or a private treaty embedded in BGP. It was a single shared development value.

What the registry can establish

The present IANA BGP Path Attributes registry still lists 255 as “Reserved for development,” citing RFC 2042. It does not designate any Path Attributes range as Private Use. The same IANA BGP Parameters collection contains other registries with vendor-specific or private-use policies, but those policies belong to those named registries. They do not leak sideways into the path-attribute code table.

This is why a registry citation must include the registry name, not merely the number. A value of 255 in one BGP sub-registry may have a different policy from 255 in another. “BGP uses 255 privately” erases the very allocation boundary that a registry is supposed to preserve.

The modern Path Attributes registry also displays a Standards Action registration procedure with RFC 4271 as its reference. RFC 8126 later defined the terminology used for such policies. This is useful current context, but it is not the wording of RFC 2042 and should not be projected backward into 1997. Historical interpretation works best when it preserves both states: the memo's own process and the registry governance that exists now.

Registration itself remains a modest kind of proof. It establishes that a code has a recorded assignee or meaning under the applicable procedure. It does not show that an implementation exists, that two implementations agree, that operators deployed it, that peers accept it, or that its behavior is safe. An assigned number is a coordination record, not a packet trace or a deployment report.

The same restraint applies to 255. A capture containing that octet establishes that a sender emitted 255 at that observation point. It cannot, without local test records, identify which experimental attribute grammar follows. It cannot prove that the receiver recognizes the experiment. It certainly cannot turn the experiment into authorized public use.

Documentation and code had to move together

RFC 2042's instruction to update both documentation and the code base after assignment is easy to overlook. It describes a dangerous seam in protocol development.

If the document changes but an implementation keeps emitting 255, the public specification and the wire image diverge. If the code changes first while test tools, peers or stored fixtures retain 255, observers may diagnose a new assigned attribute as an unknown experiment. If two independent projects both forget to leave 255 behind, their traffic can look superficially identical at the type-code level while carrying incompatible meanings.

The number swap therefore needs evidence on several layers. There should be a registry record for the unique code, a stable specification for its meaning, a build containing that code, test vectors that match it, and observations showing which version actually ran. Only then can an operator state which identity a packet attempted to carry. Successful processing still requires evidence from the receiving implementation.

This distinction echoes Heng Lu's running-code principle without turning that editorial framework into an IETF rule. A document and registry can make a narrow public identity deterministic. They cannot manufacture operating reality. Publication is symbolic and institutional evidence; a built binary is executable evidence; deployment and peer behavior are operational evidence. Clear analysis keeps those layers connected without collapsing them.

The reference error changes nothing about 255

RFC 2042 has one official erratum. Errata ID 3681 corrects a reference: the cited BGP route-reflection document should be RFC 1966, not RFC 1998. The erratum is Editorial and held for document update. It does not alter the registration process, the development reservation or the rejection of private/public partitions.

That narrow correction is worth recording because it demonstrates the same evidentiary discipline. The visible misspelling of “documentation” in the RFC text is not what the official erratum covers. A researcher should report what the errata record actually verifies, not substitute a more obvious flaw.

A placeholder is useful because it is weak

The strength of 255 was its lack of durable identity. Developers could exercise parsing, propagation and error paths without prematurely occupying a public type code. Experiments remained free to change. The shared registry remained uncluttered by every local branch.

But that convenience depended on containment. Before traffic crossed into an environment where prior agreement could no longer be assumed, the experiment needed a documented meaning and a unique identifier. The design did not promise secrecy or private autonomy; it required a deliberate transition from local ambiguity to public coordination.

RFC 2042 therefore offers a compact lesson in protocol governance. Keep the common layer small. Give unfinished work an unmistakably temporary marker. Require public identities to be documented and unique. Then verify implementation and deployment separately.

The registry can tell the world which number names an attribute. It cannot tell the world that the attribute works. And 255, by design, could not even tell the world which experiment it named.

Sources