RFC 7188 PROPOSED STANDARD ROUTING · MANET · EXTENSIBILITY
OLSRv2 and NHDP TLVs: Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs
Rules that let OLSRv2 and NHDP routers shrug off unfamiliar TLV values, so the protocols can be extended safely.
RFC EDITOR
Dearlove, C. and T. Clausen, "Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs", RFC 7188, DOI 10.17487/RFC7188, April 2014, <https://www.rfc-editor.org/info/rfc7188>.
BIBTEX
@misc{rfc7188,
series = {Request for Comments},
number = 7188,
howpublished = {RFC 7188},
publisher = {RFC Editor},
doi = {10.17487/RFC7188},
url = {https://www.rfc-editor.org/info/rfc7188},
author = {C. Dearlove and T. Clausen},
title = {{Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs}},
pagetotal = 16,
year = 2014,
month = apr,
} LINEAGE · FROM THE RFC INDEXOpen full graph →
RFC text
Contents
Internet Engineering Task Force (IETF) C. Dearlove
Request for Comments: 7188 BAE Systems ATC
Updates: 6130, 7181 T. Clausen
Category: Standards Track LIX, Ecole Polytechnique
ISSN: 2070-1721 April 2014
Optimized Link State Routing Protocol Version 2 (OLSRv2) and
MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs
Abstract
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).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7188.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
4. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Unrecognized TLV Values . . . . . . . . . . . . . . . . . 4
4.2. TLV Value Lengths . . . . . . . . . . . . . . . . . . . . 5
4.3. Undefined TLV Values . . . . . . . . . . . . . . . . . . 5
4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB . 6
4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE . . . . . . . . . 6
4.3.3. Unspecified TLV Values . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. LOCAL_IF Address Block TLVs . . . . . . . . . . . . . . . 7
5.1.1. New Registry . . . . . . . . . . . . . . . . . . . . 7
5.1.2. Modification to Existing Registry . . . . . . . . . . 8
5.2. LINK_STATUS Address Block TLVs . . . . . . . . . . . . . 8
5.2.1. New Registry . . . . . . . . . . . . . . . . . . . . 8
5.2.2. Modification to Existing Registry . . . . . . . . . . 9
5.3. OTHER_NEIGHB Address Block TLVs . . . . . . . . . . . . . 10
5.3.1. Create New Registry . . . . . . . . . . . . . . . . . 10
5.3.2. Modification to Existing Registry . . . . . . . . . . 11
5.4. MPR Address Block TLVs . . . . . . . . . . . . . . . . . 11
5.4.1. New Registry . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Modification to Existing Registry . . . . . . . . . . 12
5.5. NBR_ADDR_TYPE Address Block TLVs . . . . . . . . . . . . 12
5.5.1. New Registry . . . . . . . . . . . . . . . . . . . . 12
5.5.2. Modification to Existing Registry . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
1. Introduction
The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the
Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181]
are protocols for use in Mobile Ad Hoc Networks (MANETs) [RFC2501],
based on the Generalized MANET Packet/Message Format [RFC5444].
This document updates [RFC6130] and [RFC7181], 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
[RFC6130] and [RFC7181] 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 [RFC6130] and [RFC7181] and also are
not a reason to reject a message.
2. Terminology
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
[RFC2119].
Additionally, this document uses the terminology of [RFC5444],
[RFC6130], and [RFC7181].
3. Applicability Statement
This document updates the specification of the protocols described in
[RFC6130] and [RFC7181].
Specifically, this specification updates [RFC6130] and [RFC7181] in
the following ways:
o 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 [RFC6130] and [RFC7181].
o Specifies the handling of a TLV Value field with unexpected
length.
o Sets up IANA registries for TLV Values for the Address Block TLVs:
* LOCAL_IF, defined in [RFC6130].
* LINK_STATUS, defined in [RFC6130].
* OTHER_NEIGHB, defined in [RFC6130].
* MPR, defined in [RFC7181], now considered as a bit field.
* NBR_ADDR_TYPE, defined in [RFC7181], now considered as a bit
field.
o Defines a well-known TLV Value for "UNSPECIFIED" for the Address
Block TLV Types LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB, all
defined in [RFC6130].
4. TLV Values
NHDP [RFC6130] and OLSRv2 [RFC7181] define a number of TLVs within
the framework of [RFC5444]. 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 [RFC6130] and OLSRv2 [RFC7181] are to handle TLVs
with other TLV Value fields.
4.1. Unrecognized TLV Values
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 [RFC6130]
and Section 16.3.1 of [RFC7181]). These sections could be
interpreted as allowing rejection of a message because a TLV Value
field is unrecognized. This specification removes that latitude:
o 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.
o Hence, this specification removes the 7th, 10th, and 11th bullets
in Section 12.1 of [RFC6130].
It should be stressed that this is not a change to [RFC6130] or
[RFC7181], except with regard to not allowing this to be a reason for
rejection of a message. [RFC6130] or [RFC7181] 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.
4.2. TLV Value Lengths
The TLVs specified in [RFC6130] and [RFC7181] 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 [RFC5444]. All TLVs
specified in [RFC6130] and [RFC7181] 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 [RFC6130] and [RFC7181]. This document specifies how
implementations of [RFC6130] and [RFC7181], or extensions thereof,
MUST behave on receiving TLVs of the TLV types defined in [RFC6130]
and [RFC7181], but with TLV Value fields with other single-length
values.
The following principles apply:
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
cleared (0).
Exception:
o A received CONT_SEQ_NUM with a single-length < 2 SHOULD be
considered an error.
4.3. Undefined TLV Values
[RFC6130] and [RFC7181] 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 [RFC6130] and
[RFC7181], and as specified in Section 4.3.3.
There are different cases of TLV Values with different
characteristics. These cases are considered in this section.
4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB
For the Address-Block TLVs LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB
TLVs, defined in [RFC6130], 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 [RFC6130] -- see Section 5.
An implementation of [RFC6130] that receives a LOCAL_IF, LINK_STATUS,
or OTHER_NEIGHB TLV with any TLV Value other than the values that are
defined in [RFC6130] MUST ignore that TLV Value, as well as any
corresponding attribute association to the address.
4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE
The Address-Block TLVs MPR and NBR_ADDR_TYPE, defined in [RFC7181],
are similar to those defined in [RFC6130] 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 [RFC7181] -- see Section 5.
Other TLVs defined by [RFC7181] are not affected by this
specification.
4.3.3. Unspecified TLV Values
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 Section 5.
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').
5. IANA Considerations
IANA has completed the ten actions set out in the following sections.
5.1. LOCAL_IF Address Block TLVs
5.1.1. New Registry
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 Table 1.
+---------+-------------+-------------------------------+-----------+
| Value | Name | Description | Reference |
+---------+-------------+-------------------------------+-----------+
| 0 | THIS_IF | The network address is | RFC 7188 |
| | | associated with this local | |
| | | interface of the sending | |
| | | router | |
| | | | |
| 1 | OTHER_IF | The network address is | RFC 7188 |
| | | associated with another local | |
| | | interface of the sending | |
| | | router | |
| | | | |
| 2-223 | | Unassigned | |
| | | | |
| 224-254 | | Reserved for Experimental Use | RFC 7188 |
| | | | |
| 255 | UNSPECIFIED | No information about this | RFC 7188 |
| | | network address is provided | |
+---------+-------------+-------------------------------+-----------+
Table 1: LOCAL_IF TLV Values
New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified
in [RFC6130] and [RFC7181].
5.1.2. Modification to Existing Registry
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
Table 2.
+-----------+-----------------------------------------+-------------+
| Type | Description | Reference |
| Extension | | |
+-----------+-----------------------------------------+-------------+
| 0 | This value is to be interpreted | RFC 6130, |
| | according to the registry LOCAL_IF TLV | RFC 7188 |
| | Values | |
| | | |
| 1-255 | Unassigned | |
+-----------+-----------------------------------------+-------------+
Table 2: LOCAL_IF Address Block TLV Type Extensions Modifications
5.2. LINK_STATUS Address Block TLVs
5.2.1. New Registry
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 Table 3.
+---------+-------------+-------------------------------+-----------+
| Value | Name | Description | Reference |
+---------+-------------+-------------------------------+-----------+
| 0 | LOST | The link on this interface | RFC 7188 |
| | | from the router with that | |
| | | network address has been lost | |
| | | | |
| 1 | SYMMETRIC | The link on this interface | RFC 7188 |
| | | from the router with that | |
| | | network address has the | |
| | | status of symmetric | |
| | | | |
| 2 | HEARD | The link on this interface | RFC 7188 |
| | | from the router with that | |
| | | network address has the | |
| | | status of heard | |
| | | | |
| 3-223 | | Unassigned | |
| | | | |
| 224-254 | | Reserved for Experimental Use | RFC 7188 |
| | | | |
| 255 | UNSPECIFIED | No information about this | RFC 7188 |
| | | network address is provided | |
+---------+-------------+-------------------------------+-----------+
Table 3: LINK_STATUS TLV Values
New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified
in [RFC6130] and [RFC7181].
5.2.2. Modification to Existing Registry
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 Table 4.
+-----------+------------------------------------------+------------+
| Type | Description | Reference |
| Extension | | |
+-----------+------------------------------------------+------------+
| 0 | This value is to be interpreted | RFC 6130, |
| | according to the registry LINK_STATUS | RFC 7188 |
| | TLV Values | |
| | | |
| 1-255 | Unassigned | |
+-----------+------------------------------------------+------------+
Table 4: LINK_STATUS Address Block TLV Type Extensions Modifications
5.3. OTHER_NEIGHB Address Block TLVs
5.3.1. Create New Registry
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 Table 5.
+---------+-------------+-------------------------------+-----------+
| Value | Name | Description | Reference |
+---------+-------------+-------------------------------+-----------+
| 0 | LOST | The neighbor relationship | RFC 7188 |
| | | with the router with that | |
| | | network address has been lost | |
| | | | |
| 1 | SYMMETRIC | The neighbor relationship | RFC 7188 |
| | | with the router with that | |
| | | network address is symmetric | |
| | | | |
| 2-223 | | Unassigned | |
| | | | |
| 224-254 | | Reserved for Experimental Use | RFC 7188 |
| | | | |
| 255 | UNSPECIFIED | No information about this | RFC 7188 |
| | | network address is provided | |
+---------+-------------+-------------------------------+-----------+
Table 5: OTHER_NEIGHB Address Block TLV Values
New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified
in [RFC6130] and [RFC7181].
5.3.2. Modification to Existing Registry
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 Table 6.
+-----------+------------------------------------------+------------+
| Type | Description | Reference |
| Extension | | |
+-----------+------------------------------------------+------------+
| 0 | This value is to be interpreted | RFC 6130, |
| | according to the registry OTHER_NEIGHB | RFC 7188 |
| | TLV Values | |
| | | |
| 1-255 | Unassigned | |
+-----------+------------------------------------------+------------+
Table 6: OTHER_NEIGHB Address Block TLV Type Extensions Modifications
5.4. MPR Address Block TLVs
5.4.1. New Registry
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 Table 7.
+-----+-------+----------+------------------------------+-----------+
| Bit | Value | Name | Description | Reference |
+-----+-------+----------+------------------------------+-----------+
| 7 | 0x01 | Flooding | The neighbor with that | RFC 7188 |
| | | | network address has been | |
| | | | selected as flooding MPR | |
| | | | | |
| 6 | 0x02 | Routing | The neighbor with that | RFC 7188 |
| | | | network address has been | |
| | | | selected as routing MPR | |
| | | | | |
| 0-5 | | | Unassigned | |
+-----+-------+----------+------------------------------+-----------+
Table 7: MPR Address Block TLV Bit Values
New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified
in [RFC6130] and [RFC7181]. Additionally, the Designated Experts are
required to ensure that the following sense is preserved:
o 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.
5.4.2. Modification to Existing Registry
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 Table 8.
+-----------+-----------------------------------------+-------------+
| Type | Description | Reference |
| Extension | | |
+-----------+-----------------------------------------+-------------+
| 0 | This value is to be interpreted | RFC 7181, |
| | according to the registry MPR TLV Bit | RFC 7188 |
| | Values | |
| | | |
| 1-255 | Unassigned | |
+-----------+-----------------------------------------+-------------+
Table 8: MPR Address Block TLV Type Extensions Modifications
5.5. NBR_ADDR_TYPE Address Block TLVs
5.5.1. New Registry
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 Table 9.
+-----+-------+------------+----------------------------+-----------+
| Bit | Value | Name | Description | Reference |
+-----+-------+------------+----------------------------+-----------+
| 7 | 0x01 | ORIGINATOR | The network address is an | RFC 7188 |
| | | | originator address | |
| | | | reachable via the | |
| | | | originating router | |
| | | | | |
| 6 | 0x02 | ROUTABLE | The network address is a | RFC 7188 |
| | | | routable address reachable | |
| | | | via the originating router | |
| | | | | |
| 0-5 | | | Unassigned | |
+-----+-------+------------+----------------------------+-----------+
Table 9: NBR_ADDR_TYPE Address Block TLV Bit Values
New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified
in [RFC6130] and [RFC7181]. Additionally, the Designated Experts are
required to ensure that the following sense is preserved:
o 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.
5.5.2. Modification to Existing Registry
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 Table 10.
+-----------+-------------------------------------------+-----------+
| Type | Description | Reference |
| Extension | | |
+-----------+-------------------------------------------+-----------+
| 0 | This value is to be interpreted according | RFC 7181, |
| | to the registry NBR_ADDR_TYPE Address | RFC 7188 |
| | Block TLV Bit Values | |
| | | |
| 1-255 | Unassigned | |
+-----------+-------------------------------------------+-----------+
Table 10: NBR_ADDR_TYPE Address Block TLV Type Extensions
Modifications
6. Security Considerations
The updates made to [RFC6130] and [RFC7181] have the following
implications on the security considerations:
o 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.
o Enabled protocol extensions for registering TLV values in the
created IANA registries. Such extensions MUST specify appropriate
security considerations.
o 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.
o 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.
o Did not introduce any opportunities for attacks on the protocols
through signal modification that are not already present in the
two protocols.
7. Acknowledgments
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.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444,
February 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2", RFC
7181, April 2014.
8.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses
Christopher Dearlove
BAE Systems Advanced Technology Centre
West Hanningfield Road
Great Baddow, Chelmsford
United Kingdom
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Thomas Heide Clausen
LIX, Ecole Polytechnique
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
AI ELI5
On this page
PROBLEMNHDP and OLSRv2 let an implementation reject a message as badly formed if a TLV carried a value it did not recognize. That makes it hard to add extensions that still work with older, unextended routers.
MECHANISMRFC 7188 forbids rejecting a message for an unrecognized TLV value, says how to treat TLV values that are longer or shorter than expected, turns the MPR and NBR_ADDR_TYPE values into bit fields, and creates IANA registries for the TLV values.
WHY IT MATTERSOlder routers now ignore what they do not understand instead of dropping the whole message, and new TLV values can be registered. The RFC updates RFC 6130 and RFC 7181 and has itself been updated by RFC 7722.
§1Why the TLV Rules Needed a Fix
The MANET Neighborhood Discovery Protocol (NHDP, RFC 6130) and the Optimized Link State Routing Protocol version 2 (OLSRv2, RFC 7181) are protocols for Mobile Ad Hoc Networks (MANETs). Both are built on the Generalized MANET Packet/Message Format (RFC 5444), which carries information in TLV (Type-Length-Value) elements.
Both base specifications allow an implementation to treat a message as "badly formed" for reasons beyond those they list, and so to reject it. That could be read as allowing rejection of a message just because a TLV value was unrecognized. This document removes that latitude, which gives extensions more room and lets them interoperate with unextended implementations.
TLVs with an unknown type or type extension were already required to be ignored, and are not a reason to reject a message.
Some old rules said a router could throw away a whole message if it saw something unfamiliar. That made it risky to invent new things, so the rules were changed.
§4.1Never Reject for an Unrecognized Value
The central rule is that an implementation MUST NOT reject a message because it contains an unrecognized TLV value. An unextended implementation of NHDP or OLSRv2 must instead process or ignore that value as described in the later sections. As a result, the 7th, 10th and 11th bullets in Section 12.1 of RFC 6130 are removed.
The RFC stresses that this is not otherwise a change to the base specifications. Those specifications are written 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 an implementation that strictly follows them.
Unknown TLV types and type extensions were already to be ignored. This rule extends the same tolerance to unknown values of known TLVs.
If a kid reads a note and finds a word they do not know, they keep reading instead of crumpling it up. The rest of the note is still useful.
§4.2Handling Unexpected TLV Value Lengths
A TLV can hold one value or several (a multivalue TLV). The length of each item is its single-length, calculated as in Section 5.4.1 of RFC 5444. All TLVs defined in RFC 6130 and RFC 7181 have a one- or two-octet single-length, which is the expected length.
Extensions may introduce other lengths, so two principles apply:
- If the received single-length is greater than expected, the excess octets
MUSTbe ignored. - If it is less than expected, the absent octets
MUSTbe treated as having all bits cleared (0).
There is one exception: a received CONT_SEQ_NUM with a single-length below 2 SHOULD be considered an error.
If a form has extra boxes you do not know, ignore them. If it is missing boxes, pretend they are filled with zeros.
§4.3Registries, Bit Fields and UNSPECIFIED
The base specifications give meanings to only some values of certain TLVs. This document turns those into IANA registries so extensions can add more. For the NHDP TLVs LOCAL_IF, LINK_STATUS and OTHER_NEIGHB, an implementation that receives any value other than those defined in RFC 6130 MUST ignore that value and the attribute association it would make for the address.
For the OLSRv2 TLVs MPR and NBR_ADDR_TYPE, the existing values 1, 2 and 3 are now to be read as a bit field: 1 and 2 are two separate attributes and 3 means both. A test such as Value = 1 MUST become Value bitand 1 = 1.
The three NHDP registries also gain a defined value UNSPECIFIED, meaning no information is associated with the address. It can make multivalue TLVs more efficient or simplify an implementation. For MPR and NBR_ADDR_TYPE the value zero already serves this purpose, and for LINK_METRIC it is possible by clearing bits 0 to 3 of the first octet. In that last case the RFC recommends that the remaining bits be all clear or all set.
The messages used numbers as code words. Now the numbers are kept in a public list so people can add new code words, and there is a special "nothing to say" code word.
- MPR 0x01 (bit 7)Flooding — Neighbor selected as flooding MPR.
- MPR 0x02 (bit 6)Routing — Neighbor selected as routing MPR.
- NBR_ADDR_TYPE 0x01 (bit 7)ORIGINATOR — Originator address reachable via the originating router.
- NBR_ADDR_TYPE 0x02 (bit 6)ROUTABLE — Routable address reachable via the originating router.
§5The New IANA Registries
IANA completed ten actions: five new sub-registries and five modifications to existing ones, all within the "Mobile Ad hoc NETwork (MANET) Parameters" registry. The new ones are "LOCAL_IF TLV Values", "LINK_STATUS TLV Values", "OTHER_NEIGHB TLV Values", "MPR TLV Bit Values" and "NBR_ADDR_TYPE Address Block TLV Bit Values".
In each of the three value registries, 224 to 254 are reserved for experimental use and 255 is UNSPECIFIED. The bit registries define bits 7 and 6 (values 0x01 and 0x02) and leave bits 0 to 5 unassigned. New assignments need Expert Review, and the Designated Experts must use the guidelines in RFC 6130 and RFC 7181.
For the bit registries, the experts must also preserve one sense: a set bit means the address has the property, while an unset bit means no information is provided and must not convey anything specific. In each existing "Type Extensions" sub-registry, the entry for value 0 now points to the new registry.
There is now an official list book for each kind of code word. Anyone who wants to add a new one has to ask the experts who look after the book.
- 0LOST — The link from the router with that network address has been lost.
- 1SYMMETRIC — The link has the status of symmetric.
- 2HEARD — The link has the status of heard.
- 224-254Experimental — Reserved for experimental use.
- 255UNSPECIFIED — No information about this network address is provided.
§6Security Considerations
The RFC argues that its changes add no new security considerations. Creating the registries, adding UNSPECIFIED (which is identical to having no TLV of that type), and reducing the latitude to reject messages all leave the base protocols' behavior unchanged. The update also introduces no opportunities for attacks through signal modification that are not already present in the two protocols.
Extensions that register TLV values in the new registries MUST specify appropriate security considerations of their own.
Nothing about the new rules makes the network easier to trick. Anyone who adds new code words must explain their own safety risks.
§7References
[RFC2119]RFC 2119Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.March 1997[RFC5444]RFC 5444Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized MANET Packet/Message Format", RFC 5444, February 2009.February 2009[RFC6130]RFC 6130Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.April 2011[RFC7181]RFC 7181Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014.April 2014[RFC2501]RFC 2501Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999.January 1999