This section concerns the properties of the format defined in
[RFC5444] itself, rather than the properties of protocols using it.
The elements defined in [RFC5444] have structures that are managed by
a number of flags fields:
o Packet flags field (4 bits, 2 used) that manages the contents of
the Packet Header.
o Message flags field (4 bits, 4 used) that manages the contents of
the Message Header.
o Address Block flags field (8 bits, 4 used) that manages the
contents of an Address Block.
o TLV flags field (8 bits, 5 used) that manages the contents of a
Note that all of these flags are structural; they specify which
elements are present or absent, field lengths, or whether a field has
one or multiple values in it.
In the current version of [RFC5444], indicated by version number 0 in
the <version> field of the Packet Header, unused bits in these flags
fields are stated as "are RESERVED and SHOULD each be cleared ('0')
on transmission and SHOULD be ignored on reception". For the
avoidance of any compatibility issues, with regard to version number
0, this is updated to "MUST each be cleared ('0') on transmission and
MUST be ignored on reception".
If a specification updating [RFC5444] introduces new flags in one of
the flags fields of a packet, Address Block, or TLV (there being no
unused flags in the message flags field), the following rules MUST be
o The version number contained in the <version> field of the Packet
Header MUST NOT be 0.
o The new flag(s) MUST indicate the structure of the corresponding
packet, Address Block, or TLV. They MUST NOT be used to indicate
any other semantics, such as message forwarding behavior.
An update that would be incompatible with the current specification
of [RFC5444] SHOULD NOT be created unless there is a pressing reason
for it that cannot be satisfied using the current specification
(e.g., by use of a suitable Message TLV or Address Block TLV).
During the development of [RFC5444] (and since publication thereof),
some proposals have been made to use these RESERVED flags to specify
behavior rather than structure, message forwarding in particular.
These proposals were, after due consideration, not accepted for a
number of reasons. These reasons include that message forwarding, in
particular, is protocol specific; for example, [RFC7181] forwards
messages using its MPR mechanism rather than a "blind" flooding
mechanism. (These proposals were made during the development of
[RFC5444] when there were still unused message flags. Later addition
of a 4-bit Message Address Length field later left no unused message
flags, but other flags fields still have unused flags.)
6. Message Efficiency
The ability to organize addresses into the same or different Address
Blocks and to change the order of addresses within an Address Block
(as well as the flexibility of the TLV specification) enables
avoiding unnecessary repetition of information and can consequently
generate smaller messages. There are no algorithms for address
organization, compression, or for TLV usage in [RFC5444]; any
algorithms that leave the information content unchanged MAY be used
when generating a message. See also Appendix B.
6.1. Address Block Compression
[RFC5444] allows the addresses in an Address Block to be compressed.
A protocol generating a message SHOULD compress addresses as much as
Addresses in an Address Block consist of a Head, a Mid, and a Tail,
where all addresses in an Address Block have the same Head and Tail
but different Mids. Each has a length that is greater than or equal
to zero, the sum of the lengths being the address length. (The Mid
length is deduced from this relationship.) Compression is possible
when the Head and/or the Tail have non-zero length. An additional
compression is possible when the Tail consists of all zero-valued
octets. Expected use cases include IPv4 and IPv6 addresses from
within the same prefix and that therefore have a common Head, IPv4
subnets with a common zero-valued Tail, and IPv6 addresses with a
common Tail representing an interface identifier as well as having a
possible common Head. Note that when, for example, IPv4 addresses
have a common Head, their Tail will usually have length zero.
o The IPv4 addresses 192.0.2.1 and 192.0.2.2 would, for greatest
efficiency, have a 3-octet Head, a 1-octet Mid, and a 0-octet
o The IPv6 addresses 2001:DB8:prefix1:interface and
2001:DB8:prefix2:interface that use the same interface identifier
but completely different prefixes (except as noted) would, for
greatest efficiency, have a 4-octet head, a 4-octet Mid, and an
8-octet Tail. (They could have a larger Head and/or Tail and a
smaller Mid if the prefixes have any octets in common.)
Putting addresses into a message efficiently also requires
consideration of the following:
o The split of the addresses into Address Blocks.
o The order of the addresses within the Address Blocks.
This split and/or ordering is for efficiency only; it does not
provide any information. The split of the addresses affects both the
address compression and the TLV efficiency (see Section 6.2); the
order of the addresses within an Address Block affects only the TLV
efficiency. However, using more Address Blocks than needed can
increase the message size due to the overhead of each Address Block
and the following TLV Block, and/or if additional TLVs are now
The order of addresses can be as simple as sorting the addresses, but
if many addresses have the same TLV Types attached, it might be more
useful to put these addresses together, either within the same
Address Block as other addresses or in a separate Address Block. A
separate Address Block might also improve address compression, for
example, if more than one address form is used (such as from
independent subnets). An example of the possible use of address
ordering is a HELLO message from [RFC6130] that could be generated
with local interface addresses first and neighbor addresses later.
These could be in separate Address Blocks.
When considering TLVs, the main opportunities for creating more
efficient messages are in Address Block TLVs rather than Message
TLVs. The approaches described here apply to each Address Block.
An Address Block TLV provides attributes for one address or a
contiguous (as stored in the Address Block) set of addresses (with a
special case for when this set is of all of the addresses in the
Address Block). When associated with more than one address, a TLV
can be single value (associating the same attribute with each
address) or multivalue (associating a separate attribute with each
The approach that is simplest to implement is to use multivalue TLVs
that cover all affected addresses. However, unless care is taken to
order addresses appropriately, these affected addresses might not all
be contiguous. Some approaches to this are the following:
o Reorder the addresses. It is, for example, possible (though not
straightforward, and beyond the scope of this document to describe
exactly how) to order all addresses in HELLO message as specified
in [RFC6130] so that all TLVs used only cover contiguous
addresses. This is even possible if the MPR TLV specified in
OLSRv2 [RFC7181] is added; but it is not possible, in general, if
the LINK_METRIC TLV specified in OLSRv2 [RFC7181] is also added.
o Allow the TLV to span over addresses that do not need the
corresponding attribute and use a Value that indicates no
information; see Section 6.3.
o Use more than one TLV. Note that this can be efficient when the
TLVs become single-value TLVs. In a typical case where a
LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with
enough addresses sorted appropriately, two single-value TLVs can
be more efficient than one multivalue TLV. If only one Value is
involved (such as NHDP in a steady state with LINK_STATUS equal to
SYMMETRIC in all cases) then one single-value TLV SHOULD always be
6.3. TLV Values
If, for example, an Address Block contains five addresses, the first
two and the last two requiring Values assigned using a LINK_STATUS
TLV but the third does not, then this can be indicated using two
TLVs. It is, however, more efficient to do this with one multivalue
LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED
(as defined in [RFC7188]). In general, use of UNSPECIFIED Values
allows use of fewer TLVs and is thus often an efficiency gain;
however, a long run of consecutive UNSPECIFIED Values (more than the
overhead of a TLV) can make use of more TLVs more efficient.
Some other TLVs might need a different approach. As noted in
[RFC7188], but implicitly permissible before then, the LINK_METRIC
TLV (defined in [RFC7181]) has two octet Values whose first four bits
are flags indicating whether the metric applies in four cases; if
these are all zero, then the metric does not apply in this case,
which is thus the equivalent of an UNSPECIFIED Value.
[RFC7188] requires that protocols that extend [RFC6130] and [RFC7181]
allow unspecified values in TLVs where applicable; it is here
RECOMMENDED that all protocols follow that advice. In particular, it
is RECOMMENDED that when defining an Address Block TLV with discrete
Values, an UNSPECIFIED Value is defined with the same value (255),
and a modified approach should be used where possible for other
Address Block TLVs (for example, as is done for a LINK_METRIC TLV,
though not necessarily using that exact approach).
It might be argued that provision of an unspecified value (of any
form) to allow an Address Block TLV to cover unaffected addresses is
not always necessary because addresses can be reordered to avoid
this. However, ordering addresses to avoid this for all TLVs that
might be used is not, in general, possible.
In addition, [RFC7188] recommends that if a TLV Value (per address
for an Address Block TLV) has a single-length that does not match the
defined length for that TLV Type, then the following rules are
o If the received single-length is greater than the expected single
length, then the excess octets MUST be ignored.
o If the received single-length is less than the expected single
length, then the absent octets MUST be considered to have all bits
This specification RECOMMENDS a similar rule for all protocols
defining new TLVs.
7. Security Considerations
This document does not specify a protocol but provides rules and
recommendations for how to design protocols using [RFC5444], whose
security considerations apply.
If the recommendation from Section 4.4.1 is followed, which specifies
that messages are not modified (except for hop count and hop limit)
when forwarded, then the security framework for [RFC5444] (specified
in [RFC7182]) can be used in full. If that recommendation is not
followed, then the Packet TLVs from [RFC7182] can be used, but the
Message TLVs from [RFC7182] cannot be used as intended.
In either case, a protocol using [RFC5444] MUST document whether it
is using [RFC7182] and if so, how.
8. IANA Considerations
The Expert Review guidelines in [RFC5444] are updated to include the
general requirement that:
o The Designated Expert will consider the limited TLV and
(especially) Message Type space when considering whether a
requested allocation is allowed and whether a more efficient
allocation than that requested is possible.
IANA has added this document as a reference for the following Mobile
Ad hoc NETwork (MANET) Parameters registries:
o Message Types
o Packet TLV Types
o Message TLV Types
o Address Block TLV Types
Appendix A. Information Representation
This section describes a conceptual way to consider the information
in a message. It can be used as the basis of an approach to parsing
a message from the information that it contains and to creating a
message from the information that it is to contain. However, there
is no requirement that a protocol does so. This approach can be used
either to inform a protocol design or by a protocol (or generic
A message (excluding the Message Header) can be represented by two,
possibly multivalued, maps:
o Message: (Full Type) -> (length, Value)
o Address: (address, Full Type) -> (length, Value)
These maps (plus a representation of the Message Header) can be the
basis for a generic representation of information in a message. Such
maps can be created by parsing the message or can be constructed
using the protocol rules for creating a message and later converted
into the octet form of the message specified in [RFC5444].
While of course any implementation of software that represents
software in the above form can specify an Application Programming
Interface (API) for that software, such an interface is not proposed
here. First, a full API would be specific to a programming language.
Second, even within the above framework, there are alternative
approaches to such an interface. For example, and for illustrative
purposes only, consider the alternative address mappings:
o Input: address and Full Type. Output: list of (length, Value)
pairs. Note that for most Full Types, it will be known in advance
that this list will have a length of zero or one. The list of
addresses that can be used as inputs with non-empty output would
need to be provided as a separate output.
o Input: Full Type. Output: list of (address, length, Value)
triples. As this list length can be significant, a possible
output will be of one or two iterators that will allow iterating
through that list. (One iterator that can detect the end of the
list or a pair of iterators specifying a range.)
Additional differences in the interface might relate to, for example,
the ordering of output lists.
Appendix B. Automation
There is scope for creating a protocol-independent optimizer for
[RFC5444] messages that performs appropriate address re-organization
(ordering and Address Block separation) and TLV changes (of number,
of being single value or multivalue, and use of unspecified values)
to create more compact messages. The possible gain depends on the
efficiency of the original message creation and the specific details
of the message. Note that this process cannot be TLV Type
independent; for example, a LINK_METRIC TLV has a more complicated
Value structure than a LINK_STATUS TLV does if using UNSPECIFIED
Such a protocol-independent optimizer MAY be used by the router
generating a message but MUST NOT be used on a message that is
forwarded unchanged by a router.
The authors thank Cedric Adjih (INRIA) and Justin Dean (NRL) for
their contributions as authors of RFC 5444.