Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
updated by
Extracted elements (31)
Address aggregation via Head:Mid:Tail decomposition was chosen because MANETs typically run over limited-capacity wireless links and are less tolerant of wasted octets; aggregating addresses with common prefixes or suffixes (e.g., IPv6 interface identifiers) significantly reduces per-packet overhead.
Message Header fields (<msg-orig-addr>, <msg-hop-limit>, <msg-hop-count>, <msg-seq-num>) are each optional and included only when flagged, keeping headers compact for protocols that do not need all features; multi-message packets further reduce overhead by amortizing transport, network, and lower-layer per-packet costs.
The Message Header is explicitly designed to contain sufficient information (originator address, hop limit, hop count, sequence number) to allow duplicate detection and scope-limited forwarding decisions without parsing the Message Body, enabling separation of forwarding logic from protocol-specific processing.
All addresses within a single message must be of the same length. When a message must carry both IPv4 and IPv6 addresses, IPv4 addresses SHOULD be represented as IPv4-mapped IPv6 addresses as defined in RFC 4291, so that all addresses share a uniform 16-octet length.
Any protocol using this specification MUST define the processing order for TLVs associated with a given entity, and MUST define appropriate behavior when two TLVs of the same type but with different values apply to the same entity.
If a malformed element is found in the Packet Header, the entire packet MUST be silently discarded; contained messages MUST NOT be processed and MUST NOT be forwarded.
If a malformed element is found within a message (in the Message TLV Block, an Address Block, or an Address Block TLV Block), that message MUST be silently discarded; it MUST NOT be processed and MUST NOT be forwarded.
Reserved bits in <pkt-flags>, <addr-flags>, and <tlv-flags> SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception.
The flag combinations (ahasfulltail=1, ahaszerotail=1), (ahassingleprelen=1, ahasmultiprelen=1), and (thassingleindex=1, thasmultiindex=1) MUST NOT be used, as they do not appear in the defined interpretation tables.
The multiplexing/demultiplexing process MUST designate exactly one protocol as the 'owner' of each Message Type; incoming messages MUST be either silently discarded or delivered to the owner protocol instance, and SHOULD NOT be delivered to any other protocol instance.
The <num-addr> field in an Address Block MUST NOT be zero.
The thassingleindex and thasmultiindex flags, and the tismultivalue flag, MUST each be cleared ('0') in Packet TLVs and Message TLVs; index-based and multi-value semantics apply only to Address Block TLVs.
When registering a Message Type, registries MUST be specified for both Message-Type-specific Message TLVs and Message-Type-specific Address Block TLVs, and the allocation mechanism for those type extensions MUST be specified.
When the tismultivalue flag is set, <length> MUST be an integral multiple of number-values (= index-stop - index-start + 1); the value field is then divided into number-values equal sub-fields each of length <length>/number-values.
A message consists of a Message Header, a Message TLV Block, and zero or more (Address Block, Address Block TLV Block) pairs. All addresses within a single message share the same address length, specified by <msg-addr-length>.
A packet contains a mandatory Packet Header followed by zero or more messages. Packet length is determined by the encapsulating datagram; no explicit packet-length field is carried. A packet with zero messages is permitted when the only information is in the Packet Header TLVs.
Addresses in an Address Block are decomposed into a shared Head, individual Mid portions, and a shared Tail (Head:Mid:Tail). This allows compact aggregation of addresses sharing common prefixes or suffixes, such as IPv6 addresses on the same interface.
The TLV full type is computed as tlv-fulltype = 256 * <tlv-type> + tlv-type-ext, providing a 16-bit effective type space while keeping the base type in an 8-bit field and the optional extension in a separate 8-bit field.
Three distinct TLV kinds exist: Packet TLVs (carried in the Packet Header TLV Block), Message TLVs (carried in the per-message TLV Block before any Address Blocks), and Address Block TLVs (carried in the TLV Block following an Address Block). Index fields in Address Block TLVs select which subset of addresses the TLV applies to.
A new Message-Type-independent Address Block TLV Types registry is created: values 0–127 via Expert Review, values 128–223 reserved for Message-Type-specific use, and values 224–255 for Experimental Use. Each registered type requires its own type-extension registry.
A new Message-Type-independent Message TLV Types registry is created: values 0–127 via Expert Review, values 128–223 reserved for Message-Type-specific use (populated per Message Type registration), and values 224–255 for Experimental Use.
A new Message Types registry is created with values 0–223 assigned via Expert Review and values 224–255 reserved for Experimental Use. Registration of a Message Type triggers creation of two additional Message-Type-specific TLV registries.
A new Packet TLV Types registry is created with values 0–223 assigned via Expert Review and values 224–255 reserved for Experimental Use. Each registered Packet TLV Type additionally requires a new registry for its type extensions.
Confidentiality is not directly provided by this specification; when required it should be provided hop-by-hop via link-layer or IPsec mechanisms. However, a protocol MAY encrypt individual TLV Value fields, or wrap entire encrypted messages inside a single Packet TLV or Message TLV, defining the encrypted type and format.
End-to-end authentication and integrity for forwarded messages MAY be implemented by including a Message TLV carrying a cryptographic signature. The signature is computed over the entire message with <msg-hop-count> and <msg-hop-limit> set to 0, since those are the only fields legitimately modified during forwarding.
Hop-by-hop packet-level authentication and integrity MAY be implemented by including a Packet TLV carrying a cryptographic signature computed over the entire packet or appropriate parts, since packets are received as transmitted (not modified in transit).
A TLV block (<tlv-block>) begins with a 16-bit <tlvs-length> field containing the total octet count of all immediately following <tlv> elements, followed by zero or more <tlv> elements.
A TLV (<tlv>) encodes an 8-bit <tlv-type>, an 8-bit <tlv-flags>, an optional 8-bit <tlv-type-ext>, optional 8-bit <index-start> and <index-stop> fields, and an optional <length> field that is 8 bits when thasextlen is clear or 16 bits when set, followed by a <value> field of <length> octets when thasvalue is set.
An address block (<address-block>) encodes an 8-bit <num-addr>, an 8-bit <addr-flags>, optional <head-length>/<head>, optional <tail-length>/<tail>, zero or more <mid> fields (each mid-length = address-length - head-length - tail-length octets), and zero or more 8-bit <prefix-length> fields as governed by the ahassingleprelen and ahasmultiprelen flags.
The message header (<msg-header>) consists of an 8-bit <msg-type>, a 4-bit <msg-flags>, a 4-bit <msg-addr-length> (address length in octets minus 1), a 16-bit <msg-size>, followed by optional <msg-orig-addr>, 8-bit <msg-hop-limit>, 8-bit <msg-hop-count>, and 16-bit <msg-seq-num> fields, each present only when the corresponding flag bit is set.
The packet header (<pkt-header>) consists of a 4-bit <version> field (value 0 for this spec), a 4-bit <pkt-flags> field, an optional 16-bit <pkt-seq-num> (present when phasseqnum flag is set), and an optional <tlv-block> (present when phastlv flag is set). Network byte order is used throughout.