Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444
updates
- rfc-5444 — Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
Extracted elements (31)
Addresses MUST NOT convey meaning through their presence, absence, or ordering because doing so would reduce extensibility, prevent generic information representation, and reduce message optimization options. Assigning meaning to address presence would, for example, make it impossible to add a 'blacklist' extension to NHDP that an unmodified implementation could safely ignore.
Defining an UNSPECIFIED Value (value 255) for Address Block TLVs with discrete values is recommended to allow a single multivalue TLV to span addresses that don't need the attribute, reducing the total number of TLVs needed and producing smaller messages.
Message TLVs specific to a message type SHOULD use Message-Type-specific TLV Types (128–233) rather than Message-Type-independent types (0–127) to preserve the global TLV namespace and enable efficient allocation.
RESERVED flags in RFC 5444 flags fields were proposed during development to specify forwarding behavior, but were rejected because message forwarding is protocol-specific (e.g., OLSRv2 uses MPR-based forwarding rather than blind flooding), so structural flags must remain purely structural.
The multiplexer was designed to allow multiple protocols (e.g., NHDP and OLSRv2) to share the same IP protocol and UDP port, which became necessary when RFC 6130 was separated from RFC 7181 as distinct protocols while only a single MANET port allocation was made.
A protocol-independent message optimizer MAY be used by the generating router but MUST NOT be applied to messages that are forwarded unchanged, because reordering or restructuring a forwarded message would break end-to-end authentication mechanisms such as RFC 7182 ICV TLVs.
A message MUST be recognized as previously seen by the combination of its Message Type, Originator Address, and Message Sequence Number.
A protocol defining new TLVs MUST respect the naming and organizational rules in RFC 7631.
A protocol MUST NOT assign any meaning to the presence, absence, or ordering of addresses in an Address Block, or to the division of addresses among Address Blocks; information about address meaning MUST only be carried using Address Block TLVs.
A protocol MUST NOT reject a message based on unrecognized TLV types or unrecognized TLV values; it MUST ignore such TLVs or values when processing, and MUST NOT remove or change them if the message is forwarded unchanged.
A protocol MUST recognize any permitted representation of TLV information; even if it only generates multivalue TLVs, it MUST recognize single-value TLVs and vice versa.
A protocol using RFC 5444 MUST document whether it uses RFC 7182 for message integrity, and if so, how.
Addresses SHOULD be recorded in Address Blocks, not as data in TLV Value fields, because recording addresses in TLV Values breaks the address-attribute model and inhibits address compression.
All interoperable protocols running on MANET IANA allocations MUST conform to RFC 5444, and the multiplexing process described in RFC 5444 Appendix A is mandated for use on the MANET UDP port and IP protocol numbers.
If a received TLV single-length is greater than the expected length, excess octets MUST be ignored; if less, absent octets MUST be considered to have all bits cleared (0).
If a specification updating RFC 5444 introduces new flags, the <version> field in the Packet Header MUST NOT be 0, and new flags MUST indicate packet/Address Block/TLV structure only and MUST NOT be used for other semantics such as message forwarding behavior.
If requested by a protocol, the multiplexer MUST include a Packet Sequence Number, the sequence number MUST be specific to the interface, and separate sequence numbers MUST be maintained for each destination. Addition of Packet Sequence Numbers MUST be consistent for each interface and destination.
In RFC 5444 version 0, unused bits in flags fields MUST each be cleared ('0') on transmission and MUST be ignored on reception. This updates RFC 5444's previous SHOULD language.
Protocols SHOULD be conservative in the number of new Message Types required, as only 224 Message Types are allocatable; protocol design SHOULD consider whether different functions can share a Message Type differentiated by TLVs.
The demultiplexer MUST NOT reject a packet based on an unrecognized message type; it MUST still deliver any recognized messages in the packet to their owning protocols.
The demultiplexer MUST remove any Message TLVs added by an extension to the multiplexer, and the message MUST be passed to the protocol exactly as received from another protocol instance.
The demultiplexer MUST verify the Packet Header and message organization, MUST send each message to its owning protocol or discard it if the Message Type is unrecognized, and MUST make available the Packet Header and source/destination addresses to the protocol.
The multiplexer MUST respect any protocol-requested constraints on message delays if practical to do so, and MAY delay messages to assemble more efficient packets.
The owning protocol MUST indicate which interface(s) outgoing messages are to be sent on and their destination address when passing messages to the multiplexer.
The owning protocol MUST verify each message for correctness, MUST allow extending protocols to contribute to verification, MUST process each message, and MUST manage hop count and/or hop limit in the message.
A message is identified by its owning protocol — the one that made the IANA reservation for that Message Type. The demultiplexer inspects Message Type in each received message and delivers it to the corresponding owning protocol.
The Full Type of a TLV is the 16-bit combination of TLV Type and Type Extension (<tlv-fulltype>). This document assigns 'Full Type' as standard terminology not present in RFC 5444.
The RFC 5444 multiplexer accepts messages from MANET protocols (with interface and destination), collects them into packets for single-hop transmission using the MANET UDP port or IP protocol, and on reception extracts messages and delivers them to owning protocols by Message Type.
RFC 8245 is added as a reference for four MANET Parameters registries: Message Types, Packet TLV Types, Message TLV Types, and Address Block TLV Types. The Expert Review guidelines are updated to require consideration of the limited TLV and Message Type space when evaluating allocation requests.
If messages are not modified (except hop count and hop limit) when forwarded — as strongly recommended — the RFC 7182 security framework can be used in full for both Packet TLVs and Message TLVs. If messages are modified during forwarding, Message TLVs from RFC 7182 cannot be used as intended.
Address Blocks compress addresses using a Head (common prefix), Mid (unique per address), and Tail (common suffix), each with a length ≥ 0 summing to the full address length; zero-valued Tails receive additional compression.