idnits 2.17.1 draft-ietf-manet-packetbb-14.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 2609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2633. 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 565 has weird spacing: '...-length is a ...' == Line 576 has weird spacing: '...-length is a ...' == Line 586 has weird spacing: '...-length is a ...' == Line 726 has weird spacing: '...ype-ext is a ...' == Line 729 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 (August 1, 2008) is 5747 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: February 2, 2009 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 C. Adjih 10 INRIA Rocquencourt 11 August 1, 2008 13 Generalized MANET Packet/Message Format 14 draft-ietf-manet-packetbb-14 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 February 2, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 10 60 5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 13 61 5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 5.4.2. TLV Inclusion and Constraints . . . . . . . . . . . . 17 63 5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . 22 72 6.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 23 73 6.5.1. Address Block TLV Type Extension Registry Creation . . 23 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 75 7.1. Authentication and Integrity Suggestions . . . . . . . . . 24 76 7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 25 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . 30 85 Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 33 86 D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 33 87 D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 36 88 D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 42 89 D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 43 90 D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 50 91 D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 92 Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 56 93 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 57 94 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 58 96 1. Introduction 98 This document specifies the syntax of a packet format designed to 99 carrying multiple messages for information exchange between MANET 100 (Mobile Ad hoc NETwork) routers. Messages consist of a message 101 header, which is designed for control of message dissemination, and a 102 message body, which contains protocol information. Only the syntax 103 of the packet and messages is specified. 105 This document specifies: 107 o A packet format, allowing zero or more messages to be contained 108 within a single transmission. A packet with zero messages may be 109 sent in case the only information to exchange is contained in the 110 packet header. 112 o A message format, where a message is composed of a message header 113 and a message body. 115 o A message header format, which contains information which may be 116 sufficient to allow a protocol using this specification to make 117 processing and forwarding decisions. 119 o A message body format, containing attributes associated with the 120 message or the originator of the message, as well as blocks of 121 addresses, or address prefixes, with associated attributes. 123 o An address block format, where an address block represents sets of 124 addresses, or address prefixes, in a compact form with aggregated 125 addresses. 127 o A generalized type-length-value (TLV) format representing 128 attributes. Each TLV can be associated with a packet, a message, 129 or one or more addresses or address prefixes in a single address 130 block. Multiple TLVs can be included and each associated with a 131 packet, a message, and with the same, different or overlapping 132 sets of addresses or address prefixes. 134 The specification has been explicitly designed with the following 135 properties, listed in no particular order, in mind: 137 Parsing logic - The notation used in this specification facilitates 138 generic, protocol independent, parsing logic. 140 Extensibility - Packets and messages defined by a protocol using 141 this specification are extensible by defining new message types 142 and new TLVs. Protocols using this specification will be able to 143 correctly identify and skip such new message types and TLVs, while 144 correctly parsing the remainder of the packet and message. 146 Efficiency - When reported addresses share common bit sequences 147 (e.g. address prefixes or IPv6 interface identifiers) the address 148 block representation allows for a compact representation. Compact 149 message headers are ensured through permitting inclusion of only 150 required message header elements. The multi message packet 151 structure allows a reduction in the number of transmitted octets 152 and in the number of transmitted packets. The structure of packet 153 and message encoding allows parsing, verifying, and identifying 154 individual elements in a single pass. 156 Separation of forwarding and processing - A protocol using this 157 specification can be designed such that duplicate detection and 158 controlled scope message forwarding decisions can be made using 159 information contained in the message header, without processing 160 the message body. 162 2. Notation and Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in 167 [RFC2119]. 169 Additionally, this document uses the notation in Section 2.1, and the 170 terminology in Section 2.2. 172 2.1. Notation 174 The following notations, for elements and variables, are used in this 175 document. 177 2.1.1. Elements 179 This specification defines elements. An element is a group of any 180 number of consecutive bits which together form a syntactic entity 181 represented using the notation . Each element in this 182 document is defined as either: 184 o A specifically sized field of bits; OR 186 o A composite element, composed of other s. 188 A composite element is defined as follows: 190 := specification 192 where, on the right hand side following :=, specification is 193 represented using the regular expression syntax defined in 194 [SingleUNIX]. Only the following notation is used: 196 - Indicates that is immediately 197 followed by . 199 () - Indicates a grouping of the elements 200 enclosed by the parentheses. 202 ? - Zero or one occurrences of the preceding element or group. 204 * - Zero or more occurrences of the preceding element or group. 206 2.1.2. Variables 208 Variables are introduced into the specification solely as a means to 209 clarify the description. The following two notations are used: 211 - If is an unsigned integer field then is also 212 used to represent the value of that field. 214 bar - A variable, usually obtained through calculations based on the 215 value(s) of element(s). 217 The following variable is defined: 219 address-length - A variable whose value is the length of an address 220 in octets, it is 4 if using IPv4, or 16 if using IPv6. 222 2.2. Terminology 224 This document uses the following terminology: 226 Packet - The top level entity in this specification. A packet 227 contains a packet header and zero or more messages. 229 Message - The fundamental entity carrying protocol information, in 230 the form of address objects and TLVs. 232 Address - A number of octets of the same length as the source IP 233 address in the IP datagram carrying the packet. The meaning of an 234 address is defined by the protocol using this specification. 236 Address Prefix- An address plus a prefix length, with the prefix 237 length being a number of address bits measured from the left/most 238 significant end of the address. 240 Address Object - Either an address, or an address prefix, as 241 specified in an address block in this specification. 243 TLV - A Type-Length-Value structure. This is a generic way in which 244 an attribute can be represented and correctly parsed, without the 245 parser having to understand the attribute. 247 3. Applicability Statement 249 This specification describes a generic packet format, designed for 250 use by MANET routing protocols. The specification has been inspired 251 by and extended from that used by OLSR (The Optimized Link State 252 Routing protocol) [RFC3626]. 254 MANETs are, commonly though not exclusively, characterized as being 255 able to run over wireless network interfaces of limited to moderate 256 capacity. MANETs are therefore less tolerant of wasted transmitted 257 octets than are most wired networks. This specification thus 258 represents a tradeoff between sometimes competing attributes, 259 specifically efficiency, extensibility, and ease of use. 261 Efficiency is supported by reducing packet size and by allowing 262 multiple disjoint messages in a single packet. Reduced packet size 263 is primarily supported by address aggregation, optional packet and 264 message header fields, and optional fields in address blocks and 265 TLVs. Supporting multi-message packets allows a reduction in the 266 number of packets, each of which can incur significant bandwidth 267 costs from transport, network and lower layers. 269 This specification provides both external and internal extensibility. 270 External extensibility is supported by the ability to add packet TLVs 271 and to define new message types. Internal extensibility is supported 272 by the ability to add message TLVs and address block TLVs to existing 273 messages. Protocols can define new TLV types, and hence the contents 274 of their value fields (see Section 6.1), and new message types. 275 Protocols can also reuse message and TLV type definitions from other 276 protocols which also use this specification. 278 This specification aims at being sufficiently expressive and flexible 279 to be able to accommodate both different classes of MANET routing 280 protocols (e.g. proactive, reactive and hybrid routing protocols), as 281 well as extensions thereto. Having a common packet and message 282 format, and a common way of representing IP addresses and associated 283 attributes, allows generic parsing code to be developed, regardless 284 of the algorithm used by the routing protocol. 286 All addresses within a message are assumed to be of the same size, 287 deduced from the IP header. In the case of mixed IPv6 and IPv4 288 addresses, IPv4 addresses can be represented as IPv4-mapped IPv6 289 addresses as specified in [RFC4291]. Packets may be unicast or 290 multicast, and may use any appropriate transport protocol, or none. 292 The messages defined by this specification are designed to carry 293 MANET routing protocol signaling between MANET routers. This 294 specification includes elements which can support scope limited 295 flooding, as well as being usable for point to point delivery of 296 MANET routing protocol signaling in a multi-hop network. 298 A MANET routing protocol using the packet format defined by this 299 specification can constrain the syntax (for example requiring a 300 specific set of message header fields) that the protocol will employ. 301 Protocols with such restrictions need not be able to parse all 302 possible packet structures as defined by this document but must be 303 coherent in packet generation and reception of packets of which they 304 define. If a protocol specifies which elements are included, then 305 direct indexing of the appropriate fields is possible, dependant on 306 the syntax restrictions imposed by the protocol. Such protocols may 307 have more limited extensibility. 309 4. Protocol Overview and Functioning 311 This specification does not describe a protocol. It describes a 312 packet format, which may be used by any mobile ad hoc network routing 313 protocol. 315 5. Syntactical Specification 317 This section provides syntactical specification of a packet, 318 represented by the element and the elements from which it is 319 composed. The specification is given using the notation in 320 Section 2.1. Illustrations of specified elements are given in 321 Appendix D. 323 This format uses network byte order (most significant octet first) 324 for all fields. The most significant bit in an octet is numbered bit 325 0, and the least significant bit of an octet is numbered bit 7 326 [Stevens]. 328 5.1. Packets 330 is defined by: 332 := 333 * 335 where is as defined in Section 5.2. Successful parsing is 336 terminated when all octets of the packet (as defined by the datagram 337 containing the packet) are used. 339 is defined by: 341 := 342 343 ? 344 ? 346 where: 348 is a 4 bit unsigned integer field and specifies the 349 version of the specification on which the packet and the contained 350 messages are constructed. This document specifies version 0. 352 is a 4 bit field, specifying the interpretation of the 353 remainder of the packet header: 355 bit 0 (phasseqnum): If cleared ('0'), then is not 356 included in the . If set ('1'), then 357 is included in the . 359 bit 1 (phastlv): If cleared ('0'), then is not 360 included in the . If set ('1'), then 361 is included in the . 363 bit 2 (pnouniord): If cleared ('0'), then the packet TLV block 364 MUST conform to the constraints in Section 5.4.2. If set 365 ('1'), then the packet TLV block is not subject to the 366 constraints in Section 5.4.2. Additional constraints MAY be 367 imposed by a protocol using this specification. 369 bit 3: Is RESERVED, and SHOULD be cleared ('0') on transmission, 370 and SHOULD be ignored on reception. 372 is omitted if the phasseqnum pkt-flag is cleared 373 ('0'), otherwise is a 16 bit unsigned integer field, specifying a 374 packet sequence number. 376 is omitted if the phastlv flag is cleared ('0'), and is 377 otherwise as defined in Section 5.4. 379 5.2. Messages 381 Packets may, in addition to the packet header, contain one or more 382 messages. Messages contain: 384 o A message header. 386 o A message TLV block that contains zero or more TLVs, associated 387 with the whole message. 389 o Zero or more address blocks, each containing one or more address 390 objects. 392 o An address TLV block, containing zero or more TLVs, following each 393 address block, through which addresses can be associated with 394 additional attributes. 396 is defined by: 398 := 399 400 ()* 402 := 403 404 405 ? 406 ? 407 ? 408 ? 410 where: 412 is as defined in Section 5.4. 414 is as defined in Section 5.3. 416 is an 8 bit unsigned integer field, specifying the type 417 of the message. 419 is an 8 bit field, specifying the interpretation of the 420 remainder of the message header: 422 bit 0 (mhasorig): If cleared ('0'), then is not 423 included in the . If set ('1'), then is included in the . 426 bit 1 (mhashoplimit): If cleared ('0'), then is 427 not included in the . If set ('1'), then is included in the . 430 bit 2 (mhashopcount): If cleared ('0'), then is 431 not included in the . If set ('1'), then is included in the . 434 bit 3 (mhasseqnum): If cleared ('0'), then is not 435 included in the . If set ('1'), then 436 is included in the . 438 bit 4 (mnouniord): If cleared ('0'), then the message TLV block 439 and all address TLV blocks in the message MUST conform to the 440 constraints in Section 5.4.2. If set ('1'), then the message 441 TLV block and all address TLV blocks in the message are not 442 subject to the constraints in Section 5.4.2. Additional 443 constraints MAY be imposed by a protocol using this 444 specification. 446 bit 5-7: Are RESERVED, and SHOULD each be cleared ('0') on 447 transmission, and SHOULD be ignored on reception. 449 is a 16 bit unsigned integer field, specifying the number 450 of octets that make up the , including the . 452 is omitted if the mhasorig msg-flag is cleared 453 ('0'), otherwise is an identifier with length equal to address- 454 length, which can serve to uniquely identify the MANET router that 455 originated the message. 457 is omitted if the mhashoplimit msg-flag is cleared 458 ('0'), otherwise is an 8 bit unsigned integer field, which can 459 contain the maximum number of hops that the message should be 460 further transmitted. 462 is omitted if the mhashopcount msg-flag is cleared 463 ('0'), otherwise is an 8 bit unsigned integer field, which can 464 contain the number of hops that the message has traveled. 466 is omitted if the mhasseqnum msg-flag is cleared 467 ('0'), otherwise is a 16 bit unsigned integer field, which can 468 contain a sequence number, generated by the message's originator 469 MANET router. 471 5.3. Address Blocks 473 An address block can specify one or more addresses. It can also 474 specify prefix lengths that can be applied to all addresses in the 475 address block. This allows an address block to specify either 476 addresses or address prefixes. A protocol may specify that an 477 address with a maximum prefix length (equal to the address length, in 478 bits) is considered to be an address, rather than an address prefix, 479 thus allowing an address block to contain a mixture of addresses and 480 address prefixes. The common term "address object" is used in this 481 specification to cover both of these; note that an address object in 482 an address block always includes the prefix length, if present. 484 An address is specified as a sequence of address-length octets of the 485 form head:mid:tail. There are no semantics associated with head, mid 486 or tail; this representation is solely to allow aggregation of 487 addresses, which often have common parts (e.g. common prefixes or 488 multiple IPv6 addresses on the same interface). An address block 489 contains an ordered set of addresses all sharing the same head and 490 the same tail, but having individual mids. Independently, head and 491 tail may be empty, allowing for representation of address objects 492 which do not have common heads or common tails. Detailed examples of 493 address blocks are included in Appendix C.1. 495 An address block can specify address prefixes: 497 o with a single prefix length for all address prefixes; OR 499 o with a prefix length for each address prefix. 501 is defined by: 503 := 504 505 (?)? 506 (?)? 507 * 508 * 510 where: 512 is an 8 bit unsigned integer field containing the number 513 of addresses represented in the address block, which MUST NOT be 514 zero. 516 is an 8 bit field specifying the interpretation of the 517 remainder of the address block: 519 bit 0 (ahashead): If cleared ('0'), then and 520 are not included in the . If set ('1'), then 521 is included in the , and is 522 included in the unless is zero. 524 bit 1 (ahasfulltail) and bit 2 (ahaszerotail): Are interpreted 525 according to Table 1. A combination not shown in that table 526 MUST NOT be used. 528 bit 3 (ahassingleprelen) and bit 4 (ahasmultiprelen): Are 529 interpreted according to Table 2. A combination not shown in 530 that table MUST NOT be used. 532 bits 5-7: Are RESERVED, and SHOULD each be cleared ('0') on 533 transmission, and SHOULD be ignored on reception. 535 +--------------+--------------+---------------+---------------------+ 536 | ahasfulltail | ahaszerotail | | | 537 +--------------+--------------+---------------+---------------------+ 538 | 0 | 0 | not included | not included | 539 | 1 | 0 | included | included unless | 540 | | | | is | 541 | | | | zero | 542 | 0 | 1 | included | not included | 543 +--------------+--------------+---------------+---------------------+ 545 Table 1: Interpretation of the ahasfulltail and ahaszerotail addr- 546 flags 548 +------------+-----------+------------------+-----------------------+ 549 | ahassingle | ahasmulti | number of | prefix length of the | 550 | prelen | prelen | | nth address prefix, | 551 | | | fields | in bits | 552 +------------+-----------+------------------+-----------------------+ 553 | 0 | 0 | 0 | 8 * address-length | 554 | 1 | 0 | 1 | | 555 | 0 | 1 | | nth | 556 +------------+-----------+------------------+-----------------------+ 558 Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen 559 addr-flags 561 if present is an 8 bit unsigned integer field, which 562 contains the number of octets in the head of all of the addresses 563 in the address block. 565 head-length is a variable, defined to equal if 566 present, or 0 otherwise. 568 is omitted if head-length is equal to 0, otherwise it is a 569 field of the head-length leftmost octets common to all the 570 addresses in the address block. 572 if present is an 8 bit unsigned integer field, which 573 contains the number of octets in the tail of all of the addresses 574 in the address block. 576 tail-length is a variable, defined to equal if 577 present, or 0 otherwise. 579 is omitted if tail-length is equal to 0, or if the 580 ahaszerotail bit is set ('1'), otherwise it is a field of the 581 tail-length rightmost octets common to all the addresses in the 582 address block. If the ahaszerotail bit is set ('1') then the 583 tail-length rightmost octets of all the addresses in the address 584 block are all 0. 586 mid-length is a variable, which MUST be non-negative, defined by: 588 * mid-length := address-length - head-length - tail-length 590 is omitted if mid-length is equal to 0, otherwise each 591 is a field of length mid-length octets, representing the mid of 592 the corresponding address in the address block. When not omitted, 593 an address block contains exactly fields. 595 is an 8 bit unsigned integer field containing the 596 length, in bits, of an address prefix. If the ahassingleprelen 597 addr-flag is set ('1') then a single field is 598 included, which contains the prefix length of all addresses in the 599 address block. If the ahasmultiprelen addr-flag is set ('1') then 600 fields are included, each of which 601 contains the prefix length of the corresponding address prefix in 602 the address block (in the same order). Otherwise no fields are present; each address object can be considered 604 to have a prefix length equal to 8 * address-length bits. The 605 address block is malformed if any element has a 606 value greater than 8 * address-length. 608 5.4. TLVs and TLV Blocks 610 A TLV allows association of an arbitrary attribute with a message or 611 a packet, or with a single address or a contiguous set of addresses 612 in an address block. The attribute (value) is made up from an 613 integer number of consecutive octets. Different attributes have 614 different types; attributes which are unknown when parsing can be 615 skipped. 617 TLVs are grouped in TLV blocks, with all TLVs within a TLV block 618 associating attributes with either the packet (for the TLV block in 619 the packet header), the message (for the TLV block immediately 620 following the message header) or to addresses in the immediately 621 preceding address block. Individual TLVs in a TLV block immediately 622 following an address block can associate attributes to a single 623 address, a range of addresses or all addresses in that address block. 624 When associating an attribute with more than one address, a TLV can 625 include one value for all addresses, or one value per address. 626 Detailed examples of TLVs are included in Appendix C.2. 628 A TLV block is defined by: 630 := 631 * 633 where: 635 is a 16 bit unsigned integer field, which contains the 636 total number of octets in all of the immediately following 637 elements ( not included). 639 is as defined in Section 5.4.1. 641 5.4.1. TLVs 643 There are three kinds of TLV, each represented by an element : 645 o A packet TLV, included in the packet TLV block in a packet header. 647 o A message TLV, included in the message TLV block in a message, 648 before any address blocks. 650 o An address block TLV, included in an address TLV block following 651 an address block. An address block TLV applies to: 653 * all address objects in the address block; OR 655 * any continuous sequence of address objects in the address 656 block; OR 658 * a single address object in the address block. 660 is defined by: 662 := 663 664 ? 665 (?)? 666 (?)? 668 where: 670 is an 8 bit unsigned integer field, specifying the type 671 of the TLV, specific to the TLV kind (i.e. packet, message, or 672 address block TLV). 674 is an 8 bit field specifying the interpretation of the 675 remainder of the TLV: 677 bit 0 (thastypeext): If cleared ('0'), then is not 678 included in the . If set ('1'), then is 679 included in the . 681 bit 1 (thassingleindex) and bit 2 (thasmultiindex): Are 682 interpreted according to Table 3. A combination not shown in 683 that table MUST NOT be used. Both of these tlv-flags MUST be 684 cleared ('0') in packet and message TLVs. 686 bit 3 (thasvalue) and bit 4 (thasextlen): Are interpreted 687 according to Table 4. A combination not shown in that table 688 MUST NOT be used. 690 bit 5 (tismultivalue): This tlv-flag serves to specify how the 691 field is interpreted, as specified below. This tlv- 692 flag MUST be cleared ('0') in packet and message TLVs, if the 693 thasmultiindex tlv-flag is cleared ('0'), or if the thasvalue 694 tlv-flag is cleared ('0'). 696 bits 6-7: Are RESERVED, and SHOULD each be cleared ('0') on 697 transmission, and SHOULD be ignored on reception. 699 +-----------------+----------------+---------------+--------------+ 700 | thassingleindex | thasmultiindex | | | 701 +-----------------+----------------+---------------+--------------+ 702 | 0 | 0 | not included | not included | 703 | 1 | 0 | included | not included | 704 | 0 | 1 | included | included | 705 +-----------------+----------------+---------------+--------------+ 707 Table 3: Interpretation of the thassingleindex and thasmultiindex 708 tlv-flags 710 +-----------+------------+--------------+---------------------------+ 711 | thasvalue | thasextlen | | | 712 +-----------+------------+--------------+---------------------------+ 713 | 0 | 0 | not included | not included | 714 | 1 | 0 | 8 bits | included unless | 715 | | | | is zero | 716 | 1 | 1 | 16 bits | included unless | 717 | | | | is zero | 718 +-----------+------------+--------------+---------------------------+ 720 Table 4: Interpretation of the thasvalue and thasextlen tlv-flags 722 is an 8 bit unsigned integer field, specifying an 723 extension of the TLV type, specific to the TLV type and kind (i.e. 724 packet, message, or address block TLV). 726 tlv-type-ext is a variable, defined to equal if 727 present, or 0 otherwise. 729 tlv-fulltype is a variable, defined by: 731 * tlv-fulltype := 256 * + tlv-type-ext 733 and when present, in an address block TLV 734 only, are each an 8 bit unsigned integer field. 736 index-start and index-stop are variables, defined according to 737 Table 5. The variable end-index is defined as follows: 739 * For message and packet TLVs: 741 + end-index := 0 743 * For address block TLVs: 745 + end-index := - 1 747 An address block TLV applies to the address objects from position 748 index-start to position index-stop (inclusive) in the address 749 block, where the first address object has position zero. 751 +-----------------+----------------+----------------+---------------+ 752 | thassingleindex | thasmultiindex | index-start := | index-stop := | 753 +-----------------+----------------+----------------+---------------+ 754 | 0 | 0 | 0 | end-index | 755 | 1 | 0 | | | 756 | 0 | 1 | | | 757 +-----------------+----------------+----------------+---------------+ 759 Table 5: Interpretation of the thassingleindex and thasmultiindex 760 tlv-flags 762 number-values is a variable, defined by: 764 * number-values := index-stop - index-start + 1 766 is omitted or is an 8 or 16 bit unsigned integer field 767 according to Table 4. If the tismultivalue tlv-flag is set ('1') 768 then MUST be an integral multiple of number-values, and 769 the variable single-length is defined by: 771 * single-length := / number-values 773 If the tismultivalue tlv-flag is cleared ('0'), then the variable 774 single-length is defined by: 776 * single-length := 778 if present (see Table 4) is a field of length 779 octets. In an address block TLV, is associated with the 780 address objects from positions index-start to index-stop, 781 inclusive. If the tismultivalue tlv-flag is cleared ('0') then 782 the whole of this field is associated with each of the indicated 783 address objects. If the tismultivalue tlv-flag is set ('1') then 784 this field is divided equally into number-values fields, each of 785 length single-length octets, and these are associated, in order, 786 with the indicated address objects. 788 5.4.2. TLV Inclusion and Constraints 790 A TLV associates an attribute with a packet, a message or one or more 791 consecutive address objects in an address block. The interpretation 792 and processing of this attribute, and the relationship (including 793 order of processing) between different attributes associated with the 794 same entity MUST be defined by a protocol which uses this 795 specification. 797 If the appropriate flags (pnouniord for a packet TLV block, mnouniord 798 for a message TLV block or an address block TLV block) are cleared 799 ('0'), then the following constraints MUST be respected. These flags 800 MUST always be cleared ('0') unless a protocol using this 801 specification defines otherwise. Protocols SHOULD only define use of 802 these flags when necessary, and then MUST indicate what constraints 803 do apply if each of the indicated flags is set ('1'); each of these 804 constraints SHOULD be retained unless otherwise necessary. 806 o TLVs in the same TLV block are sorted in non-descending tlv- 807 fulltype order. 809 o Two or more address TLVs with the same tlv-fulltype in the same 810 message are not associated with the same value of address object. 812 o TLVs with the same tlv-fulltype associated with the same address 813 block are sorted in ascending index-start order. 815 In addition, packet and message TLVs MUST be defined so as to 816 indicate whether two such TLVs with the same tlv-fulltype are, or are 817 not, allowed in the same packet or message TLV block, respectively. 819 Note that the above constrains only the encoding of TLVs in a TLV 820 block for transmission, and do specifically NOT mandate any given 821 order of processing or interpretation by a protocol of the TLVs and 822 the entities to which these are associated. 824 Respecting the constraints above allows parsing and verification of a 825 TLV block in a single pass and allows terminating the search for a 826 TLV with a specific type without traversing the entire TLV block. 828 The constraints on address block TLVs ensure that encoded information 829 (entity-attributes) can be unambiguously decoded. 831 5.5. Malformed Elements 833 An element is malformed if it cannot be parsed according to its 834 syntactical specification (including if there are insufficient octets 835 available) or if a constraint (including, but not only, those 836 specified in Section 5.4.2) specified as one which MUST be satisfied, 837 is not. A protocol using this specification MUST specify the action, 838 or choice of actions, to be taken when a packet containing such 839 elements is received. Typical examples will include discarding any 840 affected message(s), or discarding the complete packet. 842 6. IANA Considerations 844 This document introduces four namespaces that require registration: 845 Message Types, Packet TLV Types, Message TLV Types and Address Block 846 TLV Types. This section specifies IANA registries for these 847 namespaces, and provides guidance to the Internet Assigned Numbers 848 Authority regarding registrations in these namespaces. 850 The following terms are used with the meanings defined in [BCP26]: 851 "Namespace", "Assigned Value", "Registration", "Unassigned", 852 "Reserved", "Hierarchical Allocation", "Designated Expert". 854 The following policies are used with the meanings defined in [BCP26]: 855 "Private Use", "Expert Review", "Standards Action". 857 6.1. Expert Review: Evaluation Guidelines 859 For registration requests where an Expert Review is required, the 860 Designated Expert SHOULD take the following general recommendations 861 into consideration: 863 o The purposes of these registries are to support Standard and 864 Experimental MANET routing and related protocols, and extensions 865 to the same. 867 o The intention is that all registrations will be accompanied by a 868 published RFC. 870 o In order to allow for registration prior to the RFC being approved 871 for publication, the Designated Expert can approve the 872 registration once it seems clear that an RFC is expected to be 873 published. 875 o The Designated Expert will post a request to the MANET WG mailing 876 list, or to a successor hereto as designated by the Area Director, 877 for comments and reviews. This request will include a reference 878 to the Internet-Draft requesting the registration. 880 o Before a period of 30 days has passed, the Designated Expert will 881 either approve or deny the registration request and publish a note 882 of the decision to the MANET WG mailing list or its successor, as 883 well as informing IANA and the IESG. A denial note MUST be 884 justified by an explanation and, in cases where it is possible, 885 suggestions as to how the request can be modified so as to become 886 acceptable SHOULD be provided. 888 For the registry for Message Types, the following guidelines apply: 890 o Registration of a message type implies creation of two registries 891 for message type specific message TLVs and message type specific 892 address block TLVs. The document which requests the registration 893 of the message type MUST indicate how these message type specific 894 TLV types are to be allocated, from any options in [BCP26], and 895 any initial allocations. The Designated Expert SHOULD take the 896 allocation policies specified for these registries into 897 consideration in reviewing the message type allocation request. 899 For the registries for Packet TLV Types, Message TLV Types and 900 Address Block TLV Types, the following guidelines apply: 902 o These are Hierarchical Allocations, allocation of a type creates a 903 registry for the extended types corresponding to that type. The 904 document which requests the registration of the type MUST indicate 905 how these extended types are to be allocated, from any options in 906 [BCP26], and any initial allocations. Normally this allocation 907 should also be Expert Review, but with the possible allocation of 908 some type extensions as Reserved, Experimental and/or Private. 910 o TLV type values 0-7 MUST NOT be registered except when a 911 documented need exists that TLVs of a given type are required to 912 appear before all other TLVs in the TLV block as encoded for 913 transmission. Note that the need for a TLV to be processed before 914 other TLVs does not however automatically translate into a need 915 for the TLV to appear before all other TLVs in the TLV block (the 916 order in which TLVs are to be processed MUST be defined, if 917 applicable, in the protocols using this specification). 919 o The request for a TLV type MUST include the specification of the 920 permitted size, syntax of any internal structure of, and meaning 921 of, the value field (if any) of the TLV. 923 For the registries for Message TLV Types and Address Block TLV Types, 924 the following additional guidelines apply: 926 o TLV type values 0-127 are common for all message types. TLVs 927 which receive registrations from the 0-127 interval SHOULD be 928 modular in design to allow reuse among protocols. 930 o TLV type values 128-223 are message type specific TLV type values, 931 relevant only in the context of the containing message type. 932 Registration of TLV type values within the 128-223 interval 933 require that a registry in the 128-223 interval exists for a 934 specific message type value (see Section 6.2.1), and registrations 935 are made in accordance with the allocation policies specified for 936 these message type specific registries. Message type specific TLV 937 types SHOULD be registered for TLVs which the Designated Expert 938 deems too message type specific for registration of a 0-127 value. 939 Multiple different TLV definitions MAY be assigned the same TLV 940 type value within the 128-223 interval, given that they are 941 associated with different message type specific TLV type 942 registries. Where possible, existing global TLV definitions and 943 modular global TLV definitions for registration in the 0-127 range 944 SHOULD be used. 946 6.2. Message Types 948 A new registry for message types must be created, with initial 949 assignments and allocation policies as specified in Table 6. 951 +---------+-------------+-------------------+ 952 | Type | Description | Allocation Policy | 953 +---------+-------------+-------------------+ 954 | 0-223 | Unassigned | Expert Review | 955 | 224-255 | Unassigned | Experimental Use | 956 +---------+-------------+-------------------+ 958 Table 6: Message Types 960 6.2.1. Message Type Specific TLV Registry Creation 962 When a message type is registered then registries MUST be specified 963 for both message type specific message TLVs (Table 8) and message 964 type specific address block TLVs (Table 10). A document which 965 creates a message type specific TLV registry MUST also specify the 966 mechanism by which message specific TLV types are allocated, from 967 among those in [BCP26]. 969 6.3. Packet TLV Types 971 A new registry for packet TLV types must be created, with initial 972 assignments and allocation policies as specified in Table 7. 974 +---------+-------------+-------------------+ 975 | Type | Description | Allocation Policy | 976 +---------+-------------+-------------------+ 977 | 0-223 | Unassigned | Expert Review | 978 | 224-255 | Unassigned | Experimental Use | 979 +---------+-------------+-------------------+ 980 Table 7: Packet TLV Types 982 6.3.1. Packet TLV Type Extension Registry Creation 984 When a packet TLV type is registered then a new registry for type 985 extensions of that type must be created. A document which defines a 986 packet TLV type MUST also specify the mechanism by which its type 987 extensions are allocated, from among those in [BCP26]. 989 6.4. Message TLV Types 991 A new registry for message type independent message TLV types must be 992 created, with initial assignments and allocation policies as 993 specified in Table 8. 995 +---------+-----------------------+-----------------------+ 996 | Type | Description | Allocation Policy | 997 +---------+-----------------------+-----------------------+ 998 | 0-127 | Unassigned | Expert Review | 999 | 128-223 | Message Type Specific | Reserved, see Table 9 | 1000 | 224-255 | Unassigned | Experimental Use | 1001 +---------+-----------------------+-----------------------+ 1003 Table 8: Message TLV Types 1005 Message TLV Types 128-223 are reserved for message type specific 1006 Message TLVs, for which a new registry is created with the 1007 registration of a message type, and with initial assignments and 1008 allocation policies as specified in Table 9. 1010 +---------+-----------------------------+-------------------+ 1011 | Type | Description | Allocation Policy | 1012 +---------+-----------------------------+-------------------+ 1013 | 0-127 | Common to all Message Types | Reserved | 1014 | 128-223 | Message Type Specific | See Below | 1015 | 224-255 | Common to all Message Types | Reserved | 1016 +---------+-----------------------------+-------------------+ 1018 Table 9: Message Specific Message TLV Types 1020 Allocation policies for message type specific message TLV types MUST 1021 be specified when creating the registry associated with the 1022 containing message type, see Section 6.2.1. 1024 6.4.1. Message TLV Type Extension Registry Creation 1026 If a message TLV type is registered then a new registry for type 1027 extensions of that type must be created. A document which defines a 1028 message TLV type MUST also specify the mechanism by which its type 1029 extensions are allocated, from among those in [BCP26]. 1031 6.5. Address Block TLV Types 1033 A new registry for message type independent address block TLV types 1034 must be created, with initial assignments and allocation policies as 1035 specified in Table 10. 1037 +---------+-----------------------+------------------------+ 1038 | Type | Description | Allocation Policy | 1039 +---------+-----------------------+------------------------+ 1040 | 0-127 | Unassigned | Expert Review | 1041 | 128-223 | Message Type Specific | Reserved, see Table 11 | 1042 | 224-255 | Unassigned | Experimental Use | 1043 +---------+-----------------------+------------------------+ 1045 Table 10: Address Block TLV Types 1047 Address Block TLV Types 128-223 are reserved for message type 1048 specific Address Block TLVs, for which a new registry is created with 1049 the registration of a message type, and with initial assignments and 1050 allocation policies as specified in Table 11. 1052 +---------+-----------------------------+-------------------+ 1053 | Type | Description | Allocation Policy | 1054 +---------+-----------------------------+-------------------+ 1055 | 0-127 | Common to all Message Types | Reserved | 1056 | 128-223 | Message Type Specific | See Below | 1057 | 224-255 | Common to all Message Types | Reserved | 1058 +---------+-----------------------------+-------------------+ 1060 Table 11: Message Specific Address Block TLV Types 1062 Allocation policies for message type specific address block TLV types 1063 MUST be specified when creating the registry associated with the 1064 containing message type, see Section 6.2.1. 1066 6.5.1. Address Block TLV Type Extension Registry Creation 1068 When an address block TLV type is registered then a new registry for 1069 type extensions of that type must be created. A document which 1070 defines a message TLV type MUST also specify the mechanism by which 1071 its type extensions are allocated, from among those in [BCP26]. 1073 7. Security Considerations 1075 This specification does not describe a protocol; it describes a 1076 packet format. As such it does not specify any security 1077 considerations, these are matters for a protocol using this 1078 specification. However some security mechanisms are enabled by this 1079 specification, and may form part of a protocol using this 1080 specification. Mechanisms which may form part of an authentication 1081 and integrity approach in a protocol using this specification, are 1082 described in Section 7.1. Mechanisms which may form part of a 1083 confidentiality approach in a protocol using this specification, are 1084 described in Section 7.2. There is however no requirement that a 1085 protocol using this specification should use either. 1087 7.1. Authentication and Integrity Suggestions 1089 The authentication and integrity suggestions made here, are based on 1090 the intended usage in Appendix B, specifically that: 1092 o Messages are designed to be carriers of protocol information and 1093 MAY, at each hop, be forwarded and/or processed by the protocol 1094 using this specification. 1096 o Packets are designed to carry a number of messages between 1097 neighboring MANET routers in a single transmission and over a 1098 single logical hop. 1100 Consequently: 1102 o For forwarded messages where the message is unchanged by 1103 forwarding MANET routers, then end-to-end authentication and 1104 integrity MAY be implemented, between MANET routers with an 1105 existing security association, by including a suitable message TLV 1106 containing a cryptographic signature in the message. Since and are the only fields that should be 1108 modified when such a message is forwarded in this manner, this 1109 signature can be calculated based on the entire message, including 1110 the message header, with the and 1111 fields set to 0 if present. 1113 o Hop-by-hop packet level authentication and integrity MAY be 1114 implemented, between MANET routers with an existing security 1115 association, by including a suitable packet TLV containing a 1116 cryptographic signature to the packet. Since packets are received 1117 as transmitted, this signature can be calculated based on the 1118 entire packet, or on parts thereof as appropriate. 1120 7.2. Confidentiality Suggestions 1122 This specification does not explicitly enable protecting packet/ 1123 message confidentiality. Such confidentiality would normally, when 1124 required, be provided hop-by-hop either by link-layer mechanisms, or 1125 at the IP layer using [RFC4301], and would apply to a packet only. 1127 It is possible, however, for a protocol using this specification to 1128 protect the confidentiality of information included in a packet, 1129 message or address block TLV by specifying that the value field of 1130 that TLV type be encrypted, as well as specifying the encryption 1131 mechanism. 1133 In an extreme case, all information can be encrypted by defining 1134 either: 1136 o A packet, consisting of only a packet header (with no messages), 1137 and containing a packet TLV, where the packet TLV type indicates 1138 that its value field contains one or more encrypted messages. 1139 Upon receipt, and once this packet TLV is successfully decrypted, 1140 these messages may then be parsed according to this specification 1141 and processed according to the protocol using this specification. 1143 o A message, consisting of only a message header and a single 1144 message TLV, where the message TLV type indicates that its value 1145 field contains an encrypted version of the message's remaining 1146 message TLVs, address blocks and address block TLVs. Upon 1147 receipt, and once this message TLV is successfully decrypted, the 1148 complete message may then be parsed according to this 1149 specification and processed according to the protocol using this 1150 specification. 1152 In either case, the protocol MUST define the encrypted TLV type, as 1153 well as the format of the encrypted data block contained in the value 1154 field of the TLV. 1156 8. References 1158 8.1. Normative References 1160 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1161 Requirement Levels", RFC 2119, BCP 14, March 1997. 1163 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing 1164 an IANA Considerations Section in RFCs", RFC 5226, 1165 BCP 26, May 2008. 1167 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1168 Architecture", RFC 4291, February 2006. 1170 [SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC 1171 1/SC22/WG15, "Single UNIX Specification, Version 3, 1172 2004 Edition", April 2004. 1174 8.2. Informative References 1176 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 1177 Routing Protocol", RFC 3626, October 2003. 1179 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1180 Internet Protocol", RFC 4301, December 2005. 1182 [Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The 1183 Protocols.", 1994. 1185 Appendix A. Multiplexing and Demultiplexing 1187 The packet and message format specified in this document is designed 1188 to allow zero or more messages to be contained within a single 1189 packet. Such messages may be from the same or from different 1190 protocols. Thus, a multiplexing and demultiplexing process MUST be 1191 present. 1193 Multiplexing messages on a given MANET router into a single packet, 1194 rather than to have each message generate its own packet, reduces the 1195 total number of octets, and the number of packets transmitted by that 1196 MANET router. 1198 The multiplexing and demultiplexing process running on a given UDP 1199 port or IP protocol number, and its associated protocols, MUST: 1201 o For each message type, a protocol - unless specified otherwise, 1202 the one making the IANA reservation for that message type - MUST 1203 be designated as the "owner" of that message type. 1205 o The packet header fields, including the Packet TLV block, is used 1206 by the multiplexing and demultiplexing process, which MAY make 1207 such information available for use its protocol instances. 1209 o The field, if present, contains a sequence number 1210 which is incremented by 1 for each packet generated by a node. 1211 The sequence number after 65535 is 0. In other words, the 1212 sequence number "wraps" in the usual way. 1214 o Incoming messages MUST be either silently discarded or MUST be 1215 delivered to the instance of the protocol which owns the 1216 associated message type. Incoming messages SHOULD NOT be 1217 delivered to any other protocol instances and SHOULD NOT be 1218 delivered to more than one protocol instance. 1220 o Outgoing messages of a given type MUST be generated only by the 1221 protocol instance which owns that message type and delivered to 1222 the multiplexing and demultiplexing process. 1224 o If two protocols both wish to use the same message type then this 1225 interaction SHOULD be specified by the protocol which is the 1226 designated owner of that message type. 1228 Appendix B. Intended Usage 1230 This appendix describes the intended usage of message header fields 1231 including their content and use. Alternative uses of this 1232 specification are permitted. 1234 The message format specified in this document is designed to carry 1235 MANET routing protocol signaling between MANET routers, and to 1236 support scope limited flooding as well as point-to-point delivery. 1238 Messages are designed to be able to be forwarded over one or more 1239 logical hops, in a new packet for each logical hop. Each logical hop 1240 may consist of one or more IP hops. 1242 Specifically Scope limited flooding is supported for messages by: 1244 o The field, if present, contains the unique 1245 identifier of the MANET router which originated the message. 1247 o The field, if present, contains a sequence number 1248 which starts at 0 when first message of a given type is generated 1249 by the originator node, and is incremented by 1 for each message 1250 generated of that type. The sequence number after 65535 is 0. In 1251 other words, the sequence number "wraps" in the usual way. 1253 o If the and fields are both present, 1254 then the message header provides for duplicate suppression, using 1255 the identifier consisting of the message's , , and . These serve to uniquely identify the 1257 message in the MANET within the time period until is 1258 repeated, i.e. wraps around to a matching value. 1260 o field, if present, contains the number of hops on 1261 which the packet is allowed to travel before being discarded by a 1262 MANET router. The is set by the message 1263 originator and is used to prevent messages from endlessly 1264 circulating in a MANET. When forwarding a message, a MANET router 1265 SHOULD decrease the by 1, and the message SHOULD 1266 be discarded when reaches 0. 1268 o field, if present, contains the number of hops on 1269 which the packet has traveled across the MANET. The by 1 and SHOULD discarded the message when 1274 reaches 255. 1276 o If the and fields are both 1277 present, then the message header provides the information to make 1278 forwarding decisions for scope limited flooding. This may be by 1279 any appropriate flooding mechanism specified by a protocol using 1280 this specification. 1282 Appendix C. Examples 1284 This appendix contains some examples of parts of this specification. 1286 C.1. Address Block Examples 1288 The following examples illustrate how some combinations of addresses 1289 may be efficiently included in address blocks. These examples are 1290 for IPv4, with address-length equal to 4. a, b, c etc. represent 1291 distinct, non-zero, octet values. 1293 Note that it is permissible to use a less efficient representation, 1294 in particular one in which the ahashead and ahasfulltail flags are 1295 cleared ('0'), and hence head-length = 0, tail-length = 0, mid-length 1296 = address-length, and (with no address prefixes) the address block 1297 consists of the number of addresses, with value 0, and a 1298 list of the unaggregated addresses. This is the most efficient way 1299 to represent a single address, and the only way to represent, for 1300 example, a.b.c.d and e.f.g.h in one address block. 1302 Examples: 1304 o To include a.b.c.d, a.b.e.f and a.b.g.h: 1306 * head-length = 2; 1308 * tail-length = 0; 1310 * mid-length = 2; 1311 * has ahashead set (value 128); 1313 * and are omitted. 1315 The address block is then 3 128 2 a b c d e f g h (11 octets). 1317 o To include a.b.c.g and d.e.f.g: 1319 * head-length = 0; 1321 * tail-length = 1; 1323 * mid-length = 3; 1325 * has ahasfulltail set (value 64); 1327 * and are omitted. 1329 The address block is then 2 64 1 g a b c d e f (10 octets). 1331 o To include a.b.d.e and a.c.d.e: 1333 * head-length = 1; 1335 * tail-length = 2; 1337 * mid-length = 1; 1339 * has ahashead and ahasfulltail set (value 192). 1341 The address block is then 2 192 1 a 2 d e b c (9 octets). 1343 o To include a.b.0.0, a.c.0.0, and a.d.0.0: 1345 * head-length = 1; 1347 * tail-length = 2; 1349 * mid-length = 1; 1351 * has ahashead and ahaszerotail set (value 160); 1353 * is omitted. 1355 The address block is then 3 160 1 a 2 b c d (8 octets). 1357 o To include a.b.0.0 and c.d.0.0: 1359 * head-length = 0; 1361 * tail-length = 2; 1363 * mid-length = 2; 1365 * has ahaszerotail set (value 32); 1367 * and are omitted. 1369 The address block is then 2 32 2 a b c d (7 octets). 1371 o To include a.b.0.0/n and c.d.0.0/n: 1373 * head-length = 0; 1375 * tail-length = 2; 1377 * mid-length = 2; 1379 * has ahaszerotail and ahassingleprelen set (value 1380 48); 1382 * and are omitted. 1384 The address block is then 2 48 2 a b c d n (8 octets). 1386 o To include a.b.0.0/n and c.d.0.0/m: 1388 * head-length = 0; 1390 * tail-length = 2; 1392 * mid-length = 2; 1394 * has ahaszerotail and ahasmultiprelen set (value 1395 40); 1397 * and are omitted. 1399 The address block is then 2 40 2 a b c d n m (9 octets). 1401 C.2. TLV Examples 1403 Assuming the definition of an address block TLV with type EXAMPLE1 1404 (and no type extension) which has single octet values per address, 1405 then if values a, a, b and c are to be associated with the four 1406 addresses in the preceding address block, where c is a default value 1407 that can be omitted, then this can be done in a number of ways. 1409 Examples: 1411 o Using one multivalue TLV covering all of the addresses: 1413 * has thasvalue and tismultivalue set (value 20); 1415 * and are omitted; 1417 * = 4 (single-length = 1). 1419 * The TLV is then EXAMPLE1 20 4 a a b c (7 octets). 1421 o Using one multivalue TLV omitting the last address: 1423 * has thasmultiindex, thasvalue and tismultivalue set 1424 (value 52); 1426 * = 0; 1428 * = 2 1430 * = 3 (single-length = 1). 1432 * The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets). 1434 o Using two single value TLVs, omitting the last address. First: 1436 * has thasmultiindex and thasvalue set (value 48); 1438 * = 0; 1440 * = 1; 1442 * = 1; 1444 * = a. 1446 * The TLV is then EXAMPLE1 48 0 1 1 a (6 octets). 1448 Second: 1450 * has thassingleindex and thasvalue set (value 80); 1452 * = 2; 1453 * is omitted; 1455 * = 1; 1457 * = b. 1459 * The TLV is then EXAMPLE1 80 2 1 b (5 octets). 1461 Total length of TLVs is 11 octets. 1463 In this case the first of these is the most efficient. In other 1464 cases patterns such as the others may be preferred. Regardless of 1465 efficiency, any of these may be used. 1467 Assuming the definition of an address block TLV with type EXAMPLE2 1468 (and no type extension) which has no value, which is to be associated 1469 with the second and third addresses in an address block, then this 1470 can be indicated with a single TLV: 1472 o has thasmultiindex set (value 32); 1474 o = 1; 1476 o = 2; 1478 o and are omitted. 1480 o The TLV is then EXAMPLE2 32 1 2 (4 octets). 1482 Assuming the definition of a message TLV with type EXAMPLE3 (and no 1483 type extension) which can take a value field of any length, for such 1484 a TLV with 8 octets of data (a to h): 1486 o has thasvalue set (value 16); 1488 o and are omitted; 1490 o = 8. 1492 o The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets). 1494 If, in this example, the number of data octets were 256 or greater 1495 then would also have thasextlen set and have value 24. 1496 The length would require two octets (most significant first). The 1497 TLV length would be 4 + N octets, where N is the number of data 1498 octets (it can be 3 + N octets if N is 255 or less). 1500 Appendix D. Illustrations 1502 This informative appendix illustrates the elements which are 1503 normatively specified in Section 5. 1505 Bits labeled Rsv or R should be cleared ('0'). Bits labeled C or M 1506 may be cleared ('0') or set ('1'). 1508 D.1. Packet 1510 Possible options for the element. These are differentiated 1511 by the flags field in the first octet. The packet may include any 1512 number (zero or more) of Messages. The number of Messages is 1513 determined from when the packet is exhausted, given the packet length 1514 from the network layer. 1516 0 1 2 3 1517 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 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 |0|0|0|0|0|0|C|R| | 1520 +-+-+-+-+-+-+-+-+ | 1521 | Message | 1522 | | 1523 | +-+-+-+-+-+-+-+-+ 1524 | | | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1526 | | 1527 : ... : 1528 | | 1529 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | | | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1532 | | 1533 | Message | 1534 | +-+-+-+-+-+-+-+-+ 1535 | | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 0 1 2 3 1538 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 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 |0|0|0|0|1|0|C|R| Packet Sequence Number | | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1542 | | 1543 | Message | 1544 | | 1545 | +-+-+-+-+-+-+-+-+ 1546 | | | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1548 | | 1549 : ... : 1550 | | 1551 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | | | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1554 | | 1555 | Message | 1556 | +-+-+-+-+-+-+-+-+ 1557 | | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 0 1 2 3 1560 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 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 |0|0|0|0|0|1|C|R| | 1563 +-+-+-+-+-+-+-+-+ | 1564 | | 1565 | Packet TLV Block | 1566 | | 1567 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | | | 1569 +-+-+-+-+-+-+-+-+ | 1570 | Message | 1571 | | 1572 | +-+-+-+-+-+-+-+-+ 1573 | | | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1575 | | 1576 : ... : 1577 | | 1578 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | | | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1581 | | 1582 | Message | 1583 | +-+-+-+-+-+-+-+-+ 1584 | | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 0 1 2 3 1587 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 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 |0|0|0|0|1|1|C|R| Packet Sequence Number | | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1591 | | 1592 | Packet TLV Block | 1593 | | 1594 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | | | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1597 | | 1598 | Message | 1599 | | 1600 | +-+-+-+-+-+-+-+-+ 1601 | | | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1603 | | 1604 : ... : 1605 | | 1606 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | | | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1609 | | 1610 | Message | 1611 | +-+-+-+-+-+-+-+-+ 1612 | | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 D.2. Message 1617 Possible options for the element. These are differentiated 1618 by their second (flags) octet. The length of the Message Body is 1619 determined using the Message Size field, which is the combined length 1620 of all the fields shown. 1622 0 1 2 3 1623 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 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 | Message Type |0|0|0|0|C| Rsv | Message Size | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | | 1628 | Message Body | 1629 | | 1630 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 0 1 2 3 1634 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 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Message Type |1|0|0|0|C| Rsv | Message Size | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | Originator Address | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | | 1641 | Message Body | 1642 | | 1643 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 0 1 2 3 1648 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 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | Message Type |0|1|0|0|C| Rsv | Message Size | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 | Hop Limit | | 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 |1|1|0|0|C| Rsv | Message Size | 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 | Originator Address | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | Hop Limit | | 1668 +-+-+-+-+-+-+-+-+ | 1669 | Message Body | 1670 | | 1671 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 0 1 2 3 1675 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 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Message Type |0|0|1|0|C| Rsv | Message Size | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | Hop Count | | 1680 +-+-+-+-+-+-+-+-+ | 1681 | Message Body | 1682 | | 1683 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 | | 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |1|0|1|0|C| Rsv | Message Size | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Originator Address | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | Hop Count | | 1695 +-+-+-+-+-+-+-+-+ | 1696 | Message Body | 1697 | | 1698 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 | | 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 0 1 2 3 1703 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 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Message Type |0|1|1|0|C| Rsv | Message Size | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | Hop Limit | Hop Count | | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1709 | | 1710 | Message Body | 1711 | | 1712 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |1|1|1|0|C| Rsv | Message Size | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Originator Address | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | Hop Limit | Hop Count | | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1724 | | 1725 | Message Body | 1726 | | 1727 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 0 1 2 3 1732 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 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Message Type |0|0|0|1|C| Rsv | Message Size | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Message Sequence Number | | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1738 | | 1739 | Message Body | 1740 | | 1741 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 0 1 2 3 1746 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 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | Message Type |1|0|0|1|C| Rsv | Message Size | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Originator Address | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | Message Sequence Number | | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1754 | | 1755 | Message Body | 1756 | | 1757 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 0 1 2 3 1761 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 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 | Message Type |0|1|0|1|C| Rsv | Message Size | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 | Hop Limit | Message Sequence Number | | 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1767 | | 1768 | Message Body | 1769 | | 1770 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 0 1 2 3 1775 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 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | Message Type |1|1|0|1|C| Rsv | Message Size | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | Originator Address | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | Hop Limit | Message Sequence Number | | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1783 | | 1784 | Message Body | 1785 | | 1786 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 | | 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 0 1 2 3 1791 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 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Message Type |0|0|1|1|C| Rsv | Message Size | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Hop Count | Message Sequence Number | | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1797 | | 1798 | Message Body | 1799 | | 1800 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |1|0|1|1|C| Rsv | Message Size | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Originator Address | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | Hop Count | Message Sequence Number | | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1812 | | 1813 | Message Body | 1814 | | 1815 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 | | 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 0 1 2 3 1820 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 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 | Message Type |0|1|1|1|C| Rsv | Message Size | 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 | Hop Limit | Hop Count | Message Sequence Number | 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 | | 1827 | Message Body | 1828 | | 1829 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 0 1 2 3 1834 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 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | Message Type |1|1|1|1|C| Rsv | Message Size | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | Originator Address | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 | Hop Limit | Hop Count | Message Sequence Number | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | | 1843 | Message Body | 1844 | | 1845 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | | 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 D.3. Message Body 1851 Format of a message body (the element excluding its initial 1852 element). The message body includes one Message TLV 1853 Block (containing zero or more TLVs) and may include any number (zero 1854 or more) of Address Block and Address TLV Block pairs. 1856 0 1 2 3 1857 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 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | | 1860 | Message TLV Block | 1861 | +-+-+-+-+-+-+-+-+ 1862 | | | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1864 | | 1865 | Address Block | 1866 | | 1867 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 | | | 1869 +-+-+-+-+-+-+-+-+ | 1870 | Address TLV Block | 1871 | | 1872 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | | | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1875 | | 1876 : ... : 1877 | | 1878 | +-+-+-+-+-+-+-+-+ 1879 | | | 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1881 | | 1882 | Address Block | 1883 | | 1884 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | | | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1887 | | 1888 | Address TLV Block | 1889 | | 1890 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 | | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 D.4. Address Block 1896 Possible options for the element. These are 1897 differentiated by their second (flags) octet. The number of Mid 1898 elements is equal to the number of addresses (except when mid-length 1899 is zero, when there are no Mid elements). Where a variable number of 1900 Prefix Length fields is shown, their number is equal to the number of 1901 addresses. 1903 0 1 2 3 1904 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 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | Number Addrs |0|0|0|0|0| Rsv | Mid | 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 | Mid (cont) | | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1910 | | 1911 : ... : 1912 | | 1913 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 | | Mid | 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 | Mid (cont) | 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 0 1 2 3 1920 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 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | Number Addrs |1|0|0|0|0| Rsv | Head Length | Head | 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 | Head (cont) | Mid | | 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1926 | | 1927 : ... : 1928 | | 1929 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | | Mid | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |0|1|0|0|0| Rsv | Tail Length | Tail | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 | Tail (cont) | Mid | | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1939 | | 1940 : ... : 1941 | | 1942 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 | | Mid | 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 0 1 2 3 1947 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 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 | Number Addrs |1|1|0|0|0| Rsv | Head Length | Head | 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 | Head (cont) | Tail Length | Tail | 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 | Mid | | 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1955 | | 1956 : ... : 1957 | | 1958 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | | Mid | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 0 1 2 3 1963 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 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | Number Addrs |0|0|1|0|0| Rsv | Tail Length | Mid | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | Mid (cont) | | 1968 +-+-+-+-+-+-+-+-+ | 1969 | | 1970 : ... : 1971 | | 1972 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | | Mid | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |1|0|1|0|0| Rsv | Head Length | Head | 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 | Head (cont) | Tail Length | Mid | 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 | | 1983 : ... : 1984 | | 1985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 | Mid | 1987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 0 1 2 3 1990 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 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1992 | Number Addrs |0|0|0|1|0| Rsv | Mid | 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 | Mid (cont) | | 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1996 | | 1997 : ... : 1998 | | 1999 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 | | Mid | 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 | Mid (cont) | Prefix Length | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 0 1 2 3 2006 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 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 | Number Addrs |1|0|0|1|0| Rsv | Head Length | Head | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | Head (cont) | Mid | | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2012 | | 2013 : ... : 2014 | | 2015 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 | | Mid | Prefix Length | 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |0|1|0|1|0| Rsv | Tail Length | Tail | 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 | Tail (cont) | Mid | | 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2025 | | 2026 : ... : 2027 | | 2028 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 | | Mid | Prefix Length | 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 0 1 2 3 2033 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 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 | Number Addrs |1|1|0|1|0| Rsv | Head Length | Head | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | Head (cont) | Tail Length | Tail | 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 | Mid | | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2041 | | 2042 : ... : 2043 | | 2044 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 | | Mid | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 | Prefix Length | 2048 +-+-+-+-+-+-+-+-+ 2050 0 1 2 3 2051 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 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | Number Addrs |0|0|1|1|0| Rsv | Tail Length | Mid | 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 | Mid (cont) | | 2056 +-+-+-+-+-+-+-+-+ | 2057 | | 2058 : ... : 2059 | | 2060 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | | Mid | Prefix Length | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |1|0|1|1|0| Rsv | Head Length | Head | 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | Head (cont) | Tail Length | Mid | 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 | | 2071 : ... : 2072 | | 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 | Mid | Prefix Length | 2075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 0 1 2 3 2078 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 2079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 | Number Addrs |0|0|0|0|1| Rsv | Mid | 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | Mid (cont) | | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2084 | | 2085 : ... : 2086 | | 2087 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 | | Mid | 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 | Mid (cont) | Prefix Length | | 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2092 | | 2093 : ... : 2094 | | 2095 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | | Prefix Length | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 0 1 2 3 2099 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 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | Number Addrs |1|0|0|0|1| Rsv | Head Length | Head | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | Head (cont) | Mid | | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2105 | | 2106 : ... : 2107 | | 2108 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | | Mid | Prefix Length | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | | 2112 : ... : 2113 | | 2114 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 | | Prefix Length | 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 0 1 2 3 2119 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 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 | Number Addrs |0|1|0|0|1| Rsv | Tail Length | Tail | 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 | Tail (cont) | Mid | | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2125 | | 2126 : ... : 2127 | | 2128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 | | Mid | Prefix Length | 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 | | 2132 : ... : 2133 | | 2134 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | | Prefix Length | 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 0 1 2 3 2138 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 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | Number Addrs |1|1|0|0|1| Rsv | Head Length | Head | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | Head (cont) | Tail Length | Tail | 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 | Mid | | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2146 | | 2147 : ... : 2148 | | 2149 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | | Mid | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | Prefix Length | | 2153 +-+-+-+-+-+-+-+-+ | 2154 : ... : 2155 | +-+-+-+-+-+-+-+-+ 2156 | | Prefix Length | 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2159 0 1 2 3 2160 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 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 | Number Addrs |0|0|1|0|1| Rsv | Tail Length | Mid | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | Mid (cont) | | 2165 +-+-+-+-+-+-+-+-+ | 2166 | | 2167 : ... : 2168 | | 2169 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | | Mid | Prefix Length | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | | 2173 : ... : 2174 | | 2175 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | | Prefix Length | 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 0 1 2 3 2179 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 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 | Number Addrs |1|0|1|0|1| Rsv | Head Length | Head | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | Head (cont) | Tail Length | Mid | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 | | 2186 : ... : 2187 | | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 | Mid | Prefix Length | | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2191 | | 2192 : ... : 2193 | | 2194 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | | Prefix Length | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 D.5. TLV Block 2200 Format of a element. There may be any number (zero or 2201 more) of TLVs, with total length of the TLVs (in octets) equal to the 2202 Length field. 2204 0 1 2 3 2205 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 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | Length | | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2209 | | 2210 | TLV | 2211 | +-+-+-+-+-+-+-+-+ 2212 | | | 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2214 | | 2215 : ... : 2216 | | 2217 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 | | | 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2220 | | 2221 | TLV | 2222 | +-+-+-+-+-+-+-+-+ 2223 | | 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 D.6. TLV 2228 Possible options for the element. These are differentiated by 2229 their second (flags) octet. If there are no index fields then this 2230 may be a packet, message or address block TLV, if there are one or 2231 two index fields then this must be an address block TLV. The Length 2232 field gives the length of the value field (in octets). 2234 0 1 2 3 2235 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 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 | Type |0|0|0|0|0|0|Rsv| 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 0 1 2 3 2241 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 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | Type |1|0|0|0|0|0|Rsv| Type Ext | 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 0 1 2 3 2247 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 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 | Type |0|1|0|0|0|0|Rsv| Index Start | 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 0 1 2 3 2253 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 2254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2255 | Type |1|1|0|0|0|0|Rsv| Type Ext | Index Start | 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 0 1 2 3 2259 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 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 | Type |0|0|1|0|0|0|Rsv| Index Start | Index Stop | 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 0 1 2 3 2264 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 2265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2266 | Type |1|0|1|0|0|0|Rsv| Type Ext | Index Start | 2267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2268 | Index Stop | 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|0|1|0|M|Rsv| Length | | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2276 | | 2277 | Value | 2278 | | 2279 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 | | 2281 +-+-+-+-+-+-+-+-+ 2283 0 1 2 3 2284 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 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | Type |1|0|0|1|0|M|Rsv| Type Ext | Length | 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 | | 2289 | Value | 2290 | | 2291 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | | 2293 +-+-+-+-+-+-+-+-+ 2295 0 1 2 3 2296 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 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 | Type |0|1|0|1|0|0|Rsv| Index Start | Length | 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 | | 2301 | Value | 2302 | | 2303 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2304 | | 2305 +-+-+-+-+-+-+-+-+ 2306 0 1 2 3 2307 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 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 | Type |1|1|0|1|0|0|Rsv| Type Ext | Index Start | 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 | Length | | 2312 +-+-+-+-+-+-+-+-+ | 2313 | Value | 2314 | | 2315 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2316 | | 2317 +-+-+-+-+-+-+-+-+ 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 |0|0|1|1|0|M|Rsv| Index Start | Index Stop | 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 |1|0|1|1|0|M|Rsv| Type Ext | Index Start | 2336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 | Index Stop | Length | | 2338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2339 | | 2340 | Value | 2341 | | 2342 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 | | 2344 +-+-+-+-+-+-+-+-+ 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 |0|0|0|0|1|M|Rsv| Length | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | | 2351 | Value | 2352 | | 2353 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | | 2355 +-+-+-+-+-+-+-+-+ 2357 0 1 2 3 2358 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 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 | Type |1|0|0|1|1|M|Rsv| Type Ext | Length | 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2362 | Length (cont) | | 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 |0|1|0|1|1|0|Rsv| Index Start | Length | 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 | Length (cont) | | 2376 +-+-+-+-+-+-+-+-+ | 2377 | | 2378 | Value | 2379 | | 2380 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 | | 2382 +-+-+-+-+-+-+-+-+ 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 |1|1|0|1|1|0|Rsv| Type Ext | Index Start | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | Length | | 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2390 | | 2391 | Value | 2392 | | 2393 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 | | 2395 +-+-+-+-+-+-+-+-+ 2397 0 1 2 3 2398 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 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 | Type |0|0|1|1|1|M|Rsv| Index Start | Index Stop | 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 | Length | | 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2404 | | 2405 | Value | 2406 | | 2407 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 | | 2409 +-+-+-+-+-+-+-+-+ 2411 0 1 2 3 2412 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 2413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2414 | Type |1|0|1|1|1|M|Rsv| Type Ext | Index Start | 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 | Index Stop | Length | | 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2418 | | 2419 | Value | 2420 | | 2421 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | | 2423 +-+-+-+-+-+-+-+-+ 2425 Appendix E. Complete Example 2427 The following example packet, using IPv4 addresses (hence address- 2428 length is four octets) is included with the intent to exemplify how 2429 packet and message headers are constructed, and how addresses and 2430 attributes are encoded using address blocks and TLV blocks. This 2431 example is specifically not constructed to exhibit maximum message or 2432 packet size reduction. Appendix D contains illustrations of all 2433 syntactical elements. 2435 The packet header has the phasseqnum flag set of its flags field set 2436 (value 8), and hence has a Packet Sequence Number, but no packet TLV 2437 block. 2439 The packet contains a single message with length 54 octets. This 2440 message has the mhasorig, mhashoplimit, mhashopcount and mhasseqnum 2441 flags of its flags octet set (value 240), and hence includes an 2442 Originator Address, a Hop Limit, a Hop Count and a Message Sequence 2443 Number (which is type independent). The message has a message TLV 2444 block with content length 9 octets, containing a single message TLV. 2445 This TLV has the thasvalue flag of its flags octet set (value 16), 2446 and hence contains a Value field, with preceding value length 6 2447 octets. The message then has two address blocks each with a 2448 following address TLV block. 2450 The first address block contains 2 address prefixes. It has the 2451 ahaszerotail and ahassingleprelen flags of its flags octet set (value 2452 48), and hence has no head (head-length is zero octets). It has a 2453 tail-length of 2 octets, hence mid-length is two octets. The two 2454 tail octets of each address are not included (since ahaszerotail is 2455 set) and have value zero. The address block has a single Prefix 2456 Length. The following address TLV block is empty (content length 0 2457 octets). 2459 The second address block contains 3 addresses. It has the ahashead 2460 flag of its flags octet set (value 128), and has head length 2 2461 octets, no tail (tail-length is zero octets) and hence mid-length is 2462 two octets. It is followed by an address TLV block, with content 2463 length 9 octets, containing two address block TLVs. The first of 2464 these TLVs has the thasvalue flag of its flags octet set (value 16), 2465 and has a single Value of length 2 octets, which applies to all of 2466 the addresses in the address block. The second of these TLVs has the 2467 thasmultiindex flag of its flags octet set (value 32), and hence has 2468 no value length or value fields. It has two index fields (Index 2469 Start and Index Stop), which indicate those addresses this TLV 2470 applies to (inclusive range, counting from zero). 2472 0 1 2 3 2473 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 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type | 2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 |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 | 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 | Originator Address (cont) | Hop Limit | 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 | Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0| 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 |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| 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 | Value | 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 | Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0| 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 |0 0 0 0 0 0 1 0| Mid | Mid | 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 | Mid (cont) | Prefix Length |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2493 |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 | 2494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2495 | Head (cont) | Mid | Mid | 2496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2497 | Mid (cont) | Mid |0 0 0 0 0 0 0 0| 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 |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| 2500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2501 | Value | TLV Type |0 0 1 0 0 0 0 0| 2502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 | Index Start | Index Stop | 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2506 Appendix F. Contributors 2508 This specification is the result of the joint efforts of the 2509 following contributors from the OLSRv2 Design Team, listed 2510 alphabetically: 2512 o Cedric Adjih, INRIA, France, 2514 o Emmanuel Baccelli, INRIA, France, 2516 o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, 2517 2519 o Justin W. Dean, NRL, USA, 2521 o Christopher Dearlove, BAE Systems, UK, 2522 2524 o Satoh Hiroki, Hitachi SDL, Japan, 2525 2527 o Philippe Jacquet, INRIA, France, 2529 o Monden Kazuya, Hitachi SDL, Japan, 2530 2532 Appendix G. Acknowledgments 2534 The authors would like to acknowledge the team behind OLSR [RFC3626], 2535 including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot 2536 (both at INRIA, France), and Amir Qayyum (Center for Advanced 2537 Research in Engineering, Pakistan) for their contributions. 2539 The authors would like to gratefully acknowledge the following people 2540 for intense technical discussions, early reviews and comments on the 2541 specification and its components (listed alphabetically): 2543 o Brian Adamson (NRL) 2545 o Teco Boot (Infinity Networks) 2547 o Florent Brunneau (LIX) 2549 o Ian Chakeres (Motorola) 2551 o Alan Cullen (BAE Systems) 2553 o Ulrich Herberg (LIX) 2555 o Joe Macker (NRL) 2557 o Yasunori Owada (Niigata University) 2559 o Charlie E. Perkins (WiChorus) 2561 o Andreas Schjonhaug (LIX) 2563 and the entire IETF MANET working group. 2565 Authors' Addresses 2567 Thomas Heide Clausen 2568 LIX, Ecole Polytechnique, France 2570 Phone: +33 6 6058 9349 2571 EMail: T.Clausen@computer.org 2572 URI: http://www.thomasclausen.org/ 2574 Christopher M. Dearlove 2575 BAE Systems Advanced Technology Centre 2577 Phone: +44 1245 242194 2578 EMail: chris.dearlove@baesystems.com 2579 URI: http://www.baesystems.com/ 2581 Justin W. Dean 2582 Naval Research Laboratory 2584 Phone: +1 202 767 3397 2585 EMail: jdean@itd.nrl.navy.mil 2586 URI: http://pf.itd.nrl.navy.mil/ 2588 Cedric Adjih 2589 INRIA Rocquencourt 2591 Phone: +33 1 3963 5215 2592 EMail: Cedric.Adjih@inria.fr 2593 URI: http://menetou.inria.fr/~adjih/ 2595 Full Copyright Statement 2597 Copyright (C) The IETF Trust (2008). 2599 This document is subject to the rights, licenses and restrictions 2600 contained in BCP 78, and except as set forth therein, the authors 2601 retain all their rights. 2603 This document and the information contained herein are provided on an 2604 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2605 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2606 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2607 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2608 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2609 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2611 Intellectual Property 2613 The IETF takes no position regarding the validity or scope of any 2614 Intellectual Property Rights or other rights that might be claimed to 2615 pertain to the implementation or use of the technology described in 2616 this document or the extent to which any license under such rights 2617 might or might not be available; nor does it represent that it has 2618 made any independent effort to identify any such rights. Information 2619 on the procedures with respect to rights in RFC documents can be 2620 found in BCP 78 and BCP 79. 2622 Copies of IPR disclosures made to the IETF Secretariat and any 2623 assurances of licenses to be made available, or the result of an 2624 attempt made to obtain a general license or permission for the use of 2625 such proprietary rights by implementers or users of this 2626 specification can be obtained from the IETF on-line IPR repository at 2627 http://www.ietf.org/ipr. 2629 The IETF invites any interested party to bring to its attention any 2630 copyrights, patents or patent applications, or other proprietary 2631 rights that may cover technology that may be required to implement 2632 this standard. Please address the information to the IETF at 2633 ietf-ipr@ietf.org.