Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs
draft-ietf-manet-nhdp-olsrv2-tlv-extension-05

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 OLSRv2 and RFC6130.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 06, 2014.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Applicability Statement
• 4. TLV Values
• 4.1. Unrecognized TLV Values
• 4.2. TLV Value Lengths
• 4.3. Undefined TLV Values
• 4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB
• 4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE
• 4.3.3. Unspecified TLV Values
• 5. IANA Considerations
• 5.1. LOCAL_IF Address Block TLVs
• 5.1.1. Create New Registry
• 5.1.2. Modification to Existing Registry
• 5.2. LINK_STATUS Address Block TLVs
• 5.2.1. Create New Registry
• 5.2.2. Modification to Existing Registry
• 5.3. OTHER_NEIGHB Address Block TLVs
• 5.3.1. Create New Registry
• 5.3.2. Modification to Existing Registry
• 5.4. MPR Address Block TLVs
• 5.4.1. Create New Registry
• 5.4.2. Modification to Existing Registry
• 5.5. NBR_ADDR_TYPE Address Block TLVs
• 5.5.1. Create New Registry
• 5.5.2. Modification to Existing Registry
• 6. Security Considerations
• 7. Acknowledgments
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State Routing Protocol, version 2 (OLSRv2) [OLSRv2] are protocols for use in mobile ad hoc networks (MANETs) [RFC2501], based on the Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format [RFC5444].

This document updates [RFC6130] and [OLSRv2], 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 [OLSRv2] and [RFC6130] 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 (Type-Length-Value elements) [RFC5444] 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 [OLSRv2], 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 [OLSRv2].

3. Applicability Statement

This document updates the specification of the protocols [OLSRv2] and [RFC6130].

Specifically, this specification updates [RFC6130] and [OLSRv2] in the following way:

• 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 [OLSRv2].
• Specifies the handling of a TLV Value field with unexpected length.
• 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 [OLSRv2], now considered as a bit field.
  • NBR_ADDR_TYPE, defined in [OLSRv2], now considered as a bit field.

• 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 [OLSRv2] 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 only defining certain TLV Values, or considering only some lengths of the TLV Value fields (or single value field in a multi value Address-Block TLV). This specification describes how NHDP [RFC6130] and OLSRv2 [OLSRv2] 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 [OLSRv2]). These sections could be interpreted as allowing rejection of a message because a TLV Value field is unrecognized. This specification removes that latitude:

• An implementation MUST NOT reject a message because it contains an unrecognized TLV value. Instead, any unrecognised TLV Value field MUST be processed or ignored by an unextended implementation of NHDP or OLSRv2, as described in the following sections.
• 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 [OLSRv2], except with regard to not allowing this to be a reason for rejection of a message. [RFC6130] or [OLSRv2] 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 [OLSRv2] may be either single-value or multi-value 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 in [RFC5444]. All TLVs specified in [RFC6130] and [OLSRv2] 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 [OLSRv2]. This document specifies how implementations of [RFC6130] and [OLSRv2], or extensions thereof, MUST behave on receiving TLVs of the TLV types defined in [RFC6130] and [OLSRv2], but with TLV Value fields with other single-length values.

The following principles apply:

• If the received single-length is greater than the expected single-length, then the excess octets MUST be ignored.
• If the received single-length is less than the expected single-length, then the absent octets MUST considered to have all bits cleared (0).

Exceptions:

• A received CONT_SEQ_NUM with a single-length < 2 SHOULD be considered an error.

4.3. Undefined TLV Values

[RFC6130] and [OLSRv2] define a number of TLVs, but for some of these TLVs 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 [OLSRv2], and as specified in Section 4.3.3.

There are different cases of TLV Values with different characteristics. These cases are considered in this section.

4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB

For the Address-Block TLVs LOCAL_IF, LINK_STATUS and OTHER_NEIGHB TLVs, defined in [RFC6130], only a limited number of values are specified for each. These are converted, by this specification, into extensible registries with initial registrations for values defined and used by [RFC6130] - see Section 5.

An implementation of [RFC6130], receiving a LOCAL_IF, LINK_STATUS, or OTHER_NEIGHB TLV with any TLV Value other than the values which 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 [OLSRv2], are similar to those defined in [RFC6130] in having only limited values specified (1, 2 and 3): 1 and 2, represent 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 bitfields, with initial registrations for values defined and used by [OLSRv2] - see Section 5.

Other TLVs defined by [OLSRv2] 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, but 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; this is therefore 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 is requested to take a total of ten actions as set out in the following sections.

5.1. LOCAL_IF Address Block TLVs

5.1.1. Create New Registry

IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) Parameters". IANA is requested to create a new sub-registry called "LOCAL_IF TLV Values".

IANA is requested to populate this registry as specified in Table 1.