]> Juniper Networks

jhaas@juniper.net

General IANA code-point This document describes common code point reservation strategies for the zeroth and last code points in IANA-managed IETF registries and for bit-field registries. This document additionally provides the reasoning to support these strategies and their adoption as Best Current Practices to be applied to all IETF registries.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

A fundamental component of networking protocols are the fields contained within their Protocol Data Units (PDUs), a.k.a. packets. The fields are typically enumerated and are often part of the common syntactic form of a Type, Length, Value (TLV) tuple. An allocation of one of these enumerated fields is a code point. When designing or extending a networking protocol, some thought must be put into the range of allowable values and format for these fields. Additionally consideration must be given to how the allocation of the code points for these fields is managed. Other documents, for example , are dedicated to strategies for the management of such code point registries. The range of allowable values must be large enough to accommodate not only immediate uses that are part of the design of a protocol or protocol extension, but must also provide room for future maintenance. Some protocols that are meant to be used in highly constrained environments may also attempt to minimize the size of packets to conserve networking resources. Thus, a balance between being small enough to conserve resources but large enough to permit future expansion provides a tension that protocol designers must navigate. One further matter for consideration for such code point registries is pre-reserving some values. This document discusses a reasoning for the reservation of the zeroth and last code point in an integer field, and a general policy for the reservation of unused bits in bit-vectors.

When designing a protocol, a design decision must be made for integer code-points as to how large to make its range. Some protocols may prize density and thus elect for a small range, often a byte and perhaps less. Other protocols may be dominated by a need for flexibility and expansion and use a large range, four bytes or larger. When creating new integer code-point registries, this document makes the following recommendation: The zeroth entry of the new registry SHOULD be reserved. This permits implementors to avoid the need of separate boolean state to represent that a code point has been set with the value zero. It is RECOMMENDED that the reservation text should be of the form, "Reserved (not to be allocated)". The last entry of the new registry SHOULD be reserved. This provides future maintainers of the protocol the ability to extend the functionality covered by the semantics of this code point when all other numbers may have otherwise been allocated. (See , Section 6, "Reserved".) It is RECOMMENDED that the reservation text should be of the form, "Reserved (for future use for registry extension)". Implementations MAY specify that the zeroth code point is explicitly prohibited in the protocol. Experience in implementation, however, has suggested that fatal error conditions based on this behavior lend itself to a brittleness in the protocol with unforseen future consequences. Implementations SHOULD NOT explicitly treat the use of the last code point as an error condition outside the semantics otherwise specified within the protocol for an unused code-point. Making this value explicitly forbidden within the protocol eliminates its usefulness for future expansion in the presence of older implementations that do not understand the expanded semantic. In other words, future proof your implementation. An example of such an allocation for a registry:

Value | Meaning ------+-------------------------------------------------- 0 | Reserved (not to be allocated) : | Max | Reserved (for future use for registry extension)

When code points representing bit-fields in protocols are made, many of the new bits are generally unallocated and left for future expansion. These bit-fields are either noted as Unassigned, Reserved, or have other similar policies associated with them in the registry containing them. Specifications containing such fields are recommended to provide text documenting these reserved fields similar to the following: "These bit-fields are Unassigned and MUST be set to zero upon transmission and SHOULD be ignored upon receipt."

This document does not introduce any security considerations.

This document does not make any requests to IANA. However, future documents may wish to utilize this document as an informative reference for their reservation strategy when making requests to IANA.

&rfc2119; &rfc5226bis;

This document was originally a lunch discussion with John Scudder about IETF code point allocations for BGP. While the above practices were thought to be widely understood, they did not appear to be written down anywhere to help educate new IETF participants. Adrian Farrel provided substantial review on the first version of this document. This document has also benefited from excellent discussion of the subject on the IETF Working Group Chairs e-mail list.