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

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.

   4.3.1.  NHDP TLVs: LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB  .   6

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.

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.

Applicability Statement

This document updates the specification of the protocols described in RFC6130 and RFC7181.

Specifically, this specification updates RFC6130 and RFC7181 in the following ways:

o Removes the latitude of rejecting a message with a TLV with a

  known type, but with an unexpected TLV Value field, for the TLV
  Types defined in RFC6130 and RFC7181.

o Specifies the handling of a TLV Value field with unexpected

  length.

o Sets up IANA registries for TLV Values for the Address Block TLVs:

  *  LOCAL_IF, defined in RFC6130.

  *  LINK_STATUS, defined in RFC6130.

  *  OTHER_NEIGHB, defined in RFC6130.

  *  MPR, defined in RFC7181, now considered as a bit field.

  *  NBR_ADDR_TYPE, defined in RFC7181, now considered as a bit
     field.

o Defines a well-known TLV Value for "UNSPECIFIED" for the Address

  Block TLV Types LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB, all
  defined in RFC6130.

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.

Unrecognized TLV Values

NHDP and OLSRv2 specify that, in addition to well-defined reasons (in the respective protocol specifications), an implementation of these protocols MAY recognize a message as "badly formed" and therefore "invalid for processing" for other reasons (Section 12.1 of RFC6130 and Section 16.3.1 of RFC7181). These sections could be interpreted as allowing rejection of a message because a TLV Value field is unrecognized. This specification removes that latitude:

o An implementation MUST NOT reject a message because it contains an

  unrecognized TLV value.  Instead, any unrecognized TLV Value field
  MUST be processed or ignored by an unextended implementation of
  NHDP or OLSRv2, as described in the following sections.

o Hence, this specification removes the 7th, 10th, and 11th bullets

  in Section 12.1 of RFC6130.

It should be stressed that this is not a change to RFC6130 or RFC7181, except with regard to not allowing this to be a reason for rejection of a message. RFC6130 or RFC7181 are specified in terms such as "if an address is associated with a value of LOST by a LINK_STATUS TLV". Association with an unrecognized value has no effect on any implementation strictly following such a specification.

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.

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.

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.

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.

Unspecified TLV Values

The registries defined in Section 5 for the LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB TLVs each include an additional TLV Value UNSPECIFIED. This TLV Value represents a defined value that, like currently undefined TLV Values, indicates that no information is associated with this address; the defined value will always have this meaning. Such a TLV Value may be used to enable the creation of more efficient multivalue Address Block TLVs or to simplify an implementation.

The similar requirement for the MPR and NBR_ADDR_TYPES TLVs is already satisfied by the TLV Value zero, provided that each bit in the TLV Value is defined as set ('1') when indicating the presence of an attribute, or clear ('0') when indicating the absence of an attribute. Therefore, this is required for registrations from the relevant registries; see Section 5.

For the LINK_METRIC TLV, this is already possible by clearing the most significant bits (0 to 3) of the first octet of the TLV Value. It is RECOMMENDED that in this case the remaining bits of the TLV Value are either all clear ('0') or all set ('1').

IANA Considerations

IANA has completed the ten actions set out in the following sections.

LOCAL_IF Address Block TLVs

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.

                   Table 1: LOCAL_IF TLV Values

New assignments are to be made by Expert Review RFC5226.

The Designated Experts are required to use the guidelines specified in RFC6130 and RFC7181.

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

LINK_STATUS Address Block TLVs

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.

                  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.

Modification to Existing Registry

IANA maintains a sub-registry called "LINK_STATUS Address Block TLV Type Extensions" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry. This sub-registry already had an entry for value 0. IANA has replaced the entry in the Description column for this value with the text "This value is to be interpreted according to the registry LINK_STATUS TLV Values". The resulting table is as specified in Table 4.

+-----------+------------------------------------------+------------+ | Type | Description | Reference | | Extension | | | +-----------+------------------------------------------+------------+ | 0 | This value is to be interpreted | RFC 6130, | | | according to the registry LINK_STATUS | RFC 7188 | | | TLV Values | | | | | | | 1-255 | Unassigned | | +-----------+------------------------------------------+------------+

Table 4: LINK_STATUS Address Block TLV Type Extensions Modifications

OTHER_NEIGHB Address Block TLVs

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.

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

MPR Address Block TLVs

New Registry

IANA has created a new sub-registry called "MPR TLV Bit Values" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.

IANA has populated this registry as specified in Table 7.

+-----+-------+----------+------------------------------+-----------+ | Bit | Value | Name | Description | Reference | +-----+-------+----------+------------------------------+-----------+ | 7 | 0x01 | Flooding | The neighbor with that | RFC 7188 | | | | | network address has been | | | | | | selected as flooding MPR | | | | | | | | | 6 | 0x02 | Routing | The neighbor with that | RFC 7188 | | | | | network address has been | | | | | | selected as routing MPR | | | | | | | | | 0-5 | | | Unassigned | | +-----+-------+----------+------------------------------+-----------+

             Table 7: MPR Address Block TLV Bit Values

New assignments are to be made by Expert Review RFC5226.

The Designated Experts are required to use the guidelines specified in RFC6130 and RFC7181. Additionally, the Designated Experts are required to ensure that the following sense is preserved:

o For each bit in the field, a set bit (1) means that the address

  has the designated property, while an unset bit (0) means that no
  information about the designated property is provided.  In
  particular, an unset bit must not be used to convey any specific
  information about the designated property.

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

NBR_ADDR_TYPE Address Block TLVs

New Registry

IANA has created a new sub-registry called "NBR_ADDR_TYPE Address Block TLV Bit Values" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry.

IANA has populated this registry as specified in Table 9.

+-----+-------+------------+----------------------------+-----------+ | Bit | Value | Name | Description | Reference | +-----+-------+------------+----------------------------+-----------+ | 7 | 0x01 | ORIGINATOR | The network address is an | RFC 7188 | | | | | originator address | | | | | | reachable via the | | | | | | originating router | | | | | | | | | 6 | 0x02 | ROUTABLE | The network address is a | RFC 7188 | | | | | routable address reachable | | | | | | via the originating router | | | | | | | | | 0-5 | | | Unassigned | | +-----+-------+------------+----------------------------+-----------+

        Table 9: NBR_ADDR_TYPE Address Block TLV Bit Values

New assignments are to be made by Expert Review RFC5226.

The Designated Experts are required to use the guidelines specified in RFC6130 and RFC7181. Additionally, the Designated Experts are required to ensure that the following sense is preserved:

o For each bit in the field, a set bit (1) means that the address

  has the designated property, while an unset bit (0) means that no
  information about the designated property is provided.  In
  particular, an unset bit must not be used to convey any specific
  information about the designated property.

Modification to Existing Registry

IANA maintains a sub-registry called "NBR_ADDR_TYPE Address Block TLV Type Extensions" within the "Mobile Ad hoc NETwork (MANET) Parameters" registry. This sub-registry already had an entry for value 0. IANA has replaced the entry in the Description column for this value with the text "This value is to be interpreted according to the registry NBR_ADDR_TYPE TLV Bit Values". The resulting table is as specified in Table 10.

+-----------+-------------------------------------------+-----------+ | Type | Description | Reference | | Extension | | | +-----------+-------------------------------------------+-----------+ | 0 | This value is to be interpreted according | RFC 7181, | | | to the registry NBR_ADDR_TYPE Address | RFC 7188 | | | Block TLV Bit Values | | | | | | | 1-255 | Unassigned | | +-----------+-------------------------------------------+-----------+

     Table 10: NBR_ADDR_TYPE Address Block TLV Type Extensions
                           Modifications

Security Considerations

The updates made to RFC6130 and RFC7181 have the following implications on the security considerations:

o Created IANA registries for retaining TLV values for TLVs, already

  defined in the already published specifications of the two
  protocols, and with initial registrations for the TLV values
  defined by these specifications.  This does not give rise to any
  additional security considerations.

o Enabled protocol extensions for registering TLV values in the

  created IANA registries.  Such extensions MUST specify appropriate
  security considerations.

o Created, in some registries, a registration for "UNSPECIFIED"

  values for more efficient use of multivalue Address Block TLVs.
  The interpretation of an address being associated with a TLV of a
  given type and with the value "UNSPECIFIED" is identical to that
  address not being associated with a TLV of that type.  Thus, this
  update does not give rise to any additional security
  considerations.

o Reduced the latitude of implementations of the two protocols to

  reject a message as "badly formed" due to the value field of a TLV
  being unexpected.  These protocols are specified in terms such as
  "if an address is associated with a value of LOST by a LINK_STATUS
  TLV".  Association with an unknown value (or a value newly defined
  to mean no link status information) has no effect on such a
  specification.  Thus, this update does not give rise to any
  additional security considerations.

o Did not introduce any opportunities for attacks on the protocols

  through signal modification that are not already present in the
  two protocols.

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.

References

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.

Informative References

RFC2501 Macker, J. and S. Corson, "Mobile Ad hoc Networking

          (MANET): Routing Protocol Performance Issues and
          Evaluation Considerations", RFC 2501, January 1999.

RFC5226 Narten, T. and H. Alvestrand, "Guidelines for Writing an

          IANA Considerations Section in RFCs", BCP 26, RFC 5226,
          May 2008.

Authors' Addresses

Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom

Phone: +44 1245 242194 EMail: [email protected] URI: http://www.baesystems.com/

Thomas Heide Clausen LIX, Ecole Polytechnique

Phone: +33 6 6058 9349 EMail: [email protected] URI: http://www.ThomasClausen.org/

Anonymous

Search

RFC7188

Contents

Introduction

Terminology

Applicability Statement

TLV Values

Unrecognized TLV Values

TLV Value Lengths

Undefined TLV Values

NHDP TLVs: LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB

OLSRv2 TLVs: MPR and NBR_ADDR_TYPE

Unspecified TLV Values

IANA Considerations

LOCAL_IF Address Block TLVs

New Registry

Modification to Existing Registry

LINK_STATUS Address Block TLVs

New Registry

Modification to Existing Registry

OTHER_NEIGHB Address Block TLVs

Create New Registry

Modification to Existing Registry

MPR Address Block TLVs

New Registry

Modification to Existing Registry

NBR_ADDR_TYPE Address Block TLVs

New Registry

Modification to Existing Registry

Security Considerations

Acknowledgments

References

Normative References

Informative References

Navigation

Wiki tools

Page tools

Categories