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 12, 2013 Expires: January 13, 2014 Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET Neighborhood Disovery Protocol (NHDP) Extension TLVs draft-dearlove-manet-nhdp-olsrv2-tlv-extension-00 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 January 13, 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 January 13, 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. Unknown TLV Values . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.1. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Dearlove & Clausen Expires January 13, 2014 [Page 2]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013 1. Introduction The Optimized Link State Routing Protocol, version 2 [OLSRv2] is a proactive link state routing protocol designed for use in mobile ad hoc networks (MANETs) [RFC2501]. This document updates that specification, and that of the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130], which is used by OLSRv2. These updates to the TLV (Type-Length-Value) elements used in these specifications increase the extensibility of these protocols, and permit 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 should 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. Both [RFC6130] and [OLSRv2] define a number of TLVs that have only some TLV values used. This extension removes the latitude of an implementation to consider the use of other TLV values as errors, thereby permitting their use in extensions. For relevant TLVs, TLV values for "no information" are also defined, which can make the creation of multivalue TLVs more efficient. Finally, the interpretation of two TLV values (MPR and NBR_ADDR_TYPE) is redefined as bit fields, which may have a minor impact on some implementations' Dearlove & Clausen Expires January 13, 2014 [Page 3]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013 interpretation of such fields in received messages. 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 unknown value, for the TLV Types defined in [RFC6130] and [OLSRv2]. 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. Unknown TLV Values NHDP [RFC6130] and OLSRv2 [OLSRv2] define a number of TLVs within the framework of [RFC5444]. A number of these TLVs specify the meaning of only some possible values that may occur in the value field of a TLV. For example the LINK_STATUS TLV defined in [RFC6130] has an 8-bit value field, yet specifies a meaning only for the values 0 (LOST), 1 (SYMMETRIC) AND 2 (HEARD). These protocols also 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]). The primary reason for that is to enable the implementation of extensions such as [NHDP-OLSRv2-sec]. These sections could however be interpreted as allowing rejection of a message because a TLV value is unknown. This specification removes that latitude: o An implementation MUST NOT reject a message because it contains such a TLV. Instead any unknown value MUST be treated, by an Dearlove & Clausen Expires January 13, 2014 [Page 4]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013 unextended implementation of NHSP or OLSRv2, as if the TLV were not present. Such unknown TLV values may be defined in later specifications. Thus, where appropriate, the TLVs specified in [RFC6130] and [OLSRv2] are re-defined with their value fields being extensible registries, and with initial registrations for values defined and used by [RFC6130] and [OLSRv2] - see Section 5. An extra entry has been added to relevant registries, to represent a value that is to permanently indicate "no information". The utility of this lies in considering multi-value TLVs, as defined in [RFC5444]. [RFC5444] defines a multi-value TLV that may be used to assign information, such as link status, to more than one address in an Address Block. Multi-value TLVs often represent an efficient (in terms of message size) way to convey the indicated information. However only consecutively recorded addresses may be covered by a multivalue TLV. If conveying only one or two pieces of information, it is possible to order address so as to efficiently use multivalue TLVs, but if conveying more, then this is no longer possible. In that case, more than one TLV may be needed for a single type of information. With the definition of a TLV value to mean "no information", greater use of multivalue TLVs is possible, allowing both more efficient messages and simpler implementations. (An implementation must still be able to recognize whatever pattern of TLVs the sender chooses to use.) 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. 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. Specific cases that are affected are described in Section 5. In three cases (LOCAL_IF, LINK_STATUS, OTHER_NEIGHB) there is no impact on [RFC6130] or [OLSRv2]. In two cases (MPR and NBR_ADDR_TYPE, used only by [OLSRv2]) the value is now to be interpreted as a bit field. 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. Not reported, because unchanged, is the LINK_METRIC TLV. However it Dearlove & Clausen Expires January 13, 2014 [Page 5]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013 should be noted that any (two octet) value with all four most significant bits clear (0) is a case that conveys no information about the network address (and which will, at least as far as this TLV is concerned, be not used by OLSRv2). It is RECOMMENDED that when using such a value deliberately that the remaining twelve bits be either all clear (0) or all set (1). However any received pattern of bits MUST be so interpreted. 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 January 13, 2014 [Page 6]
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 January 13, 2014 [Page 7]
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 January 13, 2014 [Page 8]
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 of a TLV being unknown. 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 new protocol signals, nor any additional or changed processing, compared to the already published specifications of the two protocols. 7. Acknowledgments TBD. 8. References Dearlove & Clausen Expires January 13, 2014 [Page 9]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013 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 [NHDP-OLSRv2-sec] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for Control Messages in NHDP and OLSRv2", work in progress draft-ietf-manet-nhdp-olsrv2-sec-03, July 2013. [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/ Dearlove & Clausen Expires January 13, 2014 [Page 10]
Internet-Draft NHDP and OLSRv2 Extension TLVs July 2013 Thomas Heide Clausen LIX, Ecole Polytechnique Phone: +33 6 6058 9349 Email: T.Clausen@computer.org URI: http://www.ThomasClausen.org/ Dearlove & Clausen Expires January 13, 2014 [Page 11]