doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc7188.txt b/doc/rfc/rfc7188.txt
new file mode 100644
index 0000000..258630b
--- /dev/null
+++ b/doc/rfc/rfc7188.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 1]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 2]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+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].
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 3]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+   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].
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 4]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+   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.
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 5]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+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.
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 6]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+   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
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 7]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 8]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+   +---------+-------------+-------------------------------+-----------+
+   | 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.
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                    [Page 9]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+   +-----------+------------------------------------------+------------+
+   | 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].
+
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 10]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+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
+
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 11]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+   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.
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 12]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+   +-----+-------+------------+----------------------------+-----------+
+   | 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 13]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+   +-----------+-------------------------------------------+-----------+
+   | 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.
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 14]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+   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.
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 15]
+
+RFC 7188             NHDP and OLSRv2 Extension TLVs           April 2014
+
+
+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/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dearlove & Clausen           Standards Track                   [Page 16]
+