draft-ietf-manet-nhdp-olsrv2-tlv-extension-05.txt   rfc7188.txt 
Mobile Ad hoc Networking (MANET) C. Dearlove Internet Engineering Task Force (IETF) C. Dearlove
Internet-Draft BAE Systems ATC Request for Comments: 7188 BAE Systems ATC
Updates: RFC6130, OLSRv2 T. Clausen Updates: 6130, 7181 T. Clausen
(if approved) LIX, Ecole Polytechnique Category: Standards Track LIX, Ecole Polytechnique
Intended status: Standards Track March 5, 2014 ISSN: 2070-1721 April 2014
Expires: September 6, 2014
Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Optimized Link State Routing Protocol Version 2 (OLSRv2) and
Neighborhood Discovery Protocol (NHDP) Extension TLVs MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs
draft-ietf-manet-nhdp-olsrv2-tlv-extension-05
Abstract Abstract
This specification describes extensions to definitions of TLVs used This specification describes extensions to definitions of TLVs used
by the Optimized Link State Routing Protocol version 2 (OLSRv2) and by the Optimized Link State Routing Protocol version 2 (OLSRv2) and
the MANET Neighborhood Discovery Protocol (NHDP), to increase their the MANET Neighborhood Discovery Protocol (NHDP) to increase their
abilities to accommodate protocol extensions. This document updates abilities to accommodate protocol extensions. This document updates
OLSRv2 and RFC6130. RFC 7181 (OLSRv2) and RFC 6130 (NHDP).
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 6, 2014. 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
4. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Unrecognized TLV Values . . . . . . . . . . . . . . . . . 4 4.1. Unrecognized TLV Values . . . . . . . . . . . . . . . . . 4
4.2. TLV Value Lengths . . . . . . . . . . . . . . . . . . . . 5 4.2. TLV Value Lengths . . . . . . . . . . . . . . . . . . . . 5
4.3. Undefined TLV Values . . . . . . . . . . . . . . . . . . . 6 4.3. Undefined TLV Values . . . . . . . . . . . . . . . . . . 5
4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB . . 6 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.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE . . . . . . . . . 6
4.3.3. Unspecified TLV Values . . . . . . . . . . . . . . . . 7 4.3.3. Unspecified TLV Values . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. LOCAL_IF Address Block TLVs . . . . . . . . . . . . . . . 8 5.1. LOCAL_IF Address Block TLVs . . . . . . . . . . . . . . . 7
5.1.1. Create New Registry . . . . . . . . . . . . . . . . . 8 5.1.1. New Registry . . . . . . . . . . . . . . . . . . . . 7
5.1.2. Modification to Existing Registry . . . . . . . . . . 9 5.1.2. Modification to Existing Registry . . . . . . . . . . 8
5.2. LINK_STATUS Address Block TLVs . . . . . . . . . . . . . . 10 5.2. LINK_STATUS Address Block TLVs . . . . . . . . . . . . . 8
5.2.1. Create New Registry . . . . . . . . . . . . . . . . . 10 5.2.1. New Registry . . . . . . . . . . . . . . . . . . . . 8
5.2.2. Modification to Existing Registry . . . . . . . . . . 11 5.2.2. Modification to Existing Registry . . . . . . . . . . 9
5.3. OTHER_NEIGHB Address Block TLVs . . . . . . . . . . . . . 12 5.3. OTHER_NEIGHB Address Block TLVs . . . . . . . . . . . . . 10
5.3.1. Create New Registry . . . . . . . . . . . . . . . . . 12 5.3.1. Create New Registry . . . . . . . . . . . . . . . . . 10
5.3.2. Modification to Existing Registry . . . . . . . . . . 13 5.3.2. Modification to Existing Registry . . . . . . . . . . 11
5.4. MPR Address Block TLVs . . . . . . . . . . . . . . . . . . 13 5.4. MPR Address Block TLVs . . . . . . . . . . . . . . . . . 11
5.4.1. Create New Registry . . . . . . . . . . . . . . . . . 13 5.4.1. New Registry . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Modification to Existing Registry . . . . . . . . . . 14 5.4.2. Modification to Existing Registry . . . . . . . . . . 12
5.5. NBR_ADDR_TYPE Address Block TLVs . . . . . . . . . . . . . 15 5.5. NBR_ADDR_TYPE Address Block TLVs . . . . . . . . . . . . 12
5.5.1. Create New Registry . . . . . . . . . . . . . . . . . 15 5.5.1. New Registry . . . . . . . . . . . . . . . . . . . . 12
5.5.2. Modification to Existing Registry . . . . . . . . . . 16 5.5.2. Modification to Existing Registry . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the
Optimized Link State Routing Protocol, version 2 (OLSRv2) [OLSRv2] Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181]
are protocols for use in mobile ad hoc networks (MANETs) [RFC2501], are protocols for use in Mobile Ad Hoc Networks (MANETs) [RFC2501],
based on the Generalized Mobile Ad Hoc Network (MANET) Packet/Message based on the Generalized MANET Packet/Message Format [RFC5444].
Format [RFC5444].
This document updates [RFC6130] and [OLSRv2], specifically their use This document updates [RFC6130] and [RFC7181], specifically their use
of TLV (Type-Length-Value) elements, to increase the extensibility of of TLV (Type-Length-Value) elements, to increase the extensibility of
these protocols, and to enable some improvements in their these protocols and to enable some improvements in their
implementation. implementation.
This specification reduces the latitude of implementations of This specification reduces the latitude of implementations of
[OLSRv2] and [RFC6130] to consider some messages, which will not be [RFC6130] and [RFC7181] to consider some messages, which will not be
created by implementations simply following those specifications, as created by implementations simply following those specifications, as
a reason to consider the message as "badly formed", and thus as a a reason to consider the message as "badly formed", and thus as a
reason to reject the message. This gives greater latitude to the reason to reject the message. This gives greater latitude to the
creation of extensions of these protocols, in particular extensions creation of extensions of these protocols, in particular extensions
that will interoperate with unextended implementations of those that will interoperate with unextended implementations of those
protocols. As part of that, it indicates how TLVs (Type-Length-Value protocols. As part of that, it indicates how TLVs with unexpected
elements) [RFC5444] with unexpected value fields must be handled, and value fields must be handled, and adds some additional options to
adds some additional options to those TLVs. those TLVs.
Note that TLVs with unknown type or type extension are already Note that TLVs with unknown type or type extension are already
specified as to be ignored by [RFC6130] and [OLSRv2], and also are specified as to be ignored by [RFC6130] and [RFC7181] and also are
not a reason to reject a message. not a reason to reject a message.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses the terminology of [RFC5444], Additionally, this document uses the terminology of [RFC5444],
[RFC6130], and [OLSRv2]. [RFC6130], and [RFC7181].
3. Applicability Statement 3. Applicability Statement
This document updates the specification of the protocols [OLSRv2] and This document updates the specification of the protocols described in
[RFC6130]. [RFC6130] and [RFC7181].
Specifically, this specification updates [RFC6130] and [OLSRv2] in Specifically, this specification updates [RFC6130] and [RFC7181] in
the following way: the following ways:
o Removes the latitude of rejecting a message with a TLV with a 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 known type, but with an unexpected TLV Value field, for the TLV
Types defined in [RFC6130] and [OLSRv2]. Types defined in [RFC6130] and [RFC7181].
o Specifies the handling of a TLV Value field with unexpected o Specifies the handling of a TLV Value field with unexpected
length. length.
o Sets up IANA registries for TLV Values for the Address Block TLVs: o Sets up IANA registries for TLV Values for the Address Block TLVs:
* LOCAL_IF, defined in [RFC6130]. * LOCAL_IF, defined in [RFC6130].
* LINK_STATUS, defined in [RFC6130]. * LINK_STATUS, defined in [RFC6130].
* OTHER_NEIGHB, defined in [RFC6130]. * OTHER_NEIGHB, defined in [RFC6130].
* MPR, defined in [OLSRv2], now considered as a bit field. * MPR, defined in [RFC7181], now considered as a bit field.
* NBR_ADDR_TYPE, defined in [OLSRv2], now considered as a bit * NBR_ADDR_TYPE, defined in [RFC7181], now considered as a bit
field. field.
o Defines a well-known TLV Value for "UNSPECIFIED" for the Address o Defines a well-known TLV Value for "UNSPECIFIED" for the Address
Block TLV Types LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB, all Block TLV Types LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB, all
defined in [RFC6130]. defined in [RFC6130].
4. TLV Values 4. TLV Values
NHDP [RFC6130] and OLSRv2 [OLSRv2] define a number of TLVs within the NHDP [RFC6130] and OLSRv2 [RFC7181] define a number of TLVs within
framework of [RFC5444]. These TLVs define the meaning of only some the framework of [RFC5444]. These TLVs define the meaning of only
of the contents that can be found in a TLV Value field. This some of the contents that can be found in a TLV Value field. This
limitation may be either only defining certain TLV Values, or limitation may be either defining only certain TLV Values or
considering only some lengths of the TLV Value fields (or single considering only some lengths of the TLV Value fields (or a single-
value field in a multi value Address-Block TLV). This specification value field in a multivalue Address-Block TLV). This specification
describes how NHDP [RFC6130] and OLSRv2 [OLSRv2] are to handle TLVs describes how NHDP [RFC6130] and OLSRv2 [RFC7181] are to handle TLVs
with other TLV Value fields. with other TLV Value fields.
4.1. Unrecognized TLV Values 4.1. Unrecognized TLV Values
NHDP and OLSRv2 specify that, in addition to well-defined reasons (in NHDP and OLSRv2 specify that, in addition to well-defined reasons (in
the respective protocol specifications), an implementation of these the respective protocol specifications), an implementation of these
protocols MAY recognize a message as "badly formed" and therefore protocols MAY recognize a message as "badly formed" and therefore
"invalid for processing" for other reasons (Section 12.1 of [RFC6130] "invalid for processing" for other reasons (Section 12.1 of [RFC6130]
and Section 16.3.1 of [OLSRv2]). These sections could be interpreted and Section 16.3.1 of [RFC7181]). These sections could be
as allowing rejection of a message because a TLV Value field is interpreted as allowing rejection of a message because a TLV Value
unrecognized. This specification removes that latitude: field is unrecognized. This specification removes that latitude:
o An implementation MUST NOT reject a message because it contains an o An implementation MUST NOT reject a message because it contains an
unrecognized TLV value. Instead, any unrecognised TLV Value field unrecognized TLV value. Instead, any unrecognized TLV Value field
MUST be processed or ignored by an unextended implementation of MUST be processed or ignored by an unextended implementation of
NHDP or OLSRv2, as described in the following sections. NHDP or OLSRv2, as described in the following sections.
o Hence, this specification removes the 7th, 10th, and 11th bullets o Hence, this specification removes the 7th, 10th, and 11th bullets
in Section 12.1 of [RFC6130]. in Section 12.1 of [RFC6130].
It should be stressed that this is not a change to [RFC6130] or It should be stressed that this is not a change to [RFC6130] or
[OLSRv2], except with regard to not allowing this to be a reason for [RFC7181], except with regard to not allowing this to be a reason for
rejection of a message. [RFC6130] or [OLSRv2] are specified in terms rejection of a message. [RFC6130] or [RFC7181] are specified in
such as "if an address is associated with a value of LOST by a 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 LINK_STATUS TLV". Association with an unrecognized value has no
effect on any implementation strictly following such a specification. effect on any implementation strictly following such a specification.
4.2. TLV Value Lengths 4.2. TLV Value Lengths
The TLVs specified in [RFC6130] and [OLSRv2] may be either single- The TLVs specified in [RFC6130] and [RFC7181] may be either single-
value or multi-value TLVs. In either case, the length of each item value or multivalue TLVs. In either case, the length of each item of
of information encoded in the TLV Value field is the "single-length", information encoded in the TLV Value field is the "single-length",
defined and calculated as in section 5.4.1 in [RFC5444]. All TLVs defined and calculated as in Section 5.4.1 of [RFC5444]. All TLVs
specified in [RFC6130] and [OLSRv2] have a one or two octet single- specified in [RFC6130] and [RFC7181] have a one- or two-octet single-
length. These are considered the expected single-lengths of such a length. These are considered the expected single-lengths of such a
received TLV. received TLV.
Other single-length TLV Value fields may be introduced by extensions Other single-length TLV Value fields may be introduced by extensions
to [RFC6130] and [OLSRv2]. This document specifies how to [RFC6130] and [RFC7181]. This document specifies how
implementations of [RFC6130] and [OLSRv2], or extensions thereof, implementations of [RFC6130] and [RFC7181], or extensions thereof,
MUST behave on receiving TLVs of the TLV types defined in [RFC6130] MUST behave on receiving TLVs of the TLV types defined in [RFC6130]
and [OLSRv2], but with TLV Value fields with other single-length and [RFC7181], but with TLV Value fields with other single-length
values. values.
The following principles apply: The following principles apply:
o If the received single-length is greater than the expected single- o If the received single-length is greater than the expected single-
length, then the excess octets MUST be ignored. length, then the excess octets MUST be ignored.
o If the received single-length is less than the expected single- o If the received single-length is less than the expected single-
length, then the absent octets MUST considered to have all bits length, then the absent octets MUST be considered to have all bits
cleared (0). cleared (0).
Exceptions: Exception:
o A received CONT_SEQ_NUM with a single-length < 2 SHOULD be o A received CONT_SEQ_NUM with a single-length < 2 SHOULD be
considered an error. considered an error.
4.3. Undefined TLV Values 4.3. Undefined TLV Values
[RFC6130] and [OLSRv2] define a number of TLVs, but for some of these [RFC6130] and [RFC7181] define a number of TLVs, but for some of
TLVs specify meanings for only some TLV Values. This document these TLVs they specify meanings for only some TLV Values. This
establishes IANA registries for these TLV Values, with initial document establishes IANA registries for these TLV Values, with
registrations reflecting those used by [RFC6130] and [OLSRv2], and as initial registrations reflecting those used by [RFC6130] and
specified in Section 4.3.3. [RFC7181], and as specified in Section 4.3.3.
There are different cases of TLV Values with different There are different cases of TLV Values with different
characteristics. These cases are considered in this section. characteristics. These cases are considered in this section.
4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB 4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB
For the Address-Block 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 TLVs, defined in [RFC6130], only a limited number of values are
specified for each. These are converted, by this specification, into specified for each. These are converted, by this specification, into
extensible registries with initial registrations for values defined extensible registries with initial registrations for values defined
and used by [RFC6130] - see Section 5. and used by [RFC6130] -- see Section 5.
An implementation of [RFC6130], receiving a LOCAL_IF, LINK_STATUS, or An implementation of [RFC6130] that receives a LOCAL_IF, LINK_STATUS,
OTHER_NEIGHB TLV with any TLV Value other than the values which are 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 defined in [RFC6130] MUST ignore that TLV Value, as well as any
corresponding attribute association to the address. corresponding attribute association to the address.
4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE 4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE
The Address-Block TLVs MPR and NBR_ADDR_TYPE, defined in [OLSRv2], The Address-Block TLVs MPR and NBR_ADDR_TYPE, defined in [RFC7181],
are similar to those defined in [RFC6130] in having only limited are similar to those defined in [RFC6130] in having only limited
values specified (1, 2 and 3): 1 and 2, represent presence of two values specified (1, 2, and 3): 1 and 2 represent the presence of two
different attributes associated to an address, and 3 represents "both different attributes associated to an address, and 3 represents "both
1 and 2". 1 and 2".
These TLV Value fields, are by this specification, converted to bit These TLV Value fields are, by this specification, converted to bit
fields, and MUST be interpreted as such. As the existing definitions 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 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 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 = 1 or Value = 3 MUST be converted to a test of (for
example) Value bitand 1 = 1, where "bitand" denotes a bitwise and example) Value bitand 1 = 1, where "bitand" denotes a bitwise AND
operation. operation.
This specification creates registries for recording reservations of This specification creates registries for recording reservations of
the individual bits in these bitfields, with initial registrations the individual bits in these bit fields, with initial registrations
for values defined and used by [OLSRv2] - see Section 5. for values defined and used by [RFC7181] -- see Section 5.
Other TLVs defined by [OLSRv2] are not affected by this Other TLVs defined by [RFC7181] are not affected by this
specification. specification.
4.3.3. Unspecified TLV Values 4.3.3. Unspecified TLV Values
The registries defined in Section 5 for the LOCAL_IF, LINK_STATUS and The registries defined in Section 5 for the LOCAL_IF, LINK_STATUS,
OTHER_NEIGHB TLVs each include an additional TLV Value UNSPECIFIED. and OTHER_NEIGHB TLVs each include an additional TLV Value
This TLV Value represents a defined value that, like currently UNSPECIFIED. This TLV Value represents a defined value that, like
undefined TLV Values, indicates that no information is associated currently undefined TLV Values, indicates that no information is
with this address, but will always have this meaning. Such a TLV associated with this address; the defined value will always have this
Value may be used to enable the creation of more efficient multivalue meaning. Such a TLV Value may be used to enable the creation of more
Address Block TLVs, or to simplify an implementation. efficient multivalue Address Block TLVs or to simplify an
implementation.
The similar requirement for the MPR and NBR_ADDR_TYPES TLVs is The similar requirement for the MPR and NBR_ADDR_TYPES TLVs is
already satisfied by the TLV Value zero, provided that each bit in 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 the TLV Value is defined as set ('1') when indicating the presence of
an attribute, or clear ('0') when indicating the absence of an an attribute, or clear ('0') when indicating the absence of an
attribute; this is therefore required for registrations from the attribute. Therefore, this is required for registrations from the
relevant registries, see Section 5. relevant registries; see Section 5.
For the LINK_METRIC TLV, this is already possible by clearing the 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. 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 It is RECOMMENDED that in this case the remaining bits of the TLV
Value are either all clear ('0') or all set ('1'). Value are either all clear ('0') or all set ('1').
5. IANA Considerations 5. IANA Considerations
IANA is requested to take a total of ten actions as set out in the IANA has completed the ten actions set out in the following sections.
following sections.
5.1. LOCAL_IF Address Block TLVs 5.1. LOCAL_IF Address Block TLVs
5.1.1. Create New Registry 5.1.1. New Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) IANA has created a new sub-registry called "LOCAL_IF TLV Values"
Parameters". IANA is requested to create a new sub-registry called within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
"LOCAL_IF TLV Values".
IANA is requested to populate this registry as specified in Table 1. IANA has populated this registry as specified in Table 1.
+---------+-------------+------------------------------+------------+ +---------+-------------+-------------------------------+-----------+
| Value | Name | Description | Reference | | Value | Name | Description | Reference |
+---------+-------------+------------------------------+------------+ +---------+-------------+-------------------------------+-----------+
| 0 | THIS_IF | The network address is | [This.I-D] | | 0 | THIS_IF | The network address is | RFC 7188 |
| | | associated with this local | | | | | associated with this local | |
| | | interface of the sending | | | | | interface of the sending | |
| | | router | | | | | router | |
| 1 | OTHER_IF | The network address is | [This.I-D] | | | | | |
| | | associated with another | | | 1 | OTHER_IF | The network address is | RFC 7188 |
| | | local interface of the | | | | | associated with another local | |
| | | sending router | | | | | interface of the sending | |
| 2-223 | | Unallocated: Expert Review | | | | | router | |
| 224-254 | | Experimental Use | [This.I-D] | | | | | |
| 255 | UNSPECIFIED | No information about this | [This.I-D] | | 2-223 | | Unassigned | |
| | | network address is provided | | | | | | |
+---------+-------------+------------------------------+------------+ | 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 Table 1: LOCAL_IF TLV Values
New assignments are to be made by Expert Review [RFC5226]. New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified The Designated Experts are required to use the guidelines specified
in [RFC6130] and [OLSRv2]. IANA is not expected to record this fact in [RFC6130] and [RFC7181].
in the registry.
5.1.2. Modification to Existing Registry 5.1.2. Modification to Existing Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) IANA maintains a sub-registry called "LOCAL_IF Address Block TLV Type
Parameters" with a sub-registry called "LOCAL_IF Address Block TLV Extensions" within the "Mobile Ad hoc NETwork (MANET) Parameters"
Type Extensions". This sub-registry currently has an entry for value registry. This sub-registry already had an entry for value 0. IANA
0. IANA is requested to replace the entry in the Description column has replaced the entry in the Description column for this value with
for this value with the text "The value is to be interpreted the text "This value is to be interpreted according to the registry
according to the registry LOCAL_IF TLV Values". The resulting table LOCAL_IF TLV Values". The resulting table is as specified in
should look as specified in Table 2. Table 2.
+-----------+-----------------------------------------+-------------+ +-----------+-----------------------------------------+-------------+
| Type | Description | Reference | | Type | Description | Reference |
| Extension | | | | Extension | | |
+-----------+-----------------------------------------+-------------+ +-----------+-----------------------------------------+-------------+
| 0 | The value is to be interpreted | [RFC6130] | | 0 | This value is to be interpreted | RFC 6130, |
| | according to the registry LOCAL_IF TLV | [This.I-D] | | | according to the registry LOCAL_IF TLV | RFC 7188 |
| | Values | | | | Values | |
| 1-255 | Unassigned | [This.I-D] | | | | |
| 1-255 | Unassigned | |
+-----------+-----------------------------------------+-------------+ +-----------+-----------------------------------------+-------------+
Table 2: LOCAL_IF Address Block TLV Type Extensions Modifications Table 2: LOCAL_IF Address Block TLV Type Extensions Modifications
5.2. LINK_STATUS Address Block TLVs 5.2. LINK_STATUS Address Block TLVs
5.2.1. Create New Registry 5.2.1. New Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) IANA has created a new sub-registry called "LINK_STATUS TLV Values"
Parameters". IANA is requested to create a new sub-registry called within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
"LINK_STATUS TLV Values".
IANA is requested to populate this registry as specified in Table 3. IANA has populated this registry as specified in Table 3.
+---------+-------------+------------------------------+------------+ +---------+-------------+-------------------------------+-----------+
| Value | Name | Description | Reference | | Value | Name | Description | Reference |
+---------+-------------+------------------------------+------------+ +---------+-------------+-------------------------------+-----------+
| 0 | LOST | The link on this interface | [This.I-D] | | 0 | LOST | The link on this interface | RFC 7188 |
| | | from the router with that | | | | | from the router with that | |
| | | network address has been | | | | | network address has been lost | |
| | | lost | | | | | | |
| 1 | SYMMETRIC | The link on this interface | [This.I-D] | | 1 | SYMMETRIC | The link on this interface | RFC 7188 |
| | | from the router with that | | | | | from the router with that | |
| | | network address has the | | | | | network address has the | |
| | | status of symmetric | | | | | status of symmetric | |
| 2 | HEARD | The link on this interface | [This.I-D] | | | | | |
| | | from the router with that | | | 2 | HEARD | The link on this interface | RFC 7188 |
| | | network address has the | | | | | from the router with that | |
| | | status of heard | | | | | network address has the | |
| 3-223 | | Unallocated: Expert Review | | | | | status of heard | |
| 224-254 | | Experimental Use | [This.I-D] | | | | | |
| 255 | UNSPECIFIED | No information about this | [This.I-D] | | 3-223 | | Unassigned | |
| | | network address is provided | | | | | | |
+---------+-------------+------------------------------+------------+ | 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 Table 3: LINK_STATUS TLV Values
New assignments are to be made by Expert Review [RFC5226]. New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified The Designated Experts are required to use the guidelines specified
in [RFC6130] and [OLSRv2]. IANA is not expected to record this fact in [RFC6130] and [RFC7181].
in the registry.
5.2.2. Modification to Existing Registry 5.2.2. Modification to Existing Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) IANA maintains a sub-registry called "LINK_STATUS Address Block TLV
Parameters" with a sub-registry called "LINK_STATUS Address Block TLV Type Extensions" within the "Mobile Ad hoc NETwork (MANET)
Type Extensions". This sub-registry currently has an entry for value Parameters" registry. This sub-registry already had an entry for
0. IANA is requested to replace the entry in the Description column value 0. IANA has replaced the entry in the Description column for
for this value with the text "The value is to be interpreted this value with the text "This value is to be interpreted according
according to the registry LINK_STATUS TLV Values". The resulting to the registry LINK_STATUS TLV Values". The resulting table is as
table should look as specified in Table 4. specified in Table 4.
+-----------+-----------------------------------------+-------------+ +-----------+------------------------------------------+------------+
| Type | Description | Reference | | Type | Description | Reference |
| Extension | | | | Extension | | |
+-----------+-----------------------------------------+-------------+ +-----------+------------------------------------------+------------+
| 0 | The value is to be interpreted | [RFC6130] | | 0 | This value is to be interpreted | RFC 6130, |
| | according to the registry LINK_STATUS | [This.I-D] | | | according to the registry LINK_STATUS | RFC 7188 |
| | TLV Values | | | | TLV Values | |
| 1-255 | Unassigned | [This.I-D] | | | | |
+-----------+-----------------------------------------+-------------+ | 1-255 | Unassigned | |
+-----------+------------------------------------------+------------+
Table 4: LINK_STATUS Address Block TLV Type Extensions Modifications Table 4: LINK_STATUS Address Block TLV Type Extensions Modifications
5.3. OTHER_NEIGHB Address Block TLVs 5.3. OTHER_NEIGHB Address Block TLVs
5.3.1. Create New Registry 5.3.1. Create New Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) IANA has created a new sub-registry called "OTHER_NEIGHB TLV Values"
Parameters". IANA is requested to create a new sub-registry called within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
"OTHER_NEIGHB TLV Values".
IANA is requested to populate this registry as specified in Table 5. IANA has populated this registry as specified in Table 5.
+---------+-------------+------------------------------+------------+ +---------+-------------+-------------------------------+-----------+
| Value | Name | Description | Reference | | Value | Name | Description | Reference |
+---------+-------------+------------------------------+------------+ +---------+-------------+-------------------------------+-----------+
| 0 | LOST | The neighbor relationship | [This.I-D] | | 0 | LOST | The neighbor relationship | RFC 7188 |
| | | with the router with that | | | | | with the router with that | |
| | | network address has been | | | | | network address has been lost | |
| | | lost | | | | | | |
| 1 | SYMMETRIC | The neighbor relationship | [This.I-D] | | 1 | SYMMETRIC | The neighbor relationship | RFC 7188 |
| | | with the router with that | | | | | with the router with that | |
| | | network address is symmetric | | | | | network address is symmetric | |
| 2-223 | | Unallocated: Expert Review | | | | | | |
| 224-254 | | Experimental Use | [This.I-D] | | 2-223 | | Unassigned | |
| 255 | UNSPECIFIED | No information about this | [This.I-D] | | | | | |
| | | network address is provided | | | 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 Table 5: OTHER_NEIGHB Address Block TLV Values
New assignments are to be made by Expert Review [RFC5226]. New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified The Designated Experts are required to use the guidelines specified
in [RFC6130] and [OLSRv2]. IANA is not expected to record this fact in [RFC6130] and [RFC7181].
in the registry.
5.3.2. Modification to Existing Registry 5.3.2. Modification to Existing Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) IANA maintains a sub-registry called "OTHER_NEIGHB Address Block TLV
Parameters" with a sub-registry called "OTHER_NEIGHB Address Block Type Extensions" within the "Mobile Ad hoc NETwork (MANET)
TLV Type Extensions". This sub-registry currently has an entry for Parameters" registry. This sub-registry already had an entry for
value 0. IANA is requested to replace the entry in the Description value 0. IANA has replaced the entry in the Description column for
column for this value with the text "The value is to be interpreted this value with the text "This value is to be interpreted according
according to the registry OTHER_NEIGHB TLV Values". The resulting to the registry OTHER_NEIGHB TLV Values". The resulting table is as
table should look as specified in Table 6. specified in Table 6.
+-----------+-----------------------------------------+-------------+ +-----------+------------------------------------------+------------+
| Type | Description | Reference | | Type | Description | Reference |
| Extension | | | | Extension | | |
+-----------+-----------------------------------------+-------------+ +-----------+------------------------------------------+------------+
| 0 | The value is to be interpreted | [RFC6130] | | 0 | This value is to be interpreted | RFC 6130, |
| | according to the registry OTHER_NEIGHB | [This.I-D] | | | according to the registry OTHER_NEIGHB | RFC 7188 |
| | TLV Values | | | | TLV Values | |
| 1-255 | Unassigned | [This.I-D] | | | | |
+-----------+-----------------------------------------+-------------+ | 1-255 | Unassigned | |
+-----------+------------------------------------------+------------+
Table 6: OTHER_NEIGHB Address Block TLV Type Extensions Modifications Table 6: OTHER_NEIGHB Address Block TLV Type Extensions Modifications
5.4. MPR Address Block TLVs 5.4. MPR Address Block TLVs
5.4.1. Create New Registry 5.4.1. New Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) IANA has created a new sub-registry called "MPR TLV Bit Values"
Parameters". IANA is requested to create a new sub-registry called within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.
"MPR TLV Bit Values".
IANA is requested to populate this registry as specified in Table 7. IANA has populated this registry as specified in Table 7.
+-----+-------+----------+-----------------------------+------------+ +-----+-------+----------+------------------------------+-----------+
| Bit | Value | Name | Description | Reference | | Bit | Value | Name | Description | Reference |
+-----+-------+----------+-----------------------------+------------+ +-----+-------+----------+------------------------------+-----------+
| 7 | 0x01 | Flooding | The neighbor with that | [This.I-D] | | 7 | 0x01 | Flooding | The neighbor with that | RFC 7188 |
| | | | network address has been | | | | | | network address has been | |
| | | | selected as flooding MPR | | | | | | selected as flooding MPR | |
| 6 | 0x02 | Routing | The neighbor with that | [This.I-D] | | | | | | |
| | | | network address has been | | | 6 | 0x02 | Routing | The neighbor with that | RFC 7188 |
| | | | selected as routing MPR | | | | | | network address has been | |
| 0-5 | | | Unallocated: Expert Review | | | | | | selected as routing MPR | |
+-----+-------+----------+-----------------------------+------------+ | | | | | |
| 0-5 | | | Unassigned | |
+-----+-------+----------+------------------------------+-----------+
Table 7: MPR Address Block TLV Bit Values Table 7: MPR Address Block TLV Bit Values
New assignments are to be made by Expert Review [RFC5226]. New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified The Designated Experts are required to use the guidelines specified
in [RFC6130] and [OLSRv2]. Additionally, the Designated Experts are in [RFC6130] and [RFC7181]. Additionally, the Designated Experts are
required to ensure that the following sense is preserved: required to ensure that the following sense is preserved:
o For each bit in the field, a set bit (1) means that the address 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 has the designated property, while an unset bit (0) means that no
information about the designated property is provided. In information about the designated property is provided. In
particular, an unset bit must not be used to convey any specific particular, an unset bit must not be used to convey any specific
information about the designated property. IANA is not expected information about the designated property.
to record these facts in the registry.
5.4.2. Modification to Existing Registry 5.4.2. Modification to Existing Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) IANA maintains a sub-registry called "MPR Address Block TLV Type
Parameters" with a sub-registry called "MPR Address Block TLV Type Extensions" within the "Mobile Ad hoc NETwork (MANET) Parameters"
Extensions". This sub-registry currently has an entry for value 0. registry. This sub-registry already had an entry for value 0. IANA
IANA is requested to replace the entry in the Description column for has replaced the entry in the Description column for this value with
this value with the text "The value is to be interpreted according to the text "This value is to be interpreted according to the registry
the registry MPR TLV Bit Values". The resulting table should look as MPR TLV Bit Values". The resulting table is as specified in Table 8.
specified in Table 8.
+-----------+-----------------------------------------+-------------+ +-----------+-----------------------------------------+-------------+
| Type | Description | Reference | | Type | Description | Reference |
| Extension | | | | Extension | | |
+-----------+-----------------------------------------+-------------+ +-----------+-----------------------------------------+-------------+
| 0 | The value is to be interpreted | [OLSRv2] | | 0 | This value is to be interpreted | RFC 7181, |
| | according to the registry MPR TLV Bit | [This.I-D] | | | according to the registry MPR TLV Bit | RFC 7188 |
| | Values | | | | Values | |
| 1-255 | Unassigned | [This.I-D] | | | | |
| 1-255 | Unassigned | |
+-----------+-----------------------------------------+-------------+ +-----------+-----------------------------------------+-------------+
Table 8: MPR Address Block TLV Type Extensions Modifications Table 8: MPR Address Block TLV Type Extensions Modifications
5.5. NBR_ADDR_TYPE Address Block TLVs 5.5. NBR_ADDR_TYPE Address Block TLVs
5.5.1. Create New Registry 5.5.1. New Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) IANA has created a new sub-registry called "NBR_ADDR_TYPE Address
Parameters". IANA is requested to create a new sub-registry called Block TLV Bit Values" within the "Mobile Ad hoc NETwork (MANET)
"NBR_ADDR_TYPE Address Block TLV Bit Values". Parameters" registry.
IANA is requested to populate this registry as specified in Table 9. IANA has populated this registry as specified in Table 9.
+-----+-------+------------+---------------------------+------------+ +-----+-------+------------+----------------------------+-----------+
| Bit | Value | Name | Description | Reference | | Bit | Value | Name | Description | Reference |
+-----+-------+------------+---------------------------+------------+ +-----+-------+------------+----------------------------+-----------+
| 7 | 0x01 | ORIGINATOR | The network address is an | [This.I-D] | | 7 | 0x01 | ORIGINATOR | The network address is an | RFC 7188 |
| | | | originator address | | | | | | originator address | |
| | | | reachable via the | | | | | | reachable via the | |
| | | | originating router | | | | | | originating router | |
| 6 | 0x02 | ROUTABLE | The network address is a | [This.I-D] | | | | | | |
| | | | routable address | | | 6 | 0x02 | ROUTABLE | The network address is a | RFC 7188 |
| | | | reachable via the | | | | | | routable address reachable | |
| | | | originating router | | | | | | via the originating router | |
| 0-5 | | | Unallocated: Expert | | | | | | | |
| | | | Review | | | 0-5 | | | Unassigned | |
+-----+-------+------------+---------------------------+------------+ +-----+-------+------------+----------------------------+-----------+
Table 9: NBR_ADDR_TYPE Address Block TLV Bit Values Table 9: NBR_ADDR_TYPE Address Block TLV Bit Values
New assignments are to be made by Expert Review [RFC5226]. New assignments are to be made by Expert Review [RFC5226].
The Designated Experts are required to use the guidelines specified The Designated Experts are required to use the guidelines specified
in [RFC6130] and [OLSRv2]. Additionally, the Designated Experts are in [RFC6130] and [RFC7181]. Additionally, the Designated Experts are
required to ensure that the following sense is preserved: required to ensure that the following sense is preserved:
o For each bit in the field, a set bit (1) means that the address 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 has the designated property, while an unset bit (0) means that no
information about the designated property is provided. In information about the designated property is provided. In
particular, an unset bit must not be used to convey any specific particular, an unset bit must not be used to convey any specific
information about the designated property. IANA is not expected information about the designated property.
to record these facts in the registry.
5.5.2. Modification to Existing Registry 5.5.2. Modification to Existing Registry
IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) IANA maintains a sub-registry called "NBR_ADDR_TYPE Address Block TLV
Parameters" with a sub-registry called "NBR_ADDR_TYPE Address Block Type Extensions" within the "Mobile Ad hoc NETwork (MANET)
TLV Type Extensions". This sub-registry currently has an entry for Parameters" registry. This sub-registry already had an entry for
value 0. IANA is requested to replace the entry in the Description value 0. IANA has replaced the entry in the Description column for
column for this value with the text "The value is to be interpreted this value with the text "This value is to be interpreted according
according to the registry NBR_ADDR_TYPE TLV Bit Values". The to the registry NBR_ADDR_TYPE TLV Bit Values". The resulting table
resulting table should look as specified in Table 10. is as specified in Table 10.
+-----------+------------------------------------------+------------+ +-----------+-------------------------------------------+-----------+
| Type | Description | Reference | | Type | Description | Reference |
| Extension | | | | Extension | | |
+-----------+------------------------------------------+------------+ +-----------+-------------------------------------------+-----------+
| 0 | The value is to be interpreted according | [OLSRv2] | | 0 | This value is to be interpreted according | RFC 7181, |
| | to the registry NBR_ADDR_TYPE Address | [This.I-D] | | | to the registry NBR_ADDR_TYPE Address | RFC 7188 |
| | Block TLV Bit Values | | | | Block TLV Bit Values | |
| 1-255 | Unassigned | [This.I-D] | | | | |
+-----------+------------------------------------------+------------+ | 1-255 | Unassigned | |
+-----------+-------------------------------------------+-----------+
Table 10: NBR_ADDR_TYPE Address Block TLV Type Extensions Table 10: NBR_ADDR_TYPE Address Block TLV Type Extensions
Modifications Modifications
6. Security Considerations 6. Security Considerations
The presented updates to [RFC6130] and [OLSRv2]: The updates made to [RFC6130] and [RFC7181] have the following
implications on the security considerations:
o Create IANA registries for retaining TLV values for TLVs, already o Created IANA registries for retaining TLV values for TLVs, already
defined in the already published specifications of the two defined in the already published specifications of the two
protocols, and with initial registrations for the TLV values protocols, and with initial registrations for the TLV values
defined by these specifications. This does not give rise to any defined by these specifications. This does not give rise to any
additional security considerations. additional security considerations.
o Enable protocol extensions to be able to register TLV values in o Enabled protocol extensions for registering TLV values in the
the created IANA registries. Such extensions MUST specify created IANA registries. Such extensions MUST specify appropriate
appropriate security considerations. security considerations.
o Create, in some registries, a registration for "UNSPECIFIED" o Created, in some registries, a registration for "UNSPECIFIED"
values, for more efficient use of multi-value Address Block TLVs. values for more efficient use of multivalue Address Block TLVs.
The interpretation of an address being associated with a TLV of a The interpretation of an address being associated with a TLV of a
given type and with the value "UNSPECIFIED" is identical to that given type and with the value "UNSPECIFIED" is identical to that
address not being associated with a TLV of that type. Thus, this address not being associated with a TLV of that type. Thus, this
update does not give rise to any additional security update does not give rise to any additional security
considerations. considerations.
o Reduces the latitude of implementations of the two protocols to o Reduced the latitude of implementations of the two protocols to
reject a message as "badly formed", due to the value field of a reject a message as "badly formed" due to the value field of a TLV
TLV being unexpected. These protocols are specified in terms such being unexpected. These protocols are specified in terms such as
as "if an address is associated with a value of LOST by a "if an address is associated with a value of LOST by a LINK_STATUS
LINK_STATUS TLV". Association with an unknown value (or a value TLV". Association with an unknown value (or a value newly defined
newly defined to mean no link status information) has no effect on to mean no link status information) has no effect on such a
such a specification. Thus, this update does not give rise to any specification. Thus, this update does not give rise to any
additional security considerations. additional security considerations.
o Do not introduce any opportunities for attacks on the protocols o Did not introduce any opportunities for attacks on the protocols
through signal modification that are not already present in the through signal modification that are not already present in the
two protocols. two protocols.
7. Acknowledgments 7. Acknowledgments
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews, and comments on the for intense technical discussions, early reviews, and comments on the
specification (listed alphabetically): Ulrich Herberg (Fujitsu specification (listed alphabetically): Ulrich Herberg (Fujitsu
Laboratories of America) and Henning Rogge (Frauenhofer FKIE). Laboratories of America) and Henning Rogge (Frauenhofer FKIE).
The authors would also like to express their gratitude to Adrian The authors would also like to express their gratitude to Adrian
Farrel, for his assistance and contributions to successful and timely Farrel for his assistance and contributions to the successful and
completion of this specification. timely completion of this specification.
8. References 8. References
8.1. Normative References 8.1. Normative References
[OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2",
work in progress draft-ietf-manet-olsrv2-19, March 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. 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 8.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and (MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999. Evaluation Considerations", RFC 2501, January 1999.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
Authors' Addresses Authors' Addresses
Christopher Dearlove Christopher Dearlove
BAE Systems Advanced Technology Centre BAE Systems Advanced Technology Centre
West Hanningfield Road West Hanningfield Road
Great Baddow, Chelmsford Great Baddow, Chelmsford
United Kingdom United Kingdom
Phone: +44 1245 242194 Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
Email: T.Clausen@computer.org EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/ URI: http://www.ThomasClausen.org/
 End of changes. 93 change blocks. 
335 lines changed or deleted 337 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/