idnits 2.17.1 draft-ietf-manet-nhdp-olsrv2-tlv-extension-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2014) is 3713 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) C. Dearlove 3 Internet-Draft BAE Systems ATC 4 Updates: RFC6130, OLSRv2 T. Clausen 5 (if approved) LIX, Ecole Polytechnique 6 Intended status: Standards Track February 24, 2014 7 Expires: August 28, 2014 9 Optimized Link State Routing Protocol version 2 (OLSRv2) and MANET 10 Neighborhood Discovery Protocol (NHDP) Extension TLVs 11 draft-ietf-manet-nhdp-olsrv2-tlv-extension-03 13 Abstract 15 This specification describes extensions to definitions of TLVs used 16 by the Optimized Link State Routing Protocol version 2 (OLSRv2) and 17 the MANET Neighborhood Discovery Protocol (NHDP), to increase their 18 abilities to accommodate protocol extensions. This document updates 19 OLSRv2 and RFC6130. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 28, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 58 4. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Unrecognized TLV Values . . . . . . . . . . . . . . . . . 4 60 4.2. TLV Value Lengths . . . . . . . . . . . . . . . . . . . . 5 61 4.3. Undefined TLV Values . . . . . . . . . . . . . . . . . . . 5 62 4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB . . 6 63 4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE . . . . . . . . . . 6 64 4.3.3. Unspecified TLV Values . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Address Block TLVs . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the 77 Optimized Link State Routing Protocol, version 2 (OLSRv2) [OLSRv2] 78 are protocols for use in mobile ad hoc networks (MANETs) [RFC2501], 79 based on the Generalized Mobile Ad Hoc Network (MANET) Packet/Message 80 Format [RFC5444]. 82 This document updates [RFC6130] and [OLSRv2], specifically their use 83 of TLV (Type-Length-Value) elements, to increase the extensibility of 84 these protocols, and to enable some improvements in their 85 implementation. 87 This specification reduces the latitude of implementations of 88 [OLSRv2] and [RFC6130] to consider some messages, which will not be 89 created by implementations simply following those specifications, as 90 a reason to consider the message as "badly formed", and thus as a 91 reason to reject the message. This gives greater latitude to the 92 creation of extensions of these protocols, in particular extensions 93 that will interoperate with unextended implementations of those 94 protocols. As part of that, it indicates how TLVs (Type-Length-Value 95 elements) [RFC5444] with unexpected value fields must be handled, and 96 adds some additional options to those TLVs. 98 Note that TLVs with unknown type or type extension are already 99 specified as to be ignored by [RFC6130] and [OLSRv2], and also are 100 not a reason to reject a message. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 [RFC2119]. 109 Additionally, this document uses the terminology of [RFC5444], 110 [RFC6130], and [OLSRv2]. 112 3. Applicability Statement 114 This document updates the specification of the protocols [OLSRv2] and 115 [RFC6130]. 117 Specifically, this specification updates [RFC6130] and [OLSRv2] in 118 the following way: 120 o Removes the latitude of rejecting a message with a TLV with a 121 known type, but with an unexpected TLV Value field, for the TLV 122 Types defined in [RFC6130] and [OLSRv2]. 124 o Specifies the handling of a TLV Value field with unexpected 125 length. 127 o Sets up IANA registries for TLV Values for the Address Block TLVs: 129 * LOCAL_IF, defined in [RFC6130]. 131 * LINK_STATUS, defined in [RFC6130]. 133 * OTHER_NEIGHB, defined in [RFC6130]. 135 * MPR, defined in [OLSRv2], now considered as a bit field. 137 * NBR_ADDR_TYPE, defined in [OLSRv2], now considered as a bit 138 field. 140 o Defines a well-known TLV Value for "UNSPECIFIED" for the Address 141 Block TLV Types LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB, all 142 defined in [RFC6130]. 144 4. TLV Values 146 NHDP [RFC6130] and OLSRv2 [OLSRv2] define a number of TLVs within the 147 framework of [RFC5444]. These TLVs define the meaning of only some 148 of the contents that can be found in a TLV Value field. This 149 limitation may be either only defining certain TLV Values, or 150 considering only some lengths of the TLV Value fields (or single 151 value field in a multi value Address-Block TLV). This specification 152 describes how NHDP [RFC6130] and OLSRv2 [OLSRv2] are to handle TLVs 153 with other TLV Value fields. 155 4.1. Unrecognized TLV Values 157 NHDP and OLSRv2 specify that, in addition to well-defined reasons (in 158 the respective protocol specifications), an implementation of these 159 protocols MAY recognize a message as "badly formed" and therefore 160 "invalid for processing" for other reasons (Section 12.1 of [RFC6130] 161 and Section 16.3.1 of [OLSRv2]). These sections could be interpreted 162 as allowing rejection of a message because a TLV Value field is 163 unrecognized. This specification removes that latitude: 165 o An implementation MUST NOT reject a message because it contains an 166 unrecognized TLV value. Instead, any unrecognised TLV Value field 167 MUST be processed or ignored by an unextended implementation of 168 NHDP or OLSRv2, as described in the following sections. 170 It should be stressed that this is not a change to [RFC6130] or 171 [OLSRv2], except with regard to not allowing this to be a reason for 172 rejection of a message. [RFC6130] or [OLSRv2] are specified in terms 173 such as "if an address is associated with a value of LOST by a 174 LINK_STATUS TLV". Association with an unrecognized value has no 175 effect on any implementation strictly following such a specification. 177 4.2. TLV Value Lengths 179 The TLVs specified in [RFC6130] and [OLSRv2] may be either single- 180 value or multi-value TLVs. In either case, the length of each item 181 of information encoded in the TLV Value field is the "single-length", 182 defined and calculated as in section 5.4.1 in [RFC5444]. All TLVs 183 specified in [RFC6130] and [OLSRv2] have a one or two octet single- 184 length. These are considered the expected single-lengths of such a 185 received TLV. 187 Other single-length TLV Value fields may be introduced by extensions 188 to [RFC6130] and [OLSRv2]. This document specifies how 189 implementations of [RFC6130] and [OLSRv2], or extensions thereof, 190 MUST behave on receiving TLVs of the TLV types defined in [RFC6130] 191 and [OLSRv2], but with TLV Value fields with other single-length 192 values. 194 The following principles apply: 196 o If the received single-length is greater than the expected single- 197 length, then the excess octets MUST be ignored. 199 o If the received single-length is less than the expected single- 200 length, then the absent octets MUST considered to have all bits 201 cleared (0). 203 Exceptions: 205 o A received CONT_SEQ_NUM with a single-length < 2 SHOULD be 206 considered an error. 208 4.3. Undefined TLV Values 210 [RFC6130] and [OLSRv2] define a number of TLVs, but for some of these 211 TLVs specify meanings for only some TLV Values. This document 212 establishes IANA registries for these TLV Values, with initial 213 registrations reflecting those used by [RFC6130] and [OLSRv2], and as 214 specified in Section 4.3.3. 216 There are different cases of TLV Values with different 217 characteristics. These cases are considered in this section. 219 4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB 221 For the Address-Block TLVs LOCAL_IF, LINK_STATUS and OTHER_NEIGHB 222 TLVs, defined in [RFC6130], only a limited number of values are 223 specified for each. These are converted, by this specification, into 224 extensible registries with initial registrations for values defined 225 and used by [RFC6130] - see Section 5. 227 An implementation of [RFC6130], receiving a LOCAL_IF, LINK_STATUS, or 228 OTHER_NEIGHB TLV with any TLV Value other than the values which are 229 defined in [RFC6130] MUST ignore that TLV Value, as well as any 230 corresponding attribute association to the address. 232 4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE 234 The Address-Block TLVs MPR and NBR_ADDR_TYPE, defined in [OLSRv2], 235 are similar to those defined in [RFC6130] in having only limited 236 values specified (1, 2 and 3): 1 and 2, represent presence of two 237 different attributes associated to an address, and 3 represents "both 238 1 and 2". 240 These TLV Value fields, are by this specification, converted to bit 241 fields, and MUST be interpreted as such. As the existing definitions 242 of values 1, 2, and 3 behave in that manner, it is likely that this 243 will involve no change to an implementation, but any test of (for 244 example) Value = 1 or Value = 3 MUST be converted to a test of (for 245 example) Value bitand 1 = 1, where "bitand" denotes a bitwise and 246 operation. 248 This specification creates registries for recording reservations of 249 the individual bits in these bitfields, with initial registrations 250 for values defined and used by [OLSRv2] - see Section 5. 252 Other TLVs defined by [OLSRv2] are not affected by this 253 specification. 255 4.3.3. Unspecified TLV Values 257 The registries defined in Section 5 for the LOCAL_IF, LINK_STATUS and 258 OTHER_NEIGHB TLVs each include an additional TLV Value UNSPECIFIED. 259 This TLV Value represents a defined value that, like currently 260 undefined TLV Values, indicates that no information is associated 261 with this address, but will always have this meaning. Such a TLV 262 Value may be used to enable the creation of more efficient multivalue 263 Address Block TLVs, or to simplify an implementation. 265 The similar requirement for the MPR and NBR_ADDR_TYPES TLVs is 266 already satisfied by the TLV Value zero, provided that each bit in 267 the TLV Value is defined as set ('1') when indicating the presence of 268 an attribute, or clear ('0') when indicating the absence of an 269 attribute; this is therefore required for registrations from the 270 relevant registries, see Section 5. 272 For the LINK_METRIC TLV, this is already possible by clearing the 273 most significant bits (0 to 3) of the first octet of the TLV Value. 274 It is RECOMMENDED that in this case the remaining bits of the TLV 275 Value are either all clear ('0') or all set ('1'). 277 5. IANA Considerations 279 Note: Values defined as "Unallocated: Expert Review" mean that these 280 values may be allocated according to the expert review guidelines 281 specified in [RFC6130] and [OLSRv2]. In two cases a constraint on 282 future allocation is specified. IANA tables referenced are from 283 "Mobile Ad hoc NETwork (MANET) Parameters". 285 5.1. Address Block TLVs 287 IANA is requested to create a registry associated with the Address 288 Block TLV with name LOCAL_IF (Type = 2, Type Extension = 0) defined 289 in [RFC6130], specifying the meaning of its single values. This 290 replaces the Description column in IANA table "LOCAL_IF Address Block 291 TLV Type Extensions" (from Table 6 in [RFC6130]) by a reference to 292 this table. 294 +---------+-------------+-------------------------------------------+ 295 | Value | Name | Description | 296 +---------+-------------+-------------------------------------------+ 297 | 0 | THIS_IF | The network address is associated with | 298 | | | this local interface of the sending | 299 | | | router | 300 | 1 | OTHER_IF | The network address is associated with | 301 | | | another local interface of the sending | 302 | | | router | 303 | 2-223 | | Unallocated: Expert Review | 304 | 224-254 | | Experimental Use | 305 | 255 | UNSPECIFIED | No information about this network address | 306 | | | is provided | 307 +---------+-------------+-------------------------------------------+ 309 Table 1: LOCAL_IF TLV Values 311 IANA is requested to create a registry associated with the Address 312 Block TLV with name LINK_STATUS (Type = 3, Type Extension = 0) 313 defined in [RFC6130], specifying the meaning of its single values. 314 This replaces the Description column in the IANA table "LINK_STATUS 315 Address Block TLV Type Extensions" (from Table 7 in [RFC6130]) by a 316 reference to this table. 318 +---------+-------------+-------------------------------------------+ 319 | Value | Name | Description | 320 +---------+-------------+-------------------------------------------+ 321 | 0 | LOST | The link on this interface from the | 322 | | | router with that network address has been | 323 | | | lost | 324 | 1 | SYMMETRIC | The link on this interface from the | 325 | | | router with that network address has the | 326 | | | status of symmetric | 327 | 2 | HEARD | The link on this interface from the | 328 | | | router with that network address has the | 329 | | | status of heard | 330 | 3-223 | | Unallocated: Expert Review | 331 | 224-254 | | Experimental Use | 332 | 255 | UNSPECIFIED | No information about this network address | 333 | | | is provided | 334 +---------+-------------+-------------------------------------------+ 336 Table 2: LINK_STATUS TLV Values 338 IANA is requested to create a registry associated with the Address 339 Block TLV with name OTHER_NEIGHB (Type = 4, Type Extension = 0) 340 defined in [RFC6130], specifying the meaning of its single values. 341 This replaces the Description column in Table 8 in the IANA table 342 "OTHER_NEIGHB Address Block TLV Type Extensions" (from [RFC6130]) by 343 a reference to this table. 345 +---------+-------------+-------------------------------------------+ 346 | Value | Name | Description | 347 +---------+-------------+-------------------------------------------+ 348 | 0 | LOST | The neighbor relationship with the router | 349 | | | with that network address has been lost | 350 | 1 | SYMMETRIC | The neighbor relationship with the router | 351 | | | with that network address is symmetric | 352 | 2-223 | | Unallocated: Expert Review | 353 | 224-254 | | Experimental Use | 354 | 255 | UNSPECIFIED | No information about this network address | 355 | | | is provided | 356 +---------+-------------+-------------------------------------------+ 358 Table 3: OTHER_NEIGHB TLV Values 360 IANA is requested to create a registry associated with the Address 361 Block TLV with name MPR (Type = 8, Type Extension = 0) defined in 362 [OLSRv2], specifying the meaning of its single values in terms of the 363 values of each bit of the value, from bit 0 (most significant) to bit 364 7 (least significant). If multiple bits are set then each applies. 365 This replaces the Description column in the (not yet created) IANA 366 table "MPR Address Block TLV Type Extensions" (from Table 14 in 367 [OLSRv2]) by a reference to this table. 369 +-------+-------+----------+----------------------------------------+ 370 | Value | Value | Name | Description | 371 | Bit | | | | 372 +-------+-------+----------+----------------------------------------+ 373 | 7 | 1 | FLOODING | The neighbor with that network address | 374 | | | | has been selected as flooding MPR | 375 | 6 | 2 | ROUTING | The neighbor with that network address | 376 | | | | has been selected as routing MPR | 377 | 0-5 | | | Unallocated: Expert Review | 378 +-------+-------+----------+----------------------------------------+ 380 Table 4: MPR TLV Bit Values 382 Note that this registry maintains a bit field, and that the 383 combination of the bits FLOODING + ROUTING being set (1) (which gives 384 a value of 3) is given the name FLOOD_ROUTE in [OLSRv2]. For each 385 bit in the field, a set bit (1) means that the address has the 386 designated property, while an unset bit (0) means that no information 387 about the designated property is provided. For future allocations, 388 the Designated Expert has to ensure that this sense is preserved, 389 and, in particular, an unset bit MUST NOT be used to convey any 390 specific information about the designated property. 392 IANA is requested to create a registry associated with the Address 393 Block TLV with name NBR_ADDR_TYPE (Type = 9, Type Extension = 0) 394 defined in [OLSRv2], specifying the meaning of its single values in 395 terms of the values of each bit of the value, from bit 0 (most 396 significant) to bit 7 (least significant). If multiple bits are set 397 then each applies. This replaces the Description column in the (not 398 yet created) IANA table "NBR_ADDR_TYPE Address Block TLV Type 399 Extensions" (from Table 15 in [OLSRv2]) by a reference to this table. 401 +-------+-------+------------+--------------------------------------+ 402 | Value | Value | Name | Description | 403 | Bit | | | | 404 +-------+-------+------------+--------------------------------------+ 405 | 7 | 1 | ORIGINATOR | The network address is an originator | 406 | | | | address reachable via the | 407 | | | | originating router | 408 | 6 | 2 | ROUTABLE | The network address is a routable | 409 | | | | address reachable via the | 410 | | | | originating router | 411 | 0-5 | | | Unallocated: Expert Review | 412 +-------+-------+------------+--------------------------------------+ 414 Table 5: NBR_ADDR_TYPE TLV Bit Values 416 Note that this registry maintains a bit field, and that the 417 combination of the bits ORIGINATOR + ROUTABLE being set (1) (which 418 gives a value of 3) is given the name ROUTABLE_ORIG in [OLSRv2]. For 419 each bit in the field, a set bit (1) means that the address has the 420 designated property, while an unset bit (0) means that no information 421 about the designated property is provided. For future allocations, 422 the Designated Expert has to ensure that this sense is preserved, 423 and, in particular, an unset bit MUST NOT be used to convey any 424 specific information about the designated property. 426 6. Security Considerations 428 The presented updates to [RFC6130] and [OLSRv2]: 430 o Create IANA registries for retaining TLV values for TLVs, already 431 defined in the already published specifications of the two 432 protocols, and with initial registrations for the TLV values 433 defined by these specifications. This does not give rise to any 434 additional security considerations. 436 o Enable protocol extensions to be able to register TLV values in 437 the created IANA registries. Such extensions MUST specify 438 appropriate security considerations. 440 o Create, in some registries, a registration for "UNSPECIFIED" 441 values, for more efficient use of multi-value Address Block TLVs. 442 The interpretation of an address being associated with a TLV of a 443 given type and with the value "UNSPECIFIED" is identical to that 444 address not being associated with a TLV of that type. Thus, this 445 update does not give rise to any additional security 446 considerations. 448 o Reduces the latitude of implementations of the two protocols to 449 reject a message as "badly formed", due to the value field of a 450 TLV being unexpected. These protocols are specified in terms such 451 as "if an address is associated with a value of LOST by a 452 LINK_STATUS TLV". Association with an unknown value (or a value 453 newly defined to mean no link status information) has no effect on 454 such a specification. Thus, this update does not give rise to any 455 additional security considerations. 457 o Do not introduce any opportunities for attacks on the protocols 458 through signal modification that are not already present in the 459 two protocols. 461 7. Acknowledgments 463 The authors would like to gratefully acknowledge the following people 464 for intense technical discussions, early reviews, and comments on the 465 specification (listed alphabetically): Ulrich Herberg (Fujitsu 466 Laboratories of America) and Henning Rogge (Frauenhofer FKIE). 468 8. References 470 8.1. Normative References 472 [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 473 "The Optimized Link State Routing Protocol version 2", 474 work in progress draft-ietf-manet-olsrv2-19, March 2013. 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, March 1997. 479 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 480 "Generalized MANET Packet/Message Format", RFC 5444, 481 February 2009. 483 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 484 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 485 RFC 6130, April 2011. 487 8.2. Informative References 489 [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking 490 (MANET): Routing Protocol Performance Issues and 491 Evaluation Considerations", RFC 2501, January 1999. 493 Authors' Addresses 495 Christopher Dearlove 496 BAE Systems Advanced Technology Centre 497 West Hanningfield Road 498 Great Baddow, Chelmsford 499 United Kingdom 501 Phone: +44 1245 242194 502 Email: chris.dearlove@baesystems.com 503 URI: http://www.baesystems.com/ 505 Thomas Heide Clausen 506 LIX, Ecole Polytechnique 508 Phone: +33 6 6058 9349 509 Email: T.Clausen@computer.org 510 URI: http://www.ThomasClausen.org/