Internet DRAFT - draft-dearlove-manet-nhdp-olsrv2-tlv-extension
draft-dearlove-manet-nhdp-olsrv2-tlv-extension
Mobile Ad hoc Networking (MANET) C. Dearlove
Internet-Draft BAE Systems ATC
Updates: RFC6130, OLSRv2 T. Clausen
(if approved) LIX, Ecole Polytechnique
Intended status: Standards Track July 31, 2013
Expires: February 1, 2014
Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET
Neighborhood Discovery Protocol (NHDP) Extension TLVs
draft-dearlove-manet-nhdp-olsrv2-tlv-extension-02
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 February 1, 2014.
Copyright Notice
Copyright (c) 2013 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
Dearlove & Clausen Expires February 1, 2014 [Page 1]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Dearlove & Clausen Expires February 1, 2014 [Page 2]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013
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.
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]. As such it is applicable to all implementations of these
protocols.
Specifically, this specification updates [RFC6130] and [OLSRv2] in
the following way:
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 [OLSRv2].
Dearlove & Clausen Expires February 1, 2014 [Page 3]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013
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 [OLSRv2], now considered as a bit field.
* NBR_ADDR_TYPE, defined in [OLSRv2], 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 [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] SHOULD 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:
o An implementation MUST NOT reject a message because it contains
such a TLV. Instead, any unrecognied TLV Value field MUST be
processed or ignored by an unextended implementation of NHDP or
OLSRv2, as discussed in the following sections.
It should be stressed that this is not a change to [RFC6130] or
Dearlove & Clausen Expires February 1, 2014 [Page 4]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013
[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 the
information encoded in the TLV Value field is the "single-length",
defined and calculated as per section 5.4.1 in [RFC5444]. All TLVs
specified in [RFC6130] and [OLSRv2] describe TLVs with one or two
octet TLV Value field single-lengths. These are considered the
expected values of single-length for 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.
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 considered to have all bits
cleared (0).
Exceptions:
o A received CONT_SEQ_NUM with a signle-lentgh < 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 considerd in this section.
Dearlove & Clausen Expires February 1, 2014 [Page 5]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013
4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB
For the Address-Block TLVs LOCAL_IF, LINK_STAUS 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 TLV with any TLV Value
other than those values used in that specification, MUST ignore that
TLV Value and 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 value that MUST NOT be defined in any
extension of [RFC6130]. 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
Dearlove & Clausen Expires February 1, 2014 [Page 6]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013
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
Note: Values defined as "Unallocated: Expert Review" mean that these
values may be allocated according to the expert review guidelines
specified in [RFC6130] and [OLSRv2]. In two cases a constraint on
future allocation is specified.
5.1. Address Block TLVs
IANA is requested to create a registry associated with the Address
Block TLV with name LOCAL_IF (Type = 2, Type Extension = 0) defined
in [RFC6130], specifying the meaning of its single values. This
replaces the Description column in Table 6 in [RFC6130] by a
reference to this table.
+---------+-------------+-------------------------------------------+
| Value | Name | Description |
+---------+-------------+-------------------------------------------+
| 0 | THIS_IF | The network address is associated with |
| | | this local interface of the sending |
| | | router |
| 1 | OTHER_IF | The network address is associated with |
| | | another local interface of the sending |
| | | router |
| 2-223 | | Unallocated: Expert Review |
| 224-254 | | Experimental Use |
| 255 | UNSPECIFIED | No information about this network address |
| | | is provided |
+---------+-------------+-------------------------------------------+
Table 1: LOCAL_IF TLV Values
IANA are requested to create a registry associated with the Address
Block TLV with name LINK_STATUS (Type = 3, Type Extension = 0)
defined in [RFC6130], specifying the meaning of its single values.
This replaces the Description column in Table 7 in [RFC6130] by a
reference to this table.
Dearlove & Clausen Expires February 1, 2014 [Page 7]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013
+---------+-------------+-------------------------------------------+
| Value | Name | Description |
+---------+-------------+-------------------------------------------+
| 0 | LOST | The link on this interface from the |
| | | router with that network address has been |
| | | lost |
| 1 | SYMMETRIC | The link on this interface from the |
| | | router with that network address has the |
| | | status of symmetric |
| 2 | HEARD | The link on this interface from the |
| | | router with that network address has the |
| | | status of heard |
| 3-223 | | Unallocated: Expert Review |
| 224-254 | | Experimental Use |
| 255 | UNSPECIFIED | No information about this network address |
| | | is provided |
+---------+-------------+-------------------------------------------+
Table 2: LINK_STATUS TLV Values
IANA are requested to create a registry associated with the Address
Block TLV with name OTHER_NEIGHB (Type = 4, Type Extension = 0)
defined in [RFC6130], specifying the meaning of its single values.
This replaces the Description column in Table 8 in [RFC6130] by a
reference to this table.
+---------+-------------+-------------------------------------------+
| Value | Name | Description |
+---------+-------------+-------------------------------------------+
| 0 | LOST | The neighbor relationship with the router |
| | | with that network address has been lost |
| 1 | SYMMETRIC | The neighbor relationship with the router |
| | | with that network address is symmetric |
| 2-223 | | Unallocated: Expert Review |
| 224-254 | | Experimental Use |
| 255 | UNSPECIFIED | No information about this network address |
| | | is provided |
+---------+-------------+-------------------------------------------+
Table 3: OTHER_NEIGHB TLV Values
IANA are requested to create a registry associated with the Address
Block TLV with name MPR (Type = 8, Type Extension = 0) defined in
[OLSRv2], specifying the meaning of its single values in terms of the
values of each bit of the value, from bit 0 (most significant) to bit
7 (least significant). If multiple bits are set then each applies.
This replaces the Description column in Table 14 in [OLSRv2] by a
reference to this table.
Dearlove & Clausen Expires February 1, 2014 [Page 8]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013
+-------+-------+----------+----------------------------------------+
| Value | Value | Name | Description |
| Bit | | | |
+-------+-------+----------+----------------------------------------+
| 7 | 1 | FLOODING | The neighbor with that network address |
| | | | has been selected as flooding MPR |
| 6 | 2 | ROUTING | The neighbor with that network address |
| | | | has been selected as flooding MPR |
| 0-5 | | | Unallocated: Expert Review |
+-------+-------+----------+----------------------------------------+
Table 4: MPR TLV Bit Values
Note that this registry maintains a bit field, and that the
combination of the bits FLOODING + ROUTING being set (1) (which gives
a value of 3) is given the name FLOOD_ROUTE in [OLSRv2]. For all
future allocations, the Expert Review MUST ensure that allocated bits
MUST use the unset bit (0) to indicates no information, so that the
case Value = 0 will always indicate that no information about this
network address is provided.
IANA are requested to create a registry associated with the Address
Block TLV with name NBR_ADDR_TYPE (Type = 9, Type Extension = 0)
defined in [OLSRv2], specifying the meaning of its single values in
terms of the values of each bit of the value, from bit 0 (most
significant) to bit 7 (least significant). If multiple bits are set
then each applies. This replaces the Description column in Table 15
in [OLSRv2] by a reference to this table.
+-------+-------+------------+--------------------------------------+
| Value | Value | Name | Description |
| Bit | | | |
+-------+-------+------------+--------------------------------------+
| 7 | 1 | ORIGINATOR | The network address is an originator |
| | | | address reachable via the |
| | | | originating router |
| 6 | 2 | ROUTABLE | The network address is a routable |
| | | | address reachable via the |
| | | | originating router |
| 0-5 | | | Unallocated: Expert Review |
+-------+-------+------------+--------------------------------------+
Table 5: NBR_ADDR_TYPE TLV Bit Values
Note that this registry maintains a bit field, and that the
combination of the bits ORIGINATOR + ROUTABLE being set (1) (which
gives a value of 3) is given the name ROUTABLE_ORIG in [OLSRv2]. For
all future allocations, the Expert Review MUST ensure that allocated
Dearlove & Clausen Expires February 1, 2014 [Page 9]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013
bits MUST use the unset bit (0) to indicates no information, so that
the case Value = 0 will always indicate that no information about
this network address is provided.
6. Security Considerations
The presented updates to [RFC6130] and [OLSRv2]:
o Create 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 Enable protocol extensions to be able to register TLV values in
the created IANA registries. Such extensions MUST specify
appropriate security considerations.
o Create, in some registries, a registration for "UNSPECIFIED"
values, for more efficient use of multi-value 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 Reduces 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 Do not introduce any opportunities for attacks on the protocols
through signal modification, 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).
Dearlove & Clausen Expires February 1, 2014 [Page 10]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013
8. References
8.1. Normative References
[OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2",
work in progress draft-ietf-manet-olsrv2-19, March 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
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.
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 Expires February 1, 2014 [Page 11]
