Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs
BAE Systems Advanced Technology Centre
West Hanningfield Road
Great Baddow, Chelmsford
United Kingdom
+44 1245 242194
chris.dearlove@baesystems.com
http://www.baesystems.com/
LIX, Ecole Polytechnique
+33 6 6058 9349
T.Clausen@computer.org
http://www.ThomasClausen.org/
Mobile Ad hoc Networking (MANET)
MANET
OLSRv2
NHDP
TLV
This specification describes extensions to definitions of TLVs used by the
Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET
Neighborhood Discovery Protocol (NHDP) to increase their abilities to
accommodate protocol extensions. This document updates RFC 7181 (OLSRv2) and
RFC 6130 (NHDP).
The MANET Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2
(OLSRv2) are protocols for use in Mobile Ad Hoc
Networks (MANETs) , based on the Generalized MANET
Packet/Message Format .
This document updates and , specifically their use of TLV (Type-Length-Value) elements,
to increase the extensibility of these protocols and to enable some
improvements in their implementation.
This specification reduces the latitude of implementations of
and to consider some
messages, which will not be
created by implementations simply following those specifications, as
a reason to consider the message as "badly formed", and thus as a
reason to reject the message. This gives greater latitude to the
creation of extensions of these protocols, in particular extensions
that will interoperate with unextended implementations of those
protocols. As part of that, it indicates how TLVs with
unexpected value fields must be handled, and adds some additional
options to those TLVs.
Note that TLVs with unknown type or type extension are already
specified as to be ignored by and and also are not a reason to reject a message.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
.
Additionally, this document uses the terminology of
, , and
.
This document updates the specification of the protocols described in and .
Specifically, this specification updates and in the following ways:
Removes the latitude of rejecting a message
with a TLV with a known type, but with an unexpected TLV Value field, for the
TLV Types defined in and .
Specifies the handling of a TLV Value field
with unexpected length.
Sets up IANA registries for TLV Values for the
Address Block TLVs:
LOCAL_IF, defined in .
LINK_STATUS, defined in .
OTHER_NEIGHB, defined in .
MPR, defined in , now considered as a bit field.
NBR_ADDR_TYPE, defined
in , now considered as a bit field.
Defines a well-known TLV Value for
"UNSPECIFIED" for the Address Block TLV Types LOCAL_IF, LINK_STATUS, and
OTHER_NEIGHB, all defined in .
NHDP and OLSRv2 define a number of TLVs within the framework of .
These TLVs define the meaning of only some of the contents that
can be found in a TLV Value field. This limitation may be either defining only
certain TLV Values or considering only some lengths of the TLV Value fields (or
a single-value field in a multivalue Address-Block TLV).
This specification describes how NHDP
and OLSRv2 are to handle TLVs with other TLV Value
fields.
NHDP and OLSRv2 specify that, in addition to
well-defined reasons (in the respective protocol specifications), an
implementation of these protocols MAY recognize a message as "badly formed" and
therefore "invalid for processing" for other reasons (Section 12.1 of and Section 16.3.1 of ). These
sections could be interpreted as allowing rejection of a message because a TLV
Value field is unrecognized. This specification removes that latitude:
An implementation MUST NOT reject a
message because it contains an unrecognized TLV value. Instead, any
unrecognized TLV Value field MUST be processed or ignored by an unextended
implementation of NHDP or OLSRv2, as described in the following sections.
Hence, this specification
removes the 7th, 10th, and 11th bullets in Section 12.1 of .
It should be stressed that this is not a change to or , except with regard to not
allowing this to be a reason for rejection of a message. or are specified in terms such as
"if an address is associated with a value of LOST by a LINK_STATUS
TLV". Association with an unrecognized value has no effect on any
implementation strictly following such a specification.
The TLVs specified in and
may be either single-value or multivalue TLVs. In
either case, the length of each item of information encoded in the TLV Value
field is the "single-length", defined and calculated as in Section 5.4.1 of
. All TLVs specified in and
have a one- or two-octet single-length. These are
considered the expected single-lengths of such a received TLV.
Other single-length TLV Value fields may be introduced
by extensions to and . This
document specifies how implementations of and , or extensions thereof, MUST behave on receiving TLVs of the
TLV types defined in and , but
with TLV Value fields with other single-length values.
The following principles apply:
If the received single-length is
greater than the expected single-length, then the excess octets MUST be
ignored.
If the received single-length is less than the expected single-length, then the absent octets MUST be considered to have all bits
cleared (0).
Exception:
A received CONT_SEQ_NUM with a
single-length < 2 SHOULD be considered an error.
and
define a number of TLVs, but for some of these TLVs they specify meanings for
only some TLV Values. This document establishes IANA registries for these TLV
Values, with initial registrations reflecting those used by and , and as specified in .
There are different cases of TLV Values with different
characteristics. These cases are considered in this section.
For the Address-Block TLVs LOCAL_IF,
LINK_STATUS, and OTHER_NEIGHB TLVs, defined in , only a
limited number of values are specified for each. These are converted, by this
specification, into extensible registries with initial registrations for values
defined and used by -- see .
An implementation of
that receives a LOCAL_IF, LINK_STATUS, or OTHER_NEIGHB TLV with any TLV Value
other than the values that are defined in MUST ignore
that TLV Value, as well as any corresponding attribute association to the
address.
The Address-Block TLVs MPR and NBR_ADDR_TYPE, defined in ,
are similar to those defined in in having only limited
values specified (1, 2, and 3): 1 and 2 represent the presence of
two different attributes associated to an address, and 3 represents
"both 1 and 2".
These TLV Value fields are, by this
specification, converted to bit fields and MUST be interpreted as such. As the
existing definitions of values 1, 2, and 3 behave in that manner, it is likely
that this will involve no change to an implementation, but any test of (for
example) Value = 1 or Value = 3 MUST be converted to a test of (for example)
Value bitand 1 = 1, where "bitand" denotes a bitwise AND operation.
This specification creates registries for recording
reservations of the individual bits in these bit fields, with initial
registrations for values defined and used by -- see
.
Other TLVs defined by are not
affected by this specification.
The registries defined in Section 5 for the LOCAL_IF,
LINK_STATUS, and OTHER_NEIGHB TLVs each include an additional TLV Value
UNSPECIFIED.
This TLV Value represents a defined value that, like currently
undefined TLV Values, indicates that no information is associated
with this address; the defined value will always have this
meaning.
Such a TLV Value may be used to enable the creation
of more efficient multivalue Address Block TLVs or to simplify an
implementation.
The similar requirement for the MPR and
NBR_ADDR_TYPES TLVs is already satisfied by the TLV Value zero, provided that
each bit in the TLV Value is defined as set ('1') when indicating the presence
of an attribute, or clear ('0') when indicating the absence of an
attribute. Therefore, this is required for registrations from the relevant
registries; see .
For the LINK_METRIC TLV, this is already
possible by clearing the most significant bits (0 to 3) of the first octet of
the TLV Value. It is RECOMMENDED that in this case the remaining bits of the
TLV Value are either all clear ('0') or all set ('1').
IANA has completed the ten actions set out in the
following sections.
IANA has created a new sub-registry
called "LOCAL_IF TLV Values" within the "Mobile Ad hoc
NETwork (MANET) Parameters" registry.
IANA has populated this registry as specified in .
Value
Name
Description
Reference
0
THIS_IF
The network address is associated with this local interface of the sending router
RFC 7188
1
OTHER_IF
The network address is associated with another local interface of the sending router
RFC 7188
2-223
Unassigned
224-254
Reserved for Experimental Use
RFC 7188
255
UNSPECIFIED
No information about this network address is provided
RFC 7188
New assignments are to be made by Expert Review .
The Designated Experts are required to use the
guidelines specified in and .
IANA maintains a sub-registry called "LOCAL_IF Address Block
TLV Type Extensions" within the "Mobile Ad hoc
NETwork (MANET) Parameters" registry. This sub-registry already had an entry for value 0.
IANA has replaced the entry in the Description column for this value with the
text "This value is to be interpreted according to the registry LOCAL_IF TLV
Values". The resulting table is as specified in .
Type Extension
Description
Reference
0
This value is to be interpreted according to the registry LOCAL_IF TLV Values
RFC 6130, RFC 7188
1-255
Unassigned
IANA has created a new sub-registry called
"LINK_STATUS TLV Values" within the "Mobile Ad hoc
NETwork (MANET) Parameters" registry.
IANA has populated this registry as specified in .
Value
Name
Description
Reference
0
LOST
The link on this interface from the router
with that network address has been lost
RFC 7188
1
SYMMETRIC
The link on this interface from the router
with that network address has the status of symmetric
RFC 7188
2
HEARD
The link on this interface from the router
with that network address has the status of heard
RFC 7188
3-223
Unassigned
224-254
Reserved for Experimental Use
RFC 7188
255
UNSPECIFIED
No information about this network address is provided
RFC 7188
New assignments are to be made by Expert Review .
The Designated Experts are required to use the
guidelines specified in and .
IANA maintains a sub-registry called "LINK_STATUS Address
Block TLV Type Extensions" within the "Mobile Ad hoc
NETwork (MANET) Parameters" registry. This sub-registry already had an entry for value
0. IANA has replaced the entry in the Description column for this value with
the text "This value is to be interpreted according to the registry LINK_STATUS
TLV Values". The resulting table is as specified in .
Type Extension
Description
Reference
0
This value is to be interpreted according to the registry LINK_STATUS TLV Values
RFC 6130, RFC 7188
1-255
Unassigned
IANA has created a new sub-registry called
"OTHER_NEIGHB TLV Values" within the "Mobile Ad hoc NETwork (MANET)
Parameters" registry.
IANA has populated this registry as specified in .
Value
Name
Description
Reference
0
LOST
The neighbor relationship with the router with that network address has been lost
RFC 7188
1
SYMMETRIC
The neighbor relationship with the router with that network address is symmetric
RFC 7188
2-223
Unassigned
224-254
Reserved for Experimental Use
RFC 7188
255
UNSPECIFIED
No information about this network address is provided
RFC 7188
New assignments are to be made by Expert Review .
The Designated Experts are required to use the
guidelines specified in and .
IANA maintains a sub-registry called "OTHER_NEIGHB Address
Block TLV Type Extensions" within the "Mobile Ad hoc
NETwork (MANET) Parameters" registry. This sub-registry already had an entry for value
0. IANA has replaced the entry in the Description column for this value with
the text "This value is to be interpreted according to the registry OTHER_NEIGHB
TLV Values". The resulting table is as specified in .
Type Extension
Description
Reference
0
This value is to be interpreted according to the registry OTHER_NEIGHB TLV Values
RFC 6130, RFC 7188
1-255
Unassigned
IANA has created a new sub-registry called "MPR
TLV Bit Values" within the "Mobile Ad hoc NETwork (MANET) Parameters"
registry.
IANA has populated this registry as specified in .
Bit
Value
Name
Description
Reference
7
0x01
Flooding
The neighbor with that network address has been selected as flooding MPR
RFC 7188
6
0x02
Routing
The neighbor with that network address has been selected as routing MPR
RFC 7188
0-5
Unassigned
New assignments are to be made by Expert Review .
The Designated Experts are required to use the
guidelines specified in and .
Additionally, the Designated Experts are required to ensure that the following
sense is preserved:
For each bit in the field, a
set bit (1) means that the address has the designated property, while an unset
bit (0) means that no information about the designated property is provided. In
particular, an unset bit must not be used to convey any specific information
about the designated property.
IANA maintains a sub-registry called "MPR Address Block TLV
Type Extensions" within the "Mobile Ad hoc
NETwork (MANET) Parameters" registry. This sub-registry already had an entry
for value 0. IANA has replaced the entry in the Description column for this
value with the text "This value is to be interpreted according to the registry
MPR TLV Bit Values". The resulting table is as specified in
.
Type Extension
Description
Reference
0
This value is to be interpreted according to the registry MPR TLV Bit Values
RFC 7181, RFC 7188
1-255
Unassigned
IANA has created a new sub-registry called "NBR_ADDR_TYPE Address Block TLV Bit
Values" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
IANA has populated this registry as specified in
.
Bit
Value
Name
Description
Reference
7
0x01
ORIGINATOR
The network address is an originator address
reachable via the originating router
RFC 7188
6
0x02
ROUTABLE
The network address is a routable address
reachable via the originating router
RFC 7188
0-5
Unassigned
New assignments are to be made by Expert Review .
The Designated Experts are required to use the guidelines specified in and . Additionally, the Designated Experts are required to ensure that the following sense is preserved:
For each bit in the field, a set bit (1) means that the address has the designated property, while an unset bit (0) means that no information about the designated property is provided.
In particular, an unset bit must not be used to convey any specific information about the designated property.
IANA maintains a sub-registry called "NBR_ADDR_TYPE Address
Block TLV Type Extensions" within the "Mobile Ad hoc
NETwork (MANET) Parameters" registry. This sub-registry already had an entry for value
0. IANA has replaced the entry in the Description column for this value with
the text "This value is to be interpreted according to the registry
NBR_ADDR_TYPE TLV Bit Values". The resulting table is as specified in .
Type Extension
Description
Reference
0
This value is to be interpreted
according to the registry NBR_ADDR_TYPE Address Block TLV Bit Values
RFC 7181, RFC 7188
1-255
Unassigned
The updates made to and have the following implications on the security considerations:
Created IANA registries for retaining TLV values for TLVs, already defined in the already published specifications of the two protocols, and with initial registrations for the TLV values defined by these specifications. This does not give rise to any additional security considerations.
Enabled protocol extensions for registering TLV values in the created IANA registries. Such extensions MUST specify appropriate security considerations.
Created, in some registries, a registration for "UNSPECIFIED" values for more efficient use of multivalue Address Block TLVs. The interpretation of an address being associated with a TLV of a given type and with the value "UNSPECIFIED" is identical to that address not being associated with a TLV of that type. Thus, this update does not give rise to any additional security considerations.
Reduced the latitude of implementations of the two protocols to reject a message as "badly formed" due to the value field of a TLV being unexpected. These protocols are specified in terms such as "if an address is associated with a value of LOST by a LINK_STATUS TLV". Association with an unknown value (or a value newly defined to mean no link status information) has no effect on such a specification. Thus, this update does not give rise to any additional security considerations.
Did not introduce any opportunities for attacks on the protocols through signal modification that are not already present in the two protocols.
The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews, and comments on the specification (listed alphabetically): Ulrich Herberg (Fujitsu Laboratories of America) and Henning Rogge (Frauenhofer FKIE).
The authors would also like to express their gratitude to Adrian Farrel
for his assistance and contributions to the successful and timely completion of this specification.
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
Generalized MANET Packet/Message Format
Ecole Polytechnique, France
BAE Systems Advanced Technology Centre, UK
Naval Research Laboratory, USA
INRIA Rocquencourt
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
Ecole Polytechnique, France
Naval Research Laboratory, USA
BAE Systems Advanced Technology Centre, UK
The Optimized Link State Routing Protocol Version 2
Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations
Naval Research Laboratory
University of Maryland
Guidelines for Writing an IANA Considerations Section in RFCs