idnits 2.17.1 draft-ietf-manet-packetbb-17.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 2596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2620. 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 450 has weird spacing: '...-length is a ...' == Line 575 has weird spacing: '...-length is a ...' == Line 587 has weird spacing: '...-length is a ...' == Line 597 has weird spacing: '...-length is a ...' == Line 739 has weird spacing: '...ype-ext is a ...' == (3 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 (November 18, 2008) is 5635 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: May 22, 2009 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 C. Adjih 10 INRIA Rocquencourt 11 November 18, 2008 13 Generalized MANET Packet/Message Format 14 draft-ietf-manet-packetbb-17 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 May 22, 2009. 41 Abstract 43 This document specifies a packet format capable of carrying multiple 44 messages that may be used by mobile ad hoc network routing protocols. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 4 50 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.1.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1.2. Variables . . . . . . . . . . . . . . . . . . . . . . 5 53 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 55 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 56 5. Syntactical Specification . . . . . . . . . . . . . . . . . . 7 57 5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 11 60 5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 14 61 5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 5.4.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . 17 63 5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 65 6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 18 66 6.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 20 67 6.2.1. Message Type Specific TLV Registry Creation . . . . . 20 68 6.3. Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 20 69 6.3.1. Packet TLV Type Extension Registry Creation . . . . . 21 70 6.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 21 71 6.4.1. Message TLV Type Extension Registry Creation . . . . . 22 72 6.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 22 73 6.5.1. Address Block TLV Type Extension Registry Creation . . 23 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 75 7.1. Authentication and Integrity Suggestions . . . . . . . . . 23 76 7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 24 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 25 80 Appendix A. Multiplexing and Demultiplexing . . . . . . . . . . . 25 81 Appendix B. Intended Usage . . . . . . . . . . . . . . . . . . . 26 82 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 27 83 C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 27 84 C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 30 85 Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 32 86 D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 32 87 D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 35 88 D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 41 89 D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 42 90 D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 49 91 D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 92 Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 55 93 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 57 94 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 58 96 1. Introduction 98 This document specifies the syntax of a packet format designed for 99 carrying multiple routing protocol messages for information exchange 100 between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a 101 message header, which is designed for control of message 102 dissemination, and a message body, which contains protocol 103 information. Only the syntax of the packet and messages is 104 specified. 106 This document specifies: 108 o A packet format, allowing zero or more messages to be contained 109 within a single transmission. A packet with zero messages may be 110 sent in case the only information to exchange is contained in the 111 packet header. 113 o A message format, where a message is composed of a message header 114 and a message body. 116 o A message header format, which contains information which may be 117 sufficient to allow a protocol using this specification to make 118 processing and forwarding decisions. 120 o A message body format, containing attributes associated with the 121 message or the originator of the message, as well as blocks of 122 addresses, or address prefixes, with associated attributes. 124 o An address block format, where an address block represents sets of 125 addresses, or address prefixes, in a compact form with aggregated 126 addresses. 128 o A generalized type-length-value (TLV) format representing 129 attributes. Each TLV can be associated with a packet, a message, 130 or one or more addresses or address prefixes in a single address 131 block. Multiple TLVs can be included and each associated with a 132 packet, a message, and with the same, different or overlapping 133 sets of addresses or address prefixes. 135 The specification has been explicitly designed with the following 136 properties, listed in no particular order, in mind: 138 Parsing logic - The notation used in this specification facilitates 139 generic, protocol independent, parsing logic. 141 Extensibility - Packets and messages defined by a protocol using 142 this specification are extensible by defining new message types 143 and new TLVs. Protocols using this specification will be able to 144 correctly identify and skip such new message types and TLVs, while 145 correctly parsing the remainder of the packet and message. 147 Efficiency - When reported addresses share common bit sequences 148 (e.g. address prefixes or IPv6 interface identifiers) the address 149 block representation allows for a compact representation. Compact 150 message headers are ensured through permitting inclusion of only 151 required message header elements. The multi message packet 152 structure allows a reduction in the number of transmitted octets 153 and in the number of transmitted packets. The structure of packet 154 and message encoding allows parsing, verifying, and identifying 155 individual elements in a single pass. 157 Separation of forwarding and processing - A protocol using this 158 specification can be designed such that duplicate detection and 159 controlled scope message forwarding decisions can be made using 160 information contained in the message header, without processing 161 the message body. 163 2. Notation and Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in 168 [RFC2119]. 170 Additionally, this document uses the notation in Section 2.1, and the 171 terminology in Section 2.2. 173 2.1. Notation 175 The following notations, for elements and variables, are used in this 176 document. 178 This format uses network byte order (most significant octet first) 179 for all fields. The most significant bit in an octet is numbered bit 180 0, and the least significant bit of an octet is numbered bit 7 181 [Stevens]. 183 2.1.1. Elements 185 This specification defines elements. An element is a group of any 186 number of consecutive bits which together form a syntactic entity 187 represented using the notation . Each element in this 188 document is defined as either: 190 o A specifically sized field of bits; OR 192 o A composite element, composed of other s. 194 A composite element is defined as follows: 196 := specification 198 where, on the right hand side following :=, specification is 199 represented using the regular expression syntax defined in 200 [SingleUNIX]. Only the following notation is used: 202 - Indicates that is immediately 203 followed by . 205 () - Indicates a grouping of the elements 206 enclosed by the parentheses. 208 ? - Zero or one occurrences of the preceding element or group. 210 * - Zero or more occurrences of the preceding element or group. 212 2.1.2. Variables 214 Variables are introduced into the specification solely as a means to 215 clarify the description. The following two notations are used: 217 - If is an unsigned integer field then is also 218 used to represent the value of that field. 220 bar - A variable, usually obtained through calculations based on the 221 value(s) of element(s). 223 2.2. Terminology 225 This document uses the following terminology: 227 Packet - The top level entity in this specification. A packet 228 contains a packet header and zero or more messages. 230 Message - The fundamental entity carrying protocol information, in 231 the form of address objects and TLVs. 233 Address - A number of octets that make up an address of the length 234 indicated by the encapsulating message header. The meaning of an 235 address is defined by the protocol using this specification. 237 Address Prefix - An address plus a prefix length, with the prefix 238 length being a number of address bits measured from the left/most 239 significant end of the address. 241 Address Object - Either an address, or an address prefix, as 242 specified in an address block in this specification. 244 TLV - A Type-Length-Value structure. This is a generic way in which 245 an attribute can be represented and correctly parsed, without the 246 parser having to understand the attribute. 248 3. Applicability Statement 250 This specification describes a generic packet format, designed for 251 use by MANET routing protocols. The specification has been inspired 252 by and extended from that used by OLSR (The Optimized Link State 253 Routing protocol) [RFC3626]. 255 MANETs are, commonly though not exclusively, characterized as being 256 able to run over wireless network interfaces of limited to moderate 257 capacity. MANETs are therefore less tolerant of wasted transmitted 258 octets than are most wired networks. This specification thus 259 represents a tradeoff between sometimes competing attributes, 260 specifically efficiency, extensibility, and ease of use. 262 Efficiency is supported by reducing packet size and by allowing 263 multiple disjoint messages in a single packet. Reduced packet size 264 is primarily supported by address aggregation, optional packet and 265 message header fields, and optional fields in address blocks and 266 TLVs. Supporting multi-message packets allows a reduction in the 267 number of packets, each of which can incur significant bandwidth 268 costs from transport, network, and lower layers. 270 This specification provides both external and internal extensibility. 271 External extensibility is supported by the ability to add packet TLVs 272 and to define new message types. Internal extensibility is supported 273 by the ability to add message TLVs and address block TLVs to existing 274 messages. Protocols can define new TLV types, and hence the contents 275 of their value fields (see Section 6.1), and new message types. 276 Protocols can also reuse message and TLV type definitions from other 277 protocols which also use this specification. 279 This specification aims at being sufficiently expressive and flexible 280 to be able to accommodate both different classes of MANET routing 281 protocols (e.g. proactive, reactive and hybrid routing protocols), as 282 well as extensions thereto. Having a common packet and message 283 format, and a common way of representing IP addresses and associated 284 attributes, allows generic parsing code to be developed, regardless 285 of the algorithm used by the routing protocol. 287 All addresses within a message are assumed to be of the same size, 288 specified in the message header. In the case of mixed IPv6 and IPv4 289 addresses, IPv4 addresses can be represented as IPv4-mapped IPv6 290 addresses as specified in [RFC4291]. 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. Packets may 297 be unicast or multicast, and may use any appropriate transport 298 protocol, or none. 300 A MANET routing protocol using the message format defined by this 301 specification can constrain the syntax (for example requiring a 302 specific set of message header fields) that the protocol will employ. 303 Protocols with such restrictions need not be able to parse all 304 possible message structures as defined by this document but must be 305 coherent in message generation and reception of messages which they 306 define. If a protocol specifies which elements are included, then 307 direct indexing of the appropriate fields is possible, dependent on 308 the syntax restrictions imposed by the protocol. Such protocols may 309 have more limited extensibility. 311 4. Protocol Overview and Functioning 313 This specification does not describe a protocol. It describes a 314 packet format, which may be used by any mobile ad hoc network routing 315 protocol. 317 5. Syntactical Specification 319 This section normatively provides syntactical specification of a 320 packet, represented by the element and the elements from 321 which it is composed. The specification is given using the notation 322 in Section 2.1. 324 Graphical illustrations of the layout of specified elements are given 325 in Appendix D, a graphical illustration of a complete example (a 326 packet including a message with address blocks and TLVs) is given in 327 Appendix E. 329 This format uses network byte order, as indicated in Section 2.1. 331 5.1. Packets 333 is defined by: 335 := 336 * 338 where is as defined in Section 5.2. Successful parsing is 339 terminated when all octets of the packet (as defined by the datagram 340 containing the packet) are used. 342 is defined by: 344 := 345 346 ? 347 ? 349 where: 351 is a 4 bit unsigned integer field and specifies the 352 version of the specification on which the packet and the contained 353 messages are constructed. This document specifies version 0. 355 is a 4 bit field, specifying the interpretation of the 356 remainder of the packet header: 358 bit 0 (phasseqnum): If cleared ('0'), then is not 359 included in the . If set ('1'), then 360 is included in the . 362 bit 1 (phastlv): If cleared ('0'), then is not 363 included in the . If set ('1'), then 364 is included in the . 366 bits 2-3: Are RESERVED, and SHOULD each be cleared ('0') on 367 transmission, and SHOULD be ignored on reception. 369 is omitted if the phasseqnum flag is cleared ('0'), 370 otherwise is a 16 bit unsigned integer field, specifying a packet 371 sequence number. 373 is omitted if the phastlv flag is cleared ('0'), and is 374 otherwise as defined in Section 5.4. 376 It is assumed that the network layer is able to deliver the exact 377 payload length, thus avoiding having to carry the packet length in 378 the packet. 380 5.2. Messages 382 Packets may, in addition to the packet header, contain one or more 383 messages. Messages contain: 385 o A message header. 387 o A message TLV block that contains zero or more TLVs, associated 388 with the whole message. 390 o Zero or more address blocks, each containing one or more address 391 objects. 393 o An address TLV block, containing zero or more TLVs, following each 394 address block, through which addresses can be associated with 395 additional attributes. 397 is defined by: 399 := 400 401 ()* 403 := 404 405 406 407 ? 408 ? 409 ? 410 ? 412 where: 414 is as defined in Section 5.4. 416 is as defined in Section 5.3. 418 is an 8 bit unsigned integer field, specifying the type 419 of the message. 421 is a 4 bit field, specifying the interpretation of the 422 remainder of the message header: 424 bit 0 (mhasorig): If cleared ('0'), then is not 425 included in the . If set ('1'), then is included in the . 428 bit 1 (mhashoplimit): If cleared ('0'), then is 429 not included in the . If set ('1'), then is included in the . 432 bit 2 (mhashopcount): If cleared ('0'), then is 433 not included in the . If set ('1'), then is included in the . 436 bit 3 (mhasseqnum): If cleared ('0'), then is not 437 included in the . If set ('1'), then 438 is included in the . 440 is a 4 bit unsigned integer field, encoding the 441 length of all addresses included in this message ( 442 as well as each address included in address blocks as defined in 443 Section 5.3), as follows: 445 = the length of an address in octets - 1 447 is thus 3 for IPv4 addresses, or 15 for IPv4 448 addresses. 450 address-length is a variable whose value is the length of an address 451 in octets, and is calculated as follows: 453 address-length = + 1 455 is a 16 bit unsigned integer field, specifying the number 456 of octets that make up the , including the . 458 is omitted if the mhasorig flag is cleared ('0'), 459 otherwise is an identifier with length equal to address-length, 460 which can serve to uniquely identify the MANET router that 461 originated the message. 463 is omitted if the mhashoplimit flag is cleared 464 ('0'), otherwise is an 8 bit unsigned integer field, which can 465 contain the maximum number of hops that the message should be 466 further transmitted. 468 is omitted if the mhashopcount flag is cleared 469 ('0'), otherwise is an 8 bit unsigned integer field, which can 470 contain the number of hops that the message has traveled. 472 is omitted if the mhasseqnum flag is cleared ('0'), 473 otherwise is a 16 bit unsigned integer field, which can contain a 474 sequence number, generated by the message's originator MANET 475 router. 477 5.3. Address Blocks 479 An address block can specify one or more addresses, all of which will 480 each be address-length octets long, as specified using the in the of the message containing the address 482 block. An address block can also specify prefix lengths that can be 483 applied to all addresses in the address block, if appropriate. This 484 allows an address block to specify either addresses or address 485 prefixes. A protocol may specify that an address with a maximum 486 prefix length (equal to the address length, in bits, i.e. 8 * 487 address-length) is considered to be an address, rather than an 488 address prefix, thus allowing an address block to contain a mixture 489 of addresses and address prefixes. The common term "address object" 490 is used in this specification to cover both of these; note that an 491 address object in an address block always includes the prefix length, 492 if present. 494 An address is specified as a sequence of address-length octets of the 495 form head:mid:tail. There are no semantics associated with head, mid 496 or tail; this representation is solely to allow aggregation of 497 addresses, which often have common parts (e.g. common prefixes or 498 multiple IPv6 addresses on the same interface). An address block 499 contains an ordered set of addresses all sharing the same head and 500 the same tail, but having individual mids. Independently, head and 501 tail may be empty, allowing for representation of address objects 502 which do not have common heads or common tails. Detailed examples of 503 address blocks are included in Appendix C.1. 505 An address block can specify address prefixes: 507 o with a single prefix length for all address prefixes; OR 509 o with a prefix length for each address prefix. 511 is defined by: 513 := 514 515 (?)? 516 (?)? 517 * 518 * 520 where: 522 is an 8 bit unsigned integer field containing the number 523 of addresses represented in the address block, which MUST NOT be 524 zero. 526 is an 8 bit field specifying the interpretation of the 527 remainder of the address block: 529 bit 0 (ahashead): If cleared ('0'), then and 530 are not included in the . If set ('1'), then 531 is included in the , and is 532 included in the unless is zero. 534 bit 1 (ahasfulltail) and bit 2 (ahaszerotail): Are interpreted 535 according to Table 1. A combination not shown in that table 536 MUST NOT be used. 538 bit 3 (ahassingleprelen) and bit 4 (ahasmultiprelen): Are 539 interpreted according to Table 2. A combination not shown in 540 that table MUST NOT be used. 542 bits 5-7: Are RESERVED, and SHOULD each be cleared ('0') on 543 transmission, and SHOULD be ignored on reception. 545 +--------------+--------------+---------------+---------------------+ 546 | ahasfulltail | ahaszerotail | | | 547 +--------------+--------------+---------------+---------------------+ 548 | 0 | 0 | not included | not included | 549 | 1 | 0 | included | included unless | 550 | | | | is | 551 | | | | zero | 552 | 0 | 1 | included | not included | 553 +--------------+--------------+---------------+---------------------+ 555 Table 1: Interpretation of the ahasfulltail and ahaszerotail flags 557 +------------+-----------+------------------+-----------------------+ 558 | ahassingle | ahasmulti | number of | prefix length of the | 559 | prelen | prelen | | nth address prefix, | 560 | | | fields | in bits | 561 +------------+-----------+------------------+-----------------------+ 562 | 0 | 0 | 0 | 8 * address-length | 563 | 1 | 0 | 1 | | 564 | 0 | 1 | | nth | 565 +------------+-----------+------------------+-----------------------+ 567 Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen 568 flags 570 if present is an 8 bit unsigned integer field, which 571 contains the number of octets in the head of all of the addresses 572 in the address block, i.e. each element included is octets long. 575 head-length is a variable, defined to equal if 576 present, or 0 otherwise. 578 is omitted if head-length is equal to 0, otherwise it is a 579 field of the head-length leftmost octets common to all the 580 addresses in the address block. 582 if present is an 8 bit unsigned integer field, which 583 contains the number of octets in the tail of all of the addresses 584 in the address block, i.e. each element included is octets long. 587 tail-length is a variable, defined to equal if 588 present, or 0 otherwise. 590 is omitted if tail-length is equal to 0, or if the 591 ahaszerotail flag is set ('1'), otherwise it is a field of the 592 tail-length rightmost octets common to all the addresses in the 593 address block. If the ahaszerotail flag is set ('1') then the 594 tail-length rightmost octets of all the addresses in the address 595 block are all 0. 597 mid-length is a variable, which MUST be non-negative, defined by: 599 mid-length := address-length - head-length - tail-length 601 i.e. each element included is mid-length octets long. 603 is omitted if mid-length is equal to 0, otherwise each 604 is a field of length mid-length octets, representing the mid of 605 the corresponding address in the address block. When not omitted, 606 an address block contains exactly fields. 608 is an 8 bit unsigned integer field containing the 609 length, in bits, of an address prefix. If the ahassingleprelen 610 flag is set ('1') then a single field is included, 611 which contains the prefix length of all addresses in the address 612 block. If the ahasmultiprelen flag is set ('1') then 613 fields are included, each of which contains the 614 prefix length of the corresponding address prefix in the address 615 block (in the same order). Otherwise no fields 616 are present; each address object can be considered to have a 617 prefix length equal to 8 * address-length bits. The address block 618 is malformed if any element has a value greater 619 than 8 * address-length. 621 5.4. TLVs and TLV Blocks 623 A TLV allows the association of an arbitrary attribute with a message 624 or a packet, or with a single address or a contiguous set of 625 addresses in an address block. The attribute (value) is made up from 626 an integer number of consecutive octets. Different attributes have 627 different types; attributes which are unknown when parsing can be 628 skipped. 630 TLVs are grouped in TLV blocks, with all TLVs within a TLV block 631 associating attributes with either the packet (for the TLV block in 632 the packet header), the message (for the TLV block immediately 633 following the message header) or to addresses in the immediately 634 preceding address block. Individual TLVs in a TLV block immediately 635 following an address block can associate attributes to a single 636 address, a range of addresses or all addresses in that address block. 637 When associating an attribute with more than one address, a TLV can 638 include one value for all addresses, or one value per address. 639 Detailed examples of TLVs are included in Appendix C.2. 641 A TLV block is defined by: 643 := 644 * 646 where: 648 is a 16 bit unsigned integer field, which contains the 649 total number of octets in all of the immediately following 650 elements ( not included). 652 is as defined in Section 5.4.1. 654 5.4.1. TLVs 656 There are three kinds of TLV, each represented by an element : 658 o A packet TLV, included in the packet TLV block in a packet header. 660 o A message TLV, included in the message TLV block in a message, 661 before any address blocks. 663 o An address block TLV, included in an address TLV block following 664 an address block. An address block TLV applies to: 666 * all address objects in the address block; OR 668 * any continuous sequence of address objects in the address 669 block; OR 671 * a single address object in the address block. 673 is defined by: 675 := 676 677 ? 678 (?)? 679 (?)? 681 where: 683 is an 8 bit unsigned integer field, specifying the type 684 of the TLV, specific to the TLV kind (i.e. packet, message, or 685 address block TLV). 687 is an 8 bit field specifying the interpretation of the 688 remainder of the TLV: 690 bit 0 (thastypeext): If cleared ('0'), then is not 691 included in the . If set ('1'), then is 692 included in the . 694 bit 1 (thassingleindex) and bit 2 (thasmultiindex): Are 695 interpreted according to Table 3. A combination not shown in 696 that table MUST NOT be used. Both of these flags MUST be 697 cleared ('0') in packet and message TLVs. 699 bit 3 (thasvalue) and bit 4 (thasextlen): Are interpreted 700 according to Table 4. A combination not shown in that table 701 MUST NOT be used. 703 bit 5 (tismultivalue): This flag serves to specify how the 704 field is interpreted, as specified below. This flag 705 MUST be cleared ('0') in packet and message TLVs, if the 706 thasmultiindex flag is cleared ('0'), or if the thasvalue flag 707 is cleared ('0'). 709 bits 6-7: Are RESERVED, and SHOULD each be cleared ('0') on 710 transmission, and SHOULD be ignored on reception. 712 +-----------------+----------------+---------------+--------------+ 713 | thassingleindex | thasmultiindex | | | 714 +-----------------+----------------+---------------+--------------+ 715 | 0 | 0 | not included | not included | 716 | 1 | 0 | included | not included | 717 | 0 | 1 | included | included | 718 +-----------------+----------------+---------------+--------------+ 720 Table 3: Interpretation of the thassingleindex and thasmultiindex 721 flags 723 +-----------+------------+--------------+---------------------------+ 724 | thasvalue | thasextlen | | | 725 +-----------+------------+--------------+---------------------------+ 726 | 0 | 0 | not included | not included | 727 | 1 | 0 | 8 bits | included unless | 728 | | | | is zero | 729 | 1 | 1 | 16 bits | included unless | 730 | | | | is zero | 731 +-----------+------------+--------------+---------------------------+ 733 Table 4: Interpretation of the thasvalue and thasextlen flags 735 is an 8 bit unsigned integer field, specifying an 736 extension of the TLV type, specific to the TLV type and kind (i.e. 737 packet, message, or address block TLV). 739 tlv-type-ext is a variable, defined to equal if 740 present, or 0 otherwise. 742 tlv-fulltype is a variable, defined by: 744 tlv-fulltype := 256 * + tlv-type-ext 746 and when present, in an address block TLV 747 only, are each an 8 bit unsigned integer field. 749 index-start and index-stop are variables, defined according to 750 Table 5. The variable end-index is defined as follows: 752 * For message and packet TLVs: 754 end-index := 0 756 * For address block TLVs: 758 end-index := - 1 760 An address block TLV applies to the address objects from position 761 index-start to position index-stop (inclusive) in the address 762 block, where the first address object has position zero. 764 +-----------------+----------------+----------------+---------------+ 765 | thassingleindex | thasmultiindex | index-start := | index-stop := | 766 +-----------------+----------------+----------------+---------------+ 767 | 0 | 0 | 0 | end-index | 768 | 1 | 0 | | | 769 | 0 | 1 | | | 770 +-----------------+----------------+----------------+---------------+ 772 Table 5: Interpretation of the thassingleindex and thasmultiindex 773 flags 775 number-values is a variable, defined by: 777 number-values := index-stop - index-start + 1 779 is omitted or is an 8 or 16 bit unsigned integer field 780 according to Table 4. If the tismultivalue flag is set ('1') then 781 MUST be an integral multiple of number-values, and the 782 variable single-length is defined by: 784 single-length := / number-values 786 If the tismultivalue flag is cleared ('0'), then the variable 787 single-length is defined by: 789 single-length := 791 if present (see Table 4) is a field of length 792 octets. In an address block TLV, is associated with the 793 address objects from positions index-start to index-stop, 794 inclusive. If the tismultivalue flag is cleared ('0') then the 795 whole of this field is associated with each of the indicated 796 address objects. If the tismultivalue flag is set ('1') then this 797 field is divided equally into number-values fields, each of length 798 single-length octets, and these are associated, in order, with the 799 indicated address objects. 801 5.4.2. TLV Usage 803 A TLV associates an attribute with a packet, a message or one or more 804 consecutive address objects in an address block. The interpretation 805 and processing of this attribute, and the relationship (including 806 order of processing) between different attributes associated with the 807 same entity MUST be defined by any protocol which uses this 808 specification. 810 Any protocol using this specification MUST define appropriate 811 behaviors if this associated information is inconsistent, in 812 particular if two TLVs of the same type but with different values 813 apply to the same entity (packet, message or address) but this is not 814 meaningful. The protocol MUST also specify an appropriate processing 815 order for TLVs associated with a given entity. 817 5.5. Malformed Elements 819 An element is malformed if it cannot be parsed according to its 820 syntactical specification (including if there are insufficient octets 821 available). If the malformed element is in the packet header then 822 the packet MUST be silently discarded, and contained messages MUST 823 NOT be processed and MUST NOT be forwarded. If the malformed element 824 is contained in a message (i.e. is in the message TLV block, an 825 address block, or an address block TLV block) then that message MUST 826 be silently discarded; it MUST NOT be processed and MUST NOT be 827 forwarded. 829 6. IANA Considerations 831 This document introduces four namespaces that require registration: 832 Message Types, Packet TLV Types, Message TLV Types and Address Block 833 TLV Types. This section specifies IANA registries for these 834 namespaces, and provides guidance to the Internet Assigned Numbers 835 Authority regarding registrations in these namespaces. 837 The following terms are used with the meanings defined in [BCP26]: 838 "Namespace", "Assigned Value", "Registration", "Unassigned", 839 "Reserved", "Hierarchical Allocation", "Designated Expert". 841 The following policies are used with the meanings defined in [BCP26]: 842 "Private Use", "Expert Review", "Standards Action". 844 6.1. Expert Review: Evaluation Guidelines 846 For registration requests where an Expert Review is required, the 847 Designated Expert SHOULD take the following general recommendations 848 into consideration: 850 o The purposes of these registries are to support Standard and 851 Experimental MANET routing and related protocols, and extensions 852 to the same. 854 o The intention is that all registrations will be accompanied by a 855 published RFC. 857 o In order to allow for registration prior to the RFC being approved 858 for publication, the Designated Expert can approve the 859 registration once it seems clear that an RFC is expected to be 860 published. 862 o The Designated Expert will post a request to the MANET WG mailing 863 list, or to a successor thereto as designated by the Area 864 Director, for comments and reviews. This request will include a 865 reference to the Internet-Draft requesting the registration. 867 o Before a period of 30 days has passed, the Designated Expert will 868 either approve or deny the registration request and publish a note 869 of the decision to the MANET WG mailing list or its successor, as 870 well as informing IANA and the IESG. A denial note MUST be 871 justified by an explanation and, in cases where it is possible, 872 suggestions as to how the request can be modified so as to become 873 acceptable SHOULD be provided. 875 For the registry for Message Types, the following guidelines apply: 877 o Registration of a message type implies creation of two registries 878 for message type specific message TLVs and message type specific 879 address block TLVs. The document which requests the registration 880 of the message type MUST indicate how these message type specific 881 TLV types are to be allocated, from any options in [BCP26], and 882 any initial allocations. The Designated Expert SHOULD take the 883 allocation policies specified for these registries into 884 consideration in reviewing the message type allocation request. 886 For the registries for Packet TLV Types, Message TLV Types and 887 Address Block TLV Types, the following guidelines apply: 889 o These are Hierarchical Allocations, i.e. allocation of a type 890 creates a registry for the extended types corresponding to that 891 type. The document which requests the registration of the type 892 MUST indicate how these extended types are to be allocated, from 893 any options in [BCP26], and any initial allocations. Normally 894 this allocation should also be Expert Review, but with the 895 possible allocation of some type extensions as Reserved, 896 Experimental and/or Private. 898 o The request for a TLV type MUST include the specification of the 899 permitted size, syntax of any internal structure of, and meaning 900 of, the value field (if any) of the TLV. 902 For the registries for Message TLV Types and Address Block TLV Types, 903 the following additional guidelines apply: 905 o TLV type values 0-127 are common for all message types. TLVs 906 which receive registrations from the 0-127 interval SHOULD be 907 modular in design to allow reuse among protocols. 909 o TLV type values 128-223 are message type specific TLV type values, 910 relevant only in the context of the containing message type. 911 Registration of TLV type values within the 128-223 interval 912 requires that a registry in the 128-223 interval exists for a 913 specific message type value (see Section 6.2.1), and registrations 914 are made in accordance with the allocation policies specified for 915 these message type specific registries. Message type specific TLV 916 types SHOULD be registered for TLVs which the Designated Expert 917 deems too message type specific for registration of a 0-127 value. 918 Multiple different TLV definitions MAY be assigned the same TLV 919 type value within the 128-223 interval, given that they are 920 associated with different message type specific TLV type 921 registries. Where possible, existing global TLV definitions and 922 modular global TLV definitions for registration in the 0-127 range 923 SHOULD be used. 925 6.2. Message Types 927 A new registry for message types must be created, with initial 928 assignments and allocation policies as specified in Table 6. 930 +---------+-------------+-------------------+ 931 | Type | Description | Allocation Policy | 932 +---------+-------------+-------------------+ 933 | 0-223 | Unassigned | Expert Review | 934 | 224-255 | Unassigned | Experimental Use | 935 +---------+-------------+-------------------+ 937 Table 6: Message Types 939 6.2.1. Message Type Specific TLV Registry Creation 941 When a message type is registered then registries MUST be specified 942 for both message type specific message TLVs (Table 8) and message 943 type specific address block TLVs (Table 10). A document which 944 creates a message type specific TLV registry MUST also specify the 945 mechanism by which message specific TLV types are allocated, from 946 among those in [BCP26]. 948 6.3. Packet TLV Types 950 A new registry for packet TLV types must be created, with initial 951 assignments and allocation policies as specified in Table 7. 953 +---------+-------------+-------------------+ 954 | Type | Description | Allocation Policy | 955 +---------+-------------+-------------------+ 956 | 0-223 | Unassigned | Expert Review | 957 | 224-255 | Unassigned | Experimental Use | 958 +---------+-------------+-------------------+ 960 Table 7: Packet TLV Types 962 6.3.1. Packet TLV Type Extension Registry Creation 964 When a packet TLV type is registered then a new registry for type 965 extensions of that type must be created. A document which defines a 966 packet TLV type MUST also specify the mechanism by which its type 967 extensions are allocated, from among those in [BCP26]. 969 6.4. Message TLV Types 971 A new registry for message type independent message TLV types must be 972 created, with initial assignments and allocation policies as 973 specified in Table 8. 975 +---------+-----------------------+-----------------------+ 976 | Type | Description | Allocation Policy | 977 +---------+-----------------------+-----------------------+ 978 | 0-127 | Unassigned | Expert Review | 979 | 128-223 | Message Type Specific | Reserved, see Table 9 | 980 | 224-255 | Unassigned | Experimental Use | 981 +---------+-----------------------+-----------------------+ 983 Table 8: Message TLV Types 985 Message TLV Types 128-223 are reserved for message type specific 986 Message TLVs, for which a new registry is created with the 987 registration of a message type, and with initial assignments and 988 allocation policies as specified in Table 9. 990 +---------+-----------------------------+-------------------+ 991 | Type | Description | Allocation Policy | 992 +---------+-----------------------------+-------------------+ 993 | 0-127 | Common to all Message Types | Reserved | 994 | 128-223 | Message Type Specific | See Below | 995 | 224-255 | Common to all Message Types | Reserved | 996 +---------+-----------------------------+-------------------+ 998 Table 9: Message Specific Message TLV Types 1000 Allocation policies for message type specific message TLV types MUST 1001 be specified when creating the registry associated with the 1002 containing message type, see Section 6.2.1. 1004 6.4.1. Message TLV Type Extension Registry Creation 1006 If a message TLV type is registered then a new registry for type 1007 extensions of that type must be created. A document which defines a 1008 message TLV type MUST also specify the mechanism by which its type 1009 extensions are allocated, from among those in [BCP26]. 1011 6.5. Address Block TLV Types 1013 A new registry for message type independent address block TLV types 1014 must be created, with initial assignments and allocation policies as 1015 specified in Table 10. 1017 +---------+-----------------------+------------------------+ 1018 | Type | Description | Allocation Policy | 1019 +---------+-----------------------+------------------------+ 1020 | 0-127 | Unassigned | Expert Review | 1021 | 128-223 | Message Type Specific | Reserved, see Table 11 | 1022 | 224-255 | Unassigned | Experimental Use | 1023 +---------+-----------------------+------------------------+ 1025 Table 10: Address Block TLV Types 1027 Address Block TLV Types 128-223 are reserved for message type 1028 specific Address Block TLVs, for which a new registry is created with 1029 the registration of a message type, and with initial assignments and 1030 allocation policies as specified in Table 11. 1032 +---------+-----------------------------+-------------------+ 1033 | Type | Description | Allocation Policy | 1034 +---------+-----------------------------+-------------------+ 1035 | 0-127 | Common to all Message Types | Reserved | 1036 | 128-223 | Message Type Specific | See Below | 1037 | 224-255 | Common to all Message Types | Reserved | 1038 +---------+-----------------------------+-------------------+ 1040 Table 11: Message Specific Address Block TLV Types 1042 Allocation policies for message type specific address block TLV types 1043 MUST be specified when creating the registry associated with the 1044 containing message type, see Section 6.2.1. 1046 6.5.1. Address Block TLV Type Extension Registry Creation 1048 When an address block TLV type is registered then a new registry for 1049 type extensions of that type must be created. A document which 1050 defines a message TLV type MUST also specify the mechanism by which 1051 its type extensions are allocated, from among those in [BCP26]. 1053 7. Security Considerations 1055 This specification does not describe a protocol; it describes a 1056 packet format. As such it does not specify any security 1057 considerations, these are matters for a protocol using this 1058 specification. However some security mechanisms are enabled by this 1059 specification, and may form part of a protocol using this 1060 specification. Mechanisms which may form part of an authentication 1061 and integrity approach in a protocol using this specification, are 1062 described in Section 7.1. Mechanisms which may form part of a 1063 confidentiality approach in a protocol using this specification, are 1064 described in Section 7.2. There is however no requirement that a 1065 protocol using this specification should use either. 1067 7.1. Authentication and Integrity Suggestions 1069 The authentication and integrity suggestions made here, are based on 1070 the intended usage in Appendix B, specifically that: 1072 o Messages are designed to be carriers of protocol information and 1073 MAY, at each hop, be forwarded and/or processed by the protocol 1074 using this specification. 1076 o Packets are designed to carry a number of messages between 1077 neighboring MANET routers in a single transmission and over a 1078 single logical hop. 1080 Consequently: 1082 o For forwarded messages where the message is unchanged by 1083 forwarding MANET routers, then end-to-end authentication and 1084 integrity MAY be implemented, between MANET routers with an 1085 existing security association, by including a suitable message TLV 1086 containing a cryptographic signature in the message. Since and are the only fields that should be 1088 modified when such a message is forwarded in this manner, this 1089 signature can be calculated based on the entire message, including 1090 the message header, with the and 1091 fields set to 0 if present. 1093 o Hop-by-hop packet level authentication and integrity MAY be 1094 implemented, between MANET routers with an existing security 1095 association, by including a suitable packet TLV containing a 1096 cryptographic signature to the packet. Since packets are received 1097 as transmitted, this signature can be calculated based on the 1098 entire packet, or on parts thereof as appropriate. 1100 7.2. Confidentiality Suggestions 1102 This specification does not explicitly enable protecting packet/ 1103 message confidentiality. Such confidentiality would normally, when 1104 required, be provided hop-by-hop either by link-layer mechanisms, or 1105 at the IP layer using [RFC4301], and would apply to a packet only. 1107 It is possible, however, for a protocol using this specification to 1108 protect the confidentiality of information included in a packet, 1109 message or address block TLV by specifying that the value field of 1110 that TLV type be encrypted, as well as specifying the encryption 1111 mechanism. 1113 In an extreme case, all information can be encrypted by defining 1114 either: 1116 o A packet, consisting of only a packet header (with no messages), 1117 and containing a packet TLV, where the packet TLV type indicates 1118 that its value field contains one or more encrypted messages. 1119 Upon receipt, and once this packet TLV is successfully decrypted, 1120 these messages may then be parsed according to this specification 1121 and processed according to the protocol using this specification. 1123 o A message, consisting of only a message header and a single 1124 message TLV, where the message TLV type indicates that its value 1125 field contains an encrypted version of the message's remaining 1126 message TLVs, address blocks and address block TLVs. Upon 1127 receipt, and once this message TLV is successfully decrypted, the 1128 complete message may then be parsed according to this 1129 specification and processed according to the protocol using this 1130 specification. 1132 In either case, the protocol MUST define the encrypted TLV type, as 1133 well as the format of the encrypted data block contained in the value 1134 field of the TLV. 1136 8. References 1138 8.1. Normative References 1140 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1141 Requirement Levels", RFC 2119, BCP 14, March 1997. 1143 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1144 Architecture", RFC 4291, February 2006. 1146 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing 1147 an IANA Considerations Section in RFCs", RFC 5226, 1148 BCP 26, May 2008. 1150 [SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC 1151 1/SC22/WG15, "Single UNIX Specification, Version 3, 1152 2004 Edition", April 2004. 1154 8.2. Informative References 1156 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 1157 Routing Protocol", RFC 3626, October 2003. 1159 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1160 Internet Protocol", RFC 4301, December 2005. 1162 [Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The 1163 Protocols.", 1994. 1165 Appendix A. Multiplexing and Demultiplexing 1167 The packet and message format specified in this document is designed 1168 to allow zero or more messages to be contained within a single 1169 packet. Such messages may be from the same or from different 1170 protocols. Thus, a multiplexing and demultiplexing process MUST be 1171 present. 1173 Multiplexing messages on a given MANET router into a single packet, 1174 rather than to have each message generate its own packet, reduces the 1175 total number of octets, and the number of packets transmitted by that 1176 MANET router. 1178 The multiplexing and demultiplexing process running on a given UDP 1179 port or IP protocol number, and its associated protocols, MUST: 1181 o For each message type, a protocol - unless specified otherwise, 1182 the one making the IANA reservation for that message type - MUST 1183 be designated as the "owner" of that message type. 1185 o The packet header fields, including the Packet TLV block, is used 1186 by the multiplexing and demultiplexing process, which MAY make 1187 such information available for use its protocol instances. 1189 o The field, if present, contains a sequence number 1190 which is incremented by 1 for each packet generated by a node. 1191 The sequence number after 65535 is 0. In other words, the 1192 sequence number "wraps" in the usual way. 1194 o Incoming messages MUST be either silently discarded or MUST be 1195 delivered to the instance of the protocol which owns the 1196 associated message type. Incoming messages SHOULD NOT be 1197 delivered to any other protocol instances and SHOULD NOT be 1198 delivered to more than one protocol instance. 1200 o Outgoing messages of a given type MUST be generated only by the 1201 protocol instance which owns that message type and delivered to 1202 the multiplexing and demultiplexing process. 1204 o If two protocols both wish to use the same message type then this 1205 interaction SHOULD be specified by the protocol which is the 1206 designated owner of that message type. 1208 Appendix B. Intended Usage 1210 This appendix describes the intended usage of message header fields 1211 including their content and use. Alternative uses of this 1212 specification are permitted. 1214 The message format specified in this document is designed to carry 1215 MANET routing protocol signaling between MANET routers, and to 1216 support scope limited flooding as well as point-to-point delivery. 1218 Messages are designed to be able to be forwarded over one or more 1219 logical hops, in a new packet for each logical hop. Each logical hop 1220 may consist of one or more IP hops. 1222 Specifically Scope limited flooding is supported for messages by: 1224 o The field, if present, contains the unique 1225 identifier of the MANET router which originated the message. 1227 o The field, if present, contains a sequence number 1228 which starts at 0 when first message of a given type is generated 1229 by the originator node, and is incremented by 1 for each message 1230 generated of that type. The sequence number after 65535 is 0. In 1231 other words, the sequence number "wraps" in the usual way. 1233 o If the and fields are both present, 1234 then the message header provides for duplicate suppression, using 1235 the identifier consisting of the message's , , and . These serve to uniquely identify the 1237 message in the MANET within the time period until is 1238 repeated, i.e. wraps around to a matching value. 1240 o field, if present, contains the number of hops on 1241 which the packet is allowed to travel before being discarded by a 1242 MANET router. The is set by the message 1243 originator and is used to prevent messages from endlessly 1244 circulating in a MANET. When forwarding a message, a MANET router 1245 should decrease the by 1, and the message should 1246 be discarded when reaches 0. 1248 o field, if present, contains the number of hops on 1249 which the packet has traveled across the MANET. The by 1 and should discard the message when 1254 reaches 255. 1256 o If the and fields are both 1257 present, then the message header provides the information to make 1258 forwarding decisions for scope limited flooding. This may be by 1259 any appropriate flooding mechanism specified by a protocol using 1260 this specification. 1262 Appendix C. Examples 1264 This appendix contains some examples of parts of this specification. 1266 C.1. Address Block Examples 1268 The following examples illustrate how some combinations of addresses 1269 may be efficiently included in address blocks. These examples are 1270 for IPv4, with address-length equal to 4. a, b, c etc. represent 1271 distinct, non-zero, octet values. 1273 Note that it is permissible to use a less efficient representation, 1274 in particular one in which the ahashead and ahasfulltail flags are 1275 cleared ('0'), and hence head-length = 0, tail-length = 0, mid-length 1276 = address-length, and (with no address prefixes) the address block 1277 consists of the number of addresses, with value 0, and a 1278 list of the unaggregated addresses. This is the most efficient way 1279 to represent a single address, and the only way to represent, for 1280 example, a.b.c.d and e.f.g.h in one address block. 1282 Examples: 1284 o To include a.b.c.d, a.b.e.f and a.b.g.h: 1286 * head-length = 2; 1288 * tail-length = 0; 1290 * mid-length = 2; 1292 * has ahashead set (value 128); 1294 * and are omitted. 1296 The address block is then 3 128 2 a b c d e f g h (11 octets). 1298 o To include a.b.c.g and d.e.f.g: 1300 * head-length = 0; 1302 * tail-length = 1; 1304 * mid-length = 3; 1306 * has ahasfulltail set (value 64); 1308 * and are omitted. 1310 The address block is then 2 64 1 g a b c d e f (10 octets). 1312 o To include a.b.d.e and a.c.d.e: 1314 * head-length = 1; 1316 * tail-length = 2; 1318 * mid-length = 1; 1320 * has ahashead and ahasfulltail set (value 192). 1322 The address block is then 2 192 1 a 2 d e b c (9 octets). 1324 o To include a.b.0.0, a.c.0.0, and a.d.0.0: 1326 * head-length = 1; 1328 * tail-length = 2; 1329 * mid-length = 1; 1331 * has ahashead and ahaszerotail set (value 160); 1333 * is omitted. 1335 The address block is then 3 160 1 a 2 b c d (8 octets). 1337 o To include a.b.0.0 and c.d.0.0: 1339 * head-length = 0; 1341 * tail-length = 2; 1343 * mid-length = 2; 1345 * has ahaszerotail set (value 32); 1347 * and are omitted. 1349 The address block is then 2 32 2 a b c d (7 octets). 1351 o To include a.b.0.0/n and c.d.0.0/n: 1353 * head-length = 0; 1355 * tail-length = 2; 1357 * mid-length = 2; 1359 * has ahaszerotail and ahassingleprelen set (value 1360 48); 1362 * and are omitted. 1364 The address block is then 2 48 2 a b c d n (8 octets). 1366 o To include a.b.0.0/n and c.d.0.0/m: 1368 * head-length = 0; 1370 * tail-length = 2; 1372 * mid-length = 2; 1374 * has ahaszerotail and ahasmultiprelen set (value 1375 40); 1377 * and are omitted. 1379 The address block is then 2 40 2 a b c d n m (9 octets). 1381 C.2. TLV Examples 1383 Assuming the definition of an address block TLV with type EXAMPLE1 1384 (and no type extension) which has single octet values per address, 1385 then if values a, a, b and c are to be associated with the four 1386 addresses in the preceding address block, where c is a default value 1387 that can be omitted, then this can be done in a number of ways. 1389 Examples: 1391 o Using one multivalue TLV covering all of the addresses: 1393 * has thasvalue and tismultivalue set (value 20); 1395 * and are omitted; 1397 * = 4 (single-length = 1). 1399 * The TLV is then EXAMPLE1 20 4 a a b c (7 octets). 1401 o Using one multivalue TLV omitting the last address: 1403 * has thasmultiindex, thasvalue and tismultivalue set 1404 (value 52); 1406 * = 0; 1408 * = 2 1410 * = 3 (single-length = 1). 1412 * The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets). 1414 o Using two single value TLVs, omitting the last address. First: 1416 * has thasmultiindex and thasvalue set (value 48); 1418 * = 0; 1420 * = 1; 1422 * = 1; 1423 * = a. 1425 * The TLV is then EXAMPLE1 48 0 1 1 a (6 octets). 1427 Second: 1429 * has thassingleindex and thasvalue set (value 80); 1431 * = 2; 1433 * is omitted; 1435 * = 1; 1437 * = b. 1439 * The TLV is then EXAMPLE1 80 2 1 b (5 octets). 1441 Total length of TLVs is 11 octets. 1443 In this case the first of these is the most efficient. In other 1444 cases patterns such as the others may be preferred. Regardless of 1445 efficiency, any of these may be used. 1447 Assuming the definition of an address block TLV with type EXAMPLE2 1448 (and no type extension) which has no value, which is to be associated 1449 with the second and third addresses in an address block, then this 1450 can be indicated with a single TLV: 1452 o has thasmultiindex set (value 32); 1454 o = 1; 1456 o = 2; 1458 o and are omitted. 1460 o The TLV is then EXAMPLE2 32 1 2 (4 octets). 1462 Assuming the definition of a message TLV with type EXAMPLE3 (and no 1463 type extension) which can take a value field of any length, for such 1464 a TLV with 8 octets of data (a to h): 1466 o has thasvalue set (value 16); 1468 o and are omitted; 1469 o = 8. 1471 o The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets). 1473 If, in this example, the number of data octets were 256 or greater 1474 then would also have thasextlen set and have value 24. 1475 The length would require two octets (most significant first). The 1476 TLV length would be 4 + N octets, where N is the number of data 1477 octets (it can be 3 + N octets if N is 255 or less). 1479 Appendix D. Illustrations 1481 This informative appendix illustrates the elements which are 1482 normatively specified in Section 5. 1484 Bits labeled Rsv should be cleared ('0'). Bits labeled M may be 1485 cleared ('0') or set ('1'). 1487 D.1. Packet 1489 Possible options for the element. These are differentiated 1490 by the flags field in the first octet. The packet may include any 1491 number (zero or more) of Messages. The number of Messages is 1492 determined from when the packet is exhausted, given the packet length 1493 from the network layer. 1495 0 1 2 3 1496 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 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 |0|0|0|0|0|0|Rsv| | 1499 +-+-+-+-+-+-+-+-+ | 1500 | Message | 1501 | | 1502 | +-+-+-+-+-+-+-+-+ 1503 | | | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1505 | | 1506 : ... : 1507 | | 1508 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | | | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1511 | | 1512 | Message | 1513 | +-+-+-+-+-+-+-+-+ 1514 | | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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|1|0|Rsv| Packet Sequence Number | | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1521 | | 1522 | Message | 1523 | | 1524 | +-+-+-+-+-+-+-+-+ 1525 | | | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1527 | | 1528 : ... : 1529 | | 1530 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | | | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1533 | | 1534 | Message | 1535 | +-+-+-+-+-+-+-+-+ 1536 | | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 0 1 2 3 1539 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 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 |0|0|0|0|0|1|Rsv| | 1542 +-+-+-+-+-+-+-+-+ | 1543 | | 1544 | Packet TLV Block | 1545 | | 1546 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | | | 1548 +-+-+-+-+-+-+-+-+ | 1549 | Message | 1550 | | 1551 | +-+-+-+-+-+-+-+-+ 1552 | | | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1554 | | 1555 : ... : 1556 | | 1557 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | | | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1560 | | 1561 | Message | 1562 | +-+-+-+-+-+-+-+-+ 1563 | | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 0 1 2 3 1566 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 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 |0|0|0|0|1|1|Rsv| Packet Sequence Number | | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1570 | | 1571 | Packet TLV Block | 1572 | | 1573 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | | | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1576 | | 1577 | Message | 1578 | | 1579 | +-+-+-+-+-+-+-+-+ 1580 | | | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1582 | | 1583 : ... : 1584 | | 1585 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | | | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1588 | | 1589 | Message | 1590 | +-+-+-+-+-+-+-+-+ 1591 | | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 D.2. Message 1596 Possible options for the element. These are differentiated 1597 by their second (flags) octet. The length of the Message Body is 1598 determined using the Message Size field, which is the combined length 1599 of all the fields shown. The field labeled MAL defines the length of 1600 all addresses (including the Originator Address, if present, and all 1601 addresses in address blocks) in octets, as one more than the value in 1602 the field. 1604 0 1 2 3 1605 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 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Message Type |0|0|0|0| MAL | Message Size | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | | 1610 | Message Body | 1611 | | 1612 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 0 1 2 3 1617 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 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 | Message Type |1|0|0|0| MAL | Message Size | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | Originator Address | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | | 1624 | Message Body | 1625 | | 1626 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 0 1 2 3 1631 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 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Message Type |0|1|0|0| MAL | Message Size | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Hop Limit | | 1636 +-+-+-+-+-+-+-+-+ | 1637 | Message Body | 1638 | | 1639 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 0 1 2 3 1643 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 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | Message Type |1|1|0|0| MAL | Message Size | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Originator Address | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Hop Limit | | 1650 +-+-+-+-+-+-+-+-+ | 1651 | Message Body | 1652 | | 1653 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 0 1 2 3 1658 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 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | Message Type |0|0|1|0| MAL | Message Size | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | Hop Count | | 1663 +-+-+-+-+-+-+-+-+ | 1664 | Message Body | 1665 | | 1666 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 0 1 2 3 1671 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 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | Message Type |1|0|1|0| MAL | Message Size | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | Originator Address | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Hop Count | | 1678 +-+-+-+-+-+-+-+-+ | 1679 | Message Body | 1680 | | 1681 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 0 1 2 3 1685 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 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | Message Type |0|1|1|0| MAL | Message Size | 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 | Hop Limit | Hop Count | | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1691 | | 1692 | Message Body | 1693 | | 1694 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 | | 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 0 1 2 3 1699 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 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 | Message Type |1|1|1|0| MAL | Message Size | 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 | Originator Address | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Hop Limit | Hop Count | | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1707 | | 1708 | Message Body | 1709 | | 1710 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 0 1 2 3 1715 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 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | Message Type |0|0|0|1| MAL | Message Size | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 | Message Sequence Number | | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1721 | | 1722 | Message Body | 1723 | | 1724 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | | 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 0 1 2 3 1728 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 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | Message Type |1|0|0|1| MAL | Message Size | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | Originator Address | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Message Sequence Number | | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1736 | | 1737 | Message Body | 1738 | | 1739 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 0 1 2 3 1744 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 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 | Message Type |0|1|0|1| MAL | Message Size | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | Hop Limit | Message Sequence Number | | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1750 | | 1751 | Message Body | 1752 | | 1753 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 0 1 2 3 1758 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 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | Message Type |1|1|0|1| MAL | Message Size | 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 | Originator Address | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | Hop Limit | Message Sequence Number | | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1766 | | 1767 | Message Body | 1768 | | 1769 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 0 1 2 3 1773 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 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | Message Type |0|0|1|1| MAL | Message Size | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | Hop Count | Message Sequence Number | | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1779 | | 1780 | Message Body | 1781 | | 1782 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 0 1 2 3 1787 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 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | Message Type |1|0|1|1| MAL | Message Size | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Originator Address | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Hop Count | Message Sequence Number | | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1795 | | 1796 | Message Body | 1797 | | 1798 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 0 1 2 3 1803 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 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 | Message Type |0|1|1|1| MAL | Message Size | 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | Hop Limit | Hop Count | Message Sequence Number | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | | 1810 | Message Body | 1811 | | 1812 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 0 1 2 3 1816 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 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1818 | Message Type |1|1|1|1| MAL | Message Size | 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 | Originator Address | 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 | Hop Limit | Hop Count | Message Sequence Number | 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 | | 1825 | Message Body | 1826 | | 1827 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 D.3. Message Body 1833 Format of a message body (the element excluding its initial 1834 element). The message body includes one Message TLV 1835 Block (containing zero or more TLVs) and may include any number (zero 1836 or more) of Address Block and Address TLV Block pairs. 1838 0 1 2 3 1839 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 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 | | 1842 | Message TLV Block | 1843 | +-+-+-+-+-+-+-+-+ 1844 | | | 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1846 | | 1847 | Address Block | 1848 | | 1849 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 | | | 1851 +-+-+-+-+-+-+-+-+ | 1852 | Address TLV Block | 1853 | | 1854 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | | | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1857 | | 1858 : ... : 1859 | | 1860 | +-+-+-+-+-+-+-+-+ 1861 | | | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1863 | | 1864 | Address Block | 1865 | | 1866 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | | | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1869 | | 1870 | Address TLV Block | 1871 | | 1872 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 D.4. Address Block 1878 Possible options for the element. These are 1879 differentiated by their second (flags) octet. The number of Mid 1880 elements is equal to the number of addresses (except when mid-length 1881 is zero, when there are no Mid elements). Where a variable number of 1882 Prefix Length fields is shown, their number is equal to the number of 1883 addresses. 1885 0 1 2 3 1886 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 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | Number Addrs |0|0|0|0|0| Rsv | Mid | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | Mid (cont) | | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1892 | | 1893 : ... : 1894 | | 1895 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | | Mid | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | Mid (cont) | 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 0 1 2 3 1902 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 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | Number Addrs |1|0|0|0|0| Rsv | Head Length | Head | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | Head (cont) | Mid | | 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1908 | | 1909 : ... : 1910 | | 1911 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | | Mid | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 0 1 2 3 1916 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 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 | Number Addrs |0|1|0|0|0| Rsv | Tail Length | Tail | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | Tail (cont) | Mid | | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1922 | | 1923 : ... : 1924 | | 1925 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 | | Mid | 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 0 1 2 3 1929 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 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 | Number Addrs |1|1|0|0|0| Rsv | Head Length | Head | 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 | Head (cont) | Tail Length | Tail | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 | Mid | | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1937 | | 1938 : ... : 1939 | | 1940 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 | | Mid | 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 0 1 2 3 1945 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 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 | Number Addrs |0|0|1|0|0| Rsv | Tail Length | Mid | 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 | Mid (cont) | | 1950 +-+-+-+-+-+-+-+-+ | 1951 | | 1952 : ... : 1953 | | 1954 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 | | Mid | 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 0 1 2 3 1959 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 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | Number Addrs |1|0|1|0|0| Rsv | Head Length | Head | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | Head (cont) | Tail Length | Mid | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | | 1966 : ... : 1967 | | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | Mid | 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 0 1 2 3 1972 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 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | Number Addrs |0|0|0|1|0| Rsv | Mid | 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 | Mid (cont) | | 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1978 | | 1979 : ... : 1980 | | 1981 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 | | Mid | 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 | Mid (cont) | Prefix Length | 1985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 0 1 2 3 1988 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 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 | Number Addrs |1|0|0|1|0| Rsv | Head Length | Head | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1992 | Head (cont) | Mid | | 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1994 | | 1995 : ... : 1996 | | 1997 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 | | Mid | Prefix Length | 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 0 1 2 3 2002 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 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 | Number Addrs |0|1|0|1|0| Rsv | Tail Length | Tail | 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 | Tail (cont) | Mid | | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2008 | | 2009 : ... : 2010 | | 2011 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | | Mid | Prefix Length | 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 0 1 2 3 2015 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 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | Number Addrs |1|1|0|1|0| Rsv | Head Length | Head | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | Head (cont) | Tail Length | Tail | 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 | Mid | | 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2023 | | 2024 : ... : 2025 | | 2026 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 | | Mid | 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 | 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 |0|0|1|1|0| Rsv | Tail Length | Mid | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | Mid (cont) | | 2038 +-+-+-+-+-+-+-+-+ | 2039 | | 2040 : ... : 2041 | | 2042 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 | | Mid | Prefix Length | 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 0 1 2 3 2047 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 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 | Number Addrs |1|0|1|1|0| Rsv | Head Length | Head | 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 | Head (cont) | Tail Length | Mid | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | | 2054 : ... : 2055 | | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | Mid | Prefix Length | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 0 1 2 3 2060 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 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | Number Addrs |0|0|0|0|1| Rsv | Mid | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 | Mid (cont) | | 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2066 | | 2067 : ... : 2068 | | 2069 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 | | Mid | 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 | Mid (cont) | Prefix Length | | 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2074 | | 2075 : ... : 2076 | | 2077 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2078 | | Prefix Length | 2079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 0 1 2 3 2082 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 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 | Number Addrs |1|0|0|0|1| Rsv | Head Length | Head | 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 | Head (cont) | Mid | | 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2088 | | 2089 : ... : 2090 | | 2091 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | | Mid | Prefix Length | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | | 2095 : ... : 2096 | | 2097 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 | | Prefix Length | 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 0 1 2 3 2101 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 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | Number Addrs |0|1|0|0|1| Rsv | Tail Length | Tail | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | Tail (cont) | Mid | | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2107 | | 2108 : ... : 2109 | | 2110 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | | Mid | Prefix Length | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | | 2114 : ... : 2115 | | 2116 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 | | Prefix Length | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 0 1 2 3 2121 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 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 | Number Addrs |1|1|0|0|1| Rsv | Head Length | Head | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2125 | Head (cont) | Tail Length | Tail | 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 | Mid | | 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2129 | | 2130 : ... : 2131 | | 2132 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 | | Mid | 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | Prefix Length | | 2136 +-+-+-+-+-+-+-+-+ | 2137 : ... : 2138 | +-+-+-+-+-+-+-+-+ 2139 | | Prefix Length | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 0 1 2 3 2142 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 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 | Number Addrs |0|0|1|0|1| Rsv | Tail Length | Mid | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | Mid (cont) | | 2147 +-+-+-+-+-+-+-+-+ | 2148 | | 2149 : ... : 2150 | | 2151 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | | Mid | Prefix Length | 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 | | 2155 : ... : 2156 | | 2157 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | | Prefix Length | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 0 1 2 3 2162 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 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | Number Addrs |1|0|1|0|1| Rsv | Head Length | Head | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | Head (cont) | Tail Length | Mid | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | | 2169 : ... : 2170 | | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | Mid | Prefix Length | | 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2174 | | 2175 : ... : 2176 | | 2177 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | | Prefix Length | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 D.5. TLV Block 2183 Format of a element. There may be any number (zero or 2184 more) of TLVs, with total length of the TLVs (in octets) equal to the 2185 Length field. 2187 0 1 2 3 2188 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 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 | Length | | 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2192 | | 2193 | TLV | 2194 | +-+-+-+-+-+-+-+-+ 2195 | | | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2197 | | 2198 : ... : 2199 | | 2200 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | | | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2203 | | 2204 | TLV | 2205 | +-+-+-+-+-+-+-+-+ 2206 | | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 D.6. TLV 2211 Possible options for the element. These are differentiated by 2212 their second (flags) octet. If there are no index fields then this 2213 may be a packet, message or address block TLV, if there are one or 2214 two index fields then this must be an address block TLV. The Length 2215 field gives the length of the value field (in octets). 2217 0 1 2 3 2218 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 | Type |0|0|0|0|0|0|Rsv| 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 0 1 2 3 2224 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 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 | Type |1|0|0|0|0|0|Rsv| Type Ext | 2227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 0 1 2 3 2230 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 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | Type |0|1|0|0|0|0|Rsv| Index Start | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2235 0 1 2 3 2236 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 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 | Type |1|1|0|0|0|0|Rsv| Type Ext | Index Start | 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 0 1 2 3 2242 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 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 | Type |0|0|1|0|0|0|Rsv| Index Start | Index Stop | 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 0 1 2 3 2248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 | Type |1|0|1|0|0|0|Rsv| Type Ext | Index Start | 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 | Index Stop | 2253 +-+-+-+-+-+-+-+-+ 2255 0 1 2 3 2256 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 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 | Type |0|0|0|1|0|M|Rsv| Length | | 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2260 | | 2261 | Value | 2262 | | 2263 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2264 | | 2265 +-+-+-+-+-+-+-+-+ 2266 0 1 2 3 2267 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 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 | Type |1|0|0|1|0|M|Rsv| Type Ext | Length | 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 | | 2272 | Value | 2273 | | 2274 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | | 2276 +-+-+-+-+-+-+-+-+ 2278 0 1 2 3 2279 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 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | Type |0|1|0|1|0|0|Rsv| Index Start | Length | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | | 2284 | Value | 2285 | | 2286 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 | | 2288 +-+-+-+-+-+-+-+-+ 2290 0 1 2 3 2291 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 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | Type |1|1|0|1|0|0|Rsv| Type Ext | Index Start | 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 | Length | | 2296 +-+-+-+-+-+-+-+-+ | 2297 | Value | 2298 | | 2299 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 | | 2301 +-+-+-+-+-+-+-+-+ 2302 0 1 2 3 2303 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 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 | Type |0|0|1|1|0|M|Rsv| Index Start | Index Stop | 2306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 | Length | | 2308 +-+-+-+-+-+-+-+-+ | 2309 | Value | 2310 | | 2311 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2312 | | 2313 +-+-+-+-+-+-+-+-+ 2315 0 1 2 3 2316 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 2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 | Type |1|0|1|1|0|M|Rsv| Type Ext | Index Start | 2319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 | Index Stop | Length | | 2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2322 | | 2323 | Value | 2324 | | 2325 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 | | 2327 +-+-+-+-+-+-+-+-+ 2329 0 1 2 3 2330 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 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 | Type |0|0|0|0|1|M|Rsv| Length | 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 | | 2335 | Value | 2336 | | 2337 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 | | 2339 +-+-+-+-+-+-+-+-+ 2340 0 1 2 3 2341 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 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 | Type |1|0|0|1|1|M|Rsv| Type Ext | Length | 2344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 | Length (cont) | | 2346 +-+-+-+-+-+-+-+-+ | 2347 | Value | 2348 | | 2349 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | | 2351 +-+-+-+-+-+-+-+-+ 2353 0 1 2 3 2354 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 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | Type |0|1|0|1|1|0|Rsv| Index Start | Length | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | Length (cont) | | 2359 +-+-+-+-+-+-+-+-+ | 2360 | | 2361 | Value | 2362 | | 2363 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 | | 2365 +-+-+-+-+-+-+-+-+ 2367 0 1 2 3 2368 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 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 | Type |1|1|0|1|1|0|Rsv| Type Ext | Index Start | 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 | Length | | 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2374 | | 2375 | Value | 2376 | | 2377 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2378 | | 2379 +-+-+-+-+-+-+-+-+ 2380 0 1 2 3 2381 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 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | Type |0|0|1|1|1|M|Rsv| Index Start | Index Stop | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | Length | | 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2387 | | 2388 | Value | 2389 | | 2390 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 | | 2392 +-+-+-+-+-+-+-+-+ 2394 0 1 2 3 2395 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 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 | Type |1|0|1|1|1|M|Rsv| Type Ext | Index Start | 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | Index Stop | Length | | 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2401 | | 2402 | Value | 2403 | | 2404 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 | | 2406 +-+-+-+-+-+-+-+-+ 2408 Appendix E. Complete Example 2410 The following example packet is included with the intent to exemplify 2411 how packet and message headers are constructed, and how addresses and 2412 attributes are encoded using address blocks and TLV blocks. This 2413 example is specifically not constructed to exhibit maximum message or 2414 packet size reduction. Appendix D contains illustrations of all 2415 syntactical elements. 2417 The packet header has the phasseqnum flag set of its flags field set 2418 (value 8), and hence has a Packet Sequence Number, but no packet TLV 2419 block. 2421 The packet contains a single message with length 54 octets. This 2422 message has the mhasorig, mhashoplimit, mhashopcount and mhasseqnum 2423 flags of its four bit flags field set (value 15), and hence includes 2424 an Originator Address, a Hop Limit, a Hop Count and a Message 2425 Sequence Number (which is type independent). Its four bit message 2426 address length field has value 3 and hence addresses in the message 2427 have length four octets, here being IPv4 addresses. The message has 2428 a message TLV block with content length 9 octets, containing a single 2429 message TLV. This TLV has the thasvalue flag of its flags octet set 2430 (value 16), and hence contains a Value field, with preceding value 2431 length 6 octets. The message then has two address blocks each with a 2432 following address TLV block. 2434 The first address block contains 2 address prefixes. It has the 2435 ahaszerotail and ahassingleprelen flags of its flags octet set (value 2436 48), and hence has no head (head-length is zero octets). It has a 2437 tail-length of 2 octets, hence mid-length is two octets. The two 2438 tail octets of each address are not included (since ahaszerotail is 2439 set) and have value zero. The address block has a single Prefix 2440 Length. The following address TLV block is empty (content length 0 2441 octets). 2443 The second address block contains 3 addresses. It has the ahashead 2444 flag of its flags octet set (value 128), and has head length 2 2445 octets, no tail (tail-length is zero octets) and hence mid-length is 2446 two octets. It is followed by an address TLV block, with content 2447 length 9 octets, containing two address block TLVs. The first of 2448 these TLVs has the thasvalue flag of its flags octet set (value 16), 2449 and has a single Value of length 2 octets, which applies to all of 2450 the addresses in the address block. The second of these TLVs has the 2451 thasmultiindex flag of its flags octet set (value 32), and hence has 2452 no value length or value fields. It has two index fields (Index 2453 Start and Index Stop), which indicate those addresses this TLV 2454 applies to (inclusive range, counting from zero). 2456 0 1 2 3 2457 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 2458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2459 |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type | 2460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr | 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2463 | Originator Address (cont) | Hop Limit | 2464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2465 | Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0| 2466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2467 |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| 2468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 | Value | 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 | Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0| 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 |0 0 0 0 0 0 1 0| Mid | Mid | 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 | Mid (cont) | Prefix Length |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 |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 | 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 | Head (cont) | Mid | Mid | 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 | Mid (cont) | Mid |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 0 1 0| 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 | Value | TLV Type |0 0 1 0 0 0 0 0| 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 | Index Start | Index Stop | 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 Appendix F. Contributors 2492 This specification is the result of the joint efforts of the 2493 following contributors from the OLSRv2 Design Team, listed 2494 alphabetically: 2496 o Cedric Adjih, INRIA, France, 2498 o Emmanuel Baccelli, INRIA, France, 2500 o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, 2501 2503 o Justin W. Dean, NRL, USA, 2505 o Christopher Dearlove, BAE Systems, UK, 2506 2508 o Satoh Hiroki, Hitachi SDL, Japan, 2510 o Philippe Jacquet, INRIA, France, 2512 o Monden Kazuya, Hitachi SDL, Japan, 2514 Appendix G. Acknowledgments 2516 The authors would like to acknowledge the team behind OLSR [RFC3626], 2517 including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot 2518 (both at INRIA, France), and Amir Qayyum (Center for Advanced 2519 Research in Engineering, Pakistan) for their contributions. Elwyn 2520 Davies (Folly Consulting, UK), Lars Eggert (Nokia, Finland), Chris 2521 Newman (Sun Microsystems, USA), Tim Polk (NIST, USA), and Magnus 2522 Westerlund (Ericsson, Sweden) all provided detailed reviews and 2523 insightful comments. 2525 The authors would like to gratefully acknowledge the following people 2526 for intense technical discussions, early reviews and comments on the 2527 specification and its components (listed alphabetically): 2529 o Brian Adamson (NRL) 2531 o Teco Boot (Infinity Networks) 2533 o Florent Brunneau (LIX) 2535 o Ian Chakeres (Motorola) 2537 o Alan Cullen (BAE Systems) 2539 o Ulrich Herberg (LIX) 2541 o Joe Macker (NRL) 2543 o Yasunori Owada (Niigata University) 2545 o Henning Rogge (FGAN) 2547 o Charlie E. Perkins (WiChorus) 2549 o Andreas Schjonhaug (LIX) 2550 and the entire IETF MANET working group. 2552 Authors' Addresses 2554 Thomas Heide Clausen 2555 LIX, Ecole Polytechnique, France 2557 Phone: +33 6 6058 9349 2558 EMail: T.Clausen@computer.org 2559 URI: http://www.thomasclausen.org/ 2561 Christopher M. Dearlove 2562 BAE Systems Advanced Technology Centre 2564 Phone: +44 1245 242194 2565 EMail: chris.dearlove@baesystems.com 2566 URI: http://www.baesystems.com/ 2568 Justin W. Dean 2569 Naval Research Laboratory 2571 Phone: +1 202 767 3397 2572 EMail: jdean@itd.nrl.navy.mil 2573 URI: http://pf.itd.nrl.navy.mil/ 2575 Cedric Adjih 2576 INRIA Rocquencourt 2578 Phone: +33 1 3963 5215 2579 EMail: Cedric.Adjih@inria.fr 2580 URI: http://menetou.inria.fr/~adjih/ 2582 Full Copyright Statement 2584 Copyright (C) The IETF Trust (2008). 2586 This document is subject to the rights, licenses and restrictions 2587 contained in BCP 78, and except as set forth therein, the authors 2588 retain all their rights. 2590 This document and the information contained herein are provided on an 2591 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2592 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2593 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2594 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2595 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2596 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2598 Intellectual Property 2600 The IETF takes no position regarding the validity or scope of any 2601 Intellectual Property Rights or other rights that might be claimed to 2602 pertain to the implementation or use of the technology described in 2603 this document or the extent to which any license under such rights 2604 might or might not be available; nor does it represent that it has 2605 made any independent effort to identify any such rights. Information 2606 on the procedures with respect to rights in RFC documents can be 2607 found in BCP 78 and BCP 79. 2609 Copies of IPR disclosures made to the IETF Secretariat and any 2610 assurances of licenses to be made available, or the result of an 2611 attempt made to obtain a general license or permission for the use of 2612 such proprietary rights by implementers or users of this 2613 specification can be obtained from the IETF on-line IPR repository at 2614 http://www.ietf.org/ipr. 2616 The IETF invites any interested party to bring to its attention any 2617 copyrights, patents or patent applications, or other proprietary 2618 rights that may cover technology that may be required to implement 2619 this standard. Please address the information to the IETF at 2620 ietf-ipr@ietf.org.