GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc7188

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7188.txt · Last modified: 2014/04/10 18:15 (external edit)