idnits 2.17.1 draft-ietf-manet-packetbb-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2625. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2649. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 572 has weird spacing: '...-length is a ...' == Line 584 has weird spacing: '...-length is a ...' == Line 594 has weird spacing: '...-length is a ...' == Line 736 has weird spacing: '...ype-ext is a ...' == Line 739 has weird spacing: '...ulltype is a ...' == (2 more instances...) -- 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 (September 16, 2008) is 5701 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (ref. 'BCP26') (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'SingleUNIX' Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) T. Clausen 3 Internet-Draft LIX, Ecole Polytechnique, France 4 Intended status: Standards Track C. Dearlove 5 Expires: March 20, 2009 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 C. Adjih 10 INRIA Rocquencourt 11 September 16, 2008 13 Generalized MANET Packet/Message Format 14 draft-ietf-manet-packetbb-15 16 Status of This Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on March 20, 2009. 41 Abstract 43 This document specifies a packet format capable of carrying multiple 44 messages that may be used by mobile ad hoc network routing protocols. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 4 50 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.1.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1.2. Variables . . . . . . . . . . . . . . . . . . . . . . 5 53 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 55 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 56 5. Syntactical Specification . . . . . . . . . . . . . . . . . . 7 57 5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 11 60 5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 14 61 5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 5.4.2. TLV Inclusion and Constraints . . . . . . . . . . . . 18 63 5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 65 6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 19 66 6.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 21 67 6.2.1. Message Type Specific TLV Registry Creation . . . . . 21 68 6.3. Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 22 69 6.3.1. Packet TLV Type Extension Registry Creation . . . . . 22 70 6.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 22 71 6.4.1. Message TLV Type Extension Registry Creation . . . . . 23 72 6.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 23 73 6.5.1. Address Block TLV Type Extension Registry Creation . . 24 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 75 7.1. Authentication and Integrity Suggestions . . . . . . . . . 24 76 7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 25 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 26 80 Appendix A. Multiplexing and Demultiplexing . . . . . . . . . . . 26 81 Appendix B. Intended Usage . . . . . . . . . . . . . . . . . . . 27 82 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 28 83 C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 28 84 C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 31 85 Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 33 86 D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 33 87 D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 37 88 D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 43 89 D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 44 90 D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 51 91 D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 92 Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 57 93 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 58 94 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 59 96 1. Introduction 98 This document specifies the syntax of a packet format designed for 99 carrying multiple routing protocol messages for information exchange 100 between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a 101 message header, which is designed for control of message 102 dissemination, and a message body, which contains protocol 103 information. Only the syntax of the packet and messages is 104 specified. 106 This document specifies: 108 o A packet format, allowing zero or more messages to be contained 109 within a single transmission. A packet with zero messages may be 110 sent in case the only information to exchange is contained in the 111 packet header. 113 o A message format, where a message is composed of a message header 114 and a message body. 116 o A message header format, which contains information which may be 117 sufficient to allow a protocol using this specification to make 118 processing and forwarding decisions. 120 o A message body format, containing attributes associated with the 121 message or the originator of the message, as well as blocks of 122 addresses, or address prefixes, with associated attributes. 124 o An address block format, where an address block represents sets of 125 addresses, or address prefixes, in a compact form with aggregated 126 addresses. 128 o A generalized type-length-value (TLV) format representing 129 attributes. Each TLV can be associated with a packet, a message, 130 or one or more addresses or address prefixes in a single address 131 block. Multiple TLVs can be included and each associated with a 132 packet, a message, and with the same, different or overlapping 133 sets of addresses or address prefixes. 135 The specification has been explicitly designed with the following 136 properties, listed in no particular order, in mind: 138 Parsing logic - The notation used in this specification facilitates 139 generic, protocol independent, parsing logic. 141 Extensibility - Packets and messages defined by a protocol using 142 this specification are extensible by defining new message types 143 and new TLVs. Protocols using this specification will be able to 144 correctly identify and skip such new message types and TLVs, while 145 correctly parsing the remainder of the packet and message. 147 Efficiency - When reported addresses share common bit sequences 148 (e.g. address prefixes or IPv6 interface identifiers) the address 149 block representation allows for a compact representation. Compact 150 message headers are ensured through permitting inclusion of only 151 required message header elements. The multi message packet 152 structure allows a reduction in the number of transmitted octets 153 and in the number of transmitted packets. The structure of packet 154 and message encoding allows parsing, verifying, and identifying 155 individual elements in a single pass. 157 Separation of forwarding and processing - A protocol using this 158 specification can be designed such that duplicate detection and 159 controlled scope message forwarding decisions can be made using 160 information contained in the message header, without processing 161 the message body. 163 2. Notation and Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in 168 [RFC2119]. 170 Additionally, this document uses the notation in Section 2.1, and the 171 terminology in Section 2.2. 173 2.1. Notation 175 The following notations, for elements and variables, are used in this 176 document. 178 This format uses network byte order (most significant octet first) 179 for all fields. The most significant bit in an octet is numbered bit 180 0, and the least significant bit of an octet is numbered bit 7 181 [Stevens]. 183 2.1.1. Elements 185 This specification defines elements. An element is a group of any 186 number of consecutive bits which together form a syntactic entity 187 represented using the notation . Each element in this 188 document is defined as either: 190 o A specifically sized field of bits; OR 192 o A composite element, composed of other s. 194 A composite element is defined as follows: 196 := specification 198 where, on the right hand side following :=, specification is 199 represented using the regular expression syntax defined in 200 [SingleUNIX]. Only the following notation is used: 202 - Indicates that is immediately 203 followed by . 205 () - Indicates a grouping of the elements 206 enclosed by the parentheses. 208 ? - Zero or one occurrences of the preceding element or group. 210 * - Zero or more occurrences of the preceding element or group. 212 2.1.2. Variables 214 Variables are introduced into the specification solely as a means to 215 clarify the description. The following two notations are used: 217 - If is an unsigned integer field then is also 218 used to represent the value of that field. 220 bar - A variable, usually obtained through calculations based on the 221 value(s) of element(s). 223 The following variable is defined: 225 address-length - A variable whose value is the length of an address 226 in octets, it is 4 if using IPv4, or 16 if using IPv6. 228 2.2. Terminology 230 This document uses the following terminology: 232 Packet - The top level entity in this specification. A packet 233 contains a packet header and zero or more messages. 235 Message - The fundamental entity carrying protocol information, in 236 the form of address objects and TLVs. 238 Address - A number of octets of the same length as the source IP 239 address in the IP datagram carrying the packet. The meaning of an 240 address is defined by the protocol using this specification. 242 Address Prefix- An address plus a prefix length, with the prefix 243 length being a number of address bits measured from the left/most 244 significant end of the address. 246 Address Object - Either an address, or an address prefix, as 247 specified in an address block in this specification. 249 TLV - A Type-Length-Value structure. This is a generic way in which 250 an attribute can be represented and correctly parsed, without the 251 parser having to understand the attribute. 253 3. Applicability Statement 255 This specification describes a generic packet format, designed for 256 use by MANET routing protocols. The specification has been inspired 257 by and extended from that used by OLSR (The Optimized Link State 258 Routing protocol) [RFC3626]. 260 MANETs are, commonly though not exclusively, characterized as being 261 able to run over wireless network interfaces of limited to moderate 262 capacity. MANETs are therefore less tolerant of wasted transmitted 263 octets than are most wired networks. This specification thus 264 represents a tradeoff between sometimes competing attributes, 265 specifically efficiency, extensibility, and ease of use. 267 Efficiency is supported by reducing packet size and by allowing 268 multiple disjoint messages in a single packet. Reduced packet size 269 is primarily supported by address aggregation, optional packet and 270 message header fields, and optional fields in address blocks and 271 TLVs. Supporting multi-message packets allows a reduction in the 272 number of packets, each of which can incur significant bandwidth 273 costs from transport, network and lower layers. 275 This specification provides both external and internal extensibility. 276 External extensibility is supported by the ability to add packet TLVs 277 and to define new message types. Internal extensibility is supported 278 by the ability to add message TLVs and address block TLVs to existing 279 messages. Protocols can define new TLV types, and hence the contents 280 of their value fields (see Section 6.1), and new message types. 281 Protocols can also reuse message and TLV type definitions from other 282 protocols which also use this specification. 284 This specification aims at being sufficiently expressive and flexible 285 to be able to accommodate both different classes of MANET routing 286 protocols (e.g. proactive, reactive and hybrid routing protocols), as 287 well as extensions thereto. Having a common packet and message 288 format, and a common way of representing IP addresses and associated 289 attributes, allows generic parsing code to be developed, regardless 290 of the algorithm used by the routing protocol. 292 All addresses within a message are assumed to be of the same size, 293 deduced from the IP header. In the case of mixed IPv6 and IPv4 294 addresses, IPv4 addresses can be represented as IPv4-mapped IPv6 295 addresses as specified in [RFC4291]. Packets may be unicast or 296 multicast, and may use any appropriate transport protocol, or none. 298 The messages defined by this specification are designed to carry 299 MANET routing protocol signaling between MANET routers. This 300 specification includes elements which can support scope limited 301 flooding, as well as being usable for point to point delivery of 302 MANET routing protocol signaling in a multi-hop network. 304 A MANET routing protocol using the packet format defined by this 305 specification can constrain the syntax (for example requiring a 306 specific set of message header fields) that the protocol will employ. 307 Protocols with such restrictions need not be able to parse all 308 possible packet structures as defined by this document but must be 309 coherent in packet generation and reception of packets of which they 310 define. If a protocol specifies which elements are included, then 311 direct indexing of the appropriate fields is possible, dependant on 312 the syntax restrictions imposed by the protocol. Such protocols may 313 have more limited extensibility. 315 4. Protocol Overview and Functioning 317 This specification does not describe a protocol. It describes a 318 packet format, which may be used by any mobile ad hoc network routing 319 protocol. 321 5. Syntactical Specification 323 This section provides syntactical specification of a packet, 324 represented by the element and the elements from which it is 325 composed. The specification is given using the notation in 326 Section 2.1. Illustrations of specified elements are given in 327 Appendix D. 329 This format uses network byte order, as indicated in Section 2.1. 331 5.1. Packets 333 is defined by: 335 := 336 * 338 where is as defined in Section 5.2. Successful parsing is 339 terminated when all octets of the packet (as defined by the datagram 340 containing the packet) are used. 342 is defined by: 344 := 345 346 ? 347 ? 349 where: 351 is a 4 bit unsigned integer field and specifies the 352 version of the specification on which the packet and the contained 353 messages are constructed. This document specifies version 0. 355 is a 4 bit field, specifying the interpretation of the 356 remainder of the packet header: 358 bit 0 (phasseqnum): If cleared ('0'), then is not 359 included in the . If set ('1'), then 360 is included in the . 362 bit 1 (phastlv): If cleared ('0'), then is not 363 included in the . If set ('1'), then 364 is included in the . 366 bit 2 (pnouniord): If cleared ('0'), then the packet TLV block 367 MUST conform to the constraints in Section 5.4.2. If set 368 ('1'), then the packet TLV block is not subject to the 369 constraints in Section 5.4.2. Additional constraints MAY be 370 imposed by a protocol using this specification. 372 bit 3: Is RESERVED, and SHOULD be cleared ('0') on transmission, 373 and SHOULD be ignored on reception. 375 is omitted if the phasseqnum pkt-flag is cleared 376 ('0'), otherwise is a 16 bit unsigned integer field, specifying a 377 packet sequence number. 379 is omitted if the phastlv flag is cleared ('0'), and is 380 otherwise as defined in Section 5.4. 382 It is assumed that the network layer is able to deliver the exact 383 payload length, thus avoiding having to carry the packet length in 384 the packet. 386 5.2. Messages 388 Packets may, in addition to the packet header, contain one or more 389 messages. Messages contain: 391 o A message header. 393 o A message TLV block that contains zero or more TLVs, associated 394 with the whole message. 396 o Zero or more address blocks, each containing one or more address 397 objects. 399 o An address TLV block, containing zero or more TLVs, following each 400 address block, through which addresses can be associated with 401 additional attributes. 403 is defined by: 405 := 406 407 ()* 409 := 410 411 412 ? 413 ? 414 ? 415 ? 417 where: 419 is as defined in Section 5.4. 421 is as defined in Section 5.3. 423 is an 8 bit unsigned integer field, specifying the type 424 of the message. 426 is an 8 bit field, specifying the interpretation of the 427 remainder of the message header: 429 bit 0 (mhasorig): If cleared ('0'), then is not 430 included in the . If set ('1'), then is included in the . 433 bit 1 (mhashoplimit): If cleared ('0'), then is 434 not included in the . If set ('1'), then is included in the . 437 bit 2 (mhashopcount): If cleared ('0'), then is 438 not included in the . If set ('1'), then is included in the . 441 bit 3 (mhasseqnum): If cleared ('0'), then is not 442 included in the . If set ('1'), then 443 is included in the . 445 bit 4 (mnouniord): If cleared ('0'), then the message TLV block 446 and all address TLV blocks in the message MUST conform to the 447 constraints in Section 5.4.2. If set ('1'), then the message 448 TLV block and all address TLV blocks in the message are not 449 subject to the constraints in Section 5.4.2. Additional 450 constraints MAY be imposed by a protocol using this 451 specification. 453 bit 5-7: Are RESERVED, and SHOULD each be cleared ('0') on 454 transmission, and SHOULD be ignored on reception. 456 is a 16 bit unsigned integer field, specifying the number 457 of octets that make up the , including the . 459 is omitted if the mhasorig msg-flag is cleared 460 ('0'), otherwise is an identifier with length equal to address- 461 length, which can serve to uniquely identify the MANET router that 462 originated the message. 464 is omitted if the mhashoplimit msg-flag is cleared 465 ('0'), otherwise is an 8 bit unsigned integer field, which can 466 contain the maximum number of hops that the message should be 467 further transmitted. 469 is omitted if the mhashopcount msg-flag is cleared 470 ('0'), otherwise is an 8 bit unsigned integer field, which can 471 contain the number of hops that the message has traveled. 473 is omitted if the mhasseqnum msg-flag is cleared 474 ('0'), otherwise is a 16 bit unsigned integer field, which can 475 contain a sequence number, generated by the message's originator 476 MANET router. 478 5.3. Address Blocks 480 An address block can specify one or more addresses. It can also 481 specify prefix lengths that can be applied to all addresses in the 482 address block. This allows an address block to specify either 483 addresses or address prefixes. A protocol may specify that an 484 address with a maximum prefix length (equal to the address length, in 485 bits) is considered to be an address, rather than an address prefix, 486 thus allowing an address block to contain a mixture of addresses and 487 address prefixes. The common term "address object" is used in this 488 specification to cover both of these; note that an address object in 489 an address block always includes the prefix length, if present. 491 An address is specified as a sequence of address-length octets of the 492 form head:mid:tail. There are no semantics associated with head, mid 493 or tail; this representation is solely to allow aggregation of 494 addresses, which often have common parts (e.g. common prefixes or 495 multiple IPv6 addresses on the same interface). An address block 496 contains an ordered set of addresses all sharing the same head and 497 the same tail, but having individual mids. Independently, head and 498 tail may be empty, allowing for representation of address objects 499 which do not have common heads or common tails. Detailed examples of 500 address blocks are included in Appendix C.1. 502 An address block can specify address prefixes: 504 o with a single prefix length for all address prefixes; OR 506 o with a prefix length for each address prefix. 508 is defined by: 510 := 511 512 (?)? 513 (?)? 514 * 515 * 517 where: 519 is an 8 bit unsigned integer field containing the number 520 of addresses represented in the address block, which MUST NOT be 521 zero. 523 is an 8 bit field specifying the interpretation of the 524 remainder of the address block: 526 bit 0 (ahashead): If cleared ('0'), then and 527 are not included in the . If set ('1'), then 528 is included in the , and is 529 included in the unless is zero. 531 bit 1 (ahasfulltail) and bit 2 (ahaszerotail): Are interpreted 532 according to Table 1. A combination not shown in that table 533 MUST NOT be used. 535 bit 3 (ahassingleprelen) and bit 4 (ahasmultiprelen): Are 536 interpreted according to Table 2. A combination not shown in 537 that table MUST NOT be used. 539 bits 5-7: Are RESERVED, and SHOULD each be cleared ('0') on 540 transmission, and SHOULD be ignored on reception. 542 +--------------+--------------+---------------+---------------------+ 543 | ahasfulltail | ahaszerotail | | | 544 +--------------+--------------+---------------+---------------------+ 545 | 0 | 0 | not included | not included | 546 | 1 | 0 | included | included unless | 547 | | | | is | 548 | | | | zero | 549 | 0 | 1 | included | not included | 550 +--------------+--------------+---------------+---------------------+ 552 Table 1: Interpretation of the ahasfulltail and ahaszerotail addr- 553 flags 555 +------------+-----------+------------------+-----------------------+ 556 | ahassingle | ahasmulti | number of | prefix length of the | 557 | prelen | prelen | | nth address prefix, | 558 | | | fields | in bits | 559 +------------+-----------+------------------+-----------------------+ 560 | 0 | 0 | 0 | 8 * address-length | 561 | 1 | 0 | 1 | | 562 | 0 | 1 | | nth | 563 +------------+-----------+------------------+-----------------------+ 564 Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen 565 addr-flags 567 if present is an 8 bit unsigned integer field, which 568 contains the number of octets in the head of all of the addresses 569 in the address block, i.e. each element included is octets long. 572 head-length is a variable, defined to equal if 573 present, or 0 otherwise. 575 is omitted if head-length is equal to 0, otherwise it is a 576 field of the head-length leftmost octets common to all the 577 addresses in the address block. 579 if present is an 8 bit unsigned integer field, which 580 contains the number of octets in the tail of all of the addresses 581 in the address block, i.e. each element included is octets long. 584 tail-length is a variable, defined to equal if 585 present, or 0 otherwise. 587 is omitted if tail-length is equal to 0, or if the 588 ahaszerotail bit is set ('1'), otherwise it is a field of the 589 tail-length rightmost octets common to all the addresses in the 590 address block. If the ahaszerotail bit is set ('1') then the 591 tail-length rightmost octets of all the addresses in the address 592 block are all 0. 594 mid-length is a variable, which MUST be non-negative, defined by: 596 mid-length := address-length - head-length - tail-length 598 i.e. each element included is mid-length octets long. 600 is omitted if mid-length is equal to 0, otherwise each 601 is a field of length mid-length octets, representing the mid of 602 the corresponding address in the address block. When not omitted, 603 an address block contains exactly fields. 605 is an 8 bit unsigned integer field containing the 606 length, in bits, of an address prefix. If the ahassingleprelen 607 addr-flag is set ('1') then a single field is 608 included, which contains the prefix length of all addresses in the 609 address block. If the ahasmultiprelen addr-flag is set ('1') then 610 fields are included, each of which 611 contains the prefix length of the corresponding address prefix in 612 the address block (in the same order). Otherwise no fields are present; each address object can be considered 614 to have a prefix length equal to 8 * address-length bits. The 615 address block is malformed if any element has a 616 value greater than 8 * address-length. 618 5.4. TLVs and TLV Blocks 620 A TLV allows association of an arbitrary attribute with a message or 621 a packet, or with a single address or a contiguous set of addresses 622 in an address block. The attribute (value) is made up from an 623 integer number of consecutive octets. Different attributes have 624 different types; attributes which are unknown when parsing can be 625 skipped. 627 TLVs are grouped in TLV blocks, with all TLVs within a TLV block 628 associating attributes with either the packet (for the TLV block in 629 the packet header), the message (for the TLV block immediately 630 following the message header) or to addresses in the immediately 631 preceding address block. Individual TLVs in a TLV block immediately 632 following an address block can associate attributes to a single 633 address, a range of addresses or all addresses in that address block. 634 When associating an attribute with more than one address, a TLV can 635 include one value for all addresses, or one value per address. 636 Detailed examples of TLVs are included in Appendix C.2. 638 A TLV block is defined by: 640 := 641 * 643 where: 645 is a 16 bit unsigned integer field, which contains the 646 total number of octets in all of the immediately following 647 elements ( not included). 649 is as defined in Section 5.4.1. 651 5.4.1. TLVs 653 There are three kinds of TLV, each represented by an element : 655 o A packet TLV, included in the packet TLV block in a packet header. 657 o A message TLV, included in the message TLV block in a message, 658 before any address blocks. 660 o An address block TLV, included in an address TLV block following 661 an address block. An address block TLV applies to: 663 * all address objects in the address block; OR 665 * any continuous sequence of address objects in the address 666 block; OR 668 * a single address object in the address block. 670 is defined by: 672 := 673 674 ? 675 (?)? 676 (?)? 678 where: 680 is an 8 bit unsigned integer field, specifying the type 681 of the TLV, specific to the TLV kind (i.e. packet, message, or 682 address block TLV). 684 is an 8 bit field specifying the interpretation of the 685 remainder of the TLV: 687 bit 0 (thastypeext): If cleared ('0'), then is not 688 included in the . If set ('1'), then is 689 included in the . 691 bit 1 (thassingleindex) and bit 2 (thasmultiindex): Are 692 interpreted according to Table 3. A combination not shown in 693 that table MUST NOT be used. Both of these tlv-flags MUST be 694 cleared ('0') in packet and message TLVs. 696 bit 3 (thasvalue) and bit 4 (thasextlen): Are interpreted 697 according to Table 4. A combination not shown in that table 698 MUST NOT be used. 700 bit 5 (tismultivalue): This tlv-flag serves to specify how the 701 field is interpreted, as specified below. This tlv- 702 flag MUST be cleared ('0') in packet and message TLVs, if the 703 thasmultiindex tlv-flag is cleared ('0'), or if the thasvalue 704 tlv-flag is cleared ('0'). 706 bits 6-7: Are RESERVED, and SHOULD each be cleared ('0') on 707 transmission, and SHOULD be ignored on reception. 709 +-----------------+----------------+---------------+--------------+ 710 | thassingleindex | thasmultiindex | | | 711 +-----------------+----------------+---------------+--------------+ 712 | 0 | 0 | not included | not included | 713 | 1 | 0 | included | not included | 714 | 0 | 1 | included | included | 715 +-----------------+----------------+---------------+--------------+ 717 Table 3: Interpretation of the thassingleindex and thasmultiindex 718 tlv-flags 720 +-----------+------------+--------------+---------------------------+ 721 | thasvalue | thasextlen | | | 722 +-----------+------------+--------------+---------------------------+ 723 | 0 | 0 | not included | not included | 724 | 1 | 0 | 8 bits | included unless | 725 | | | | is zero | 726 | 1 | 1 | 16 bits | included unless | 727 | | | | is zero | 728 +-----------+------------+--------------+---------------------------+ 730 Table 4: Interpretation of the thasvalue and thasextlen tlv-flags 732 is an 8 bit unsigned integer field, specifying an 733 extension of the TLV type, specific to the TLV type and kind (i.e. 734 packet, message, or address block TLV). 736 tlv-type-ext is a variable, defined to equal if 737 present, or 0 otherwise. 739 tlv-fulltype is a variable, defined by: 741 tlv-fulltype := 256 * + tlv-type-ext 743 and when present, in an address block TLV 744 only, are each an 8 bit unsigned integer field. 746 index-start and index-stop are variables, defined according to 747 Table 5. The variable end-index is defined as follows: 749 * For message and packet TLVs: 751 end-index := 0 753 * For address block TLVs: 755 end-index := - 1 757 An address block TLV applies to the address objects from position 758 index-start to position index-stop (inclusive) in the address 759 block, where the first address object has position zero. 761 +-----------------+----------------+----------------+---------------+ 762 | thassingleindex | thasmultiindex | index-start := | index-stop := | 763 +-----------------+----------------+----------------+---------------+ 764 | 0 | 0 | 0 | end-index | 765 | 1 | 0 | | | 766 | 0 | 1 | | | 767 +-----------------+----------------+----------------+---------------+ 769 Table 5: Interpretation of the thassingleindex and thasmultiindex 770 tlv-flags 772 number-values is a variable, defined by: 774 number-values := index-stop - index-start + 1 776 is omitted or is an 8 or 16 bit unsigned integer field 777 according to Table 4. If the tismultivalue tlv-flag is set ('1') 778 then MUST be an integral multiple of number-values, and 779 the variable single-length is defined by: 781 single-length := / number-values 783 If the tismultivalue tlv-flag is cleared ('0'), then the variable 784 single-length is defined by: 786 single-length := 788 if present (see Table 4) is a field of length 789 octets. In an address block TLV, is associated with the 790 address objects from positions index-start to index-stop, 791 inclusive. If the tismultivalue tlv-flag is cleared ('0') then 792 the whole of this field is associated with each of the indicated 793 address objects. If the tismultivalue tlv-flag is set ('1') then 794 this field is divided equally into number-values fields, each of 795 length single-length octets, and these are associated, in order, 796 with the indicated address objects. 798 5.4.2. TLV Inclusion and Constraints 800 A TLV associates an attribute with a packet, a message or one or more 801 consecutive address objects in an address block. The interpretation 802 and processing of this attribute, and the relationship (including 803 order of processing) between different attributes associated with the 804 same entity MUST be defined by a protocol which uses this 805 specification. 807 If the appropriate flags (pnouniord for a packet TLV block, mnouniord 808 for a message TLV block or an address block TLV block) are cleared 809 ('0'), then the following constraints MUST be respected. These flags 810 MUST always be cleared ('0') unless a protocol using this 811 specification defines otherwise. Protocols SHOULD only define use of 812 these flags when necessary, and then MUST indicate what constraints 813 do apply if each of the indicated flags is set ('1'); each of these 814 constraints SHOULD be retained unless otherwise necessary. 816 o TLVs in the same TLV block are sorted in non-descending tlv- 817 fulltype order. 819 o Two or more address TLVs with the same tlv-fulltype in the same 820 message are not associated with the same value of address object. 822 o TLVs with the same tlv-fulltype associated with the same address 823 block are sorted in ascending index-start order. 825 In addition, packet and message TLVs MUST be defined so as to 826 indicate whether two such TLVs with the same tlv-fulltype are, or are 827 not, allowed in the same packet or message TLV block, respectively. 829 Note that the above constrains only the encoding of TLVs in a TLV 830 block for transmission, and do specifically NOT mandate any given 831 order of processing or interpretation by a protocol of the TLVs and 832 the entities to which these are associated. 834 Respecting the constraints above allows parsing and verification of a 835 TLV block in a single pass and allows terminating the search for a 836 TLV with a specific type without traversing the entire TLV block. 838 The constraints on address block TLVs ensure that encoded information 839 (entity-attributes) can be unambiguously decoded. 841 5.5. Malformed Elements 843 An element is malformed if it cannot be parsed according to its 844 syntactical specification (including if there are insufficient octets 845 available) or if a constraint (including, but not only, those 846 specified in Section 5.4.2) specified as one which MUST be satisfied, 847 is not. A protocol using this specification MUST specify the action, 848 or choice of actions, to be taken when a packet containing such 849 elements is received. Typical examples will include discarding any 850 affected message(s), or discarding the complete packet. 852 6. IANA Considerations 854 This document introduces four namespaces that require registration: 855 Message Types, Packet TLV Types, Message TLV Types and Address Block 856 TLV Types. This section specifies IANA registries for these 857 namespaces, and provides guidance to the Internet Assigned Numbers 858 Authority regarding registrations in these namespaces. 860 The following terms are used with the meanings defined in [BCP26]: 861 "Namespace", "Assigned Value", "Registration", "Unassigned", 862 "Reserved", "Hierarchical Allocation", "Designated Expert". 864 The following policies are used with the meanings defined in [BCP26]: 865 "Private Use", "Expert Review", "Standards Action". 867 6.1. Expert Review: Evaluation Guidelines 869 For registration requests where an Expert Review is required, the 870 Designated Expert SHOULD take the following general recommendations 871 into consideration: 873 o The purposes of these registries are to support Standard and 874 Experimental MANET routing and related protocols, and extensions 875 to the same. 877 o The intention is that all registrations will be accompanied by a 878 published RFC. 880 o In order to allow for registration prior to the RFC being approved 881 for publication, the Designated Expert can approve the 882 registration once it seems clear that an RFC is expected to be 883 published. 885 o The Designated Expert will post a request to the MANET WG mailing 886 list, or to a successor thereto as designated by the Area 887 Director, for comments and reviews. This request will include a 888 reference to the Internet-Draft requesting the registration. 890 o Before a period of 30 days has passed, the Designated Expert will 891 either approve or deny the registration request and publish a note 892 of the decision to the MANET WG mailing list or its successor, as 893 well as informing IANA and the IESG. A denial note MUST be 894 justified by an explanation and, in cases where it is possible, 895 suggestions as to how the request can be modified so as to become 896 acceptable SHOULD be provided. 898 For the registry for Message Types, the following guidelines apply: 900 o Registration of a message type implies creation of two registries 901 for message type specific message TLVs and message type specific 902 address block TLVs. The document which requests the registration 903 of the message type MUST indicate how these message type specific 904 TLV types are to be allocated, from any options in [BCP26], and 905 any initial allocations. The Designated Expert SHOULD take the 906 allocation policies specified for these registries into 907 consideration in reviewing the message type allocation request. 909 For the registries for Packet TLV Types, Message TLV Types and 910 Address Block TLV Types, the following guidelines apply: 912 o These are Hierarchical Allocations, allocation of a type creates a 913 registry for the extended types corresponding to that type. The 914 document which requests the registration of the type MUST indicate 915 how these extended types are to be allocated, from any options in 916 [BCP26], and any initial allocations. Normally this allocation 917 should also be Expert Review, but with the possible allocation of 918 some type extensions as Reserved, Experimental and/or Private. 920 o TLV type values 0-7 MUST NOT be registered except when a 921 documented need exists that TLVs of a given type are required to 922 appear before all other TLVs in the TLV block as encoded for 923 transmission. Note that the need for a TLV to be processed before 924 other TLVs does not however automatically translate into a need 925 for the TLV to appear before all other TLVs in the TLV block (the 926 order in which TLVs are to be processed MUST be defined, if 927 applicable, in the protocols using this specification). 929 o The request for a TLV type MUST include the specification of the 930 permitted size, syntax of any internal structure of, and meaning 931 of, the value field (if any) of the TLV. 933 For the registries for Message TLV Types and Address Block TLV Types, 934 the following additional guidelines apply: 936 o TLV type values 0-127 are common for all message types. TLVs 937 which receive registrations from the 0-127 interval SHOULD be 938 modular in design to allow reuse among protocols. 940 o TLV type values 128-223 are message type specific TLV type values, 941 relevant only in the context of the containing message type. 943 Registration of TLV type values within the 128-223 interval 944 requires that a registry in the 128-223 interval exists for a 945 specific message type value (see Section 6.2.1), and registrations 946 are made in accordance with the allocation policies specified for 947 these message type specific registries. Message type specific TLV 948 types SHOULD be registered for TLVs which the Designated Expert 949 deems too message type specific for registration of a 0-127 value. 950 Multiple different TLV definitions MAY be assigned the same TLV 951 type value within the 128-223 interval, given that they are 952 associated with different message type specific TLV type 953 registries. Where possible, existing global TLV definitions and 954 modular global TLV definitions for registration in the 0-127 range 955 SHOULD be used. 957 6.2. Message Types 959 A new registry for message types must be created, with initial 960 assignments and allocation policies as specified in Table 6. 962 +---------+-------------+-------------------+ 963 | Type | Description | Allocation Policy | 964 +---------+-------------+-------------------+ 965 | 0-223 | Unassigned | Expert Review | 966 | 224-255 | Unassigned | Experimental Use | 967 +---------+-------------+-------------------+ 969 Table 6: Message Types 971 6.2.1. Message Type Specific TLV Registry Creation 973 When a message type is registered then registries MUST be specified 974 for both message type specific message TLVs (Table 8) and message 975 type specific address block TLVs (Table 10). A document which 976 creates a message type specific TLV registry MUST also specify the 977 mechanism by which message specific TLV types are allocated, from 978 among those in [BCP26]. 980 6.3. Packet TLV Types 982 A new registry for packet TLV types must be created, with initial 983 assignments and allocation policies as specified in Table 7. 985 +---------+-------------+-------------------+ 986 | Type | Description | Allocation Policy | 987 +---------+-------------+-------------------+ 988 | 0-223 | Unassigned | Expert Review | 989 | 224-255 | Unassigned | Experimental Use | 990 +---------+-------------+-------------------+ 992 Table 7: Packet TLV Types 994 6.3.1. Packet TLV Type Extension Registry Creation 996 When a packet TLV type is registered then a new registry for type 997 extensions of that type must be created. A document which defines a 998 packet TLV type MUST also specify the mechanism by which its type 999 extensions are allocated, from among those in [BCP26]. 1001 6.4. Message TLV Types 1003 A new registry for message type independent message TLV types must be 1004 created, with initial assignments and allocation policies as 1005 specified in Table 8. 1007 +---------+-----------------------+-----------------------+ 1008 | Type | Description | Allocation Policy | 1009 +---------+-----------------------+-----------------------+ 1010 | 0-127 | Unassigned | Expert Review | 1011 | 128-223 | Message Type Specific | Reserved, see Table 9 | 1012 | 224-255 | Unassigned | Experimental Use | 1013 +---------+-----------------------+-----------------------+ 1015 Table 8: Message TLV Types 1017 Message TLV Types 128-223 are reserved for message type specific 1018 Message TLVs, for which a new registry is created with the 1019 registration of a message type, and with initial assignments and 1020 allocation policies as specified in Table 9. 1022 +---------+-----------------------------+-------------------+ 1023 | Type | Description | Allocation Policy | 1024 +---------+-----------------------------+-------------------+ 1025 | 0-127 | Common to all Message Types | Reserved | 1026 | 128-223 | Message Type Specific | See Below | 1027 | 224-255 | Common to all Message Types | Reserved | 1028 +---------+-----------------------------+-------------------+ 1030 Table 9: Message Specific Message TLV Types 1032 Allocation policies for message type specific message TLV types MUST 1033 be specified when creating the registry associated with the 1034 containing message type, see Section 6.2.1. 1036 6.4.1. Message TLV Type Extension Registry Creation 1038 If a message TLV type is registered then a new registry for type 1039 extensions of that type must be created. A document which defines a 1040 message TLV type MUST also specify the mechanism by which its type 1041 extensions are allocated, from among those in [BCP26]. 1043 6.5. Address Block TLV Types 1045 A new registry for message type independent address block TLV types 1046 must be created, with initial assignments and allocation policies as 1047 specified in Table 10. 1049 +---------+-----------------------+------------------------+ 1050 | Type | Description | Allocation Policy | 1051 +---------+-----------------------+------------------------+ 1052 | 0-127 | Unassigned | Expert Review | 1053 | 128-223 | Message Type Specific | Reserved, see Table 11 | 1054 | 224-255 | Unassigned | Experimental Use | 1055 +---------+-----------------------+------------------------+ 1057 Table 10: Address Block TLV Types 1059 Address Block TLV Types 128-223 are reserved for message type 1060 specific Address Block TLVs, for which a new registry is created with 1061 the registration of a message type, and with initial assignments and 1062 allocation policies as specified in Table 11. 1064 +---------+-----------------------------+-------------------+ 1065 | Type | Description | Allocation Policy | 1066 +---------+-----------------------------+-------------------+ 1067 | 0-127 | Common to all Message Types | Reserved | 1068 | 128-223 | Message Type Specific | See Below | 1069 | 224-255 | Common to all Message Types | Reserved | 1070 +---------+-----------------------------+-------------------+ 1072 Table 11: Message Specific Address Block TLV Types 1074 Allocation policies for message type specific address block TLV types 1075 MUST be specified when creating the registry associated with the 1076 containing message type, see Section 6.2.1. 1078 6.5.1. Address Block TLV Type Extension Registry Creation 1080 When an address block TLV type is registered then a new registry for 1081 type extensions of that type must be created. A document which 1082 defines a message TLV type MUST also specify the mechanism by which 1083 its type extensions are allocated, from among those in [BCP26]. 1085 7. Security Considerations 1087 This specification does not describe a protocol; it describes a 1088 packet format. As such it does not specify any security 1089 considerations, these are matters for a protocol using this 1090 specification. However some security mechanisms are enabled by this 1091 specification, and may form part of a protocol using this 1092 specification. Mechanisms which may form part of an authentication 1093 and integrity approach in a protocol using this specification, are 1094 described in Section 7.1. Mechanisms which may form part of a 1095 confidentiality approach in a protocol using this specification, are 1096 described in Section 7.2. There is however no requirement that a 1097 protocol using this specification should use either. 1099 7.1. Authentication and Integrity Suggestions 1101 The authentication and integrity suggestions made here, are based on 1102 the intended usage in Appendix B, specifically that: 1104 o Messages are designed to be carriers of protocol information and 1105 MAY, at each hop, be forwarded and/or processed by the protocol 1106 using this specification. 1108 o Packets are designed to carry a number of messages between 1109 neighboring MANET routers in a single transmission and over a 1110 single logical hop. 1112 Consequently: 1114 o For forwarded messages where the message is unchanged by 1115 forwarding MANET routers, then end-to-end authentication and 1116 integrity MAY be implemented, between MANET routers with an 1117 existing security association, by including a suitable message TLV 1118 containing a cryptographic signature in the message. Since and are the only fields that should be 1120 modified when such a message is forwarded in this manner, this 1121 signature can be calculated based on the entire message, including 1122 the message header, with the and 1123 fields set to 0 if present. 1125 o Hop-by-hop packet level authentication and integrity MAY be 1126 implemented, between MANET routers with an existing security 1127 association, by including a suitable packet TLV containing a 1128 cryptographic signature to the packet. Since packets are received 1129 as transmitted, this signature can be calculated based on the 1130 entire packet, or on parts thereof as appropriate. 1132 7.2. Confidentiality Suggestions 1134 This specification does not explicitly enable protecting packet/ 1135 message confidentiality. Such confidentiality would normally, when 1136 required, be provided hop-by-hop either by link-layer mechanisms, or 1137 at the IP layer using [RFC4301], and would apply to a packet only. 1139 It is possible, however, for a protocol using this specification to 1140 protect the confidentiality of information included in a packet, 1141 message or address block TLV by specifying that the value field of 1142 that TLV type be encrypted, as well as specifying the encryption 1143 mechanism. 1145 In an extreme case, all information can be encrypted by defining 1146 either: 1148 o A packet, consisting of only a packet header (with no messages), 1149 and containing a packet TLV, where the packet TLV type indicates 1150 that its value field contains one or more encrypted messages. 1151 Upon receipt, and once this packet TLV is successfully decrypted, 1152 these messages may then be parsed according to this specification 1153 and processed according to the protocol using this specification. 1155 o A message, consisting of only a message header and a single 1156 message TLV, where the message TLV type indicates that its value 1157 field contains an encrypted version of the message's remaining 1158 message TLVs, address blocks and address block TLVs. Upon 1159 receipt, and once this message TLV is successfully decrypted, the 1160 complete message may then be parsed according to this 1161 specification and processed according to the protocol using this 1162 specification. 1164 In either case, the protocol MUST define the encrypted TLV type, as 1165 well as the format of the encrypted data block contained in the value 1166 field of the TLV. 1168 8. References 1170 8.1. Normative References 1172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1173 Requirement Levels", RFC 2119, BCP 14, March 1997. 1175 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing 1176 an IANA Considerations Section in RFCs", RFC 5226, 1177 BCP 26, May 2008. 1179 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1180 Architecture", RFC 4291, February 2006. 1182 [SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC 1183 1/SC22/WG15, "Single UNIX Specification, Version 3, 1184 2004 Edition", April 2004. 1186 8.2. Informative References 1188 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 1189 Routing Protocol", RFC 3626, October 2003. 1191 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1192 Internet Protocol", RFC 4301, December 2005. 1194 [Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The 1195 Protocols.", 1994. 1197 Appendix A. Multiplexing and Demultiplexing 1199 The packet and message format specified in this document is designed 1200 to allow zero or more messages to be contained within a single 1201 packet. Such messages may be from the same or from different 1202 protocols. Thus, a multiplexing and demultiplexing process MUST be 1203 present. 1205 Multiplexing messages on a given MANET router into a single packet, 1206 rather than to have each message generate its own packet, reduces the 1207 total number of octets, and the number of packets transmitted by that 1208 MANET router. 1210 The multiplexing and demultiplexing process running on a given UDP 1211 port or IP protocol number, and its associated protocols, MUST: 1213 o For each message type, a protocol - unless specified otherwise, 1214 the one making the IANA reservation for that message type - MUST 1215 be designated as the "owner" of that message type. 1217 o The packet header fields, including the Packet TLV block, is used 1218 by the multiplexing and demultiplexing process, which MAY make 1219 such information available for use its protocol instances. 1221 o The field, if present, contains a sequence number 1222 which is incremented by 1 for each packet generated by a node. 1223 The sequence number after 65535 is 0. In other words, the 1224 sequence number "wraps" in the usual way. 1226 o Incoming messages MUST be either silently discarded or MUST be 1227 delivered to the instance of the protocol which owns the 1228 associated message type. Incoming messages SHOULD NOT be 1229 delivered to any other protocol instances and SHOULD NOT be 1230 delivered to more than one protocol instance. 1232 o Outgoing messages of a given type MUST be generated only by the 1233 protocol instance which owns that message type and delivered to 1234 the multiplexing and demultiplexing process. 1236 o If two protocols both wish to use the same message type then this 1237 interaction SHOULD be specified by the protocol which is the 1238 designated owner of that message type. 1240 Appendix B. Intended Usage 1242 This appendix describes the intended usage of message header fields 1243 including their content and use. Alternative uses of this 1244 specification are permitted. 1246 The message format specified in this document is designed to carry 1247 MANET routing protocol signaling between MANET routers, and to 1248 support scope limited flooding as well as point-to-point delivery. 1250 Messages are designed to be able to be forwarded over one or more 1251 logical hops, in a new packet for each logical hop. Each logical hop 1252 may consist of one or more IP hops. 1254 Specifically Scope limited flooding is supported for messages by: 1256 o The field, if present, contains the unique 1257 identifier of the MANET router which originated the message. 1259 o The field, if present, contains a sequence number 1260 which starts at 0 when first message of a given type is generated 1261 by the originator node, and is incremented by 1 for each message 1262 generated of that type. The sequence number after 65535 is 0. In 1263 other words, the sequence number "wraps" in the usual way. 1265 o If the and fields are both present, 1266 then the message header provides for duplicate suppression, using 1267 the identifier consisting of the message's , , and . These serve to uniquely identify the 1269 message in the MANET within the time period until is 1270 repeated, i.e. wraps around to a matching value. 1272 o field, if present, contains the number of hops on 1273 which the packet is allowed to travel before being discarded by a 1274 MANET router. The is set by the message 1275 originator and is used to prevent messages from endlessly 1276 circulating in a MANET. When forwarding a message, a MANET router 1277 should decrease the by 1, and the message should 1278 be discarded when reaches 0. 1280 o field, if present, contains the number of hops on 1281 which the packet has traveled across the MANET. The by 1 and should discard the message when 1286 reaches 255. 1288 o If the and fields are both 1289 present, then the message header provides the information to make 1290 forwarding decisions for scope limited flooding. This may be by 1291 any appropriate flooding mechanism specified by a protocol using 1292 this specification. 1294 Appendix C. Examples 1296 This appendix contains some examples of parts of this specification. 1298 C.1. Address Block Examples 1300 The following examples illustrate how some combinations of addresses 1301 may be efficiently included in address blocks. These examples are 1302 for IPv4, with address-length equal to 4. a, b, c etc. represent 1303 distinct, non-zero, octet values. 1305 Note that it is permissible to use a less efficient representation, 1306 in particular one in which the ahashead and ahasfulltail flags are 1307 cleared ('0'), and hence head-length = 0, tail-length = 0, mid-length 1308 = address-length, and (with no address prefixes) the address block 1309 consists of the number of addresses, with value 0, and a 1310 list of the unaggregated addresses. This is the most efficient way 1311 to represent a single address, and the only way to represent, for 1312 example, a.b.c.d and e.f.g.h in one address block. 1314 Examples: 1316 o To include a.b.c.d, a.b.e.f and a.b.g.h: 1318 * head-length = 2; 1320 * tail-length = 0; 1322 * mid-length = 2; 1324 * has ahashead set (value 128); 1326 * and are omitted. 1328 The address block is then 3 128 2 a b c d e f g h (11 octets). 1330 o To include a.b.c.g and d.e.f.g: 1332 * head-length = 0; 1334 * tail-length = 1; 1336 * mid-length = 3; 1338 * has ahasfulltail set (value 64); 1340 * and are omitted. 1342 The address block is then 2 64 1 g a b c d e f (10 octets). 1344 o To include a.b.d.e and a.c.d.e: 1346 * head-length = 1; 1348 * tail-length = 2; 1350 * mid-length = 1; 1351 * has ahashead and ahasfulltail set (value 192). 1353 The address block is then 2 192 1 a 2 d e b c (9 octets). 1355 o To include a.b.0.0, a.c.0.0, and a.d.0.0: 1357 * head-length = 1; 1359 * tail-length = 2; 1361 * mid-length = 1; 1363 * has ahashead and ahaszerotail set (value 160); 1365 * is omitted. 1367 The address block is then 3 160 1 a 2 b c d (8 octets). 1369 o To include a.b.0.0 and c.d.0.0: 1371 * head-length = 0; 1373 * tail-length = 2; 1375 * mid-length = 2; 1377 * has ahaszerotail set (value 32); 1379 * and are omitted. 1381 The address block is then 2 32 2 a b c d (7 octets). 1383 o To include a.b.0.0/n and c.d.0.0/n: 1385 * head-length = 0; 1387 * tail-length = 2; 1389 * mid-length = 2; 1391 * has ahaszerotail and ahassingleprelen set (value 1392 48); 1394 * and are omitted. 1396 The address block is then 2 48 2 a b c d n (8 octets). 1398 o To include a.b.0.0/n and c.d.0.0/m: 1400 * head-length = 0; 1402 * tail-length = 2; 1404 * mid-length = 2; 1406 * has ahaszerotail and ahasmultiprelen set (value 1407 40); 1409 * and are omitted. 1411 The address block is then 2 40 2 a b c d n m (9 octets). 1413 C.2. TLV Examples 1415 Assuming the definition of an address block TLV with type EXAMPLE1 1416 (and no type extension) which has single octet values per address, 1417 then if values a, a, b and c are to be associated with the four 1418 addresses in the preceding address block, where c is a default value 1419 that can be omitted, then this can be done in a number of ways. 1421 Examples: 1423 o Using one multivalue TLV covering all of the addresses: 1425 * has thasvalue and tismultivalue set (value 20); 1427 * and are omitted; 1429 * = 4 (single-length = 1). 1431 * The TLV is then EXAMPLE1 20 4 a a b c (7 octets). 1433 o Using one multivalue TLV omitting the last address: 1435 * has thasmultiindex, thasvalue and tismultivalue set 1436 (value 52); 1438 * = 0; 1440 * = 2 1442 * = 3 (single-length = 1). 1444 * The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets). 1446 o Using two single value TLVs, omitting the last address. First: 1448 * has thasmultiindex and thasvalue set (value 48); 1450 * = 0; 1452 * = 1; 1454 * = 1; 1456 * = a. 1458 * The TLV is then EXAMPLE1 48 0 1 1 a (6 octets). 1460 Second: 1462 * has thassingleindex and thasvalue set (value 80); 1464 * = 2; 1466 * is omitted; 1468 * = 1; 1470 * = b. 1472 * The TLV is then EXAMPLE1 80 2 1 b (5 octets). 1474 Total length of TLVs is 11 octets. 1476 In this case the first of these is the most efficient. In other 1477 cases patterns such as the others may be preferred. Regardless of 1478 efficiency, any of these may be used. 1480 Assuming the definition of an address block TLV with type EXAMPLE2 1481 (and no type extension) which has no value, which is to be associated 1482 with the second and third addresses in an address block, then this 1483 can be indicated with a single TLV: 1485 o has thasmultiindex set (value 32); 1487 o = 1; 1489 o = 2; 1491 o and are omitted. 1493 o The TLV is then EXAMPLE2 32 1 2 (4 octets). 1495 Assuming the definition of a message TLV with type EXAMPLE3 (and no 1496 type extension) which can take a value field of any length, for such 1497 a TLV with 8 octets of data (a to h): 1499 o has thasvalue set (value 16); 1501 o and are omitted; 1503 o = 8. 1505 o The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets). 1507 If, in this example, the number of data octets were 256 or greater 1508 then would also have thasextlen set and have value 24. 1509 The length would require two octets (most significant first). The 1510 TLV length would be 4 + N octets, where N is the number of data 1511 octets (it can be 3 + N octets if N is 255 or less). 1513 Appendix D. Illustrations 1515 This informative appendix illustrates the elements which are 1516 normatively specified in Section 5. 1518 Bits labeled Rsv or R should be cleared ('0'). Bits labeled C or M 1519 may be cleared ('0') or set ('1'). 1521 D.1. Packet 1523 Possible options for the element. These are differentiated 1524 by the flags field in the first octet. The packet may include any 1525 number (zero or more) of Messages. The number of Messages is 1526 determined from when the packet is exhausted, given the packet length 1527 from the network layer. 1529 0 1 2 3 1530 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 |0|0|0|0|0|0|C|R| | 1533 +-+-+-+-+-+-+-+-+ | 1534 | Message | 1535 | | 1536 | +-+-+-+-+-+-+-+-+ 1537 | | | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1539 | | 1540 : ... : 1541 | | 1542 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | | | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1545 | | 1546 | Message | 1547 | +-+-+-+-+-+-+-+-+ 1548 | | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 0 1 2 3 1551 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 |0|0|0|0|1|0|C|R| Packet Sequence Number | | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1555 | | 1556 | Message | 1557 | | 1558 | +-+-+-+-+-+-+-+-+ 1559 | | | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1561 | | 1562 : ... : 1563 | | 1564 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | | | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1567 | | 1568 | Message | 1569 | +-+-+-+-+-+-+-+-+ 1570 | | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 0 1 2 3 1573 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 |0|0|0|0|0|1|C|R| | 1576 +-+-+-+-+-+-+-+-+ | 1577 | | 1578 | Packet TLV Block | 1579 | | 1580 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | | | 1582 +-+-+-+-+-+-+-+-+ | 1583 | Message | 1584 | | 1585 | +-+-+-+-+-+-+-+-+ 1586 | | | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1588 | | 1589 : ... : 1590 | | 1591 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | | | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1594 | | 1595 | Message | 1596 | +-+-+-+-+-+-+-+-+ 1597 | | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 0 1 2 3 1600 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 |0|0|0|0|1|1|C|R| Packet Sequence Number | | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1604 | | 1605 | Packet TLV Block | 1606 | | 1607 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | | | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1610 | | 1611 | Message | 1612 | | 1613 | +-+-+-+-+-+-+-+-+ 1614 | | | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1616 | | 1617 : ... : 1618 | | 1619 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | | | 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1622 | | 1623 | Message | 1624 | +-+-+-+-+-+-+-+-+ 1625 | | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 D.2. Message 1630 Possible options for the element. These are differentiated 1631 by their second (flags) octet. The length of the Message Body is 1632 determined using the Message Size field, which is the combined length 1633 of all the fields shown. 1635 0 1 2 3 1636 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | Message Type |0|0|0|0|C| Rsv | Message Size | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | | 1641 | Message Body | 1642 | | 1643 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 0 1 2 3 1647 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Message Type |1|0|0|0|C| Rsv | Message Size | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Originator Address | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | | 1654 | Message Body | 1655 | | 1656 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 0 1 2 3 1661 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | Message Type |0|1|0|0|C| Rsv | Message Size | 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 | Hop Limit | | 1666 +-+-+-+-+-+-+-+-+ | 1667 | Message Body | 1668 | | 1669 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 | | 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 0 1 2 3 1674 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | Message Type |1|1|0|0|C| Rsv | Message Size | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | Originator Address | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | Hop Limit | | 1681 +-+-+-+-+-+-+-+-+ | 1682 | Message Body | 1683 | | 1684 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 | | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 0 1 2 3 1688 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | Message Type |0|0|1|0|C| Rsv | Message Size | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Hop Count | | 1693 +-+-+-+-+-+-+-+-+ | 1694 | Message Body | 1695 | | 1696 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 | | 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 0 1 2 3 1701 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 | Message Type |1|0|1|0|C| Rsv | Message Size | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Originator Address | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | Hop Count | | 1708 +-+-+-+-+-+-+-+-+ | 1709 | Message Body | 1710 | | 1711 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 0 1 2 3 1716 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Message Type |0|1|1|0|C| Rsv | Message Size | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Hop Limit | Hop Count | | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1722 | | 1723 | Message Body | 1724 | | 1725 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 0 1 2 3 1729 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 | Message Type |1|1|1|0|C| Rsv | Message Size | 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 | Originator Address | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 | Hop Limit | Hop Count | | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1737 | | 1738 | Message Body | 1739 | | 1740 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 0 1 2 3 1745 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 | Message Type |0|0|0|1|C| Rsv | Message Size | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 | Message Sequence Number | | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1751 | | 1752 | Message Body | 1753 | | 1754 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 | | 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 0 1 2 3 1759 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 | Message Type |1|0|0|1|C| Rsv | Message Size | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 | Originator Address | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 | Message Sequence Number | | 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1767 | | 1768 | Message Body | 1769 | | 1770 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 0 1 2 3 1774 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | Message Type |0|1|0|1|C| Rsv | Message Size | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | Hop Limit | Message Sequence Number | | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1780 | | 1781 | Message Body | 1782 | | 1783 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 0 1 2 3 1788 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Message Type |1|1|0|1|C| Rsv | Message Size | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Originator Address | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | Hop Limit | Message Sequence Number | | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1796 | | 1797 | Message Body | 1798 | | 1799 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 0 1 2 3 1804 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Message Type |0|0|1|1|C| Rsv | Message Size | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Hop Count | Message Sequence Number | | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1810 | | 1811 | Message Body | 1812 | | 1813 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 0 1 2 3 1817 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | Message Type |1|0|1|1|C| Rsv | Message Size | 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | Originator Address | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | Hop Count | Message Sequence Number | | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1825 | | 1826 | Message Body | 1827 | | 1828 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 0 1 2 3 1833 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | Message Type |0|1|1|1|C| Rsv | Message Size | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | Hop Limit | Hop Count | Message Sequence Number | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | | 1840 | Message Body | 1841 | | 1842 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 | | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 0 1 2 3 1847 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 | Message Type |1|1|1|1|C| Rsv | Message Size | 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | Originator Address | 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | Hop Limit | Hop Count | Message Sequence Number | 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | | 1856 | Message Body | 1857 | | 1858 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 D.3. Message Body 1864 Format of a message body (the element excluding its initial 1865 element). The message body includes one Message TLV 1866 Block (containing zero or more TLVs) and may include any number (zero 1867 or more) of Address Block and Address TLV Block pairs. 1869 0 1 2 3 1870 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | | 1873 | Message TLV Block | 1874 | +-+-+-+-+-+-+-+-+ 1875 | | | 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1877 | | 1878 | Address Block | 1879 | | 1880 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | | | 1882 +-+-+-+-+-+-+-+-+ | 1883 | Address TLV Block | 1884 | | 1885 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | | | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1888 | | 1889 : ... : 1890 | | 1891 | +-+-+-+-+-+-+-+-+ 1892 | | | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1894 | | 1895 | Address Block | 1896 | | 1897 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | | | 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1900 | | 1901 | Address TLV Block | 1902 | | 1903 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 D.4. Address Block 1909 Possible options for the element. These are 1910 differentiated by their second (flags) octet. The number of Mid 1911 elements is equal to the number of addresses (except when mid-length 1912 is zero, when there are no Mid elements). Where a variable number of 1913 Prefix Length fields is shown, their number is equal to the number of 1914 addresses. 1916 0 1 2 3 1917 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | Number Addrs |0|0|0|0|0| Rsv | Mid | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | Mid (cont) | | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1923 | | 1924 : ... : 1925 | | 1926 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | | Mid | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | Mid (cont) | 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 0 1 2 3 1933 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 | Number Addrs |1|0|0|0|0| Rsv | Head Length | Head | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 | Head (cont) | Mid | | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1939 | | 1940 : ... : 1941 | | 1942 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 | | Mid | 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 0 1 2 3 1946 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | Number Addrs |0|1|0|0|0| Rsv | Tail Length | Tail | 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 | Tail (cont) | Mid | | 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1952 | | 1953 : ... : 1954 | | 1955 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | | Mid | 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 0 1 2 3 1960 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 | Number Addrs |1|1|0|0|0| Rsv | Head Length | Head | 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 | Head (cont) | Tail Length | Tail | 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 | Mid | | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1968 | | 1969 : ... : 1970 | | 1971 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | | Mid | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 0 1 2 3 1976 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 | Number Addrs |0|0|1|0|0| Rsv | Tail Length | Mid | 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 | Mid (cont) | | 1981 +-+-+-+-+-+-+-+-+ | 1982 | | 1983 : ... : 1984 | | 1985 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 | | Mid | 1987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 0 1 2 3 1989 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | Number Addrs |1|0|1|0|0| Rsv | Head Length | Head | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Head (cont) | Tail Length | Mid | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | | 1996 : ... : 1997 | | 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 | Mid | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 0 1 2 3 2003 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | Number Addrs |0|0|0|1|0| Rsv | Mid | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | Mid (cont) | | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2009 | | 2010 : ... : 2011 | | 2012 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 | | Mid | 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 | Mid (cont) | Prefix Length | 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 0 1 2 3 2019 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 | Number Addrs |1|0|0|1|0| Rsv | Head Length | Head | 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 | Head (cont) | Mid | | 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2025 | | 2026 : ... : 2027 | | 2028 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 | | Mid | Prefix Length | 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 0 1 2 3 2032 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | Number Addrs |0|1|0|1|0| Rsv | Tail Length | Tail | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | Tail (cont) | Mid | | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2038 | | 2039 : ... : 2040 | | 2041 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | | Mid | Prefix Length | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 0 1 2 3 2046 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | Number Addrs |1|1|0|1|0| Rsv | Head Length | Head | 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 | Head (cont) | Tail Length | Tail | 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 | Mid | | 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2054 | | 2055 : ... : 2056 | | 2057 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 | | Mid | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 | Prefix Length | 2061 +-+-+-+-+-+-+-+-+ 2063 0 1 2 3 2064 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 | Number Addrs |0|0|1|1|0| Rsv | Tail Length | Mid | 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | Mid (cont) | | 2069 +-+-+-+-+-+-+-+-+ | 2070 | | 2071 : ... : 2072 | | 2073 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 | | Mid | Prefix Length | 2075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 0 1 2 3 2077 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 | Number Addrs |1|0|1|1|0| Rsv | Head Length | Head | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | Head (cont) | Tail Length | Mid | 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 | | 2084 : ... : 2085 | | 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 | Mid | Prefix Length | 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 0 1 2 3 2091 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2093 | Number Addrs |0|0|0|0|1| Rsv | Mid | 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | Mid (cont) | | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2097 | | 2098 : ... : 2099 | | 2100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | | Mid | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | Mid (cont) | Prefix Length | | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2105 | | 2106 : ... : 2107 | | 2108 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | | Prefix Length | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 0 1 2 3 2112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 | Number Addrs |1|0|0|0|1| Rsv | Head Length | Head | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 | Head (cont) | Mid | | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2118 | | 2119 : ... : 2120 | | 2121 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 | | Mid | Prefix Length | 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | | 2125 : ... : 2126 | | 2127 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | | Prefix Length | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 0 1 2 3 2132 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | Number Addrs |0|1|0|0|1| Rsv | Tail Length | Tail | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | Tail (cont) | Mid | | 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2138 | | 2139 : ... : 2140 | | 2141 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | | Mid | Prefix Length | 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 | | 2145 : ... : 2146 | | 2147 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | | Prefix Length | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 0 1 2 3 2151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 | Number Addrs |1|1|0|0|1| Rsv | Head Length | Head | 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 | Head (cont) | Tail Length | Tail | 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 | Mid | | 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2159 | | 2160 : ... : 2161 | | 2162 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 | | Mid | 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 | Prefix Length | | 2166 +-+-+-+-+-+-+-+-+ | 2167 : ... : 2168 | +-+-+-+-+-+-+-+-+ 2169 | | Prefix Length | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 0 1 2 3 2173 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 | Number Addrs |0|0|1|0|1| Rsv | Tail Length | Mid | 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 | Mid (cont) | | 2178 +-+-+-+-+-+-+-+-+ | 2179 | | 2180 : ... : 2181 | | 2182 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | | Mid | Prefix Length | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 | | 2186 : ... : 2187 | | 2188 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 | | Prefix Length | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 0 1 2 3 2192 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 | Number Addrs |1|0|1|0|1| Rsv | Head Length | Head | 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 | Head (cont) | Tail Length | Mid | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 | | 2199 : ... : 2200 | | 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 | Mid | Prefix Length | | 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2204 | | 2205 : ... : 2206 | | 2207 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | | Prefix Length | 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 D.5. TLV Block 2213 Format of a element. There may be any number (zero or 2214 more) of TLVs, with total length of the TLVs (in octets) equal to the 2215 Length field. 2217 0 1 2 3 2218 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 | Length | | 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2222 | | 2223 | TLV | 2224 | +-+-+-+-+-+-+-+-+ 2225 | | | 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2227 | | 2228 : ... : 2229 | | 2230 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2231 | | | 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2233 | | 2234 | TLV | 2235 | +-+-+-+-+-+-+-+-+ 2236 | | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 D.6. TLV 2241 Possible options for the element. These are differentiated by 2242 their second (flags) octet. If there are no index fields then this 2243 may be a packet, message or address block TLV, if there are one or 2244 two index fields then this must be an address block TLV. The Length 2245 field gives the length of the value field (in octets). 2247 0 1 2 3 2248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 | Type |0|0|0|0|0|0|Rsv| 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2253 0 1 2 3 2254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 | Type |1|0|0|0|0|0|Rsv| Type Ext | 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 0 1 2 3 2260 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 | Type |0|1|0|0|0|0|Rsv| Index Start | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 0 1 2 3 2266 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2268 | Type |1|1|0|0|0|0|Rsv| Type Ext | Index Start | 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 0 1 2 3 2272 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | Type |0|0|1|0|0|0|Rsv| Index Start | Index Stop | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 0 1 2 3 2277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | Type |1|0|1|0|0|0|Rsv| Type Ext | Index Start | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | Index Stop | 2282 +-+-+-+-+-+-+-+-+ 2284 0 1 2 3 2285 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 | Type |0|0|0|1|0|M|Rsv| Length | | 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2289 | | 2290 | Value | 2291 | | 2292 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | | 2294 +-+-+-+-+-+-+-+-+ 2296 0 1 2 3 2297 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 | Type |1|0|0|1|0|M|Rsv| Type Ext | Length | 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 | | 2302 | Value | 2303 | | 2304 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 | | 2306 +-+-+-+-+-+-+-+-+ 2308 0 1 2 3 2309 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 | Type |0|1|0|1|0|0|Rsv| Index Start | Length | 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 | | 2314 | Value | 2315 | | 2316 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 | | 2318 +-+-+-+-+-+-+-+-+ 2319 0 1 2 3 2320 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 | Type |1|1|0|1|0|0|Rsv| Type Ext | Index Start | 2323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2324 | Length | | 2325 +-+-+-+-+-+-+-+-+ | 2326 | Value | 2327 | | 2328 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2329 | | 2330 +-+-+-+-+-+-+-+-+ 2332 0 1 2 3 2333 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 | Type |0|0|1|1|0|M|Rsv| Index Start | Index Stop | 2336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 | Length | | 2338 +-+-+-+-+-+-+-+-+ | 2339 | Value | 2340 | | 2341 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | | 2343 +-+-+-+-+-+-+-+-+ 2345 0 1 2 3 2346 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | Type |1|0|1|1|0|M|Rsv| Type Ext | Index Start | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | Index Stop | Length | | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2352 | | 2353 | Value | 2354 | | 2355 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | | 2357 +-+-+-+-+-+-+-+-+ 2358 0 1 2 3 2359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 | Type |0|0|0|0|1|M|Rsv| Length | 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 | | 2364 | Value | 2365 | | 2366 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2367 | | 2368 +-+-+-+-+-+-+-+-+ 2370 0 1 2 3 2371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 | Type |1|0|0|1|1|M|Rsv| Type Ext | Length | 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 | Length (cont) | | 2376 +-+-+-+-+-+-+-+-+ | 2377 | Value | 2378 | | 2379 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 | | 2381 +-+-+-+-+-+-+-+-+ 2383 0 1 2 3 2384 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 | Type |0|1|0|1|1|0|Rsv| Index Start | Length | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | Length (cont) | | 2389 +-+-+-+-+-+-+-+-+ | 2390 | | 2391 | Value | 2392 | | 2393 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 | | 2395 +-+-+-+-+-+-+-+-+ 2396 0 1 2 3 2397 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | Type |1|1|0|1|1|0|Rsv| Type Ext | Index Start | 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Length | | 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2403 | | 2404 | Value | 2405 | | 2406 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 | | 2408 +-+-+-+-+-+-+-+-+ 2410 0 1 2 3 2411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 | Type |0|0|1|1|1|M|Rsv| Index Start | Index Stop | 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 | Length | | 2416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2417 | | 2418 | Value | 2419 | | 2420 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 | | 2422 +-+-+-+-+-+-+-+-+ 2424 0 1 2 3 2425 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 | Type |1|0|1|1|1|M|Rsv| Type Ext | Index Start | 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2429 | Index Stop | Length | | 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2431 | | 2432 | Value | 2433 | | 2434 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2435 | | 2436 +-+-+-+-+-+-+-+-+ 2438 Appendix E. Complete Example 2440 The following example packet, using IPv4 addresses (hence address- 2441 length is four octets) is included with the intent to exemplify how 2442 packet and message headers are constructed, and how addresses and 2443 attributes are encoded using address blocks and TLV blocks. This 2444 example is specifically not constructed to exhibit maximum message or 2445 packet size reduction. Appendix D contains illustrations of all 2446 syntactical elements. 2448 The packet header has the phasseqnum flag set of its flags field set 2449 (value 8), and hence has a Packet Sequence Number, but no packet TLV 2450 block. 2452 The packet contains a single message with length 54 octets. This 2453 message has the mhasorig, mhashoplimit, mhashopcount and mhasseqnum 2454 flags of its flags octet set (value 240), and hence includes an 2455 Originator Address, a Hop Limit, a Hop Count and a Message Sequence 2456 Number (which is type independent). The message has a message TLV 2457 block with content length 9 octets, containing a single message TLV. 2458 This TLV has the thasvalue flag of its flags octet set (value 16), 2459 and hence contains a Value field, with preceding value length 6 2460 octets. The message then has two address blocks each with a 2461 following address TLV block. 2463 The first address block contains 2 address prefixes. It has the 2464 ahaszerotail and ahassingleprelen flags of its flags octet set (value 2465 48), and hence has no head (head-length is zero octets). It has a 2466 tail-length of 2 octets, hence mid-length is two octets. The two 2467 tail octets of each address are not included (since ahaszerotail is 2468 set) and have value zero. The address block has a single Prefix 2469 Length. The following address TLV block is empty (content length 0 2470 octets). 2472 The second address block contains 3 addresses. It has the ahashead 2473 flag of its flags octet set (value 128), and has head length 2 2474 octets, no tail (tail-length is zero octets) and hence mid-length is 2475 two octets. It is followed by an address TLV block, with content 2476 length 9 octets, containing two address block TLVs. The first of 2477 these TLVs has the thasvalue flag of its flags octet set (value 16), 2478 and has a single Value of length 2 octets, which applies to all of 2479 the addresses in the address block. The second of these TLVs has the 2480 thasmultiindex flag of its flags octet set (value 32), and hence has 2481 no value length or value fields. It has two index fields (Index 2482 Start and Index Stop), which indicate those addresses this TLV 2483 applies to (inclusive range, counting from zero). 2485 0 1 2 3 2486 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type | 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 |1 1 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr | 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 | Originator Address (cont) | Hop Limit | 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0| 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 |0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 1 1 0| 2497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2498 | Value | 2499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2500 | Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0| 2501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2502 |0 0 0 0 0 0 1 0| Mid | Mid | 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2504 | Mid (cont) | Prefix Length |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2506 |0 0 0 0 0 0 1 1|1 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0| Head | 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 | Head (cont) | Mid | Mid | 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 | Mid (cont) | Mid |0 0 0 0 0 0 0 0| 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 |0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 0 1 0| 2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2514 | Value | TLV Type |0 0 1 0 0 0 0 0| 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 | Index Start | Index Stop | 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 Appendix F. Contributors 2521 This specification is the result of the joint efforts of the 2522 following contributors from the OLSRv2 Design Team, listed 2523 alphabetically: 2525 o Cedric Adjih, INRIA, France, 2527 o Emmanuel Baccelli, INRIA, France, 2529 o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, 2530 2532 o Justin W. Dean, NRL, USA, 2534 o Christopher Dearlove, BAE Systems, UK, 2535 2537 o Satoh Hiroki, Hitachi SDL, Japan, 2538 2540 o Philippe Jacquet, INRIA, France, 2542 o Monden Kazuya, Hitachi SDL, Japan, 2543 2545 Appendix G. Acknowledgments 2547 The authors would like to acknowledge the team behind OLSR [RFC3626], 2548 including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot 2549 (both at INRIA, France), and Amir Qayyum (Center for Advanced 2550 Research in Engineering, Pakistan) for their contributions. Elwyn 2551 Davis (Folly Consulting, UK), Lars Eggert (Nokia, Finland), Chris 2552 Newman (Sun Microsystems, USA), Tim Polk (NIST, USA), and Magnus 2553 Westerlund (Ericsson, Sweden) all provided detailed reviews and 2554 insightful comments. 2556 The authors would like to gratefully acknowledge the following people 2557 for intense technical discussions, early reviews and comments on the 2558 specification and its components (listed alphabetically): 2560 o Brian Adamson (NRL) 2562 o Teco Boot (Infinity Networks) 2564 o Florent Brunneau (LIX) 2566 o Ian Chakeres (Motorola) 2568 o Alan Cullen (BAE Systems) 2570 o Ulrich Herberg (LIX) 2572 o Joe Macker (NRL) 2574 o Yasunori Owada (Niigata University) 2576 o Charlie E. Perkins (WiChorus) 2578 o Andreas Schjonhaug (LIX) 2579 and the entire IETF MANET working group. 2581 Authors' Addresses 2583 Thomas Heide Clausen 2584 LIX, Ecole Polytechnique, France 2586 Phone: +33 6 6058 9349 2587 EMail: T.Clausen@computer.org 2588 URI: http://www.thomasclausen.org/ 2590 Christopher M. Dearlove 2591 BAE Systems Advanced Technology Centre 2593 Phone: +44 1245 242194 2594 EMail: chris.dearlove@baesystems.com 2595 URI: http://www.baesystems.com/ 2597 Justin W. Dean 2598 Naval Research Laboratory 2600 Phone: +1 202 767 3397 2601 EMail: jdean@itd.nrl.navy.mil 2602 URI: http://pf.itd.nrl.navy.mil/ 2604 Cedric Adjih 2605 INRIA Rocquencourt 2607 Phone: +33 1 3963 5215 2608 EMail: Cedric.Adjih@inria.fr 2609 URI: http://menetou.inria.fr/~adjih/ 2611 Full Copyright Statement 2613 Copyright (C) The IETF Trust (2008). 2615 This document is subject to the rights, licenses and restrictions 2616 contained in BCP 78, and except as set forth therein, the authors 2617 retain all their rights. 2619 This document and the information contained herein are provided on an 2620 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2621 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2622 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2623 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2624 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2625 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2627 Intellectual Property 2629 The IETF takes no position regarding the validity or scope of any 2630 Intellectual Property Rights or other rights that might be claimed to 2631 pertain to the implementation or use of the technology described in 2632 this document or the extent to which any license under such rights 2633 might or might not be available; nor does it represent that it has 2634 made any independent effort to identify any such rights. Information 2635 on the procedures with respect to rights in RFC documents can be 2636 found in BCP 78 and BCP 79. 2638 Copies of IPR disclosures made to the IETF Secretariat and any 2639 assurances of licenses to be made available, or the result of an 2640 attempt made to obtain a general license or permission for the use of 2641 such proprietary rights by implementers or users of this 2642 specification can be obtained from the IETF on-line IPR repository at 2643 http://www.ietf.org/ipr. 2645 The IETF invites any interested party to bring to its attention any 2646 copyrights, patents or patent applications, or other proprietary 2647 rights that may cover technology that may be required to implement 2648 this standard. Please address the information to the IETF at 2649 ietf-ipr@ietf.org.