idnits 2.17.1 draft-ietf-manet-rfc5444-usage-01.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 document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC5444, but the abstract doesn't seem to directly say this. It does mention RFC5444 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5444, updated by this document, for RFC5378 checks: 2006-03-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 22, 2015) is 3042 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) -- Duplicate reference: RFC7183, mentioned in 'RFC7188', was also mentioned in 'RFC7183'. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Clausen 3 Internet-Draft LIX, Ecole Polytechnique 4 Updates: 5444 (if approved) C. Dearlove 5 Intended status: Standards Track BAE Systems 6 Expires: June 24, 2016 U. Herberg 7 H. Rogge 8 December 22, 2015 10 Rules For Designing Protocols Using the RFC 5444 Generalized Packet/ 11 Message Format 12 draft-ietf-manet-rfc5444-usage-01 14 Abstract 16 This document updates the generalized MANET packet/message format, 17 specified in RFC 5444, by providing rules and recommendations for how 18 protocols can use that packet/message format. In particular, the 19 mandatory rules prohibit a number of uses of RFC 5444 that have been 20 suggested in various proposals, and which would have led to 21 interoperability problems, to the impediment of protocol extension 22 development, and to an inability to use generic RFC 5444 parsers. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 24, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. History and Purpose . . . . . . . . . . . . . . . . . . . 3 60 1.2. RFC 5444 Features . . . . . . . . . . . . . . . . . . . . 3 61 1.3. Status of This Document . . . . . . . . . . . . . . . . . 5 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 64 4. Information Transmission . . . . . . . . . . . . . . . . . . . 6 65 4.1. Where to Record Information . . . . . . . . . . . . . . . 6 66 4.2. Packets and Messages . . . . . . . . . . . . . . . . . . . 7 67 4.3. Messages, Addresses and Attributes . . . . . . . . . . . . 9 68 4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 9 69 4.5. Information Representation . . . . . . . . . . . . . . . . 11 70 4.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 12 72 5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Address Block Compression . . . . . . . . . . . . . . . . 14 75 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 16 77 6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 [RFC5444] specifies a generalized packet/message format, designed for 89 use by MANET routing protocols. [RFC5498] mandates the use of this 90 format by protocols operating over the manet IP protocol and port 91 numbers that were allocated following its request. 93 Following experiences with [RFC3626] which attempted, but did not 94 quite succeed in, providing a packet/message format accommodating for 95 diverse protocol extensions, [RFC5444] was designed by the MANET 96 working group as a common building block for use by both proactive 97 and reactive MANET routing protocols. 99 1.1. History and Purpose 101 Since the publication of [RFC5444] in 2009, several RFCs have been 102 published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181], 103 [RFC7182], [RFC7183], [RFC7188], and [RFC7631], that use the format 104 of [RFC5444]. The ITU-T recommendation [G9903] also uses the format 105 of [RFC5444] for encoding some of its control signals. In developing 106 these specifications, experience with the use of [RFC5444] has been 107 acquired, specifically with respect to how to write specifications 108 using [RFC5444] so as to ensure "forward compatibility" of a protocol 109 with future extensions, to enable the creation of efficient messages, 110 and to enable the use of an efficient and generic parser for all 111 protocols using [RFC5444]. 113 During the same time period, other suggestions have been made to use 114 [RFC5444] in a manner that would inhibit the development of 115 interoperable protocol extensions, would potentially lead to 116 inefficiencies, or would lead to incompatibilities with generic 117 parsers for [RFC5444]. While these uses were not all explicitly 118 prohibited by [RFC5444], they should be strongly discouraged. This 119 document is intended to prohibit such uses, to present experiences 120 from designing protocols using [RFC5444], and to provide these as 121 guidelines (with their rationale) for future protocol designs using 122 [RFC5444]. 124 1.2. RFC 5444 Features 126 Among the characteristics, and design criteria, of the packet/message 127 format of [RFC5444] are: 129 o It is designed for carrying MANET routing protocol control 130 signals. 132 o It defines a packet as a Packet Header with a set of Packet TLVs, 133 followed by a set of messages. Each message has a well-defined 134 structure consisting of a Message Header (designed for making 135 processing and forwarding decisions) followed by a set of Message 136 TLVs (Type-Length-Value structures), and a set of (address, type, 137 value) associations using Address Blocks and their Address Block 138 TLVs. The [RFC5444] packet/message format then enables the use of 139 simple and generic parsing logic for packets, Message Headers, and 140 message content. 142 A packet may include messages from different protocols, such as 143 [RFC6130] and [RFC7181], in a single transmission. This was 144 observed in [RFC3626] to be beneficial, especially in wireless 145 networks where media contention may be significant. [RFC5444] 146 defines a multiplexing process to achieve this that is mandated by 147 [RFC5498] for use on the manet IP port and UDP port. This makes 148 the contents of the Packet Header, which may also contain Packet 149 TLVs, and the transmission of packets over UDP or directly over 150 IP, the responsibility of this multiplexing process. 152 o Its packets are designed to travel between two neighboring 153 interfaces, which will result in a single decrement/increment of 154 the IPv4 TTL or IPv6 hop limit. The Packet Header and any Packet 155 TLVs should convey information relevant to that link (for example, 156 the Packet Sequence Number can be used to count transmission 157 successes across that link). Packets are not retransmitted, a 158 packet transmission following a successful packet reception may 159 include all, some, or none of the received messages, plus possibly 160 additional messages received in separate packets or generated at 161 that router. Messages may thus travel more than one hop, and are 162 designed to carry end-to-end protocol signals. 164 o It supports "internal extensibility" using TLVs; an extension can 165 add information to an existing message without that information 166 rendering the message un-parseable by a router that does not 167 support the extension. An extension is typically of the protocol 168 that created the message to be extended, for example [RFC7181] 169 adds information to the HELLO messages created by [RFC6130]. 170 However an extension may also be independent of the protocol, for 171 example [RFC7182] can add ICV (Integrity Check Value) and 172 timestamp information to any message (or to a packet, thus 173 extending the [RFC5444] multiplexing process). 175 Information can be added to the message as a whole, such as the 176 [RFC7182] integrity information, or may be associated with 177 specific addresses in the message, such as the MPR selection and 178 link metric information added to HELLO messages by [RFC7181]. An 179 extension may also add addresses to a message. 181 o It uses address aggregation into compact Address Blocks by 182 exploiting commonalities between addresses. In many deployments, 183 addresses (IPv4 and IPv6) used on interfaces share a common prefix 184 that need not be repeated. Using IPv6, several addresses (of the 185 same interface) may have common interface identifiers that need 186 not be repeated. 188 o It sets up common namespaces, formats, and data structures for use 189 by different protocols, where common parsing logic can be used. 190 For example, [RFC5497] defines a generic TLV format for 191 representing time information (such as interval time or validity 192 time). 194 o It contains a minimal Message Header (a maximum of five elements: 195 type, originator, sequence number, hop count and hop limit) that 196 permit decisions whether to locally process a message, or forward 197 a message (thus enabling MANET-wide flooding of a message) without 198 processing the body of the message. 200 1.3. Status of This Document 202 This document updates [RFC5444], and is intended for publication as a 203 Proposed Standard (rather than as Informational) because it specifies 204 and mandates constraints on the use of [RFC5444] which, if not 205 followed, makes forms of extensions of those protocols impossible, 206 impedes the ability to generate efficient messages, or makes 207 desirable forms of generic parsers impossible. 209 2. Terminology 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 213 "OPTIONAL" in this document are to be interpreted as described in 214 [RFC2119]. 216 This document uses the terminology and notation defined in [RFC5444], 217 in particular the terms "packet", "Packet Header", "message", 218 "Message Header", "address", "Address Block", "TLV" and "TLV Block" 219 are to be interpreted as described therein. 221 3. Applicability Statement 223 This document does not specify a protocol, but documents constraints 224 on how to design protocols which are using the generic packet/message 225 format defined in [RFC5444] which, if not followed, makes forms of 226 extensions of those protocols impossible, impedes the ability to 227 generate efficient (small) messages, or makes desirable forms of 228 generic parsers impossible. The use of this format is mandated by 229 [RFC5498] for all protocols running over the manet protocol and port 230 number, defined therein. Thus, the constraints in this document 231 apply to all protocols running over the manet protocol and port 232 number. 234 4. Information Transmission 236 Protocols need to transmit information from one instance implementing 237 the protocol to another. 239 4.1. Where to Record Information 241 A protocol has the following choices as to where to put information 242 for transmission: 244 o In a TLV to be added to the Packet Header. 246 o In a message of a type owned by another protocol. 248 o In a message of a type owned by the protocol. 250 The first case (a Packet TLV) can only be used when the information 251 is to be carried one hop. It SHOULD only be used either where the 252 information relates to the packet as a whole (for example packet 253 integrity check values and timestamps, as specified in [RFC7182]) or 254 if the information is of expected wider application than the single 255 protocol. A protocol can also request that the Packet Header include 256 Packet Sequence Numbers, but does not control those numbers. 258 The second case (in a message of a type owned by another protocol) is 259 only possible if the adding protocol is an extension to the owning 260 protocol, for example OLSRv2 [RFC7181] is an extension of NHDP 261 [RFC6130]. While this is not the most common case, protocols SHOULD 262 be designed to enable this to be possible, and most rules in this 263 document are to help facilitate that. An extension to [RFC5444], 264 such as [RFC7182], is considered to be an extension to all protocols 265 in this regard. 267 The third case is the normal case for a new protocol. Protocols MUST 268 be conservative in the number of new message types that they require, 269 as the total available number of allocatable message types is only 270 224. Protocol design SHOULD consider whether different functions can 271 be implemented by differences in TLVs carried in the same Message 272 Type, rather than using multiple Message Types. If a protocol's 273 needs can be covered by use of the second case, then this SHOULD be 274 done. 276 TLV space, although greater than message space, SHOULD also be used 277 efficiently. The extended type of a TLV occupies two octets, thus 278 there are many more available TLVs. However, in some cases 279 (currently LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from 280 [RFC7182] in the global TLV space) a full set of 256 TLVs is defined 281 (but not necessarily allocated). Each message has a block of message 282 specific TLV Types (128 to 233, each with 256 type extensions), these 283 SHOULD be used in preference to the common TLV Types (0 to 127, each 284 with 256 type extensions) when a TLV is message-specific. 286 A message contains a Message Header and a Message Body; note that the 287 Message TLV Block is considered as part of the latter. The Message 288 Header contains information whose primary purpose is to decide 289 whether to process the message, and whether to forward the message. 291 A message MUST be recognized by the combination of its type, 292 Originator Address and Message Sequence Number. This allows each 293 protocol to manage its own Message Sequence Numbers, and also allows 294 for the possibility that different Message Types may have greatly 295 differing transmission rates. [RFC7181] contains a general purpose 296 process for managing processing and forwarding decisions, albeit one 297 presented as for use with MPR flooding. (Blind flooding can be 298 handled similarly by assuming that all other routers are MPR 299 selectors; it is not necessary in this case to differentiate between 300 interfaces on which a message is received.) 302 Most protocol information is thus contained in the Message Body. A 303 model of how such information may be viewed is described in 304 Section 4.3 and Section 4.4. To use that model, addresses (for 305 example of neighboring or otherwise known routers) SHOULD be recorded 306 in Address Blocks, not as data in TLVs. Recording addresses in TLV 307 Value fields both breaks the model of addresses as identities and 308 associated information (attributes) and also inhibits address 309 compression. However in some cases alternative addresses (e.g., 310 hardware addresses when the Address Block is recording IP addresses) 311 MAY be carried as TLV Values. Note that a message contains a Message 312 Address Length field that can be used to allow carrying alternative 313 message sizes, but only one length of addresses can be used in a 314 single message, in all Address Blocks and the Originator Address. 316 4.2. Packets and Messages 318 The [RFC5444] multiplexing process has to handle packet reception and 319 message demultiplexing, and message transmission and packet 320 multiplexing. 322 When a packet arrives, the following steps are required: 324 o The packet and/or the messages it contains MAY be verified by an 325 extension to the demultiplexer, such as [RFC7182]. 327 o Each message MUST be sent to its owning protocol, which MAY also 328 view the Packet Header, and the source address in the IP datagram 329 that included the packet. 331 o The owning protocol SHOULD verify each message, it SHOULD allow 332 any extending protocol(s) to also contribute to this. 334 o The owning protocol MUST process each message, or make an informed 335 decision not to do so. In the former case an owning protocol that 336 permits this MUST allow any extending protocols to process or 337 ignore the message. 339 Packets are formed for transmission by: 341 o Outgoing messages are created by their owning protocol, and MAY be 342 modified by any extending protocols if the owning protocol permits 343 this. Messages MAY also be forwarded by their owning protocol. 344 It is RECOMMENDED that messages are not modified in the latter 345 case. 347 o Outgoing messages are then sent to the [RFC5444] multiplexing 348 process. The owning protocol MUST indicate which interface(s) the 349 messages are to be sent on and their destination address, and MAY 350 request that messages are kept together in a packet; the 351 multiplexing process SHOULD respect this request if possible. A 352 protocol MAY also request that a Packet Sequence Number and/or 353 specified Packet TLVs are included, such requests SHOULD also be 354 respected if possible. 356 o The multiplexing process SHOULD combine messages from multiple 357 protocols that are sent on the same interface in a packet, 358 provided that in so doing the multiplexing process does not cause 359 an IP packet to exceed the current MTU (Maximum Transmission 360 Unit). (Note that the multiplexing process cannot fragment 361 messages, creating suitable sized messages is the responsibility 362 of the protocol.) 364 o If requested by a protocol the multiplexer SHOULD, and otherwise 365 MAY, include a Packet Sequence Number in the packet. Note that, 366 as per the errata to [RFC5444], this Packet Sequence Number MUST 367 be specific to the interface on which the packet is sent. 369 o An extension to the multiplexing process MAY add TLVs to the 370 packet and/or the messages (for example as by [RFC7182]). 372 4.3. Messages, Addresses and Attributes 374 The information in a Message Body, including Message TLVs and Address 375 Block TLVs, can be considered to consist of: 377 o Attributes of the message, each attribute consisting of an 378 extended type, a length, and a value (of that length). 380 o A set of addresses, carried in one or more Address Blocks. 382 o Attributes of each address, each attribute consisting of an 383 extended type, a length, and a value (of that length). 385 Attributes are carried in TLVs. For Message TLVs the mapping from 386 TLV to attribute is one to one. For Address Block TLVs the mapping 387 from TLV to attribute is one to many, one TLV can carry attributes 388 for multiple addresses, but only one attribute per address. 389 Attributes for different addresses may be the same or different. 391 A TLV extended type MAY be (and this is RECOMMENDED whenever 392 possible) defined so that there may only be one TLV of that extended 393 type associated with the message (Message TLV) or any value of any 394 address (Address Block TLV). Note that an address may appear more 395 than once in a message, but the restriction on associating TLVs with 396 addresses covers all copies of that address. It is RECOMMENDED that 397 addresses are not repeated in a message. 399 4.4. Addresses Require Attributes 401 It is not mandatory in [RFC5444] to associate an address with 402 attributes using Address Block TLVs. Information about an address 403 could thus, in principle be carried using: 405 o The simple presence of an address. 407 o The ordering of addresses in an Address Block. 409 o The use of different meanings for different Address Blocks. 411 This specification, however, requires that those methods of carrying 412 information MUST NOT be used for any protocol using [RFC5444]. 413 Information about the meaning of an address MUST only be carried 414 using Address Block TLVs. 416 In addition, rules for the extensibility of OLSRv2 and NHDP are 417 described in [RFC7188]. This specification extends their 418 applicability to other uses of [RFC5444]. 420 The following points indicate the reasons for these rules, based on 421 considerations of extensibility and efficiency. 423 A protocol MUST NOT assign any meaning to the presence, or absence, 424 of an address, as this would prevent the addition of addresses with 425 other meanings. For example consider NHDP's HELLO messages 426 [RFC6130]. The basic function of a HELLO message is to indicate that 427 an address is of a neighbor, using the LINK_STATUS and OTHER_NEIGHB 428 TLVs. An extension to NHDP might decide to use the HELLO message to 429 report that, for example, an address is one that could be used for a 430 specialized purpose, but not for normal NHDP-based purposes. Such an 431 example already exists (but within the basic specification, rather 432 than as an extension) in the use of LOST Values in the LINK_STATUS 433 and OTHER_NEIGHB TLVs to report that an address is of a router known 434 not to be a neighbor. A future example might be to list an address 435 to be added to a "blacklist" of addresses not to be used. This would 436 be indicated by a new TLV (or a new Value of an existing TLV, see 437 below). An unmodified extension to NHDP would ignore such addresses, 438 as required, as it does not support that specialized purpose. If 439 NHDP had been designed so that just the presence of an address 440 indicated a neighbor, that extension would not have been possible. 442 This example can be taken further. NHDP must also not reject a HELLO 443 message because it contains an unrecognized TLV. This also applies 444 to unrecognized TLV Values, where a TLV supports only a limited set 445 of Values. For example, the blacklisting described in the previous 446 paragraph could be signaled not with a new TLV, but with a new Value 447 of a LINK_STATUS or OTHER_NEIGHB TLV (requiring an IANA allocation as 448 described in [RFC7188]), as is already done in the LOST case. 450 Information may also be added to addresses recognized by the base 451 protocol. For example OLSRv2 [RFC7181] is, among other things, an 452 extension to NHDP. It adds information to addresses in an NHDP HELLO 453 message using a LINK_METRIC TLV. A non-OLSRv2 implementation of 454 NHDP, for example to support Simplified Multicast Flooding (SMF) 455 [RFC6621], must still process the HELLO message, ignoring the 456 LINK_METRIC TLVs. 458 This does not, however, mean that added information is completely 459 ignored for purposes of the base protocol. Suppose that a faulty 460 implementation of OLSRv2 (including NHDP) creates a HELLO message 461 that assigns two different values of the same link metric to an 462 address, something that is not permitted by [RFC7181]. A receiving 463 OLSRv2-aware implementation of NHDP MUST reject such a message, even 464 though a receiving OLSRv2-unaware implementation of NHDP will process 465 it. This is because the OLSRv2-aware implementation has access to 466 additional information, that the HELLO message is definitely invalid, 467 and the message is best ignored, as it is unknown what other errors 468 it may contain. 470 The restrictions on the use of address ordering and an address 471 presence or absence in given Address Blocks for carrying information 472 are for two reasons. First, use of those prevents the approach to 473 information representation described in Section 4.5. Second, it 474 reduces the options available for message optimization described in 475 Section 6. 477 4.5. Information Representation 479 A message (excluding the Message Header) can thus be represented by 480 two, possibly multivalued, maps: 482 o Message: (extended type) -> (length, value) 484 o Address: (address, extended type) -> (length, value) 486 These maps (plus a representation of the Message Header) can be the 487 basis for a generic representation of information in a message. Such 488 maps can be created by parsing the message, or can be constructed 489 using the protocol rules for creating a message, and later converted 490 into the octet form of the message specified in [RFC5444]. 492 While of course any implementation of software that represents 493 software in the above form can specify an application programming 494 interface (API) for that software, such an interface is not proposed 495 here. First, a full API would be programming language specific. 496 Second, even within the above framework, there are alternative 497 approaches to such an interface. For example, and for illustrative 498 purposes only, for the address mapping: 500 o Input: address and extended type. Output: list of (length, value) 501 pairs. Note that for most extended types it will be known in 502 advance that this list will have length zero or one. The list of 503 addresses that can be used as inputs with non-empty output would 504 need to be provided as a separate output. 506 o Input: extended type. Output: list of (address, length, value) 507 triples. As this list length may be significant, a possible 508 output will be of one or two iterators that will allow iterating 509 through that list. (One iterator that can detect the end of list, 510 or a pair of iterators specifying a range.) 512 Additional differences in the interface may relate to, for example, 513 the ordering of output lists. 515 4.6. TLVs 517 Within a message, the attributes are represented by TLVs. 518 Particularly for Address Block TLVs, different TLVs may represent the 519 same information. For example, using the LINK_STATUS TLV defined in 520 [RFC6130], if some addresses have Value SYMMETRIC and some have Value 521 HEARD, arranged in that order, then this information can be 522 represented using two single value TLVs or one multivalue TLV. The 523 latter can be used even if the addresses are not so ordered. 525 A protocol MAY use any representation of information using TLVs that 526 convey the required information. A protocol SHOULD use an efficient 527 representation, but this is a quality of implementation issue. A 528 protocol MUST recognize any permitted representation of the 529 information, even if it chooses to (for example) only use multivalue 530 TLVs, it MUST recognize single value TLVs (and vice versa). 532 A protocol defining new TLVs MUST respect the naming and 533 organizational rules in [RFC7631]. It SHOULD follow the guidance in 534 RFC [RFC7181], except where those requirements are ones that MUST be 535 followed as required by this specification (or when extending 536 [RFC6130] or [RFC7181], when these MUST also be followed). 538 4.7. Message Integrity 540 In addition to not rejecting a message due to unknown TLVs or TLV 541 Values, a protocol MUST NOT fail to forward a message (by whatever 542 means of message forwarding are appropriate to that protocol) due to 543 the presence of such TLVs or TLV Values, and MUST NOT remove such 544 TLVs or TLV Values. Such behavior would have the consequences that: 546 o It might disrupt the operation of an extension of which it is 547 unaware. Note that it is the responsibility of a protocol 548 extension to handle interoperation with unextended instances of 549 the protocol. For example OLSRv2 [RFC7181] adds an MPR_WILLNG TLV 550 to HELLO messages (created by NHDP, [RFC6130], of which it is in 551 part an extension) to recognize this case (and for other reasons). 552 If an incompatible protocol extension were defined, it would be 553 the responsibility of network management to ensure that 554 incompatible routers were not both present in the MANET; this case 555 is NOT RECOMMENDED. 557 o It would prevent the operation of end to end message 558 authentication using [RFC7182], or any similar mechanism. The use 559 of immutable (apart from hop count and/or hop limit) messages by a 560 protocol is strongly RECOMMENDED for that reason. 562 5. Structure 564 The elements defined in [RFC5444] have structures that are managed by 565 a number of flags fields: 567 o Packet flags field (4 bits, 2 used) that manages the contents of 568 the Packet Header. 570 o Message flags field (4 bits, 4 used) that manages the contents of 571 the Message Header. 573 o Address Block flags field (8 bits, 4 used) that manages the 574 contents of an Address Block. 576 o TLV flags field (8 bits, 5 used) that manages the contents of a 577 TLV. 579 Note that all of these flags are structural, they specify which 580 elements are present or absent, or field lengths, or whether a field 581 has one or multiple values in it. 583 In the current version of [RFC5444], indicated by version number 0 in 584 the field of the Packet Header, unused bits in these flags 585 fields "are RESERVED and SHOULD each be cleared ('0') on transmission 586 and SHOULD be ignored on reception". 588 If a specification updating [RFC5444] introduces new flags in one of 589 the flags fields of a packet, message or Address Block, the following 590 rules MUST be followed: 592 o The version number contained in the field of the Packet 593 Header MUST NOT be 0. 595 o The new flag(s) MUST indicate the structure of the corresponding 596 packet, message, Address Block or TLV, and MUST NOT be used to 597 indicate any other semantics, such as message forwarding behavior. 599 An update that would be incompatible with the current specification 600 of [RFC5444] SHOULD NOT be created unless there is a pressing reason 601 for it that cannot be satisfied using the current specification 602 (e.g., by use of a suitable Message TLV). 604 During the development of [RFC5444], and since publication thereof, 605 some proposals have been made to use these RESERVED flags to specify 606 behavior rather than structure, in particular message forwarding. 607 These proposals were, after due consideration, not accepted, for a 608 number of reasons. These reasons include that message forwarding, in 609 particular, is protocol-specific; for example [RFC7181] forwards 610 messages using its MPR (Multi-Point Relay) mechanism, rather than a 611 "blind" flooding mechanism. (The later addition of a 4 bit Message 612 Address Length field later left no unused message flags bits, but 613 other fields still have unused bits.) 615 6. Message Efficiency 617 The ability to organize addresses into different, or the same, 618 Address Blocks, as well as to change the order of addresses within an 619 Address Block, and the flexibility of the TLV specification, enables 620 avoiding unnecessary repetition of information, and consequently can 621 generate smaller messages. No algorithms for address organization or 622 compression or for TLV usage are given in [RFC5444], any algorithms 623 that leave the information content unchanged MAY be used. 625 6.1. Address Block Compression 627 Addresses in an Address Block can be compressed, and SHOULD be. 629 Compression of addresses in an Address Block considers addresses to 630 consist of a Head, a Mid, and a Tail, where all addresses in an 631 Address Block have the same Head and Tail, but different Mids. An 632 additional compression is possible when the Tail consists of all 633 zero-valued octets. Expected use cases are IPv4 and IPv6 addresses 634 from within the same prefix and which therefore have a common Head, 635 IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with 636 a common Tail representing an interface identifier as well as a 637 possible common Head. Note that when, for example, IPv4 addresses 638 have a common Head, their Tail will usually be empty. For example 639 192.0.2.1 and 192.0.2.2 would, for greatest efficiency, have a 3 640 octet Head, a 1 octet Mid, and a 0 octet Tail. 642 Putting addresses into a message efficiently also has to include: 644 o The split of the addresses into Address Blocks. 646 o The order of the addresses within the Address Blocks. 648 This split and/or ordering is for efficiency only, it does not 649 provide any information. The split of the addresses affects both the 650 address compression and the TLV efficiency (see Section 6.2), the 651 order of the addresses within an Address Block affects only the TLV 652 efficiency. However using more Address Blocks than is needed can 653 increase the message size due to the overhead of each Address Block 654 and the following TLV Block, and/or if additional TLVs are now 655 required. 657 The order of addresses can be as simple as sorting the addresses, but 658 if many addresses have the same TLV Types attached, it might be more 659 useful to put these addresses together, either within the same 660 Address Block as other addresses, or in a separate Address Block. A 661 separate address block might also improve address compression, for 662 example if more than one address form is used (such as from 663 independent subnets). An example of the possible use of address 664 ordering is a HELLO message from [RFC6130] which MAY be generated 665 with local interface addresses first and neighbor addresses later. 666 These MAY be in separate Address Blocks. 668 6.2. TLVs 670 The main opportunities for efficient messages when considering TLVs 671 are in Address Block TLVs, rather than Message TLVs. 673 An Address Block TLV provides attributes for one address or a 674 contiguous (as stored in the Address Block) set of addresses (with a 675 special case for when this is all addresses in an Address Block). 676 When associated with more than one address, a TLV may be single value 677 (associating the same attribute with each address) or multivalue 678 (associating a separate attribute with each address). 680 The simplest to implement approach is to use multivalue TLVs that 681 cover all affected addresses. However unless care is taken to order 682 addresses appropriately, these affected addresses may not all be 683 contiguous. Approaches to this are to: 685 o Reorder the addresses. It is, for example, possible (though not 686 straightforward) to order all addresses in HELLO message as 687 specified in [RFC6130] so that all TLVs used only cover contiguous 688 addresses. This is even possible if the MPR TLV specified in 689 OLSRv2 [RFC7181] is added; but it is not possible, in general, if 690 the LINK_METRIC TLV is also added. 692 o Allow the TLV to span over addresses that do not need the 693 corresponding attribute, using a Value that indicates no 694 information, see Section 6.3. 696 o Use more than one TLV. Note that this can be efficient when the 697 TLVs thus become single value TLVs. In a typical case where a 698 LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with 699 enough addresses, sorted appropriately, two single value TLVs can 700 be more efficient than one multivalue TLV. (When only one Value 701 is involved, such as NHDP in a steady state with LINK_STATUS equal 702 to SYMMETRIC in all cases, one single value TLV SHOULD always be 703 used.) 705 6.3. TLV Values 707 If, for example, an Address Block contains five addresses, the first 708 two and the last two requiring Values assigned using a LINK_STATUS 709 TLV, but the third does not, then this can be indicated using two 710 TLVs. It is however more efficient to do this with one multivalue 711 LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED. 712 This approach was specified in [RFC7188], and required for protocols 713 that extend [RFC6130] and [RFC7181]. It is here RECOMMENDED that 714 this approach is followed when defining any Address Block TLV that 715 may be used by a protocol using [RFC5444]. 717 It might be argued that this is not necessary in the example above, 718 because the addresses can be reordered. However ordering addresses 719 in such a way for all possible TLVs is not, in general, possible. 721 As indicated, the LINK_STATUS TLV, and some other TLVs that take 722 single octet Values (per address), have a Value UNSPECIFIED defined, 723 as the Value 255, in [RFC7188]. A similar approach (and a similar 724 Value) is RECOMMENDED in any similar cases. Some other TLVs may need 725 a different approach. As noted in [RFC7188], but implicitly 726 permissible before then, the LINK_METRIC TLV has two octet Values 727 whose first four bits are flags indicating whether the metric applies 728 in four cases; if these are all zero then the metric does not apply 729 in this case, which is thus the equivalent of an UNSPECIFIED Value. 731 6.4. Automation 733 There is scope for creating a protocol-independent optimizer for 734 [RFC5444] messages that performs appropriate address re-organization 735 (ordering and Address Block separation) and TLV changes (of number, 736 single- or multi- valuedness and use of UNSPECIFIED Values) to create 737 more compact messages. The possible gain depends on the efficiency 738 of the original message creation, and the specific details of the 739 message. Note that this process cannot be TLV Type independent, for 740 example a LINK_METRIC TLV has a more complicated Value structure than 741 a LINK_STATUS TLV does if using UNSPECIFIED Values. 743 7. Security Considerations 745 This document does not specify a protocol, but provides rules and 746 recommendations for how to design protocols using [RFC5444]. This 747 document does not introduce any new security considerations; 748 protocols designed according to these rules and recommendations are 749 subject to the security considerations detailed in [RFC5444]. In 750 particular the applicability of the security framework for [RFC5444] 751 specified in [RFC7182] is unchanged. 753 8. IANA Considerations 755 This document has no actions for IANA. 757 9. Acknowledgments 759 TBD. 761 10. References 763 10.1. Normative References 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", RFC 2119, BCP 14, March 1997. 768 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 769 "Generalized MANET Packet/Message Format", RFC 5444, 770 February 2009. 772 10.2. Informative References 774 [G9903] "ITU-T G.9903: Narrow-band orthogonal frequency division 775 multiplexing power line communication transceivers for G3- 776 PLC networks", May 2013. 778 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 779 Routing Protocol", RFC 3626, October 2003. 781 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 782 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 783 March 2009. 785 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 786 (MANET) Protocols", RFC 5498, March 2009. 788 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 789 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 790 RFC 6130, April 2011. 792 [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, 793 May 2012. 795 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 796 "The Optimized Link State Routing Protocol version 2", 797 RFC 7181, April 2014. 799 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 800 Check Value and Timestamp TLV Definitions for Mobile Ad 801 Hoc Networks (MANETs)", RFC 7182, April 2014. 803 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 804 Protection for the Neighborhood Discovery Protocol (NHDP) 805 and Optimized Link State Routing Protocol Version 2 806 (OLSRv2)", RFC 7183, April 2014. 808 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 809 Protocol version 2 (OLSRv2) and MANET Neighborhood 810 Discovery Protocol (NHDP) Extension TLVs", RFC 7183, 811 April 2014. 813 [RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the MANET 814 Generalized Packet/Message Format", RFC 7631, 815 January 2015. 817 Authors' Addresses 819 Thomas Clausen 820 LIX, Ecole Polytechnique 821 91128 Palaiseau Cedex, 822 France 824 Phone: +33-6-6058-9349 825 Email: T.Clausen@computer.org 826 URI: http://www.thomasclausen.org 828 Christopher Dearlove 829 BAE Systems Applied Intelligence Laboratories 830 West Hanningfield Road 831 Great Baddow, Chelmsford 832 United Kingdom 834 Phone: +44 1245 242194 835 Email: chris.dearlove@baesystems.com 836 URI: http://www.baesystems.com/ 838 Ulrich Herberg 840 Email: ulrich@herberg.name 841 URI: http://www.herberg.name 842 Henning Rogge 844 Email: henning.rogge@fkie.fraunhofer.de