idnits 2.17.1 draft-ietf-manet-nhdp-olsrv2-tlv-extension-05.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 (March 5, 2014) is 3667 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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 March 5, 2014 7 Expires: September 6, 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-05 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 September 6, 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 . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. LOCAL_IF Address Block TLVs . . . . . . . . . . . . . . . 8 67 5.1.1. Create New Registry . . . . . . . . . . . . . . . . . 8 68 5.1.2. Modification to Existing Registry . . . . . . . . . . 9 69 5.2. LINK_STATUS Address Block TLVs . . . . . . . . . . . . . . 10 70 5.2.1. Create New Registry . . . . . . . . . . . . . . . . . 10 71 5.2.2. Modification to Existing Registry . . . . . . . . . . 11 72 5.3. OTHER_NEIGHB Address Block TLVs . . . . . . . . . . . . . 12 73 5.3.1. Create New Registry . . . . . . . . . . . . . . . . . 12 74 5.3.2. Modification to Existing Registry . . . . . . . . . . 13 75 5.4. MPR Address Block TLVs . . . . . . . . . . . . . . . . . . 13 76 5.4.1. Create New Registry . . . . . . . . . . . . . . . . . 13 77 5.4.2. Modification to Existing Registry . . . . . . . . . . 14 78 5.5. NBR_ADDR_TYPE Address Block TLVs . . . . . . . . . . . . . 15 79 5.5.1. Create New Registry . . . . . . . . . . . . . . . . . 15 80 5.5.2. Modification to Existing Registry . . . . . . . . . . 16 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 The MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] and the 91 Optimized Link State Routing Protocol, version 2 (OLSRv2) [OLSRv2] 92 are protocols for use in mobile ad hoc networks (MANETs) [RFC2501], 93 based on the Generalized Mobile Ad Hoc Network (MANET) Packet/Message 94 Format [RFC5444]. 96 This document updates [RFC6130] and [OLSRv2], specifically their use 97 of TLV (Type-Length-Value) elements, to increase the extensibility of 98 these protocols, and to enable some improvements in their 99 implementation. 101 This specification reduces the latitude of implementations of 102 [OLSRv2] and [RFC6130] to consider some messages, which will not be 103 created by implementations simply following those specifications, as 104 a reason to consider the message as "badly formed", and thus as a 105 reason to reject the message. This gives greater latitude to the 106 creation of extensions of these protocols, in particular extensions 107 that will interoperate with unextended implementations of those 108 protocols. As part of that, it indicates how TLVs (Type-Length-Value 109 elements) [RFC5444] with unexpected value fields must be handled, and 110 adds some additional options to those TLVs. 112 Note that TLVs with unknown type or type extension are already 113 specified as to be ignored by [RFC6130] and [OLSRv2], and also are 114 not a reason to reject a message. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 [RFC2119]. 123 Additionally, this document uses the terminology of [RFC5444], 124 [RFC6130], and [OLSRv2]. 126 3. Applicability Statement 128 This document updates the specification of the protocols [OLSRv2] and 129 [RFC6130]. 131 Specifically, this specification updates [RFC6130] and [OLSRv2] in 132 the following way: 134 o Removes the latitude of rejecting a message with a TLV with a 135 known type, but with an unexpected TLV Value field, for the TLV 136 Types defined in [RFC6130] and [OLSRv2]. 138 o Specifies the handling of a TLV Value field with unexpected 139 length. 141 o Sets up IANA registries for TLV Values for the Address Block TLVs: 143 * LOCAL_IF, defined in [RFC6130]. 145 * LINK_STATUS, defined in [RFC6130]. 147 * OTHER_NEIGHB, defined in [RFC6130]. 149 * MPR, defined in [OLSRv2], now considered as a bit field. 151 * NBR_ADDR_TYPE, defined in [OLSRv2], now considered as a bit 152 field. 154 o Defines a well-known TLV Value for "UNSPECIFIED" for the Address 155 Block TLV Types LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB, all 156 defined in [RFC6130]. 158 4. TLV Values 160 NHDP [RFC6130] and OLSRv2 [OLSRv2] define a number of TLVs within the 161 framework of [RFC5444]. These TLVs define the meaning of only some 162 of the contents that can be found in a TLV Value field. This 163 limitation may be either only defining certain TLV Values, or 164 considering only some lengths of the TLV Value fields (or single 165 value field in a multi value Address-Block TLV). This specification 166 describes how NHDP [RFC6130] and OLSRv2 [OLSRv2] are to handle TLVs 167 with other TLV Value fields. 169 4.1. Unrecognized TLV Values 171 NHDP and OLSRv2 specify that, in addition to well-defined reasons (in 172 the respective protocol specifications), an implementation of these 173 protocols MAY recognize a message as "badly formed" and therefore 174 "invalid for processing" for other reasons (Section 12.1 of [RFC6130] 175 and Section 16.3.1 of [OLSRv2]). These sections could be interpreted 176 as allowing rejection of a message because a TLV Value field is 177 unrecognized. This specification removes that latitude: 179 o An implementation MUST NOT reject a message because it contains an 180 unrecognized TLV value. Instead, any unrecognised TLV Value field 181 MUST be processed or ignored by an unextended implementation of 182 NHDP or OLSRv2, as described in the following sections. 184 o Hence, this specification removes the 7th, 10th, and 11th bullets 185 in Section 12.1 of [RFC6130]. 187 It should be stressed that this is not a change to [RFC6130] or 188 [OLSRv2], except with regard to not allowing this to be a reason for 189 rejection of a message. [RFC6130] or [OLSRv2] are specified in terms 190 such as "if an address is associated with a value of LOST by a 191 LINK_STATUS TLV". Association with an unrecognized value has no 192 effect on any implementation strictly following such a specification. 194 4.2. TLV Value Lengths 196 The TLVs specified in [RFC6130] and [OLSRv2] may be either single- 197 value or multi-value TLVs. In either case, the length of each item 198 of information encoded in the TLV Value field is the "single-length", 199 defined and calculated as in section 5.4.1 in [RFC5444]. All TLVs 200 specified in [RFC6130] and [OLSRv2] have a one or two octet single- 201 length. These are considered the expected single-lengths of such a 202 received TLV. 204 Other single-length TLV Value fields may be introduced by extensions 205 to [RFC6130] and [OLSRv2]. This document specifies how 206 implementations of [RFC6130] and [OLSRv2], or extensions thereof, 207 MUST behave on receiving TLVs of the TLV types defined in [RFC6130] 208 and [OLSRv2], but with TLV Value fields with other single-length 209 values. 211 The following principles apply: 213 o If the received single-length is greater than the expected single- 214 length, then the excess octets MUST be ignored. 216 o If the received single-length is less than the expected single- 217 length, then the absent octets MUST considered to have all bits 218 cleared (0). 220 Exceptions: 222 o A received CONT_SEQ_NUM with a single-length < 2 SHOULD be 223 considered an error. 225 4.3. Undefined TLV Values 227 [RFC6130] and [OLSRv2] define a number of TLVs, but for some of these 228 TLVs specify meanings for only some TLV Values. This document 229 establishes IANA registries for these TLV Values, with initial 230 registrations reflecting those used by [RFC6130] and [OLSRv2], and as 231 specified in Section 4.3.3. 233 There are different cases of TLV Values with different 234 characteristics. These cases are considered in this section. 236 4.3.1. NHDP TLVs: LOCAL_IF, LINK_STATUS and OTHER_NEIGHB 238 For the Address-Block TLVs LOCAL_IF, LINK_STATUS and OTHER_NEIGHB 239 TLVs, defined in [RFC6130], only a limited number of values are 240 specified for each. These are converted, by this specification, into 241 extensible registries with initial registrations for values defined 242 and used by [RFC6130] - see Section 5. 244 An implementation of [RFC6130], receiving a LOCAL_IF, LINK_STATUS, or 245 OTHER_NEIGHB TLV with any TLV Value other than the values which are 246 defined in [RFC6130] MUST ignore that TLV Value, as well as any 247 corresponding attribute association to the address. 249 4.3.2. OLSRv2 TLVs: MPR and NBR_ADDR_TYPE 251 The Address-Block TLVs MPR and NBR_ADDR_TYPE, defined in [OLSRv2], 252 are similar to those defined in [RFC6130] in having only limited 253 values specified (1, 2 and 3): 1 and 2, represent presence of two 254 different attributes associated to an address, and 3 represents "both 255 1 and 2". 257 These TLV Value fields, are by this specification, converted to bit 258 fields, and MUST be interpreted as such. As the existing definitions 259 of values 1, 2, and 3 behave in that manner, it is likely that this 260 will involve no change to an implementation, but any test of (for 261 example) Value = 1 or Value = 3 MUST be converted to a test of (for 262 example) Value bitand 1 = 1, where "bitand" denotes a bitwise and 263 operation. 265 This specification creates registries for recording reservations of 266 the individual bits in these bitfields, with initial registrations 267 for values defined and used by [OLSRv2] - see Section 5. 269 Other TLVs defined by [OLSRv2] are not affected by this 270 specification. 272 4.3.3. Unspecified TLV Values 274 The registries defined in Section 5 for the LOCAL_IF, LINK_STATUS and 275 OTHER_NEIGHB TLVs each include an additional TLV Value UNSPECIFIED. 276 This TLV Value represents a defined value that, like currently 277 undefined TLV Values, indicates that no information is associated 278 with this address, but will always have this meaning. Such a TLV 279 Value may be used to enable the creation of more efficient multivalue 280 Address Block TLVs, or to simplify an implementation. 282 The similar requirement for the MPR and NBR_ADDR_TYPES TLVs is 283 already satisfied by the TLV Value zero, provided that each bit in 284 the TLV Value is defined as set ('1') when indicating the presence of 285 an attribute, or clear ('0') when indicating the absence of an 286 attribute; this is therefore required for registrations from the 287 relevant registries, see Section 5. 289 For the LINK_METRIC TLV, this is already possible by clearing the 290 most significant bits (0 to 3) of the first octet of the TLV Value. 291 It is RECOMMENDED that in this case the remaining bits of the TLV 292 Value are either all clear ('0') or all set ('1'). 294 5. IANA Considerations 296 IANA is requested to take a total of ten actions as set out in the 297 following sections. 299 5.1. LOCAL_IF Address Block TLVs 301 5.1.1. Create New Registry 303 IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) 304 Parameters". IANA is requested to create a new sub-registry called 305 "LOCAL_IF TLV Values". 307 IANA is requested to populate this registry as specified in Table 1. 309 +---------+-------------+------------------------------+------------+ 310 | Value | Name | Description | Reference | 311 +---------+-------------+------------------------------+------------+ 312 | 0 | THIS_IF | The network address is | [This.I-D] | 313 | | | associated with this local | | 314 | | | interface of the sending | | 315 | | | router | | 316 | 1 | OTHER_IF | The network address is | [This.I-D] | 317 | | | associated with another | | 318 | | | local interface of the | | 319 | | | sending router | | 320 | 2-223 | | Unallocated: Expert Review | | 321 | 224-254 | | Experimental Use | [This.I-D] | 322 | 255 | UNSPECIFIED | No information about this | [This.I-D] | 323 | | | network address is provided | | 324 +---------+-------------+------------------------------+------------+ 326 Table 1: LOCAL_IF TLV Values 328 New assignments are to be made by Expert Review [RFC5226]. 330 The Designated Experts are required to use the guidelines specified 331 in [RFC6130] and [OLSRv2]. IANA is not expected to record this fact 332 in the registry. 334 5.1.2. Modification to Existing Registry 336 IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) 337 Parameters" with a sub-registry called "LOCAL_IF Address Block TLV 338 Type Extensions". This sub-registry currently has an entry for value 339 0. IANA is requested to replace the entry in the Description column 340 for this value with the text "The value is to be interpreted 341 according to the registry LOCAL_IF TLV Values". The resulting table 342 should look as specified in Table 2. 344 +-----------+-----------------------------------------+-------------+ 345 | Type | Description | Reference | 346 | Extension | | | 347 +-----------+-----------------------------------------+-------------+ 348 | 0 | The value is to be interpreted | [RFC6130] | 349 | | according to the registry LOCAL_IF TLV | [This.I-D] | 350 | | Values | | 351 | 1-255 | Unassigned | [This.I-D] | 352 +-----------+-----------------------------------------+-------------+ 354 Table 2: LOCAL_IF Address Block TLV Type Extensions Modifications 356 5.2. LINK_STATUS Address Block TLVs 358 5.2.1. Create New Registry 360 IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) 361 Parameters". IANA is requested to create a new sub-registry called 362 "LINK_STATUS TLV Values". 364 IANA is requested to populate this registry as specified in Table 3. 366 +---------+-------------+------------------------------+------------+ 367 | Value | Name | Description | Reference | 368 +---------+-------------+------------------------------+------------+ 369 | 0 | LOST | The link on this interface | [This.I-D] | 370 | | | from the router with that | | 371 | | | network address has been | | 372 | | | lost | | 373 | 1 | SYMMETRIC | The link on this interface | [This.I-D] | 374 | | | from the router with that | | 375 | | | network address has the | | 376 | | | status of symmetric | | 377 | 2 | HEARD | The link on this interface | [This.I-D] | 378 | | | from the router with that | | 379 | | | network address has the | | 380 | | | status of heard | | 381 | 3-223 | | Unallocated: Expert Review | | 382 | 224-254 | | Experimental Use | [This.I-D] | 383 | 255 | UNSPECIFIED | No information about this | [This.I-D] | 384 | | | network address is provided | | 385 +---------+-------------+------------------------------+------------+ 387 Table 3: LINK_STATUS TLV Values 389 New assignments are to be made by Expert Review [RFC5226]. 391 The Designated Experts are required to use the guidelines specified 392 in [RFC6130] and [OLSRv2]. IANA is not expected to record this fact 393 in the registry. 395 5.2.2. Modification to Existing Registry 397 IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) 398 Parameters" with a sub-registry called "LINK_STATUS Address Block TLV 399 Type Extensions". This sub-registry currently has an entry for value 400 0. IANA is requested to replace the entry in the Description column 401 for this value with the text "The value is to be interpreted 402 according to the registry LINK_STATUS TLV Values". The resulting 403 table should look as specified in Table 4. 405 +-----------+-----------------------------------------+-------------+ 406 | Type | Description | Reference | 407 | Extension | | | 408 +-----------+-----------------------------------------+-------------+ 409 | 0 | The value is to be interpreted | [RFC6130] | 410 | | according to the registry LINK_STATUS | [This.I-D] | 411 | | TLV Values | | 412 | 1-255 | Unassigned | [This.I-D] | 413 +-----------+-----------------------------------------+-------------+ 415 Table 4: LINK_STATUS Address Block TLV Type Extensions Modifications 417 5.3. OTHER_NEIGHB Address Block TLVs 419 5.3.1. Create New Registry 421 IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) 422 Parameters". IANA is requested to create a new sub-registry called 423 "OTHER_NEIGHB TLV Values". 425 IANA is requested to populate this registry as specified in Table 5. 427 +---------+-------------+------------------------------+------------+ 428 | Value | Name | Description | Reference | 429 +---------+-------------+------------------------------+------------+ 430 | 0 | LOST | The neighbor relationship | [This.I-D] | 431 | | | with the router with that | | 432 | | | network address has been | | 433 | | | lost | | 434 | 1 | SYMMETRIC | The neighbor relationship | [This.I-D] | 435 | | | with the router with that | | 436 | | | network address is symmetric | | 437 | 2-223 | | Unallocated: Expert Review | | 438 | 224-254 | | Experimental Use | [This.I-D] | 439 | 255 | UNSPECIFIED | No information about this | [This.I-D] | 440 | | | network address is provided | | 441 +---------+-------------+------------------------------+------------+ 443 Table 5: OTHER_NEIGHB Address Block TLV Values 445 New assignments are to be made by Expert Review [RFC5226]. 447 The Designated Experts are required to use the guidelines specified 448 in [RFC6130] and [OLSRv2]. IANA is not expected to record this fact 449 in the registry. 451 5.3.2. Modification to Existing Registry 453 IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) 454 Parameters" with a sub-registry called "OTHER_NEIGHB Address Block 455 TLV Type Extensions". This sub-registry currently has an entry for 456 value 0. IANA is requested to replace the entry in the Description 457 column for this value with the text "The value is to be interpreted 458 according to the registry OTHER_NEIGHB TLV Values". The resulting 459 table should look as specified in Table 6. 461 +-----------+-----------------------------------------+-------------+ 462 | Type | Description | Reference | 463 | Extension | | | 464 +-----------+-----------------------------------------+-------------+ 465 | 0 | The value is to be interpreted | [RFC6130] | 466 | | according to the registry OTHER_NEIGHB | [This.I-D] | 467 | | TLV Values | | 468 | 1-255 | Unassigned | [This.I-D] | 469 +-----------+-----------------------------------------+-------------+ 471 Table 6: OTHER_NEIGHB Address Block TLV Type Extensions Modifications 473 5.4. MPR Address Block TLVs 475 5.4.1. Create New Registry 477 IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) 478 Parameters". IANA is requested to create a new sub-registry called 479 "MPR TLV Bit Values". 481 IANA is requested to populate this registry as specified in Table 7. 483 +-----+-------+----------+-----------------------------+------------+ 484 | Bit | Value | Name | Description | Reference | 485 +-----+-------+----------+-----------------------------+------------+ 486 | 7 | 0x01 | Flooding | The neighbor with that | [This.I-D] | 487 | | | | network address has been | | 488 | | | | selected as flooding MPR | | 489 | 6 | 0x02 | Routing | The neighbor with that | [This.I-D] | 490 | | | | network address has been | | 491 | | | | selected as routing MPR | | 492 | 0-5 | | | Unallocated: Expert Review | | 493 +-----+-------+----------+-----------------------------+------------+ 495 Table 7: MPR Address Block TLV Bit Values 497 New assignments are to be made by Expert Review [RFC5226]. 499 The Designated Experts are required to use the guidelines specified 500 in [RFC6130] and [OLSRv2]. Additionally, the Designated Experts are 501 required to ensure that the following sense is preserved: 503 o For each bit in the field, a set bit (1) means that the address 504 has the designated property, while an unset bit (0) means that no 505 information about the designated property is provided. In 506 particular, an unset bit must not be used to convey any specific 507 information about the designated property. IANA is not expected 508 to record these facts in the registry. 510 5.4.2. Modification to Existing Registry 512 IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) 513 Parameters" with a sub-registry called "MPR Address Block TLV Type 514 Extensions". This sub-registry currently has an entry for value 0. 515 IANA is requested to replace the entry in the Description column for 516 this value with the text "The value is to be interpreted according to 517 the registry MPR TLV Bit Values". The resulting table should look as 518 specified in Table 8. 520 +-----------+-----------------------------------------+-------------+ 521 | Type | Description | Reference | 522 | Extension | | | 523 +-----------+-----------------------------------------+-------------+ 524 | 0 | The value is to be interpreted | [OLSRv2] | 525 | | according to the registry MPR TLV Bit | [This.I-D] | 526 | | Values | | 527 | 1-255 | Unassigned | [This.I-D] | 528 +-----------+-----------------------------------------+-------------+ 530 Table 8: MPR Address Block TLV Type Extensions Modifications 532 5.5. NBR_ADDR_TYPE Address Block TLVs 534 5.5.1. Create New Registry 536 IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) 537 Parameters". IANA is requested to create a new sub-registry called 538 "NBR_ADDR_TYPE Address Block TLV Bit Values". 540 IANA is requested to populate this registry as specified in Table 9. 542 +-----+-------+------------+---------------------------+------------+ 543 | Bit | Value | Name | Description | Reference | 544 +-----+-------+------------+---------------------------+------------+ 545 | 7 | 0x01 | ORIGINATOR | The network address is an | [This.I-D] | 546 | | | | originator address | | 547 | | | | reachable via the | | 548 | | | | originating router | | 549 | 6 | 0x02 | ROUTABLE | The network address is a | [This.I-D] | 550 | | | | routable address | | 551 | | | | reachable via the | | 552 | | | | originating router | | 553 | 0-5 | | | Unallocated: Expert | | 554 | | | | Review | | 555 +-----+-------+------------+---------------------------+------------+ 557 Table 9: NBR_ADDR_TYPE Address Block TLV Bit Values 559 New assignments are to be made by Expert Review [RFC5226]. 561 The Designated Experts are required to use the guidelines specified 562 in [RFC6130] and [OLSRv2]. Additionally, the Designated Experts are 563 required to ensure that the following sense is preserved: 565 o For each bit in the field, a set bit (1) means that the address 566 has the designated property, while an unset bit (0) means that no 567 information about the designated property is provided. In 568 particular, an unset bit must not be used to convey any specific 569 information about the designated property. IANA is not expected 570 to record these facts in the registry. 572 5.5.2. Modification to Existing Registry 574 IANA maintains a registry called "Mobile Ad hoc NETwork (MANET) 575 Parameters" with a sub-registry called "NBR_ADDR_TYPE Address Block 576 TLV Type Extensions". This sub-registry currently has an entry for 577 value 0. IANA is requested to replace the entry in the Description 578 column for this value with the text "The value is to be interpreted 579 according to the registry NBR_ADDR_TYPE TLV Bit Values". The 580 resulting table should look as specified in Table 10. 582 +-----------+------------------------------------------+------------+ 583 | Type | Description | Reference | 584 | Extension | | | 585 +-----------+------------------------------------------+------------+ 586 | 0 | The value is to be interpreted according | [OLSRv2] | 587 | | to the registry NBR_ADDR_TYPE Address | [This.I-D] | 588 | | Block TLV Bit Values | | 589 | 1-255 | Unassigned | [This.I-D] | 590 +-----------+------------------------------------------+------------+ 592 Table 10: NBR_ADDR_TYPE Address Block TLV Type Extensions 593 Modifications 595 6. Security Considerations 597 The presented updates to [RFC6130] and [OLSRv2]: 599 o Create IANA registries for retaining TLV values for TLVs, already 600 defined in the already published specifications of the two 601 protocols, and with initial registrations for the TLV values 602 defined by these specifications. This does not give rise to any 603 additional security considerations. 605 o Enable protocol extensions to be able to register TLV values in 606 the created IANA registries. Such extensions MUST specify 607 appropriate security considerations. 609 o Create, in some registries, a registration for "UNSPECIFIED" 610 values, for more efficient use of multi-value Address Block TLVs. 611 The interpretation of an address being associated with a TLV of a 612 given type and with the value "UNSPECIFIED" is identical to that 613 address not being associated with a TLV of that type. Thus, this 614 update does not give rise to any additional security 615 considerations. 617 o Reduces the latitude of implementations of the two protocols to 618 reject a message as "badly formed", due to the value field of a 619 TLV being unexpected. These protocols are specified in terms such 620 as "if an address is associated with a value of LOST by a 621 LINK_STATUS TLV". Association with an unknown value (or a value 622 newly defined to mean no link status information) has no effect on 623 such a specification. Thus, this update does not give rise to any 624 additional security considerations. 626 o Do not introduce any opportunities for attacks on the protocols 627 through signal modification that are not already present in the 628 two protocols. 630 7. Acknowledgments 632 The authors would like to gratefully acknowledge the following people 633 for intense technical discussions, early reviews, and comments on the 634 specification (listed alphabetically): Ulrich Herberg (Fujitsu 635 Laboratories of America) and Henning Rogge (Frauenhofer FKIE). 637 The authors would also like to express their gratitude to Adrian 638 Farrel, for his assistance and contributions to successful and timely 639 completion of this specification. 641 8. References 643 8.1. Normative References 645 [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 646 "The Optimized Link State Routing Protocol version 2", 647 work in progress draft-ietf-manet-olsrv2-19, March 2013. 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, March 1997. 652 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 653 "Generalized MANET Packet/Message Format", RFC 5444, 654 February 2009. 656 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 657 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 658 RFC 6130, April 2011. 660 8.2. Informative References 662 [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking 663 (MANET): Routing Protocol Performance Issues and 664 Evaluation Considerations", RFC 2501, January 1999. 666 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 667 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 668 May 2008. 670 Authors' Addresses 672 Christopher Dearlove 673 BAE Systems Advanced Technology Centre 674 West Hanningfield Road 675 Great Baddow, Chelmsford 676 United Kingdom 678 Phone: +44 1245 242194 679 Email: chris.dearlove@baesystems.com 680 URI: http://www.baesystems.com/ 682 Thomas Heide Clausen 683 LIX, Ecole Polytechnique 685 Phone: +33 6 6058 9349 686 Email: T.Clausen@computer.org 687 URI: http://www.ThomasClausen.org/