Summary

  • RFC 3692 chose generic testing values over temporary exclusive assignments that could be difficult to reclaim and risky to reuse.
  • Its values 253 and 254 do not identify one experiment or guarantee that devices understand one another; safe use depends on local agreement, explicit configuration and ordinary allocation for anything permanent.

A test needs a number before it has a name

Imagine two engineers adding a new field to a packet. Their code can compile, but a receiving system still needs a value that says what the field means. In a closed lab they may choose one privately. The difficulty begins when they want the experiment to pass through real protocol machinery without taking a number that belongs to someone else—or asking an authority to lend one that may later need to be taken back.

RFC 3692, published in January 2004 as Best Current Practice 82, addressed that narrow gap. Temporary exclusive assignments looked tidy on paper: allocate a value for the experiment, then return it when the work ends. But the document points out the human and operational residue. Contacts go stale; nobody can establish whether a test is still running; a value may escape into a product; and reuse can surprise devices whose deployment history is no longer visible.

The alternative was less like borrowing a labeled key and more like setting aside a common test bench. For the IP Protocol field, IANA assigned 253 and 254 for experimentation and testing. Different consenting systems could use the same value for different trials. The value was deliberately generic. It did not reserve a protocol’s meaning, bind other implementers, or establish a compatibility contract.

Collision was part of the design

This is the counterintuitive part: RFC 3692 did not eliminate collisions by giving every experiment a unique temporary number. It made collision risk explicit and placed the boundary locally. An administrator could choose a value for a specific purpose and make sure it was not already used in that environment. Outside that local choice, uniqueness was not promised.

That changes what a test result can prove. A packet using 253 may show that a configured peer recognizes the extension. It does not show that an unrelated network will interpret the same value the same way. A successful exchange inside an agreed lab says something about those endpoints and conditions, not about broad deployment. If an experiment becomes useful, RFC 3692 directs its authors back to normal assignment procedures for a permanent number.

The product boundary is equally clear. Experimental recognition should not be enabled by default in a shipped product. A user must explicitly turn it on and, in most cases, configure which value to use. A hard-coded value can collide with another experiment and create an interoperability problem precisely because these numbers are shared rather than exclusive.

A later catalogue did not change the bargain

RFC 4727 later documented experimental values in IPv4, IPv6, ICMP, UDP and TCP header spaces. It says not to select one and hard-code it into a system, and directs readers back to RFC 3692’s precautions. That wider catalogue made experimentation easier to specify; it did not convert its values into unique names or generally deployed features.

The distinction still matters when reading registries. IANA currently lists IPv4 Protocol values 253 and 254 for experimentation and testing. That is evidence of an allocation’s purpose, not a count of implementations or a claim that an experimental protocol is running across the Internet. RFC 8126 is later general guidance for IANA considerations; RFC 3692’s references to the older RFC 2434 belong to its 2004 history, not today’s complete allocation rulebook.

RFC 3692’s small contribution was a safer grammar for trying things: reserve generic space, make local consent visible, require opt-in, and graduate useful work through the ordinary process. A test value opens a door. It does not tell everyone what is on the other side.

Sources