idnits 2.17.1 draft-ietf-manet-rfc5444-usage-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The 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 (April 5, 2016) is 2942 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 Ecole Polytechnique 4 Updates: 5444 (if approved) C. Dearlove 5 Intended status: Standards Track BAE Systems 6 Expires: October 7, 2016 U. Herberg 8 H. Rogge 9 Fraunhofer FKIE 10 April 5, 2016 12 Rules For Designing Protocols Using the RFC 5444 Generalized Packet/ 13 Message Format 14 draft-ietf-manet-rfc5444-usage-03 16 Abstract 18 This document updates the generalized MANET packet/message format, 19 specified in RFC 5444, by providing rules and recommendations for how 20 protocols can use that packet/message format. In particular, the 21 mandatory rules prohibit a number of uses of RFC 5444 that have been 22 suggested in various proposals, and which would have led to 23 interoperability problems, to the impediment of protocol extension 24 development, and to an inability to use generic RFC 5444 parsers. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 7, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. History and Purpose . . . . . . . . . . . . . . . . . . . 3 62 1.2. RFC 5444 Features . . . . . . . . . . . . . . . . . . . . 3 63 1.2.1. Packet/Message Format . . . . . . . . . . . . . . . . 4 64 1.2.2. Multiplexing and Demultiplexing . . . . . . . . . . . 5 65 1.3. Status of This Document . . . . . . . . . . . . . . . . . 6 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 68 4. Information Transmission . . . . . . . . . . . . . . . . . . . 7 69 4.1. Where to Record Information . . . . . . . . . . . . . . . 7 70 4.2. Packets and Messages . . . . . . . . . . . . . . . . . . . 9 71 4.3. Messages, Addresses and Attributes . . . . . . . . . . . . 10 72 4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 11 73 4.5. Information Representation . . . . . . . . . . . . . . . . 13 74 4.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 4.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 14 76 5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 16 78 6.1. Address Block Compression . . . . . . . . . . . . . . . . 16 79 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 18 81 6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 19 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction 92 [RFC5444] specifies a generalized packet/message format, designed for 93 use by MANET routing protocols. 95 [RFC5444] was designed following experiences with [RFC3626], which 96 attempted, but did not quite succeed in, providing a packet/message 97 format accommodating for diverse protocol extensions. [RFC5444] was 98 designed as a common building block for use by both proactive and 99 reactive MANET routing protocols. 101 [RFC5498] mandates the use of this packet/message format, and of the 102 packet multiplexing process described in an Appendix to [RFC5444], by 103 protocols operating over the manet IP protocol and port numbers that 104 were allocated following [RFC5498]. 106 1.1. History and Purpose 108 Since the publication of [RFC5444] in 2009, several RFCs have been 109 published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181], 110 [RFC7182], [RFC7183], [RFC7188], and [RFC7631], that use the format 111 of [RFC5444]. The ITU-T recommendation [G9903] also uses the format 112 of [RFC5444] for encoding some of its control signals. In developing 113 these specifications, experience with the use of [RFC5444] has been 114 acquired, specifically with respect to how to write specifications 115 using [RFC5444] so as to ensure "forward compatibility" of a protocol 116 with future extensions, to enable the creation of efficient messages, 117 and to enable the use of an efficient and generic parser for all 118 protocols using [RFC5444]. 120 During the same time period, other suggestions have been made to use 121 [RFC5444] in a manner that would inhibit the development of 122 interoperable protocol extensions, that would potentially lead to 123 inefficiencies, or that would lead to incompatibilities with generic 124 parsers for [RFC5444]. While these uses were not all explicitly 125 prohibited by [RFC5444], they should be strongly discouraged. This 126 document is intended to prohibit such uses, to present experiences 127 from designing protocols using [RFC5444], and to provide these as 128 guidelines (with their rationale) for future protocol designs using 129 [RFC5444]. 131 1.2. RFC 5444 Features 133 [RFC5444] performs two main functions: 135 o It defines a packet/message format for use by MANET routing 136 protocols. Although not required by [RFC5444], it is natural to 137 implement this using protocol-independent packet/message creation 138 and parsing processes. 140 o It specifies, in its Appendix A combined with the intended usage 141 in its Appendix B, a multiplexing and demultiplexing process 142 whereby an entity which may be referred to as the "RFC 5444 143 multiplexer" (in this document, simply as the multiplexer, or 144 demultiplexer when performing that function) manages packets that 145 travel a single (logical) hop, and which contain messages that are 146 owned by individual protocols. A packet may contain messages from 147 more than one protocol. This process, and its usage, is mandated 148 for use on the "manet" UDP port and IP protocol (alternative means 149 for the transport of packets) by [RFC5498]. 151 1.2.1. Packet/Message Format 153 Among the characteristics and design objectives of the packet/message 154 format of [RFC5444] are: 156 o It is designed for carrying MANET routing protocol control 157 signals. 159 o It defines a packet as a Packet Header with a set of Packet TLVs 160 (Type-Length-Value structures), followed by a set of messages. 161 Each message has a well-defined structure consisting of a Message 162 Header (designed for making processing and forwarding decisions) 163 followed by a set of Message TLVs, and a set of (address, type, 164 value) associations using Address Blocks and their Address Block 165 TLVs. The [RFC5444] packet/message format then enables the use of 166 simple and generic parsing logic for Packet Headers, Message 167 Headers, and message content. 169 A packet may include messages from different protocols, such as 170 [RFC6130] and [RFC7181], in a single transmission. This was 171 observed in [RFC3626] to be beneficial, especially in wireless 172 networks where media contention may be significant. 174 o Its packets are designed to travel between two neighboring 175 interfaces, which will result in a single decrement/increment of 176 the IPv4 TTL or IPv6 hop limit. The Packet Header and any Packet 177 TLVs may thus convey information relevant to that link (for 178 example, the Packet Sequence Number can be used to count 179 transmission successes across that link). Packets are designed to 180 be constructed for a single hop transmission; a packet 181 transmission following a successful packet reception is by design 182 of a new packet that may include all, some, or none of the 183 received messages, plus possibly additional messages either 184 received in separate packets, or generated locally at that router. 185 Messages may thus travel more than one hop, and are designed to 186 carry end-to-end protocol signals. 188 o It supports "internal extensibility" using TLVs; an extension can 189 add information to an existing message without that information 190 rendering the message unparseable or unusable by a router that 191 does not support the extension. An extension is typically of the 192 protocol that created the message to be extended, for example 193 [RFC7181] adds information to the HELLO messages created by 194 [RFC6130]. However an extension may also be independent of the 195 protocol, for example [RFC7182] can add ICV (Integrity Check 196 Value) and timestamp information to any message (or to a packet, 197 thus extending the [RFC5444] multiplexer). 199 Information, in the form of TLVs, can be added to the message as a 200 whole, such as the [RFC7182] integrity information, or may be 201 associated with specific addresses in the message, such as the MPR 202 selection and link metric information added to HELLO messages by 203 [RFC7181]. An extension can also add addresses to a message. 205 o It uses address aggregation into compact Address Blocks by 206 exploiting commonalities between addresses. In many deployments, 207 addresses (IPv4 and IPv6) used on interfaces share a common prefix 208 that need not be repeated. Using IPv6, several addresses (of the 209 same interface) may have common interface identifiers that need 210 not be repeated. 212 o It sets up common namespaces, formats, and data structures for use 213 by different protocols, where common parsing logic can be used. 214 For example, [RFC5497] defines a generic TLV format for 215 representing time information (such as interval time or validity 216 time). 218 o It contains a minimal Message Header (a maximum of five elements: 219 type, originator, sequence number, hop count and hop limit) that 220 permit decisions whether to locally process a message, or forward 221 a message (thus enabling MANET-wide flooding of a message) without 222 processing the body of the message. 224 1.2.2. Multiplexing and Demultiplexing 226 The primary purposes of the multiplexer are to: 228 o Accept messages from MANET protocols, which also indicate over 229 which interface(s) the messages are to be sent, and to which 230 destination address. The latter may be a unicast address or the 231 "LL-MANET-Routers" link local multicast address defined in 232 [RFC5498]. 234 o Collect messages, possibly from multiple protocols, for the same 235 interface and destination, into packets to be sent one logical 236 hop, and to send packets using the "manet" UDP port or IP protocol 237 defined in [RFC5498]. 239 o Extract messages from received packets, and pass them to their 240 owning protocols. 242 The multiplexer is also responsible for the Packet Header, including 243 any Packet Sequence Number and Packet TLVs. It may accept some 244 additional instructions from protocols, pass additional information 245 to protocols, and must follow some additional rules, see Section 4.2. 247 1.3. Status of This Document 249 This document updates [RFC5444], and is intended for publication as a 250 Proposed Standard (rather than as Informational) because it specifies 251 and mandates constraints on the use of [RFC5444] which, if not 252 followed, makes forms of extensions of those protocols impossible, 253 impedes the ability to generate efficient messages, or makes 254 desirable forms of generic parsers impossible. 256 2. Terminology 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 260 "OPTIONAL" in this document are to be interpreted as described in 261 [RFC2119]. 263 This document uses the terminology and notation defined in [RFC5444], 264 in particular the terms "packet", "Packet Header", "message", 265 "Message Header", "address", "Address Block", "TLV" and "TLV Block" 266 are to be interpreted as described therein. 268 Additionally, this document uses the following terminology: 270 Owning Protocol - As per [RFC5444], for each Message Type, a 271 protocol -- unless specified otherwise, the one making the IANA 272 reservation for that Message Type -- is designated as the "owning 273 protocol" of that Message Type. The (de)multiplexer inspects the 274 Message Type of each received message, and delivers each message 275 to its corresponding "owning protocol". 277 3. Applicability Statement 279 This document does not specify a protocol, but documents constraints 280 on how to design protocols which are using the generic packet/message 281 format defined in [RFC5444] which, if not followed, makes forms of 282 extensions of those protocols impossible, impedes the ability to 283 generate efficient (small) messages, or makes desirable forms of 284 generic parsers impossible. The use of the [RFC5444] format is 285 mandated by [RFC5498] for all protocols running over the manet 286 protocol and port number, defined therein. Thus, the constraints in 287 this document apply to all protocols running over the manet protocol 288 and port number. 290 4. Information Transmission 292 Protocols need to transmit information from one instance implementing 293 the protocol to another. 295 4.1. Where to Record Information 297 A protocol has the following choices as to where to put information 298 for transmission: 300 o In a TLV to be added to the Packet Header. 302 o In a message of a type owned by another protocol. 304 o In a message of a type owned by the protocol. 306 The first case (a Packet TLV) can only be used when the information 307 is to be carried one hop. It SHOULD only be used either where the 308 information relates to the packet as a whole (for example packet 309 integrity check values and timestamps, as specified in [RFC7182]) or 310 if the information is of expected wider application than a single 311 protocol. A protocol can also request that the Packet Header include 312 Packet Sequence Numbers, but does not control those numbers. 314 The second case (in a message of a type owned by another protocol) is 315 only possible if the adding protocol is an extension to the owning 316 protocol; for example OLSRv2 [RFC7181] is an extension of NHDP 317 [RFC6130]. While this is not the most common case, protocols SHOULD 318 be designed to enable this to be possible, and most rules in this 319 document are to help facilitate that. An extension to [RFC5444], 320 such as [RFC7182], is considered to be an extension to all protocols 321 in this regard. 323 The third case is the normal case for a new protocol. Protocols MUST 324 be conservative in the number of new Message Types that they require, 325 as the total available number of allocatable Message Types is only 326 224. Protocol design SHOULD consider whether different functions can 327 be implemented by differences in TLVs carried in the same Message 328 Type, rather than using multiple Message Types. If a protocol's 329 needs can be covered by use of the second case, then this SHOULD be 330 done. 332 The TLV Type space, although greater than the Message Type space, 333 SHOULD also be used efficiently. The extended type of a TLV occupies 334 two octets, thus there are many more available TLV extended types 335 than there are Message Types. However, in some cases (currently 336 LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from [RFC7182], all 337 in the global TLV Type space) a TLV Type with a full set of 256 TLV 338 extended types is defined (but not necessarily allocated). 340 Each Message Type has an associated block of Message-Type-specific 341 TLV Types (128 to 233, each of with 256 type extensions), both for 342 Address Block TLV Types and Message TLV Types. TLV Types from within 343 these blocks SHOULD be used in preference to the Message-Type- 344 independent Message TLV Types (0 to 127, each with 256 type 345 extensions) when a TLV is specific to a message. 347 A message contains a Message Header and a Message Body; note that the 348 Message TLV Block is considered as part of the latter. The Message 349 Header contains information whose primary purpose is to decide 350 whether to process the message, and whether to forward the message. 352 A message MUST be recognized by the combination of its Message Type, 353 Originator Address and Message Sequence Number. This allows each 354 protocol to manage its own Message Sequence Numbers, and also allows 355 for the possibility that different Message Types may have greatly 356 differing transmission rates. [RFC7181] contains a general purpose 357 process for managing processing and forwarding decisions, albeit one 358 presented as for use with MPR flooding. (Blind flooding can be 359 handled similarly by assuming that all other routers are MPR 360 selectors; it is not necessary in this case to differentiate between 361 interfaces on which a message is received.) 363 Most protocol information is thus contained in the Message Body. A 364 model of how such information may be viewed is described in 365 Section 4.3 and Section 4.4. To use that model, addresses (for 366 example of neighboring or otherwise known routers) SHOULD be recorded 367 in Address Blocks, not as data in TLVs. Recording addresses in TLV 368 Value fields both breaks the model of addresses as identities and 369 associated information (attributes) and also inhibits address 370 compression. However in some cases alternative addresses (e.g., 371 hardware addresses when the Address Block is recording IP addresses) 372 MAY be carried as TLV Values. Note that a message contains a Message 373 Address Length field that can be used to allow carrying alternative 374 message sizes, but only one length of addresses can be used in a 375 single message, in all Address Blocks and the Originator Address, and 376 is established by the router and protocol generating the message. 378 4.2. Packets and Messages 380 The multiplexer has to handle message transmission and packet 381 multiplexing, and packet reception and message demultiplexing. The 382 multiplexer and the protocols that use it are subject to the 383 following rules. 385 Packets are formed for transmission by: 387 o Outgoing messages are created by their owning protocol, and MAY be 388 modified by any extending protocols if the owning protocol permits 389 this. Messages MAY also be forwarded by their owning protocol. 390 It is strongly RECOMMENDED that messages are not modified in the 391 latter case. 393 o Outgoing messages are then sent to the [RFC5444] multiplexer. The 394 owning protocol MUST indicate which interface(s) the messages are 395 to be sent on and their destination address, and MAY request that 396 messages are kept together in a packet; the multiplexer SHOULD 397 respect this request if at all possible. 399 o The multiplexer SHOULD combine messages from multiple protocols 400 that are sent on the same interface in a packet, provided that in 401 so doing the multiplexer does not cause an IP packet to exceed the 402 current MTU (Maximum Transmission Unit). (Note that the 403 multiplexer cannot fragment messages; creating suitable sized 404 messages is the responsibility of the protocol generating the 405 message.) 407 o The multiplexer MAY delay messages briefly in order to assemble 408 more efficient packets. It SHOULD respect any constraints on such 409 delays requested by the protocol. 411 o If requested by a protocol, the multiplexer SHOULD, and otherwise 412 MAY, include a Packet Sequence Number in the packet. Note that, 413 as per the errata to [RFC5444], this Packet Sequence Number MUST 414 be specific to the interface on which the packet is sent. 415 Separate sequence numbers SHOULD be maintained for each 416 destination to which packets are sent. (Note that packets travel 417 one hop; the destination is therefore either a link local 418 multicast address, if the packet is being multicast, or the 419 address of the neighbor interface to which the packet is sent.) 421 o An extension to the multiplexer MAY add TLVs to the packet and/or 422 the messages (for example as by [RFC7182], which MAY be used by 423 the multiplexer to add Packet TLVs or Message TLVs, or by the 424 protocol to add Message TLVs). 426 When a packet is received, the following steps are required to be 427 performed by the demultiplexer: 429 o The packet and/or the messages it contains MAY be verified by an 430 extension to the demultiplexer, such as [RFC7182]. 432 o Each message MUST be sent to its owning protocol. The 433 demultiplexer MUST also make the Packet Header, and the source and 434 destination addresses in the IP datagram that included the packet, 435 available to the protocol. 437 o The demultiplexer MUST remove any TLVs added to the message by the 438 multiplexer. The message MUST be passed on to the protocol 439 exactly as received from (another instance of) the protocol. 441 o The owning protocol SHOULD verify each message for correctness, it 442 SHOULD allow any extending protocol(s) to also contribute to this 443 verification. 445 o The owning protocol MUST process each message, or make an informed 446 decision not to do so. In the former case an owning protocol that 447 permits this MUST allow any extending protocols to process or 448 ignore the message. 450 o The owning protocol is responsible for managing the hop count 451 and/or hop limit in the message. It is RECOMMENDED that these are 452 handled as described in Appendix B of [RFC5444]; they MUST be so 453 handled if using hop count dependent TLVs such as those defined in 454 [RFC5497]. 456 4.3. Messages, Addresses and Attributes 458 The information in a Message Body, including Message TLVs and Address 459 Block TLVs, can be considered to consist of: 461 o Attributes of the message, each attribute consisting of an 462 extended type, a length, and a value (of that length). 464 o A set of addresses, carried in one or more Address Blocks. 466 o Attributes of each address, each attribute consisting of an 467 extended type, a length, and a value (of that length). 469 Attributes are carried in TLVs. For Message TLVs the mapping from 470 TLV to attribute is one to one. For Address Block TLVs the mapping 471 from TLV to attribute is one to many: one TLV can carry attributes 472 for multiple addresses, but only one attribute per address. 473 Attributes for different addresses may be the same or different. 475 A TLV extended type MAY be (and this is RECOMMENDED whenever 476 possible) defined so that there may only be one TLV of that extended 477 type associated with the packet (Packet TLV), message (Message TLV), 478 or any value of any address (Address Block TLV). Note that an 479 address may appear more than once in a message, but the restriction 480 on associating TLVs with addresses covers all copies of that address. 481 It is RECOMMENDED that addresses are not repeated in a message. 483 4.4. Addresses Require Attributes 485 It is not mandatory in [RFC5444] to associate an address with 486 attributes using Address Block TLVs. Information about an address 487 could thus, in principle, be carried using: 489 o The simple presence of an address. 491 o The ordering of addresses in an Address Block. 493 o The use of different meanings for different Address Blocks. 495 This specification, however, requires that those methods of carrying 496 information MUST NOT be used for any protocol using [RFC5444]. 497 Information about the meaning of an address MUST only be carried 498 using Address Block TLVs. 500 In addition, rules for the extensibility of OLSRv2 and NHDP are 501 described in [RFC7188]. This specification extends their 502 applicability to other uses of [RFC5444]. 504 These rules are: 506 o A protocol MUST NOT assign any meaning to the presence or absence 507 of an address (either in a Message, or in a given Address Block in 508 a Message), to the ordering of addresses in an Address Block, or 509 to the division of addresses among Address Blocks. 511 o A protocol MUST NOT reject a message based on the inclusion of a 512 TLV of an unrecognized type. The protocol MUST ignore any such 513 TLVs when processing the message. The protocol MUST NOT remove or 514 change any such TLVs if the message is to be forwarded unchanged. 516 o A protocol MUST NOT reject a message based on the inclusion of an 517 unrecognized Value in a TLV of a recognized type. The protocol 518 MUST ignore any such Values when processing the message, but MUST 519 NOT ignore recognized Values in such a TLV. The protocol MUST NOT 520 remove or change any such TLVs if the message is to be forwarded 521 unchanged. 523 o Similar restrictions to the two preceding points apply to the 524 demultiplexer, which also MUST NOT reject a packet based on an 525 unrecognized message; although it will reject any such messages, 526 it MUST deliver any other messages in the packet to their owning 527 protocols. 529 The following points indicate the reasons for these rules, based on 530 considerations of extensibility and efficiency. 532 Assigning a meaning to the presence, absence or location, of an 533 address would reduce the extensibility of the protocol, prevent the 534 approach to information representation described in Section 4.5, and 535 reduce the options available for message optimization described in 536 Section 6. 538 For example, consider NHDP's HELLO messages [RFC6130]. The basic 539 function of a HELLO message is to indicate that an address is of a 540 neighbor, using the LINK_STATUS and OTHER_NEIGHB TLVs. An extension 541 to NHDP might decide to use the HELLO message to report that, for 542 example, an address is one that could be used for a specialized 543 purpose, but not for normal NHDP-based purposes. Such an example 544 already exists (but within the basic specification, rather than as an 545 extension) in the use of LOST Values in the LINK_STATUS and 546 OTHER_NEIGHB TLVs to report that an address is of a router known not 547 to be a neighbor. A future example might be to list an address to be 548 added to a "blacklist" of addresses not to be used. This would be 549 indicated by a new TLV (or a new Value of an existing TLV, see 550 below). An unmodified extension to NHDP would ignore such addresses, 551 as required, as it does not support that specialized purpose. If 552 NHDP had been designed so that just the presence of an address 553 indicated a neighbor, that extension would not have been possible. 555 Rejecting a message because it contains an unrecognized TLV Type, or 556 an unrecognized TLV Value, reduces the extensibility of the protocol. 558 For example, OLSRv2 [RFC7181] is, among other things, an extension to 559 NHDP. It adds information to addresses in an NHDP HELLO message 560 using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP, for 561 example to support Simplified Multicast Flooding (SMF) [RFC6621], 562 must still process the HELLO message, ignoring the LINK_METRIC TLVs. 564 Also, the blacklisting described in the example above could be 565 signaled not with a new TLV, but with a new Value of a LINK_STATUS or 566 OTHER_NEIGHB TLV (requiring an IANA allocation as described in 567 [RFC7188]), as is already done in the LOST case. 569 The creation of Multi-Topology OLSRv2 (MT-OLSRv2) [RFC7722], as an 570 extension to OLSRv2 that can interoperate with unextended instances 571 of OLSRv2, would not have been possible without these restrictions, 572 which were applied to NHDP and OLSRv2 by [RFC7181]. 574 These restrictions do not, however, mean that added information is 575 completely ignored for purposes of the base protocol. Suppose that a 576 faulty implementation of OLSRv2 (including NHDP) creates a HELLO 577 message that assigns two different values of the same link metric to 578 an address, something that is not permitted by [RFC7181]. A 579 receiving OLSRv2-aware implementation of NHDP MUST reject such a 580 message, even though a receiving OLSRv2-unaware implementation of 581 NHDP will process it. This is because the OLSRv2-aware 582 implementation has access to additional information, that the HELLO 583 message is definitely invalid, and the message is best ignored, as it 584 is unknown what other errors it may contain. 586 4.5. Information Representation 588 A message (excluding the Message Header) can thus be represented by 589 two, possibly multivalued, maps: 591 o Message: (extended type) -> (length, value) 593 o Address: (address, extended type) -> (length, value) 595 These maps (plus a representation of the Message Header) can be the 596 basis for a generic representation of information in a message. Such 597 maps can be created by parsing the message, or can be constructed 598 using the protocol rules for creating a message, and later converted 599 into the octet form of the message specified in [RFC5444]. 601 While of course any implementation of software that represents 602 software in the above form can specify an application programming 603 interface (API) for that software, such an interface is not proposed 604 here. First, a full API would be programming language specific. 605 Second, even within the above framework, there are alternative 606 approaches to such an interface. For example, and for illustrative 607 purposes only, for the address mapping: 609 o Input: address and extended type. Output: list of (length, value) 610 pairs. Note that for most extended types it will be known in 611 advance that this list will have length zero or one. The list of 612 addresses that can be used as inputs with non-empty output would 613 need to be provided as a separate output. 615 o Input: extended type. Output: list of (address, length, value) 616 triples. As this list length may be significant, a possible 617 output will be of one or two iterators that will allow iterating 618 through that list. (One iterator that can detect the end of list, 619 or a pair of iterators specifying a range.) 621 Additional differences in the interface may relate to, for example, 622 the ordering of output lists. 624 4.6. TLVs 626 Within a message, the attributes are represented by TLVs. 627 Particularly for Address Block TLVs, different TLVs may represent the 628 same information. For example, using the LINK_STATUS TLV defined in 629 [RFC6130], if some addresses have Value SYMMETRIC and some have Value 630 HEARD, arranged in that order, then this information can be 631 represented using two single value TLVs or one multivalue TLV. The 632 latter can be used even if the addresses are not so ordered. 634 A protocol MAY use any representation of information using TLVs that 635 convey the required information. A protocol SHOULD use an efficient 636 representation, but this is a quality of implementation issue. A 637 protocol MUST recognize any permitted representation of the 638 information; even if it chooses to (for example) only use multivalue 639 TLVs, it MUST recognize single value TLVs (and vice versa). 641 A protocol defining new TLVs MUST respect the naming and 642 organizational rules in [RFC7631]. It SHOULD follow the guidance in 643 [RFC7188], except where those requirements are ones that MUST be 644 followed as required by this specification (or when extending 645 [RFC6130] or [RFC7181], when these MUST also be followed). 647 4.7. Message Integrity 649 In addition to not rejecting a message due to unknown TLVs or TLV 650 Values, a protocol MUST NOT fail to forward a message (by whatever 651 means of message forwarding are appropriate to that protocol) due to 652 the presence of such TLVs or TLV Values, and MUST NOT remove such 653 TLVs or TLV Values. Such behavior would have the consequences that: 655 o It might disrupt the operation of an extension of which it is 656 unaware. Note that it is the responsibility of a protocol 657 extension to handle interoperation with unextended instances of 658 the protocol. For example OLSRv2 [RFC7181] adds an MPR_WILLNG TLV 659 to HELLO messages (created by NHDP, [RFC6130], of which it is in 660 part an extension) to recognize this case (and for other reasons). 661 If an incompatible protocol extension were defined, it would be 662 the responsibility of network management to ensure that 663 incompatible routers were not both present in the MANET; this case 664 is NOT RECOMMENDED. 666 o It would prevent the operation of end to end message 667 authentication using [RFC7182], or any similar mechanism. The use 668 of immutable (apart from hop count and/or hop limit) messages by a 669 protocol is strongly RECOMMENDED for that reason. 671 5. Structure 673 The elements defined in [RFC5444] have structures that are managed by 674 a number of flags fields: 676 o Packet flags field (4 bits, 2 used) that manages the contents of 677 the Packet Header. 679 o Message flags field (4 bits, 4 used) that manages the contents of 680 the Message Header. 682 o Address Block flags field (8 bits, 4 used) that manages the 683 contents of an Address Block. 685 o TLV flags field (8 bits, 5 used) that manages the contents of a 686 TLV. 688 Note that all of these flags are structural, they specify which 689 elements are present or absent, or field lengths, or whether a field 690 has one or multiple values in it. 692 In the current version of [RFC5444], indicated by version number 0 in 693 the field of the Packet Header, unused bits in these flags 694 fields "are RESERVED and SHOULD each be cleared ('0') on transmission 695 and SHOULD be ignored on reception". 697 If a specification updating [RFC5444] introduces new flags in one of 698 the flags fields of a packet, message or Address Block, the following 699 rules MUST be followed: 701 o The version number contained in the field of the Packet 702 Header MUST NOT be 0. 704 o The new flag(s) MUST indicate the structure of the corresponding 705 packet, message, Address Block or TLV, and MUST NOT be used to 706 indicate any other semantics, such as message forwarding behavior. 708 An update that would be incompatible with the current specification 709 of [RFC5444] SHOULD NOT be created unless there is a pressing reason 710 for it that cannot be satisfied using the current specification 711 (e.g., by use of a suitable Message TLV). 713 During the development of [RFC5444], and since publication thereof, 714 some proposals have been made to use these RESERVED flags to specify 715 behavior rather than structure, in particular message forwarding. 716 These proposals were, after due consideration, not accepted, for a 717 number of reasons. These reasons include that message forwarding, in 718 particular, is protocol-specific; for example [RFC7181] forwards 719 messages using its MPR (Multi-Point Relay) mechanism, rather than a 720 "blind" flooding mechanism. (The later addition of a 4 bit Message 721 Address Length field later left no unused message flags bits, but 722 other fields still have unused bits.) 724 6. Message Efficiency 726 The ability to organize addresses into different, or the same, 727 Address Blocks, as well as to change the order of addresses within an 728 Address Block, and the flexibility of the TLV specification, enables 729 avoiding unnecessary repetition of information, and consequently can 730 generate smaller messages. No algorithms for address organization or 731 compression or for TLV usage are given in [RFC5444], any algorithms 732 that leave the information content unchanged MAY be used when 733 generating a message. Note, however, that this does not apply when 734 forwarding a message, a message that is (as strongly RECOMMENDED) 735 forwarded unchanged MUST have an identical octet representation, 736 other than that the owning protocol SHOULD increment and decrement, 737 respectively, the hop count and hop limit, if present. 739 6.1. Address Block Compression 741 Addresses in an Address Block can be compressed, and SHOULD be. 743 Compression of addresses in an Address Block considers addresses to 744 consist of a Head, a Mid, and a Tail, where all addresses in an 745 Address Block have the same Head and Tail, but different Mids. An 746 additional compression is possible when the Tail consists of all 747 zero-valued octets. Expected use cases are IPv4 and IPv6 addresses 748 from within the same prefix and which therefore have a common Head, 749 IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with 750 a common Tail representing an interface identifier as well as having 751 a possible common Head. Note that when, for example, IPv4 addresses 752 have a common Head, their Tail will usually be empty. For example 753 192.0.2.1 and 192.0.2.2 would, for greatest efficiency, have a 3 754 octet Head, a 1 octet Mid, and a 0 octet Tail. 756 Putting addresses into a message efficiently also has to include: 758 o The split of the addresses into Address Blocks. 760 o The order of the addresses within the Address Blocks. 762 This split and/or ordering is for efficiency only, it does not 763 provide any information. The split of the addresses affects both the 764 address compression and the TLV efficiency (see Section 6.2), the 765 order of the addresses within an Address Block affects only the TLV 766 efficiency. However using more Address Blocks than is needed can 767 increase the message size due to the overhead of each Address Block 768 and the following TLV Block, and/or if additional TLVs are now 769 required. 771 The order of addresses can be as simple as sorting the addresses, but 772 if many addresses have the same TLV Types attached, it might be more 773 useful to put these addresses together, either within the same 774 Address Block as other addresses, or in a separate Address Block. A 775 separate address block might also improve address compression, for 776 example if more than one address form is used (such as from 777 independent subnets). An example of the possible use of address 778 ordering is a HELLO message from [RFC6130] which MAY be generated 779 with local interface addresses first and neighbor addresses later. 780 These MAY be in separate Address Blocks. 782 6.2. TLVs 784 The main opportunities for efficient messages when considering TLVs 785 are in Address Block TLVs, rather than Message TLVs. 787 An Address Block TLV provides attributes for one address or a 788 contiguous (as stored in the Address Block) set of addresses (with a 789 special case for when this is all addresses in an Address Block). 790 When associated with more than one address, a TLV may be single value 791 (associating the same attribute with each address) or multivalue 792 (associating a separate attribute with each address). 794 The simplest to implement approach is to use multivalue TLVs that 795 cover all affected addresses. However unless care is taken to order 796 addresses appropriately, these affected addresses may not all be 797 contiguous. Approaches to this are to: 799 o Reorder the addresses. It is, for example, possible (though not 800 straightforward) to order all addresses in HELLO message as 801 specified in [RFC6130] so that all TLVs used only cover contiguous 802 addresses. This is even possible if the MPR TLV specified in 803 OLSRv2 [RFC7181] is added; but it is not possible, in general, if 804 the LINK_METRIC TLV is also added. 806 o Allow the TLV to span over addresses that do not need the 807 corresponding attribute, using a Value that indicates no 808 information, see Section 6.3. 810 o Use more than one TLV. Note that this can be efficient when the 811 TLVs thus become single value TLVs. In a typical case where a 812 LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with 813 enough addresses, sorted appropriately, two single value TLVs can 814 be more efficient than one multivalue TLV. (When only one Value 815 is involved, such as NHDP in a steady state with LINK_STATUS equal 816 to SYMMETRIC in all cases, one single value TLV SHOULD always be 817 used.) 819 6.3. TLV Values 821 If, for example, an Address Block contains five addresses, the first 822 two and the last two requiring Values assigned using a LINK_STATUS 823 TLV, but the third does not, then this can be indicated using two 824 TLVs. It is however more efficient to do this with one multivalue 825 LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED. 826 In general, use of UNSPECIFIED Values allows use of fewer TLVs and 827 thus often an efficiency gain; however a long run of consecutive 828 UNSPECIFIED Values (more than the overhead of a TLV) may make more 829 TLVs more efficient. 831 This approach was specified in [RFC7188], and required for protocols 832 that extend [RFC6130] and [RFC7181]. It is here RECOMMENDED that 833 this approach is followed when defining any Address Block TLV that 834 may be used by a protocol using [RFC5444]. 836 It might be argued that this is not necessary in the example above, 837 because the addresses can be reordered. However ordering addresses 838 in such a way for all possible TLVs is not, in general, possible. 840 As indicated, the LINK_STATUS TLV, and some other TLVs that take 841 single octet Values (per address), have a Value UNSPECIFIED defined, 842 as the Value 255, in [RFC7188]. A similar approach (and a similar 843 Value) is RECOMMENDED in any similar cases. Some other TLVs may need 844 a different approach. As noted in [RFC7188], but implicitly 845 permissible before then, the LINK_METRIC TLV has two octet Values 846 whose first four bits are flags indicating whether the metric applies 847 in four cases; if these are all zero then the metric does not apply 848 in this case, which is thus the equivalent of an UNSPECIFIED Value. 850 6.4. Automation 852 There is scope for creating a protocol-independent optimizer for 853 [RFC5444] messages that performs appropriate address re-organization 854 (ordering and Address Block separation) and TLV changes (of number, 855 single- or multi- valuedness and use of UNSPECIFIED Values) to create 856 more compact messages. The possible gain depends on the efficiency 857 of the original message creation, and the specific details of the 858 message. Note that this process cannot be TLV Type independent, for 859 example a LINK_METRIC TLV has a more complicated Value structure than 860 a LINK_STATUS TLV does if using UNSPECIFIED Values. 862 Such a protocol-independent optimizer MAY be used by the router 863 generating a message, but MUST NOT be used on a message that is 864 forwarded unchanged by a router. 866 7. Security Considerations 868 This document does not specify a protocol, but provides rules and 869 recommendations for how to design protocols using [RFC5444]. This 870 document does not introduce any new security considerations; 871 protocols designed according to these rules and recommendations are 872 subject to the security considerations detailed in [RFC5444]. In 873 particular the applicability of the security framework for [RFC5444] 874 specified in [RFC7182] is unchanged. 876 8. IANA Considerations 878 This document has no actions for IANA. 880 9. Acknowledgments 882 The authors thank Cedric Adjih (INRIA) and Justin Dean (NRL) for 883 their contributions as authors of RFC 5444. 885 10. References 887 10.1. Normative References 889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 890 Requirement Levels", RFC 2119, BCP 14, March 1997. 892 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 893 "Generalized MANET Packet/Message Format", RFC 5444, 894 February 2009. 896 10.2. Informative References 898 [G9903] "ITU-T G.9903: Narrow-band orthogonal frequency division 899 multiplexing power line communication transceivers for G3- 900 PLC networks", May 2013. 902 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 903 Routing Protocol", RFC 3626, October 2003. 905 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 906 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 907 March 2009. 909 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 910 (MANET) Protocols", RFC 5498, March 2009. 912 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 913 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 914 RFC 6130, April 2011. 916 [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, 917 May 2012. 919 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 920 "The Optimized Link State Routing Protocol version 2", 921 RFC 7181, April 2014. 923 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 924 Check Value and Timestamp TLV Definitions for Mobile Ad 925 Hoc Networks (MANETs)", RFC 7182, April 2014. 927 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 928 Protection for the Neighborhood Discovery Protocol (NHDP) 929 and Optimized Link State Routing Protocol Version 2 930 (OLSRv2)", RFC 7183, April 2014. 932 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 933 Protocol version 2 (OLSRv2) and MANET Neighborhood 934 Discovery Protocol (NHDP) Extension TLVs", RFC 7183, 935 April 2014. 937 [RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the MANET 938 Generalized Packet/Message Format", RFC 7631, 939 January 2015. 941 [RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for 942 the Optimized Link State Routing Protocol Version 2 943 (OLSRv2)", RFC 7722, December 2015. 945 Authors' Addresses 947 Thomas Clausen 948 Ecole Polytechnique 949 91128 Palaiseau Cedex, 950 France 952 Phone: +33-6-6058-9349 953 Email: T.Clausen@computer.org 954 URI: http://www.thomasclausen.org 956 Christopher Dearlove 957 BAE Systems Applied Intelligence Laboratories 958 West Hanningfield Road 959 Great Baddow, Chelmsford 960 United Kingdom 962 Email: chris.dearlove@baesystems.com 963 URI: http://www.baesystems.com 965 Ulrich Herberg 967 Email: ulrich@herberg.name 968 URI: http://www.herberg.name 969 Henning Rogge 970 Fraunhofer FKIE 971 Fraunhofer Strasse 20 972 53343 Wachtberg 973 Germany 975 Email: henning.rogge@fkie.fraunhofer.de