idnits 2.17.1 draft-ietf-manet-rfc5444-usage-00.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 (June 23, 2015) is 3227 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 (~~), 1 warning (==), 4 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 AI Labs 6 Expires: December 25, 2015 U. Herberg 7 H. Rogge 8 June 23, 2015 10 Rules For Designing Protocols Using the RFC5444 Generalized Packet/ 11 Message Format 12 draft-ietf-manet-rfc5444-usage-00 14 Abstract 16 This document updates the generalized MANET packet/message format, 17 specified in RFC5444, by providing prescriptive guidelines for how 18 protocols can use that packet/message format. In particular, these 19 mandatory guidelines prohibit a number of uses of RFC5444 that have 20 been suggested in various proposals, and which would have lead to 21 interoperability problems, to impediment of protocol extension 22 development, and to inability to use generic RFC5444 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 December 25, 2015. 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 . . . . . . . . . . . . 8 68 4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 9 69 4.5. Information Representation . . . . . . . . . . . . . . . . 10 70 4.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 11 71 5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. Addressesblock compression . . . . . . . . . . . . . . . . 13 74 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 14 76 6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 [RFC5444] specifies a generalized packet/message format, designed for 88 use by MANET routing protocols. [RFC5498] mandates the use of this 89 format by protocols operating over the manet IP protocol and port 90 numbers whose allocation it requested. 92 Following experiences with [RFC3626] which attempted - but did not 93 quite succeed in - providing a packet/message format accommodating 94 for diverse protocol extensions, [RFC5444] was designed by the MANET 95 working group as a common building block for use by both proactive 96 and reactive MANET routing protocols. 98 1.1. History and Purpose 100 Since the publication of [RFC5444] in 2009, several RFCs have been 101 published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181], 102 [RFC7182], [RFC7183], and [RFC7188], which use the format of 103 [RFC5444]. The ITU-T recommendation [G9903] also uses the format of 104 [RFC5444] for encoding some of its control signals. In developing 105 these specifications, experience with the use of [RFC5444] has been 106 acquired, specifically with respect to how to write specifications 107 using [RFC5444] so as to (i) enable the use of an efficient and 108 generic parser for all protocols using [RFC5444], (ii) ensure 109 "forward compatibility" of a protocol with future extensions, and 110 (iii) enable the creation of efficient messages. 112 During the same time period, other suggestions have been made to use 113 [RFC5444] in a manner that would lead to incompatibilities with 114 generic RFC 5444 parsers, would inhibit the development of 115 interoperable protocol extensions, or would potentially lead to 116 inefficiencies. While these uses were not all explicitly prohibited 117 by [RFC5444], they should be strongly discouraged. This document is 118 intended to prohibit such uses, to present experiences from designing 119 protocols using [RFC5444] and to provide these as guidelines (with 120 their rationale) for future protocol designs using [RFC5444]. 122 1.2. RFC 5444 Features 124 Among the characteristics, and design criteria, of the packet/message 125 format of [RFC5444] are: 127 o It is designed for carrying MANET routing protocol control 128 signals. 130 o It defines a packet as a packet header with a set of packet TLVs, 131 followed by a set of messages. Each message has a well-defined 132 structure consisting of a message header (designed for making 133 processing and forwarding decisions) followed by set of message 134 TLVs (Type-Length-Value structures), and a set of (address, type, 135 value) associations using address blocks and their address block 136 TLVs. The [RFC5444] packet/message format then enables the use of 137 simple and generic parsing logic for packets, message headers, and 138 message content. 140 A packet may include messages from different protocols, such as 141 [RFC6130] and [RFC7181], in a single transmission. This was 142 observed in [RFC3626] to be beneficial, especially in wireless 143 networks where media contention may be significant. [RFC5444] 144 defines a multiplexing process to achieve this that is mandated by 145 [RFC5498] for use on the manet IP port and UDP port. This makes 146 the contents of the packet header, which may also contain packet 147 TLVs, and the transmission of packet over UDP or directly over IP, 148 the responsibility of this multiplexing process. 150 o A packet is designed to travel between two neighboring interfaces, 151 which will result in a single decrement/increment of the IPv4 TTL 152 or IPv6 hop limit. The packet header and any packet TLVs should 153 convey information relevant to that link (for example, the packet 154 sequence number can be used to count transmission successes across 155 that link). Packets are not retransmitted, a packet transmission 156 following a successful packet reception may include all, some, or 157 none of the received messages, plus possibly additional messages 158 received in separate packets or generated at that router. 159 Messages may thus travel more than one hop, and are designed to 160 carry end-to-end protocol signals. 162 o It supports "internal extensibility" using TLVs; an extension can 163 add information to an existing message type without that 164 information rendering the message un-parseable by a router that 165 does not support the extension. An extension is typically of the 166 protocol that created the message to be extended, for example 167 [RFC7181] adds information to the HELLO messages created by 168 [RFC6130]. However an extension may also be independent of the 169 protocol, for example [RFC7182] can add ICV (Integrity Check 170 Value) and timestamp information to any message (or to a packet, 171 thus extending the [RFC5444] multiplexing process). 173 Information can be added to the message as a whole, such as the 174 [RFC7182] integrity information, or may be associated with 175 specific addresses in the message, such as the MPR selection and 176 link metric information added to HELLO messages by [RFC7181]. An 177 extension may also add addresses to a message. 179 o It uses address aggregation into compact address blocks by 180 exploiting commonalities between addresses. In many deployments, 181 addresses (IPv4 and IPv6) used on interfaces share a common prefix 182 that need not be repeated. Using IPv6, several addresses (of the 183 same interface) may have a common interface Identifiers, also, 184 that need not be repeated. 186 o It sets up common namespaces, formats, and data structures for use 187 by different protocols, where common parsing logic can be used. 188 For example, [RFC5497] defines a generic TLV type for representing 189 time information (such as interval time or validity time). 191 o It contains a minimal message header (a maximum of five elements: 192 type, originator, sequence number, hop count and limit) that 193 permit decisions whether to locally process a message, or forward 194 a message (thus enabling MANET-wide flooding of a message) without 195 processing the body of the message. 197 1.3. Status of This Document 199 This document updates [RFC5444], and is intended for publication as a 200 Proposed Standard (rather than as Informational) because it specifies 201 and mandates constraints on the use of [RFC5444] which, if not 202 followed, make desirable forms of generic parsers impossible, or make 203 forms of extensions of those protocols impossible, or impedes on the 204 ability to generate efficient messages. 206 2. Terminology 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 210 "OPTIONAL" in this document are to be interpreted as described in 211 [RFC2119]. 213 This document uses the terminology and notation defined in [RFC5444], 214 specifically the terms "Packet", "Packet Header", "Message", "Message 215 Header", "Address", "Address Block", "TLV" and "TLV Block" are to be 216 interpreted as described therein. 218 3. Applicability Statement 220 This document does not specify a protocol, but documents constraints 221 on how to design protocols which are using the generic packet/message 222 format defined in [RFC5444] which, if not followed, make desirable 223 forms of generic parsers impossible, or make forms of extensions of 224 those protocols impossible, or impedes on the ability to generate 225 efficient (small) messages. The use of this format is mandated by 226 [RFC5498] for all protocols running over the MANET protocol and port 227 number, defined therein. Thus, the constraints in this document 228 apply to all protocols running over the MANET protocol and port 229 number. 231 4. Information Transmission 233 Protocols need to transmit information from one instance implementing 234 the protocol to another. 236 4.1. Where to Record Information 238 A protocol has the following choices as to where to put information 239 for transmission: 241 o In a TLV to be added to the packet header. 243 o In a message of a type owned by another protocol. 245 o In a message of a type owned by the protocol. 247 The first case (a Packet TLV) can only be used when the information 248 is to be carried one hop. It SHOULD only be used either where the 249 information relates to the packet as a whole (for example packet 250 integrity check values and timestamps, as specified in [RFC7182]) or 251 if the information is of expected wider application than the single 252 protocol. A protocol can also request that the packet header include 253 packet sequence numbers, but does not control those numbers. 255 The second case (in a message of a type owned by another protocol) is 256 only possible if the adding protocol is an extension to the owning 257 protocol, for example OLSRv2 [RFC7181] is an extension of NHDP 258 [RFC6130]. #### SEE COMMENTS IN SVN COMMIT MESSAGE AND ON LIST #### 259 While this is not the most common case, protocols SHOULD be designed 260 to enable this to be possible, and most rules in this document are to 261 help facilitate that. An extension to [RFC5444], such as [RFC7182] 262 is considered to be an extension to all protocols in this regard. 264 The third case is the normal case for a new protocol. Protocols MUST 265 be conservative in the number of new message types that they require, 266 as the total available number of allocatable message types is only 267 224. Protocol design SHOULD consider whether different functions can 268 be implemented by differences in TLVs carried in the same message 269 type, rather than using multiple message types. If a protocol's 270 needs can be covered by use of the second case, then this SHOULD be 271 considered. 273 TLV space, although greater than message space, SHOULD also be used 274 efficiently. The full type of TLV occupies two octets, thus there 275 are many more available TLVs. However, in some cases (currently 276 LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from [RFC7182] in 277 the global TLV space) a full set of 256 TLVs is defined (but not 278 necessarily allocated). Each message has a block of message specific 279 TLV types (128 to 233, each with 256 type extensions), these SHOULD 280 be used in preference to the common TLV types (0 to 127, each with 281 256 type extensions) when a TLV is message-specific. 283 A message contains a message header and a message body; note that the 284 Message TLV block is considered as part of the latter. The message 285 header contains information whose primary purpose is to decide 286 whether to process the message, and whether to forward the message. 287 [RFC7181] contains a general purpose process for doing that, albeit 288 one presented as for use with MPR flooding. (Blind flooding can be 289 handled similarly by assuming that all other routers are MPR 290 selectors; it is not necessary in this case to differentiate between 291 interfaces on which a message is received.) 293 Most protocol information is thus contained in the message body. A 294 model of how such information may be viewed is described in the 295 following section. To use that model, addresses (for example of 296 neighboring or otherwise known routers) SHOULD be recorded in address 297 blocks, not as data in TLVs. Recording addresses in TLV value fields 298 both breaks the model of addresses as identities and associated 299 information (attributes) and also inhibits address compression. 300 However in some cases alternative addresses (e.g., HW addresses when 301 the address block is recording IP addresses) MAY be carried as TLV 302 values. Note that a message contains a Message Address Length (MAL) 303 field that can be used to allow carrying alternative message sizes, 304 but only one length of addresses in all address blocks can be used in 305 a single message. 307 4.2. Packets and Messages 309 The [RFC5444] multiplexing process has to handle packet reception and 310 message demultiplexing, and message transmission and packet 311 multiplexing. 313 When a packet arrives, the following steps are required: 315 o The packet and/or the messages it contains MAY be verified by an 316 extension to the demultiplexer, such as [RFC7182]. 318 o Each message MUST be sent to its owning protocol, which MAY also 319 view the packet header. 321 o The owning protocol SHOULD verify each message, it SHOULD allow 322 any extending protocol(s) to also contribute to this. 324 o The owning protocol MUST process each message, or make an informed 325 decision not to do so. In the former case an owning protocol that 326 permits this MUST allow any extending protocols to process or 327 ignore the message. 329 Packets are formed for transmission by: 331 o Outgoing messages MAY be created by the owning protocol, and MAY 332 be modified by any extending protocols if the owning protocol 333 permits this. Messages MAY also be forwarded by their owning 334 protocol. It is RECOMMENDED that messages are not modified in the 335 latter case. 337 o Outgoing messages are then sent to the [RFC5444] multiplexing 338 process. The owning protocol MAY request that messages are kept 339 together in a packet, the multiplexing process SHOULD respect this 340 request if possible. A protocol MAY also request that a packet 341 sequence number and/or specified packet TLVs are included, such 342 requests SHOULD also be respected if possible. 344 o The multiplexing process MAY combine messages from multiple 345 protocols in a packet. 347 o An extension to the multiplexing process MAY add TLVs to the 348 packet and/or the messages (for example as by [RFC7182]). 350 4.3. Messages, Addresses and Attributes 352 The information in a message body, including Message TLVs and Address 353 Block TLVs, can be considered to consist of: 355 o Attributes of the message, each attribute consisting of an 356 extended type, a length, and a value (of that length). 358 o A set of addresses, carried in one or more Address Blocks. 360 o Attributes of each address, each attribute consisting of an 361 extended type, a length, and a value (of that length). 363 Attributes are carried in TLVs. For Message TLVs the mapping from 364 TLV to attribute is one to one. For Address Block TLVs the mapping 365 from TLV to attribute is one to many, one TLV can carry attributes 366 for multiple addresses, but only one attribute per address. 367 Attributes for different addresses may be the same or different. 369 A TLV extended type may be (and this is RECOMMENDED whenever 370 possible) defined so that there may only be one TLV of that extended 371 type associated with the message (Message TLV) or any value of any 372 address (Address TLV). Note that an address may appear more than 373 once in a message, but the restriction on associating TLVs with 374 addresses covers all copies of that address. It is RECOMMENDED that 375 addresses are not repeated in a message. 377 4.4. Addresses Require Attributes 379 It is not mandatory in [RFC5444] to associate an address with 380 attributes using Address Block TLVs, information about an address 381 could thus, in principle be carried using: 383 o The simple presence of an address. 385 o The ordering of addresses in an address block. 387 o The use of different meanings for different address blocks. 389 This specification, however, requires that those methods of carrying 390 information MUST NOT be used for any protocol using [RFC5444]. 391 Information about the meaning of an address MUST only be carried 392 using Address Block TLVs. 394 In addition, rules for the extensibility of OLSRv2 and NHDP are 395 described in [RFC7188]. This specification extends their 396 applicability to other uses of [RFC5444]. 398 The following points indicate the reasons for these rules, based on 399 considerations of extensibility and efficiency. 401 A protocol MUST NOT assign any meaning to the presence, or absence, 402 of an address, as this would prevent the addition of addresses with 403 other meanings. For example consider NHDP's HELLO messages 404 [RFC6130]. The basic function of a HELLO message is to indicate that 405 an address is of a neighbor, using the LINK_STATUS and OTHER_NEIGHB 406 TLVs. An extension to NHDP might decide to use the HELLO message to 407 report that, for example, an address is one that could be used for a 408 specialized purpose, but not for normal NHDP-based purposes. Such an 409 example already exists (but within the basic specification, rather 410 than as an extension) in the use of LOST values in the LINK_STATUS 411 and OTHER_NEIGHB TLVs to report that an address is of a router known 412 not to be a neighbor. A future example might be to list an address 413 to be added to a "blacklist" of addresses not to be used. This would 414 be indicated by a new TLV (or a new value of an existing TLV, see 415 below). An unmodified extension to NHDP would ignore such addresses, 416 as required, as it does not support that specialized purpose. If 417 NHDP had been designed so that just the presence of an address 418 indicated a neighbor, that extension would not have been possible. 420 This example can be taken further. NHDP must also not reject a HELLO 421 message because it contains an unrecognized TLV. This also applies 422 to unrecognized TLV values, where a TLV supports only a limited set 423 of values. For example, the blacklisting described in the previous 424 paragraph could be signaled not with a new TLV, but with a new value 425 of a LINK_STATUS or OTHER_NEIGHB TLV (requiring an IANA allocation as 426 described in [RFC7188]), as is already done in the LOST case. 428 Information may also be added to addresses recognized by the base 429 protocol. For example OLSRv2 [RFC7181] is, among other things, an 430 extension to NHDP. It adds information to addresses in an NHDP HELLO 431 message using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP 432 (for example, to support SMF [RFC6621]) must still process the HELLO 433 message, ignoring the LINK_METRIC TLVs. 435 This does not, however, mean that added information is completely 436 ignored for purposes of the base protocol. Suppose that a faulty 437 implementation of OLSRv2 (including NHDP) creates a HELLO message 438 that assigns two different values of the same link metric to an 439 address, something which is not permitted by [RFC7181]. A receiving 440 OLSRv2-aware implementation of NHDP should reject such a message, 441 even though a receiving OLSRv2-unaware implementation of NHDP will 442 process it. This is because the OLSRv2-aware implementation has 443 access to additional information, that the HELLO message is 444 definitely invalid, and the message is best ignored, as it is unknown 445 what other errors it may contain. 447 The restrictions on the use of address ordering and an address 448 presence or absence in given address blocks for carrying information 449 are for two reasons. First use of those prevents the approach to 450 information representation described in Section 4.5. Second, it 451 reduces the options available for message optimization described in 452 Section 6. 454 4.5. Information Representation 456 A message (excluding the message header) can thus be represented by 457 two, possibly multivalued, maps: 459 o Message: (extended type) -> (length, value) 461 o Address: (address, extended type) -> (length, value) 463 These maps (plus a representation of the message header) can be the 464 basis for a generic representation of information in a message. Such 465 maps can be created by parsing the message, or can be constructed 466 using the protocol rules for creating a message, and later converted 467 into the octet form of the message specified in [RFC5444]. 469 While of course any implementation of software that represents 470 software in the above form can specify an application programming 471 interface (API) for that software, such an interface is not proposed 472 here. First, a full API would be programming language specific. 473 Second, even within the above framework, there are alternative 474 approaches to such an interface. For example, and for illustrative 475 purposes only, for the address mapping: 477 o Input: address and extended type. Output: list of (length, value) 478 pairs. Note that for most extended types it will be known in 479 advance that this list will have length zero or one. The list of 480 addresses that can be used as inputs with non-empty output would 481 need to be provided as a separate output. 483 o Input: extended type. Output: list of (address, length, value) 484 triples. As this list length may be significant, the likely 485 output will be of one or two iterators that will allow iterating 486 through that list. (One iterator that can detect the end of list, 487 or a pair of iterators specifying a range.) 489 Additional differences in the interface may relate to, for example, 490 the ordering of output lists. 492 4.6. Message Integrity 494 In addition to not rejecting a message due to unknown TLVs or TLV 495 values, a protocol MUST NOT fail to forward a message (by whatever 496 means of message forwarding are appropriate to that protocol) due to 497 the presence of such TLVs or TLV values, and MUST NOT remove such 498 TLVs or values. Such behavior would have the consequences that: 500 o It might disrupt the operation of an extension of which it is 501 unaware. Note that it is the responsibility of a protocol 502 extension to handle interoperation with unextended instances of 503 the protocol. For example OLSRv2 [RFC7181] adds an MPR_WILLNG TLV 504 to HELLO messages (created by NHDP, [RFC6130], of which it is in 505 part an extension) to recognize this case (and for other reasons). 506 If an incompatible protocol extension were defined, it would be 507 the responsibility of network management to ensure that 508 incompatible routers were not both present in the MANET, this case 509 is NOT RECOMMENDED. 511 o It would prevent the operation of end to end message 512 authentication using [RFC7182], or any similar mechanism. The use 513 of immutable (apart from hop count and/or limit) messages by a 514 protocol is strongly RECOMMENDED for that reason. 516 5. Structure 518 The elements defined in [RFC5444] have structures that are managed by 519 a number of flags fields: 521 o Packet flags (4 bits, 2 used) that manages the contents of the 522 packet header. 524 o Message flags (4 bits, 4 used) that manages the contents of the 525 message header. 527 o Address Block flags (8 bits, 4 used) that manages the contents of 528 an Address Block. 530 o TLV flags (8 bits, 5 used) that manages the contents of a TLV. 532 Note that all of these flags are structural, they specify which 533 elements are present or absent, or field lengths, or whether a field 534 has one or multiple values in it. 536 In the current version of [RFC5444], indicated by version number 0 in 537 the field of the packet header, unused bits in these flags 538 fields "are RESERVED and SHOULD each be cleared ('0') on transmission 539 and SHOULD be ignored on reception.". 541 If a specification introduces new flags in one of the flags fields of 542 a packet, message or Address Block, the following rules MUST be 543 followed: 545 o The version number contained in the field of the packet 546 header MUST NOT be 0. 548 o The new flag(s) MUST indicate the structure of the corresponding 549 packet, message, Address Block or TLV, and MUST NOT be used to 550 indicate any other semantics, such as message forwarding behavior. 552 During the development of [RFC5444], and since publication hereof, 553 some proposals have been made to use these RESERVED flags to specify 554 behavior rather than structure, in particular message forwarding. 555 These were, after due consideration, not accepted, for a number of 556 reasons. These include that message forwarding, in particular, is 557 protocol-specific. For example [RFC7181] forwards messages using its 558 MPR (Multi-Point Relay) mechanism, rather than a "blind" flooding 559 mechanism. The later addition of a 4 bit Message Address Length 560 field later left no spare flags bits at the message level for such 561 use. 563 6. Message Efficiency 565 The ability to organize addresses into different, or the same, 566 address blocks, as well as to change the order of addresses within an 567 address block, enables avoiding unnecessary repetition of information 568 - and, consequently, generation of smaller messages. 570 6.1. Addressesblock compression 572 Addresses in an address block can be compressed, and SHOULD be. 573 While no algorithm for compression is given in [RFC5444], an 574 efficient compression algorithm given a set of addresses, has to obey 575 certain contraints. 577 The protocol using RFC5444 sets the constraints by defining the list 578 of addresses and a list of addressblock TLV types and values for each 579 of the addresses. A compression strategy has to decide two 580 additional things which will have a major influence on the 581 compression efficiency. 583 o the split of the addresses into address blocks 585 o the order of the addresses within the address blocks. 587 The order of addresses can be as simple as sorting the addresses, but 588 if a lot of addresses have the same TLV types attached, it might be 589 more useful to group the messages by sections with same or similar 590 TLV types (e.g. RFC6130 HELLO messages with local interface 591 addresses first and neighbor addresses later). 593 Compression of address blocks is obtained by considering addresses to 594 consist of a Head, a Mid, and a Tail, where all addresses in an 595 address block have the same Head and Tail, but different Mids. An 596 additional compression is possible when the Tail consists of all 597 zero-valued octets. Expected use cases are IPv4 and IPv6 addresses 598 from within the same prefix and which therefore have a common Head, 599 IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with 600 a common Tail representing an interface identifier as well as a 601 possible common Head. Note that when, for example, IPv4 addresses 602 have a common Head, their Tail will be empty. For example 192.0.2.1 603 and 192.0.2.2 would have a 3 octet Head, a 1 octet Mid, and a 0 octet 604 Tail. 606 Address blocks with few similar addresses will save more bytes by 607 using longer Head and Tails in the address block header. Address 608 blocks with a lot of addresses will reduce the overhead created by 609 the address block header and TLV headers for multivalue TLVs. The 610 compression strategy will have to select the tradeof between these 611 two optimizations that will lead to a minimal number of bytes. 613 6.2. TLVs 615 The main opportunities for efficient messages when considering TLVs 616 are Address Block TLVs, rather than Message TLVs. 618 An Address Block TLV provides attributes for one address or a 619 contiguous (as stored in the address block) set of addresses (with a 620 special case for when this is all addresses in an address block). 621 When associated with more than one address, a TLV may be single- 622 valued (associating the same attribute with each address) or multi- 623 valued (associating a separate attribute with each address). 625 The simplest to implement approach is to use multi-valued TLVs that 626 cover all affected addresses. However unless care is taken to order 627 addresses appropriately, these affected addresses may not all be 628 contiguous. Approaches to this are to: 630 o Reorder the addresses. It is, for example, possible (though not 631 straightforward) to order all addresses in HELLO message as 632 specified in [RFC6130] so that all TLVs used only cover contiguous 633 addresses. This is even possible if the MPR TLV specified in 634 OLSRv2 [RFC7181] is added; but it is not possible, in general, if 635 the LINK_METRIC TLV is also added. 637 o Allow the TLV to span over addresses that do not need the 638 corresponding attribute, using a value that indicates no 639 information, see Section 6.3. 641 o Use more than one TLV. Note that this can be efficient when the 642 TLVs thus become single-valued. In a typical case where a 643 LINK_STATUS TLV uses only the values HEARD and SYMMETRIC, with 644 enough addresses, sorted appropriately, two single-valued TLVs can 645 be more efficient than one multi-valued TLV. (When only one value 646 is involved, such as NHDP in a steady state with LINK_STATUS equal 647 to SYMMETRIC in all cases, a single single-valued TLV should 648 always be used.) 650 6.3. TLV Values 652 If, for example, an address block contains five addresses, the first 653 two and the last two requiring values assigned using a LINK_STATUS 654 TLV, but the third does not, then this can be indicated using two 655 TLVs. It is however more efficient to do this with a single 656 multivalue LINK_STATUS TLV, assigning the third address the value 657 UNSPECIFIED. This approach was specified in [RFC7188], and required 658 for protocols that extend [RFC6130] and [RFC7181]. It is here 659 RECOMMNDED that this approach is followed when defining any Address 660 Block TLV that may be used by a protocol using [RFC5444]. 662 It might be argued that this is not necessary in the example above, 663 because the addresses can be reordered. However ordering addresses 664 in such a way for all possible TLVs is not, in general, possible. 666 As indicated, the LINK_STATUS TLV, and some other TLVs that take 667 single octet values (per address) has a value UNSPECIFIED defined, as 668 the value 255, in [RFC7188]. A similar approach (and a similar 669 value) is RECOMMENDED in any similar cases. Some other TLVs may need 670 a different approach, as noted in [RFC7188], but implicitly 671 permissible before then, the LINK_METRIC TLV has two octet values 672 whose first four bits are flags indicating whether the metric value 673 applies in four cases; if these are all zero then the metric value 674 does not apply in this case, which is thus the equivalent of an 675 UNSPECIFIED value. 677 6.4. Automation 679 There is scope for creating a protocol-independent optimizer for 680 [RFC5444] messages that performs appropriate address re-organization 681 (ordering and block separation) and TLV changes (of number, single- 682 or multi- valuedness and use of unspecified values) to create more 683 compact messages. The possible gain depends on the efficiency of the 684 original message creation, and the specific details of the message. 685 Note that while protocol-independent, this cannot be entirely TLV- 686 independent, for example a LINK_METRIC TLV has a more complicated 687 value structure than a LINK_STATUS TLV does if using unspecified 688 values. 690 7. Security Considerations 692 This document does not specify a protocol, but provides rules and 693 recommendations for how to design protocols using [RFC5444]. This 694 document does not introduce any new security considerations; 695 protocols designed according to these guidelines and recommendations 696 are subject to the security considerations detailed in [RFC5444]. In 697 particular the applicability of the security framework for [RFC5444] 698 specified in [RFC7182] is unchanged. 700 8. IANA Considerations 702 This document has no actions for IANA. 704 9. Acknowledgments 706 TBD 708 10. References 710 10.1. Normative References 712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", RFC 2119, BCP 14, March 1997. 715 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 716 "Generalized MANET Packet/Message Format", RFC 5444, 717 February 2009. 719 10.2. Informative References 721 [G9903] "ITU-T G.9903: Narrow-band orthogonal frequency division 722 multiplexing power line communication transceivers for G3- 723 PLC networks", May 2013. 725 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 726 Routing Protocol", RFC 3626, October 2003. 728 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 729 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 730 March 2009. 732 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 733 (MANET) Protocols", RFC 5498, March 2009. 735 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 736 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 737 RFC 6130, April 2011. 739 [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, 740 May 2012. 742 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 743 "The Optimized Link State Routing Protocol version 2", 744 RFC 7181, April 2014. 746 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 747 Check Value and Timestamp TLV Definitions for Mobile Ad 748 Hoc Networks (MANETs)", RFC 7182, April 2014. 750 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 751 Protection for the Neighborhood Discovery Protocol (NHDP) 752 and Optimized Link State Routing Protocol Version 2 753 (OLSRv2)", RFC 7183, April 2014. 755 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 756 Protocol version 2 (OLSRv2) and MANET Neighborhood 757 Discovery Protocol (NHDP) Extension TLVs", RFC 7188, 758 April 2014. 760 Authors' Addresses 762 Thomas Clausen 763 LIX, Ecole Polytechnique 764 91128 Palaiseau Cedex, 765 France 767 Phone: +33-6-6058-9349 768 Email: T.Clausen@computer.org 769 URI: http://www.thomasclausen.org 771 Christopher Dearlove 772 BAE Systems Applied Intelligence Laboratories 773 West Hanningfield Road 774 Great Baddow, Chelmsford 775 United Kingdom 777 Phone: +44 1245 242194 778 Email: chris.dearlove@baesystems.com 779 URI: http://www.baesystems.com/ 781 Ulrich Herberg 783 Email: ulrich@herberg.name 784 URI: http://www.herberg.name 786 Henning Rogge 788 Email: henning.rogge@fkie.fraunhofer.de