TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format
updated by
- rfc-7722 — Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
updates
- rfc-5444 — Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
Extracted elements (24)
Two distinct forms of TLV allocation exist: one where the TLV type immediately defines all type extensions (e.g., LINK_METRIC), and one where only type extension 0 (and possibly 1) is defined. The naming policy differs: the first form receives a common name at the type level; the second form should only name the specific full type (type + extension), not the type itself, to avoid blocking future type extensions with counterintuitive names.
When a TLV type does not define all its type extensions, leaving the TLV type unnamed (described only by number as 'Defined by Type Extension') facilitates future allocation of additional type extensions without imposing an inappropriate or misleading name on them. For example, LINK_STATUS becomes the name of the full type (type 3, extension 0) rather than of type 3 generally.
RFC 7631 notes that the new naming convention (attaching names to full types rather than TLV types) is already effectively in use in RFC 6130 and RFC 7181, the main users of allocated TLVs. For example, RFC 6130 already indicates that all usage of LINK_STATUS refers to that TLV with type extension 0. No protocol behavior changes.
This document adds Experimental Use reservations (type extensions 224-255) to the MPR, NBR_ADDR_TYPE, and GATEWAY Address Block TLV type extension registries, correcting omissions in RFC 7181 that left these ranges without explicit disposition.
For TLV types that do not define all type extensions, it is RECOMMENDED that the 'description' field for the allocated TLV type be set to 'Defined by Type Extension', and that the type extension registry be named 'Type XX Packet/Message/Address Block TLV Type Extensions' with XX replaced by the numerical TLV type value.
If a requested TLV type does not immediately define all corresponding type extensions, a common name SHOULD NOT be assigned for that TLV type. This prevents future extensions from bearing an inappropriate inherited name.
If a requested TLV type immediately defines (but not necessarily allocates) all corresponding type extensions, a common name SHOULD be assigned for the TLV type. This case is unchanged by RFC 7631 and includes TLV types named ICV, TIMESTAMP, and LINK_METRIC.
When a new type extension is required, unless there are reasons to the contrary, the next consecutive type extension SHOULD be allocated and given a name. Reasons to deviate MAY include maintaining correspondence between Packet, Message, and Address Block TLVs, or reserving type extension zero if not yet allocated.
A TLV has a one-octet type and a one-octet type extension that together form a two-octet full type. A TLV may omit the type extension in its representation when it is zero, but conceptually it still has type extension 0. Each TLV type defines an IANA registry of type extensions.
The 'Address Block TLV Types' registry is updated so that types 0-4, 8, 9, and 10 now bear the description 'Defined by Type Extension'. LINK_METRIC (type 7) retains its name as it covers all type extensions; ICV (type 5) and TIMESTAMP (type 6) are unchanged.
The 'CONT_SEQ_NUM Message Type Extensions' registry is renamed 'Type 8 Message TLV Type Extensions'. Extension 0 is named CONT_SEQ_NUM (COMPLETE) and extension 1 is CONT_SEQ_NUM (INCOMPLETE); extensions 2-223 are unassigned.
The 'GATEWAY Address Block TLV Type Extensions' registry is renamed 'Type 10 Address Block TLV Type Extensions'. Extension 0 retains GATEWAY (number of hops to reach a network address via a gateway on the originating router); 224-255 reserved for experimental use added by this document.
The 'INTERVAL_TIME Address Block TLV Type Extensions' registry is renamed 'Type 0 Address Block TLV Type Extensions'. Extension 0 retains INTERVAL_TIME; extensions 1-223 unassigned, 224-255 reserved for experimental use.
The 'INTERVAL_TIME Message Type Extensions' registry is renamed 'Type 0 Message TLV Type Extensions'. Type extension 0 retains the name INTERVAL_TIME; extensions 1-223 are unassigned and 224-255 reserved for experimental use (RFC 5497).
The 'LINK_STATUS Address Block TLV Type Extensions' registry is renamed 'Type 3 Address Block TLV Type Extensions'. Extension 0 retains LINK_STATUS (interpreted per the 'LINK_STATUS TLV Values' registry); extensions 1-223 unassigned.
The 'LOCAL_IF Address Block TLV Type Extensions' registry is renamed 'Type 2 Address Block TLV Type Extensions'. Extension 0 retains LOCAL_IF (interpreted per the 'LOCAL_IF TLV Values' registry); extensions 1-223 unassigned.
The 'Message TLV Types' registry is updated so that types 0, 1, 7, and 8 now bear the description 'Defined by Type Extension' rather than specific TLV names. ICV (type 5) and TIMESTAMP (type 6) retain their names; types 9-223 remain unassigned and 224-255 reserved for experimental use.
The 'MPR Address Block TLV Type Extensions' registry is renamed 'Type 8 Address Block TLV Type Extensions'. Extension 0 retains MPR (interpreted per 'MPR TLV Bit Values'); extensions 1-223 unassigned; 224-255 reserved for experimental use (reservation added by this document, previously omitted in RFC 7181).
The 'MPR_WILLING Message Type Extensions' registry is renamed 'Type 7 Message TLV Type Extensions'. Type extension 0 retains the name MPR_WILLING (bits 0-3 for flooding MPR willingness, bits 4-7 for routing MPR willingness); extensions 1-223 unassigned.
The 'NBR_ADDR_TYPE Address Block TLV Type Extensions' registry is renamed 'Type 9 Address Block TLV Type Extensions'. Extension 0 retains NBR_ADDR_TYPE (interpreted per 'NBR_ADDR_TYPE Address Block TLV Bit Values'); 224-255 reserved for experimental use added by this document.
The 'OTHER_NEIGHB Address Block TLV Type Extensions' registry is renamed 'Type 4 Address Block TLV Type Extensions'. Extension 0 retains OTHER_NEIGHB (interpreted per the 'OTHER_NEIGHB TLV Values' registry); extensions 1-223 unassigned.
The 'VALIDITY_TIME Address Block TLV Type Extensions' registry is renamed 'Type 1 Address Block TLV Type Extensions'. Extension 0 retains VALIDITY_TIME; extensions 1-223 unassigned, 224-255 reserved for experimental use.
The 'VALIDITY_TIME Message Type Extensions' registry is renamed 'Type 1 Message TLV Type Extensions'. Type extension 0 retains the name VALIDITY_TIME; extensions 1-223 are unassigned and 224-255 reserved for experimental use (RFC 5497).
RFC 7631 has no security considerations. The document is concerned only with how TLV types and type extensions are named in IANA registries and standards documents; these names have no bearing on protocol security.