idnits 2.17.1 draft-ietf-manet-packetbb-13.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 2602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2626. 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 550 has weird spacing: '...-length is a ...' == Line 561 has weird spacing: '...-length is a ...' == Line 571 has weird spacing: '...-length is a ...' == Line 711 has weird spacing: '...ype-ext is a ...' == Line 714 has weird spacing: '...ulltype is a ...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 2008) is 5785 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'POSIX' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECMAScript' Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 10 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: December 26, 2008 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 C. Adjih 10 INRIA Rocquencourt 11 June 24, 2008 13 Generalized MANET Packet/Message Format 14 draft-ietf-manet-packetbb-13 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 December 26, 2008. 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.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 53 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 54 5. Syntactical Specification . . . . . . . . . . . . . . . . . . 7 55 5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 10 58 5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 13 59 5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14 60 5.4.2. TLV Inclusion and Constraints . . . . . . . . . . . . 17 61 5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 63 6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 18 64 6.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 21 65 6.2.1. Message Type Specific TLV Registry Creation . . . . . 21 66 6.3. Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 21 67 6.3.1. Packet TLV Type Extension Registry Creation . . . . . 21 68 6.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 21 69 6.4.1. Message TLV Type Extension Registry Creation . . . . . 22 70 6.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 22 71 6.5.1. Address Block TLV Type Extension Registry Creation . . 23 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 73 7.1. Authentication and Integrity Suggestions . . . . . . . . . 24 74 7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 24 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 26 78 Appendix A. Intended Usage . . . . . . . . . . . . . . . . . . . 26 79 Appendix B. Multiplexing and Demultiplexing . . . . . . . . . . . 27 80 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 28 81 C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 28 82 C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 30 83 Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 32 84 D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 33 85 D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 36 86 D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 42 87 D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 43 88 D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 50 89 D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 90 Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 56 91 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 57 92 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 58 94 1. Introduction 96 This document specifies the syntax of a packet format designed to 97 carrying multiple messages for information exchange between MANET 98 (Mobile Ad hoc NETwork) routers. Messages consist of a message 99 header, which is designed for control of message dissemination, and a 100 message body, which contains protocol information. Only the syntax 101 of the packet and messages is specified. All syntactical entities, 102 including packets and messages, are specified using a regular 103 expression derived notation. 105 This document specifies: 107 o A packet format, allowing zero or more messages to be contained 108 within a single transmission. A packet with zero messages may be 109 sent in case the only information to exchange is contained in the 110 packet header. 112 o A message format, where a message is composed of a message header 113 and a message body. 115 o A message header format, which contains information which may be 116 sufficient to allow a protocol using this specification to make 117 processing and forwarding decisions. 119 o A message body format, containing attributes associated with the 120 message or the originator of the message, as well as blocks of 121 addresses, or address prefixes, with associated attributes. 123 o An address block format, where an address block represents sets of 124 addresses, or address prefixes, in a compact form with aggregated 125 addresses. 127 o A generalized type-length-value (TLV) format representing 128 attributes. Each TLV can be associated with a packet, a message, 129 or one or more addresses or address prefixes in a single address 130 block. Multiple TLVs can be included and each associated with a 131 packet, a message, and with the same, different or overlapping 132 sets of addresses or address prefixes. 134 The specification has been explicitly designed with the following 135 properties, listed in no particular order, in mind: 137 Parsing logic - the regular expression derived notation used in this 138 specification facilitates generic, protocol independent, parsing 139 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 structure of packet and 152 message encoding allows parsing, verifying, and identifying 153 individual elements in a single pass. 155 Separation of forwarding and processing - a protocol using this 156 specification can be designed such that duplicate detection and 157 controlled scope message forwarding decisions can be made using 158 information contained in the message header, without processing 159 the message body. 161 2. Notation and Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in 166 [RFC2119]. 168 Additionally, this document uses the notation in Section 2.1, and the 169 terminology in Section 2.2. 171 2.1. Notation 173 This specification uses a derivative of the regular expression 174 language from [SingleUNIX], [POSIX] or [ECMAScript], using only the 175 following notation: 177 Element - A group of any number of consecutive bits which, together, 178 forms a syntactic entity, represented using the notation . 180 - If is an unsigned integer field then is also 181 used to represent the value of that field. 183 bar - A variable, usually obtained through calculations based on the 184 value(s) of element(s). Variables are introduced into the 185 specification solely as a means to clarify the description. 187 := - Indicates that the element or variable on the left hand side is 188 defined as the expression on the right hand side. 190 () - Indicates a grouping of the elements 191 enclosed by the parentheses. 193 ? - Zero or one occurrences of the preceding element or group. 195 * - Zero or more occurrences of the preceding element or group. 197 address-length - A variable whose value is the length of an address 198 in octets, it is 4 if using IPv4, or 16 if using IPv6. 200 2.2. Terminology 202 This document uses the following terminology: 204 Packet - The top level entity in this specification. A packet 205 contains a packet header and zero or more messages. 207 Message - The fundamental entity carrying protocol information, in 208 the form of address objects and TLVs. 210 Address - A number of octets of the same length as the source IP 211 address in the IP datagram carrying the packet. The meaning of an 212 address is defined by the protocol using this specification. 214 Address Prefix - An address plus a prefix length, with the prefix 215 length being a number of address bits measured from the left/most 216 significant end of the address. 218 Address Object - Either an address, or an address prefix, as 219 specified in an address block in this specification. 221 TLV - A Type-Length-Value structure. This is a generic way in which 222 an attribute can be represented and correctly parsed, without the 223 parser having to understand the attribute. 225 3. Applicability Statement 227 This specification describes a generic packet format, designed for 228 use by MANET routing protocols. The specification has been inspired 229 by and extended from that used by OLSR (The Optimized Link State 230 Routing protocol) [RFC3626]. 232 MANETs are, commonly though not exclusively, characterized as being 233 able to run over wireless network interfaces of limited to moderate 234 capacity. MANETs are therefore less tolerant of wasted transmitted 235 octets than are most wired networks. This specification thus 236 represents a tradeoff between sometimes competing attributes, 237 specifically efficiency, extensibility, and ease of use. 239 Efficiency is supported by reducing packet size and by allowing 240 multiple disjoint messages in a single packet. Reduced packet size 241 is primarily supported by address aggregation, optional packet and 242 message header fields, and optional fields in address blocks and 243 TLVs. Supporting multi-message packets allows a reduction in the 244 number of packets, each of which can incur significant bandwidth 245 costs from transport, network and lower layers. 247 This specification provides both external and internal extensibility. 248 External extensibility is supported by the ability to add packet TLVs 249 and to define new message types. Internal extensibility is supported 250 by the ability to add message TLVs and address block TLVs to existing 251 messages. Protocols can define new TLV types, and hence the contents 252 of their value fields (see Section 6.1), and new message types. 253 Protocols can also reuse message and TLV type definitions from other 254 protocols which also use this specification. 256 This specification aims at being sufficiently expressive and flexible 257 to be able to accommodate both different classes of MANET routing 258 protocols (e.g. proactive, reactive and hybrid routing protocols), as 259 well as extensions thereto. Having a common packet and message 260 format, and a common way of representing IP addresses and associated 261 attributes, allows generic parsing code to be developed, regardless 262 of the algorithm used by the routing protocol. 264 All addresses within a message are assumed to be of the same size, 265 deduced from the IP header. In the case of mixed IPv6 and IPv4 266 addresses, IPv4 addresses can be represented as IPv4-mapped IPv6 267 addresses as specified in [RFC4291]. Packets may be unicast or 268 multicast, and may use any appropriate transport protocol, or none. 270 The messages defined by this specification are designed to carry 271 MANET routing protocol signaling between MANET routers. This 272 specification includes elements which can support limited diffusion 273 (flooding), as well as being usable for point to point delivery of 274 MANET routing protocol signaling in a multi-hop network. 276 A MANET routing protocol using the packet format defined by this 277 specification can constrain the syntax (for example requiring a 278 specific set of message header fields) that the protocol will employ. 279 Protocols with such restrictions need not be able to parse all 280 possible packet structures as defined by this document but must be 281 coherent in packet generation and reception of packets of which they 282 define. If a protocol specifies which elements are included, then 283 direct indexing of the appropriate fields is possible, dependant on 284 the syntax restrictions imposed by the protocol. Such protocols may 285 have more limited extensibility. 287 4. Protocol Overview and Functioning 289 This specification does not describe a protocol. It describes a 290 packet format, which may be used by any mobile ad hoc network routing 291 protocol. 293 5. Syntactical Specification 295 This section provides syntactical specification of a packet, 296 represented by the element and the elements from which it is 297 composed. The specification is given using the notation in 298 Section 2.1. Illustrations of specified elements are given in 299 Appendix D. 301 This format uses network byte order (most significant octet first) 302 for all fields. The most significant bit in an octet is numbered bit 303 0, and the least significant bit of an octet is numbered bit 7 304 [Stevens]. 306 5.1. Packets 308 is defined by: 310 := 311 * 313 where is as defined in Section 5.2. Successful parsing is 314 terminated when all octets of the packet (as defined by the datagram 315 containing the packet) are used. 317 is defined by: 319 := 320 321 ? 322 ? 324 where: 326 is a 4 bit unsigned integer field and specifies the 327 version of the specification on which the packet and the contained 328 messages are constructed. This document specifies version 0. 330 is a 4 bit field, specifying the interpretation of the 331 remainder of the packet header: 333 bit 0 (phasseqnum): If cleared ('0'), then is not 334 included in the . If set ('1'), then 335 is included in the . 337 bit 1 (phastlv): If cleared ('0'), then is not 338 included in the . If set ('1'), then 339 is included in the . 341 bit 2 (pnouniord): If cleared ('0'), then the packet TLV block 342 MUST conform to the constraints in Section 5.4.2. If set 343 ('1'), then the packet TLV block is not subject to the 344 constraints in Section 5.4.2. Additional constraints MAY be 345 imposed by a protocol using this specification. 347 bit 3: Is RESERVED, and SHOULD be cleared ('0') on transmission, 348 and SHOULD be ignored on reception. 350 is omitted if the phasseqnum pkt-flag is cleared 351 ('0'), otherwise is a 16 bit unsigned integer field, specifying a 352 packet sequence number. 354 is omitted if the phastlv flag is cleared ('0'), and is 355 otherwise as defined in Section 5.4. 357 5.2. Messages 359 Packets may, in addition to the packet header, contain one or more 360 messages. Messages contain: 362 o A message header. 364 o A message TLV block that contains zero or more TLVs, associated 365 with the whole message. 367 o Zero or more address blocks, each containing one or more address 368 objects. 370 o An address TLV block, containing zero or more TLVs, following each 371 address block, through which addresses can be associated with 372 additional attributes. 374 is defined by: 376 := 377 378 ()* 380 := 381 382 383 ? 384 ? 385 ? 386 ? 388 where: 390 is as defined in Section 5.4. 392 is as defined in Section 5.3. 394 is an 8 bit unsigned integer field, specifying the type 395 of the message. 397 is an 8 bit field, specifying the interpretation of the 398 remainder of the message header: 400 bit 0 (mhasorig): If cleared ('0'), then is not 401 included in the . If set ('1'), then is included in the . 404 bit 1 (mhashoplimit): If cleared ('0'), then is 405 not included in the . If set ('1'), then is included in the . 408 bit 2 (mhashopcount): If cleared ('0'), then is 409 not included in the . If set ('1'), then is included in the . 412 bit 3 (mhasseqnum): If cleared ('0'), then is not 413 included in the . If set ('1'), then 414 is included in the . 416 bit 4 (mistypedep): If cleared ('0'), then the message sequence 417 number in the message is type-independent. If set ('1'), then 418 the message sequence number contained in the message is type 419 dependent (the message originator maintains a sequence number 420 specific to ). This msg-flag MUST be cleared ('0') 421 if the mhasorig msg-flag is cleared ('0'). 423 bit 5 (mnouniord): If cleared ('0'), then the message TLV block 424 and all address TLV blocks in the message MUST conform to the 425 constraints in Section 5.4.2. If set ('1'), then the message 426 TLV block and all address TLV blocks in the message are not 427 subject to the constraints in Section 5.4.2. Additional 428 constraints MAY be imposed by a protocol using this 429 specification. 431 bit 6-7: Are RESERVED, and SHOULD each be cleared ('0') on 432 transmission, and SHOULD be ignored on reception. 434 is a 16 bit unsigned integer field, specifying the number 435 of octets that make up the , including the . 437 is omitted if the mhasorig msg-flag is cleared 438 ('0'), otherwise is an identifier with length equal to address- 439 length, which can serve to uniquely identify the node that 440 originated the message. 442 is omitted if the mhashoplimit msg-flag is cleared 443 ('0'), otherwise is an 8 bit unsigned integer field, which can 444 contain the maximum number of hops that the message should be 445 further transmitted. 447 is omitted if the mhashopcount msg-flag is cleared 448 ('0'), otherwise is an 8 bit unsigned integer field, which can 449 contain the number of hops that the message has traveled. 451 is omitted if the mhasseqnum msg-flag is cleared 452 ('0'), otherwise is a 16 bit unsigned integer field, which can 453 contain a sequence number, generated by the message's originator 454 node. 456 5.3. Address Blocks 458 An address block can specify one or more addresses. It can also 459 specify prefix lengths that can be applied to all addresses in the 460 address block. This allows an address block to specify either 461 addresses or address prefixes. A protocol may specify that an 462 address with a maximum prefix length (equal to the address length, in 463 bits) is considered to be an address, rather than an address prefix, 464 thus allowing an address block to contain a mixture of addresses and 465 address prefixes. The common term "address object" is used in this 466 specification to cover both of these; note that an address object in 467 an address block always includes the prefix length, if present. 469 An address is specified as a sequence of address-length octets of the 470 form head:mid:tail. There are no semantics associated with head, mid 471 or tail; this representation is solely to allow aggregation of 472 addresses, which often have common parts (e.g. common prefixes or 473 multiple IPv6 addresses on the same interface). An address block 474 contains an ordered set of addresses all sharing the same head and 475 the same tail, but having individual mids. Independently, head and 476 tail may be empty, allowing for representation of address objects 477 which do not have common heads or common tails. Detailed examples of 478 address blocks are included in Appendix C.1. 480 An address block can specify address prefixes: 482 o with a single prefix length for all address prefixes; OR 484 o with a prefix length for each address prefix. 486 is defined by: 488 := 489 490 (?)? 491 (?)? 492 * 493 * 495 where: 497 is an 8 bit unsigned integer field containing the number 498 of addresses represented in the address block, which MUST NOT be 499 zero. 501 is an 8 bit field specifying the interpretation of the 502 remainder of the address block: 504 bit 0 (ahashead): If cleared ('0'), then and 505 are not included in the . If set ('1'), then 506 is included in the , and is 507 included in the unless is zero. 509 bit 1 (ahasfulltail) and bit 2 (ahaszerotail): Are interpreted 510 according to Table 1. A combination not shown in that table 511 MUST NOT be used. 513 bit 3 (ahassingleprelen) and bit 4 (ahasmultiprelen): Are 514 interpreted according to Table 2. A combination not shown in 515 that table MUST NOT be used. 517 bits 5-7: Are RESERVED, and SHOULD each be cleared ('0') on 518 transmission, and SHOULD be ignored on reception. 520 +--------------+--------------+---------------+---------------------+ 521 | ahasfulltail | ahaszerotail | | | 522 +--------------+--------------+---------------+---------------------+ 523 | 0 | 0 | not included | not included | 524 | 1 | 0 | included | included unless | 525 | | | | is | 526 | | | | zero | 527 | 0 | 1 | included | not included | 528 +--------------+--------------+---------------+---------------------+ 530 Table 1: Interpretation of the ahasfulltail and ahaszerotail addr- 531 flags 533 +------------+-----------+------------------+-----------------------+ 534 | ahassingle | ahasmulti | number of | prefix length of the | 535 | prelen | prelen | | nth address prefix, | 536 | | | fields | in bits | 537 +------------+-----------+------------------+-----------------------+ 538 | 0 | 0 | 0 | 8 * address-length | 539 | 1 | 0 | 1 | | 540 | 0 | 1 | | nth | 541 +------------+-----------+------------------+-----------------------+ 543 Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen 544 addr-flags 546 if present is an 8 bit unsigned integer field, which 547 contains the number of octets in the head of all of the addresses 548 in the address block. 550 head-length is a variable, defined to equal if 551 present, or 0 otherwise. 553 is omitted if head-length is equal to 0, otherwise it is a 554 field of the head-length leftmost octets common to all the 555 addresses in the address block. 557 if present is an 8 bit unsigned integer field, which 558 contains the number of octets in the tail of all of the addresses 559 in the address block. 561 tail-length is a variable, defined to equal if 562 present, or 0 otherwise. 564 is omitted if tail-length is equal to 0, or if the 565 ahaszerotail bit is set ('1'), otherwise it is a field of the 566 tail-length rightmost octets common to all the addresses in the 567 address block. If the ahaszerotail bit is set ('1') then the 568 tail-length rightmost octets of all the addresses in the address 569 block are all 0. 571 mid-length is a variable, which MUST be non-negative, defined by: 573 * mid-length := address-length - head-length - tail-length 575 is omitted if mid-length is equal to 0, otherwise each 576 is a field of length mid-length octets, representing the mid of 577 the corresponding address in the address block. When not omitted, 578 an address block contains exactly fields. 580 is an 8 bit unsigned integer field containing the 581 length, in bits, of an address prefix. If the ahassingleprelen 582 addr-flag is set ('1') then a single field is 583 included, which contains the prefix length of all addresses in the 584 address block. If the ahasmultiprelen addr-flag is set ('1') then 585 fields are included, each of which 586 contains the prefix length of the corresponding address prefix in 587 the address block (in the same order). Otherwise no fields are present; each address object can be considered 589 to have a prefix length equal to 8 * address-length bits. The 590 address block is malformed if any element has a 591 value greater than 8 * address-length. 593 5.4. TLVs and TLV Blocks 595 A TLV allows association of an arbitrary attribute with a message or 596 a packet, or with a single address or a contiguous set of addresses 597 in an address block. The attribute (value) is made up from an 598 integer number of consecutive octets. Different attributes have 599 different types; attributes which are unknown when parsing can be 600 skipped. 602 TLVs are grouped in TLV blocks, with all TLVs within a TLV block 603 associating attributes with either the packet (for the TLV block in 604 the packet header), the message (for the TLV block immediately 605 following the message header) or to addresses in the immediately 606 preceding address block. Individual TLVs in a TLV block immediately 607 following an address block can associate attributes to a single 608 address, a range of addresses or all addresses in that address block. 609 When associating an attribute with more than one address, a TLV can 610 include one value for all addresses, or one value per address. 611 Detailed examples of TLVs are included in Appendix C.2. 613 A TLV block is defined by: 615 := 616 * 618 where: 620 is a 16 bit unsigned integer field, which contains the 621 total number of octets in all of the immediately following 622 elements ( not included). 624 is as defined in Section 5.4.1. 626 5.4.1. TLVs 628 There are three kinds of TLV, each represented by an element : 630 o A packet TLV, included in the packet TLV block in a packet header. 632 o A message TLV, included in the message TLV block in a message, 633 before any address blocks. 635 o An address block TLV, included in an address TLV block following 636 an address block. An address block TLV applies to: 638 * all address objects in the address block; OR 640 * any continuous sequence of address objects in the address 641 block; OR 643 * a single address object in the address block. 645 is defined by: 647 := 648 649 ? 650 (?)? 651 (?)? 653 where: 655 is an 8 bit unsigned integer field, specifying the type 656 of the TLV, specific to the TLV kind (i.e. packet, message, or 657 address block TLV). 659 is an 8 bit field specifying the interpretation of the 660 remainder of the TLV: 662 bit 0 (thastypeext): If cleared ('0'), then is not 663 included in the . If set ('1'), then is 664 included in the . 666 bit 1 (thassingleindex) and bit 2 (thasmultiindex): Are 667 interpreted according to Table 3. A combination not shown in 668 that table MUST NOT be used. Both of these tlv-flags MUST be 669 cleared ('0') in packet and message TLVs. 671 bit 3 (thasvalue) and bit 4 (thasextlen): Are interpreted 672 according to Table 4. A combination not shown in that table 673 MUST NOT be used. 675 bit 5 (tismultivalue): This tlv-flag serves to specify how the 676 field is interpreted, as specified below. This tlv- 677 flag MUST be cleared ('0') in packet and message TLVs, if the 678 thasmultiindex tlv-flag is cleared ('0'), or if the thasvalue 679 tlv-flag is cleared ('0'). 681 bits 6-7: Are RESERVED, and SHOULD each be cleared ('0') on 682 transmission, and SHOULD be ignored on reception. 684 +-----------------+----------------+---------------+--------------+ 685 | thassingleindex | thasmultiindex | | | 686 +-----------------+----------------+---------------+--------------+ 687 | 0 | 0 | not included | not included | 688 | 1 | 0 | included | not included | 689 | 0 | 1 | included | included | 690 +-----------------+----------------+---------------+--------------+ 692 Table 3: Interpretation of the thassingleindex and thasmultiindex 693 tlv-flags 695 +-----------+------------+--------------+---------------------------+ 696 | thasvalue | thasextlen | | | 697 +-----------+------------+--------------+---------------------------+ 698 | 0 | 0 | not included | not included | 699 | 1 | 0 | 8 bits | included unless | 700 | | | | is zero | 701 | 1 | 1 | 16 bits | included unless | 702 | | | | is zero | 703 +-----------+------------+--------------+---------------------------+ 705 Table 4: Interpretation of the thasvalue and thasextlen tlv-flags 707 is an 8 bit unsigned integer field, specifying an 708 extension of the TLV type, specific to the TLV type and kind (i.e. 709 packet, message, or address block TLV). 711 tlv-type-ext is a variable, defined to equal if 712 present, or 0 otherwise. 714 tlv-fulltype is a variable, defined by: 716 * tlv-fulltype := 256 * + tlv-type-ext 718 and when present, in an address block TLV 719 only, are each an 8 bit unsigned integer field. 721 index-start and index-stop are variables, defined according to 722 Table 5. The variable end-index is defined as follows: 724 * For message and packet TLVs: 726 + end-index := 0 728 * For address block TLVs: 730 + end-index := - 1 732 An address block TLV applies to the address objects from position 733 index-start to position index-stop (inclusive) in the address 734 block, where the first address object has position zero. 736 +-----------------+----------------+----------------+---------------+ 737 | thassingleindex | thasmultiindex | index-start := | index-stop := | 738 +-----------------+----------------+----------------+---------------+ 739 | 0 | 0 | 0 | end-index | 740 | 1 | 0 | | | 741 | 0 | 1 | | | 742 +-----------------+----------------+----------------+---------------+ 744 Table 5: Interpretation of the thassingleindex and thasmultiindex 745 tlv-flags 747 number-values is a variable, defined by: 749 * number-values := index-stop - index-start + 1 751 is omitted or is an 8 or 16 bit unsigned integer field 752 according to Table 4. If the tismultivalue tlv-flag is set ('1') 753 then MUST be an integral multiple of number-values, and 754 the variable single-length is defined by: 756 * single-length := / number-values 758 If the tismultivalue tlv-flag is cleared ('0'), then the variable 759 single-length is defined by: 761 * single-length := 763 if present (see Table 4) is a field of length 764 octets. In an address block TLV, is associated with the 765 address objects from positions index-start to index-stop, 766 inclusive. If the tismultivalue tlv-flag is cleared ('0') then 767 the whole of this field is associated with each of the indicated 768 address objects. If the tismultivalue tlv-flag is set ('1') then 769 this field is divided equally into number-values fields, each of 770 length single-length octets, and these are associated, in order, 771 with the indicated address objects. 773 5.4.2. TLV Inclusion and Constraints 775 A TLV associates an attribute with a packet, a message or one or more 776 consecutive address objects in an address block. The interpretation 777 and processing of this attribute, and the relationship (including 778 order of processing) between different attributes associated with the 779 same entity MUST be defined by a protocol which uses this 780 specification. 782 If the appropriate flags (pnouniord for a packet TLV block, mnouniord 783 for a message TLV block or an address block TLV block) are cleared 784 ('0'), then the following constraints MUST be respected. These flags 785 MUST always be cleared ('0') unless a protocol using this 786 specification defines otherwise. Protocols SHOULD only define use of 787 these flags when necessary, and then MUST indicate what constraints 788 do apply if each of the indicated flags is set ('1'); each of these 789 constraints SHOULD be retained unless otherwise necessary. 791 o TLVs in the same TLV block are sorted in non-descending tlv- 792 fulltype order. 794 o Two or more address TLVs with the same tlv-fulltype in the same 795 message are not associated with the same value of address object. 797 o TLVs with the same tlv-fulltype associated with the same address 798 block are sorted in ascending index-start order. 800 In addition, packet and message TLVs MUST be defined so as to 801 indicate whether two such TLVs with the same tlv-fulltype are, or are 802 not, allowed in the same packet or message TLV block, respectively. 804 Note that the above constrains only the encoding of TLVs in a TLV 805 block for transmission, and do specifically NOT mandate any given 806 order of processing or interpretation by a protocol of the TLVs and 807 the entities to which these are associated. 809 Respecting the constraints above allows parsing and verification of a 810 TLV block in a single pass and allows terminating the search for a 811 TLV with a specific type without traversing the entire TLV block. 813 The constraints on address block TLVs ensure that encoded information 814 (entity-attributes) can be unambiguously decoded. 816 5.5. Malformed Elements 818 An element is malformed if it cannot be parsed according to its 819 syntactical specification (including if there are insufficient octets 820 available) or if a constraint (including, but not only, those 821 specified in Section 5.4.2) specified as one which MUST be satisfied, 822 is not. A protocol using this specification MUST specify the action, 823 or choice of actions, to be taken when a packet containing such 824 elements is received. Typical examples will include discarding any 825 affected message(s), or discarding the complete packet. 827 6. IANA Considerations 829 This document introduces four namespaces that require registration: 830 Message Types, Packet TLV Types, Message TLV Types and Address Block 831 TLV Types. This section specifies IANA registries for these 832 namespaces, and provides guidance to the Internet Assigned Numbers 833 Authority regarding registrations in these namespaces. 835 The following terms are used with the meanings defined in [BCP26]: 836 "Namespace", "Assigned Value", "Registration", "Unassigned", 837 "Reserved", "Hierarchical Allocation", "Designated Expert". 839 The following policies are used with the meanings defined in [BCP26]: 840 "Private Use", "Expert Review", "Standards Action". 842 6.1. Expert Review: Evaluation Guidelines 844 For registration requests where an Expert Review is required, the 845 Designated Expert SHOULD take the following general recommendations 846 into consideration: 848 o The purposes of these registries are to support Standard and 849 Experimental MANET routing and related protocols, and extensions 850 to the same. 852 o The intention is that all registrations will be accompanied by a 853 published RFC. 855 o In order to allow for registration prior to the RFC being approved 856 for publication, the Designated Expert can approve the 857 registration once it seems clear that an RFC is expected to be 858 published. 860 o The Designated Expert will post a request to the MANET WG mailing 861 list, or to a successor hereto as designated by the Area Director, 862 for comments and reviews. This request will include a reference 863 to the Internet-Draft requesting the registration. 865 o Before a period of 30 days has passed, the Designated Expert will 866 either approve or deny the registration request and publish a note 867 of the decision to the MANET WG mailing list or its successor, as 868 well as informing IANA and the IESG. A denial note MUST be 869 justified by an explanation and, in cases where it is possible, 870 suggestions as to how the request can be modified so as to become 871 acceptable SHOULD be provided. 873 For the registry for Message Types, the following guidelines apply: 875 o Registration of a message type implies creation of two registries 876 for message type specific message TLVs and message type specific 877 address block TLVs. The document which requests the registration 878 of the message type MUST indicate how these message type specific 879 TLV types are to be allocated, from any options in [BCP26], and 880 any initial allocations. The Designated Expert SHOULD take the 881 allocation policies specified for these registries into 882 consideration in reviewing the message type allocation request. 884 For the registries for Packet TLV Types, Message TLV Types and 885 Address Block TLV Types, the following guidelines apply: 887 o These are Hierarchical Allocations, allocation of a type creates a 888 registry for the extended types corresponding to that type. The 889 document which requests the registration of the type MUST indicate 890 how these extended types are to be allocated, from any options in 891 [BCP26], and any initial allocations. Normally this allocation 892 should also be Expert Review, but with the possible allocation of 893 some type extensions as Reserved, Experimental and/or Private. 895 o TLV type values 0-7 MUST NOT be registered except when a 896 documented need exists that TLVs of a given type are required to 897 appear before all other TLVs in the TLV block as encoded for 898 transmission. Note that the need for a TLV to be processed before 899 other TLVs does not however automatically translate into a need 900 for the TLV to appear before all other TLVs in the TLV block (the 901 order in which TLVs are to be processed MUST be defined, if 902 applicable, in the protocols using this specification). 904 o The request for a TLV type MUST include the specification of the 905 permitted size, syntax of any internal structure of, and meaning 906 of, the value field (if any) of the TLV. 908 For the registries for Message TLV Types and Address Block TLV Types, 909 the following additional guidelines apply: 911 o TLV type values 0-127 are common for all message types. TLVs 912 which receive registrations from the 0-127 interval SHOULD be 913 modular in design to allow reuse among protocols. 915 o TLV type values 128-223 are message type specific TLV type values, 916 relevant only in the context of the containing message type. 917 Registration of TLV type values within the 128-223 interval 918 require that a registry in the 128-223 interval exists for a 919 specific message type value (see Section 6.2.1), and registrations 920 are made in accordance with the allocation policies specified for 921 these message type specific registries. Message type specific TLV 922 types SHOULD be registered for TLVs which the Designated Expert 923 deems too message type specific for registration of a 0-127 value. 924 Multiple different TLV definitions MAY be assigned the same TLV 925 type value within the 128-223 interval, given that they are 926 associated with different message type specific TLV type 927 registries. Where possible, existing global TLV definitions and 928 modular global TLV definitions for registration in the 0-127 range 929 SHOULD be used. 931 6.2. Message Types 933 A new registry for message types must be created, with initial 934 assignments and allocation policies as specified in Table 6. 936 +---------+-------------+-------------------+ 937 | Type | Description | Allocation Policy | 938 +---------+-------------+-------------------+ 939 | 0-223 | Unassigned | Expert Review | 940 | 224-255 | Unassigned | Experimental Use | 941 +---------+-------------+-------------------+ 943 Table 6: Message Types 945 6.2.1. Message Type Specific TLV Registry Creation 947 When a message type is registered then registries MUST be specified 948 for both message type specific message TLVs (Table 8) and message 949 type specific address block TLVs (Table 10). A document which 950 creates a message type specific TLV registry MUST also specify the 951 mechanism by which message specific TLV types are allocated, from 952 among those in [BCP26]. 954 6.3. Packet TLV Types 956 A new registry for packet TLV types must be created, with initial 957 assignments and allocation policies as specified in Table 7. 959 +---------+-------------+-------------------+ 960 | Type | Description | Allocation Policy | 961 +---------+-------------+-------------------+ 962 | 0-223 | Unassigned | Expert Review | 963 | 224-255 | Unassigned | Experimental Use | 964 +---------+-------------+-------------------+ 966 Table 7: Packet TLV Types 968 6.3.1. Packet TLV Type Extension Registry Creation 970 When a packet TLV type is registered then a new registry for type 971 extensions of that type must be created. A document which defines a 972 packet TLV type MUST also specify the mechanism by which its type 973 extensions are allocated, from among those in [BCP26]. 975 6.4. Message TLV Types 977 A new registry for message type independent message TLV types must be 978 created, with initial assignments and allocation policies as 979 specified in Table 8. 981 +---------+-----------------------+-----------------------+ 982 | Type | Description | Allocation Policy | 983 +---------+-----------------------+-----------------------+ 984 | 0-127 | Unassigned | Expert Review | 985 | 128-223 | Message Type Specific | Reserved, see Table 9 | 986 | 224-255 | Unassigned | Experimental Use | 987 +---------+-----------------------+-----------------------+ 989 Table 8: Message TLV Types 991 Message TLV Types 128-223 are reserved for message type specific 992 Message TLVs, for which a new registry is created with the 993 registration of a message type, and with initial assignments and 994 allocation policies as specified in Table 9. 996 +---------+-----------------------------+-------------------+ 997 | Type | Description | Allocation Policy | 998 +---------+-----------------------------+-------------------+ 999 | 0-127 | Common to all Message Types | Reserved | 1000 | 128-223 | Message Type Specific | See Below | 1001 | 224-255 | Common to all Message Types | Reserved | 1002 +---------+-----------------------------+-------------------+ 1004 Table 9: Message Specific Message TLV Types 1006 Allocation policies for message type specific message TLV types MUST 1007 be specified when creating the registry associated with the 1008 containing message type, see Section 6.2.1. 1010 6.4.1. Message TLV Type Extension Registry Creation 1012 If a message TLV type is registered then a new registry for type 1013 extensions of that type must be created. A document which defines a 1014 message TLV type MUST also specify the mechanism by which its type 1015 extensions are allocated, from among those in [BCP26]. 1017 6.5. Address Block TLV Types 1019 A new registry for message type independent address block TLV types 1020 must be created, with initial assignments and allocation policies as 1021 specified in Table 10. 1023 +---------+-----------------------+------------------------+ 1024 | Type | Description | Allocation Policy | 1025 +---------+-----------------------+------------------------+ 1026 | 0-127 | Unassigned | Expert Review | 1027 | 128-223 | Message Type Specific | Reserved, see Table 11 | 1028 | 224-255 | Unassigned | Experimental Use | 1029 +---------+-----------------------+------------------------+ 1031 Table 10: Address Block TLV Types 1033 Address Block TLV Types 128-223 are reserved for message type 1034 specific Address Block TLVs, for which a new registry is created with 1035 the registration of a message type, and with initial assignments and 1036 allocation policies as specified in Table 11. 1038 +---------+-----------------------------+-------------------+ 1039 | Type | Description | Allocation Policy | 1040 +---------+-----------------------------+-------------------+ 1041 | 0-127 | Common to all Message Types | Reserved | 1042 | 128-223 | Message Type Specific | See Below | 1043 | 224-255 | Common to all Message Types | Reserved | 1044 +---------+-----------------------------+-------------------+ 1046 Table 11: Message Specific Address Block TLV Types 1048 Allocation policies for message type specific address block TLV types 1049 MUST be specified when creating the registry associated with the 1050 containing message type, see Section 6.2.1. 1052 6.5.1. Address Block TLV Type Extension Registry Creation 1054 When an address block TLV type is registered then a new registry for 1055 type extensions of that type must be created. A document which 1056 defines a message TLV type MUST also specify the mechanism by which 1057 its type extensions are allocated, from among those in [BCP26]. 1059 7. Security Considerations 1061 This specification does not describe a protocol; it describes a 1062 packet format. As such it does not specify any security 1063 considerations, these are matters for a protocol using this 1064 specification. However some security mechanisms are enabled by this 1065 specification, and may form part of a protocol using this 1066 specification. Mechanisms which may form part of an authentication 1067 and integrity approach in a protocol using this specification, are 1068 described in Section 7.1. Mechanisms which may form part of a 1069 confidentiality approach in a protocol using this specification, are 1070 described in Section 7.2. There is however no requirement that a 1071 protocol using this specification should use either. 1073 7.1. Authentication and Integrity Suggestions 1075 The authentication and integrity suggestions made here, are based on 1076 the intended usage in Appendix A, specifically that: 1078 o Messages are designed to be carriers of protocol information and 1079 MAY, at each hop, be forwarded and/or processed by the protocol 1080 using this specification. 1082 o Packets are designed to carry a number of messages between 1083 neighboring nodes in a single transmission and over a single 1084 logical hop. 1086 Consequently: 1088 o For forwarded messages where the message is unchanged by 1089 forwarding nodes, then end-to-end authentication and integrity MAY 1090 be implemented, between nodes with an existing security 1091 association, by including a suitable message TLV containing a 1092 cryptographic signature in the message. Since and 1093 are the only fields that should be modified when such 1094 a message is forwarded in this manner, this signature can be 1095 calculated based on the entire message, including the message 1096 header, with the and fields set to 0 if 1097 present. 1099 o Hop-by-hop packet level authentication and integrity MAY be 1100 implemented, between nodes with an existing security association, 1101 by including a suitable packet TLV containing a cryptographic 1102 signature to the packet. Since packets are received as 1103 transmitted, this signature can be calculated based on the entire 1104 packet, or on parts thereof as appropriate. 1106 7.2. Confidentiality Suggestions 1108 This specification does not explicitly enable protecting packet/ 1109 message confidentiality. Such confidentiality would normally, when 1110 required, be provided hop-by-hop either by link-layer mechanisms, or 1111 at the IP layer using [RFC4301], and would apply to a packet only. 1113 It is possible, however, for a protocol using this specification to 1114 protect the confidentiality of information included in a packet, 1115 message or address block TLV by specifying that the value field of 1116 that TLV type be encrypted, as well as specifying the encryption 1117 mechanism. 1119 In an extreme case, all information can be encrypted by defining 1120 either: 1122 o A packet, consisting of only a packet header (with no messages), 1123 and containing a packet TLV, where the packet TLV type indicates 1124 that its value field contains one or more encrypted messages. 1125 Upon receipt, and once this packet TLV is successfully decrypted, 1126 these messages may then be parsed according to this specification 1127 and processed according to the protocol using this specification. 1129 o A message, consisting of only a message header and a single 1130 message TLV, where the message TLV type indicates that its value 1131 field contains an encrypted version of the message's remaining 1132 message TLVs, address blocks and address block TLVs. Upon 1133 receipt, and once this message TLV is successfully decrypted, the 1134 complete message may then be parsed according to this 1135 specification and processed according to the protocol using this 1136 specification. 1138 In either case, the protocol MUST define the encrypted TLV type, as 1139 well as the format of the encrypted data block contained in the value 1140 field of the TLV. 1142 8. References 1144 8.1. Normative References 1146 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1147 Requirement Levels", RFC 2119, BCP 14, March 1997. 1149 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing 1150 an IANA Considerations Section in RFCs", RFC 5226, 1151 BCP 26, May 2008. 1153 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1154 Architecture", RFC 4291, February 2006. 1156 [SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC 1157 1/SC22/WG15, "Single UNIX Specification, Version 3, 1158 2004 Edition", April 2004. 1160 [POSIX] ISO/IEC Standard 9945-1:2003, "Portable Operating 1161 System Interface (POSIX) - Part 1: Base Definitions", 1162 January 2003. 1164 [ECMAScript] ISO/IEC Standard 9845-1:2003, "Ecma-262, ECMAScript 1165 Language Specification", January 2003. 1167 8.2. Informative References 1169 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 1170 Routing Protocol", RFC 3626, October 2003. 1172 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1173 Internet Protocol", RFC 4301, December 2005. 1175 [Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The 1176 Protocols.", 1994. 1178 Appendix A. Intended Usage 1180 The packet and message format specified in this document is designed 1181 to carry MANET routing protocol signaling between MANET routers, and 1182 to support scope limited diffusion (flooding) as well as point-to- 1183 point delivery. 1185 Specifically: 1187 o Packets are transmitted over a single logical hop and are not 1188 forwarded. Messages are designed to be able to be forwarded over 1189 one or more logical hops, in a new packet for each logical hop. 1190 Each logical hop may consist of one or more IP hops. Packets may 1191 contain a different combination of messages for each logical hop. 1192 Packets may be formed from messages from more than one MANET 1193 routing protocol; the use of a single message type space for all 1194 such protocols allows these messages to be separated by protocol. 1196 o Scope limited flooding is supported for messages thus: 1198 * If the mhasorig and mhasseqnum msg-flags are both set ('1') 1199 then the message header provides for duplicate suppression, 1200 using the identifier consisting of the message's , , and, if the mistypedep flag in the field is set ('1'), . These serve to uniquely 1203 identify the message in the network within the time period 1204 until is repeated, i.e. wraps around to a 1205 matching value if used sequentially. 1207 * If the mhashoplimit msg-flag is set ('1'), then the message 1208 header provides the information to make forwarding decisions 1209 for scope limited diffusion (flooding). This may be by any 1210 appropriate flooding mechanism specified by a protocol using 1211 this specification. 1213 * SHOULD, if present, be decremented, usually by 1214 one, if the message is forwarded. 1216 * SHOULD, if present, be incremented, usually by 1217 one, if the message is forwarded. 1219 Appendix B. Multiplexing and Demultiplexing 1221 The packet and message format specified in this document is designed 1222 to allow zero or more messages to be contained within a single packet 1223 (e.g. a single IP datagram or UDP datagram). Such messages may be 1224 from the same or may be from different protocols. In the latter 1225 case, multiplexing of outgoing messages from different protocols and 1226 demultiplexing of incoming messages contained within a single packet, 1227 must be addressed. 1229 Multiplexing messages of different message types from different 1230 protocols running on a given node into a single packet, rather than 1231 to have each protocol generate its own packet, is an optimization. 1232 Doing so may reduce the total number of octets as transmitted by that 1233 node, while not doing so should not have any adverse effects on 1234 protocol functioning. 1236 Having two different protocols (or, two different instances of the 1237 same protocol) generate messages of the same message type on the same 1238 interface may, however, cause inconsistencies, unless this message 1239 generation is coordinated. 1241 If a packet contains messages destined for multiple protocols, 1242 correct functioning of each of these protocols depends on the 1243 appropriate messages being delivered to each protocol. 1245 If multiple protocols which are using the packet and message format 1246 specified in this document are running over the same UDP port or IP 1247 protocol number, multiplexing and demultiplexing of messages SHOULD 1248 be accomplished based on message types, ensuring a correspondence 1249 between message types and protocol instances thus: 1251 o For each message type, a protocol - unless specified otherwise, 1252 the one making the IANA reservation for that message type - SHOULD 1253 be designated as the "owner" of that message type. 1255 o On a given interface, and for a given UDP port or IP protocol 1256 number, only one protocol instance of a protocol which is the 1257 designated "owner" of a message type SHOULD be running, 1259 o Any incoming messages of a given message type SHOULD be delivered 1260 to the protocol instance on the receiving interface which "owns" 1261 messages of that type. Specifically, any incoming message SHOULD 1262 NOT be delivered to any other protocol instances and SHOULD NOT be 1263 delivered to more than one protocol instance. 1265 o Any outgoing messages of a given type SHOULD be generated and 1266 transmitted only by the protocol instance which "owns" that 1267 message type. 1269 o If two protocols both wish to use the same message type (e.g. 1270 through inspecting information carried in messages of that type, 1271 or through inserting information into generated messages of that 1272 type) then this interaction SHOULD be specified by the protocol 1273 which is the designated "owner" of that message type. 1275 Appendix C. Examples 1277 This appendix contains some examples of parts of this specification. 1279 C.1. Address Block Examples 1281 The following examples illustrate how some combinations of addresses 1282 may be efficiently included in address blocks. These examples are 1283 for IPv4, with address-length equal to 4. a, b, c etc. represent 1284 distinct, non-zero, octet values. 1286 Note that it is permissible to use a less efficient representation, 1287 in particular one in which the ahashead and ahasfulltail flags are 1288 cleared ('0'), and hence head-length = 0, tail-length = 0, mid-length 1289 = address-length, and (with no address prefixes) the address block 1290 consists of the number of addresses, with value 0, and a 1291 list of the unaggregated addresses. This is the most efficient way 1292 to represent a single address, and the only way to represent, for 1293 example, a.b.c.d and e.f.g.h in one address block. 1295 Examples: 1297 o To include a.b.c.d, a.b.e.f and a.b.g.h: 1299 * head-length = 2; 1301 * tail-length = 0; 1303 * mid-length = 2; 1305 * has ahashead set (value 128); 1307 * and are omitted. 1309 The address block is then 3 128 2 a b c d e f g h (11 octets). 1311 o To include a.b.c.g and d.e.f.g: 1313 * head-length = 0; 1315 * tail-length = 1; 1317 * mid-length = 3; 1319 * has ahasfulltail set (value 64); 1321 * and are omitted. 1323 The address block is then 2 64 1 g a b c d e f (10 octets). 1325 o To include a.b.d.e and a.c.d.e: 1327 * head-length = 1; 1329 * tail-length = 2; 1331 * mid-length = 1; 1333 * has ahashead and ahasfulltail set (value 192). 1335 The address block is then 2 192 1 a 2 d e b c (9 octets). 1337 o To include a.b.0.0, a.c.0.0, and a.d.0.0: 1339 * head-length = 1; 1341 * tail-length = 2; 1343 * mid-length = 1; 1345 * has ahashead and ahaszerotail set (value 160); 1347 * is omitted. 1349 The address block is then 3 160 1 a 2 b c d (8 octets). 1351 o To include a.b.0.0 and c.d.0.0: 1353 * head-length = 0; 1355 * tail-length = 2; 1357 * mid-length = 2; 1359 * has ahaszerotail set (value 32); 1360 * and are omitted. 1362 The address block is then 2 32 2 a b c d (7 octets). 1364 o To include a.b.0.0/n and c.d.0.0/n: 1366 * head-length = 0; 1368 * tail-length = 2; 1370 * mid-length = 2; 1372 * has ahaszerotail and ahassingleprelen set (value 1373 48); 1375 * and are omitted. 1377 The address block is then 2 48 2 a b c d n (8 octets). 1379 o To include a.b.0.0/n and c.d.0.0/m: 1381 * head-length = 0; 1383 * tail-length = 2; 1385 * mid-length = 2; 1387 * has ahaszerotail and ahasmultiprelen set (value 1388 40); 1390 * and are omitted. 1392 The address block is then 2 40 2 a b c d n m (9 octets). 1394 C.2. TLV Examples 1396 Assuming the definition of an address block TLV with type EXAMPLE1 1397 (and no type extension) which has single octet values per address, 1398 then if values a, a, b and c are to be associated with the four 1399 addresses in the preceding address block, where c is a default value 1400 that can be omitted, then this can be done in a number of ways. 1402 Examples: 1404 o Using one multivalue TLV covering all of the addresses: 1406 * has thasvalue and tismultivalue set (value 20); 1407 * and are omitted; 1409 * = 4 (single-length = 1). 1411 * The TLV is then EXAMPLE1 20 4 a a b c (7 octets). 1413 o Using one multivalue TLV omitting the last address: 1415 * has thasmultiindex, thasvalue and tismultivalue set 1416 (value 52); 1418 * = 0; 1420 * = 2 1422 * = 3 (single-length = 1). 1424 * The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets). 1426 o Using two single value TLVs, omitting the last address. First: 1428 * has thasmultiindex and thasvalue set (value 48); 1430 * = 0; 1432 * = 1; 1434 * = 1; 1436 * = a. 1438 * The TLV is then EXAMPLE1 48 0 1 1 a (6 octets). 1440 Second: 1442 * has thassingleindex and thasvalue set (value 80); 1444 * = 2; 1446 * is omitted; 1448 * = 1; 1450 * = b. 1452 * The TLV is then EXAMPLE1 80 2 1 b (5 octets). 1454 Total length of TLVs is 11 octets. 1456 In this case the first of these is the most efficient. In other 1457 cases patterns such as the others may be preferred. Regardless of 1458 efficiency, any of these may be used. 1460 Assuming the definition of an address block TLV with type EXAMPLE2 1461 (and no type extension) which has no value, which is to be associated 1462 with the second and third addresses in an address block, then this 1463 can be indicated with a single TLV: 1465 o has thasmultiindex set (value 32); 1467 o = 1; 1469 o = 2; 1471 o and are omitted. 1473 o The TLV is then EXAMPLE2 32 1 2 (4 octets). 1475 Assuming the definition of a message TLV with type EXAMPLE3 (and no 1476 type extension) which can take a value field of any length, for such 1477 a TLV with 8 octets of data (a to h): 1479 o has thasvalue set (value 16); 1481 o and are omitted; 1483 o = 8. 1485 o The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets). 1487 If, in this example, the number of data octets were 256 or greater 1488 then would also have thasextlen set and have value 24. 1489 The length would require two octets (most significant first). The 1490 TLV length would be 4 + N octets, where N is the number of data 1491 octets (it can be 3 + N octets if N is 255 or less). 1493 Appendix D. Illustrations 1495 This informative appendix illustrates the elements which are 1496 normatively specified in Section 5. 1498 Bits labeled Rsv or R should be cleared ('0'). Bits labeled C, N, or 1499 M may be cleared ('0') or set ('1'). 1501 D.1. Packet 1503 Possible options for the element. These are differentiated 1504 by the flags field in the first octet. The packet may include any 1505 number (zero or more) of Messages. The number of Messages is 1506 determined from when the packet is exhausted, given the packet length 1507 from the network layer. 1509 0 1 2 3 1510 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 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 |0|0|0|0|0|0|C|R| | 1513 +-+-+-+-+-+-+-+-+ | 1514 | Message | 1515 | | 1516 | +-+-+-+-+-+-+-+-+ 1517 | | | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1519 | | 1520 : ... : 1521 | | 1522 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | | | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1525 | | 1526 | Message | 1527 | +-+-+-+-+-+-+-+-+ 1528 | | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 0 1 2 3 1531 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 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 |0|0|0|0|1|0|C|R| Packet Sequence Number | | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1535 | | 1536 | Message | 1537 | | 1538 | +-+-+-+-+-+-+-+-+ 1539 | | | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1541 | | 1542 : ... : 1543 | | 1544 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | | | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1547 | | 1548 | Message | 1549 | +-+-+-+-+-+-+-+-+ 1550 | | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 0 1 2 3 1553 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 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 |0|0|0|0|0|1|C|R| | 1556 +-+-+-+-+-+-+-+-+ | 1557 | | 1558 | Packet TLV Block | 1559 | | 1560 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | | | 1562 +-+-+-+-+-+-+-+-+ | 1563 | Message | 1564 | | 1565 | +-+-+-+-+-+-+-+-+ 1566 | | | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1568 | | 1569 : ... : 1570 | | 1571 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | | | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1574 | | 1575 | Message | 1576 | +-+-+-+-+-+-+-+-+ 1577 | | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 0 1 2 3 1580 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 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 |0|0|0|0|1|1|C|R| Packet Sequence Number | | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1584 | | 1585 | Packet TLV Block | 1586 | | 1587 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | | | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1590 | | 1591 | Message | 1592 | | 1593 | +-+-+-+-+-+-+-+-+ 1594 | | | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1596 | | 1597 : ... : 1598 | | 1599 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | | | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1602 | | 1603 | Message | 1604 | +-+-+-+-+-+-+-+-+ 1605 | | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 D.2. Message 1610 Possible options for the element. These are differentiated 1611 by their second (flags) octet. The length of the Message Body is 1612 determined using the Message Size field, which is the combined length 1613 of all the fields shown. 1615 0 1 2 3 1616 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 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Message Type |0|0|0|0|0|C|Rsv| Message Size | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | | 1621 | Message Body | 1622 | | 1623 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 0 1 2 3 1627 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 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | Message Type |1|0|0|0|0|C|Rsv| Message Size | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | Originator Address | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | | 1634 | Message Body | 1635 | | 1636 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 0 1 2 3 1641 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 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | Message Type |0|1|0|0|0|C|Rsv| Message Size | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | Hop Limit | | 1646 +-+-+-+-+-+-+-+-+ | 1647 | Message Body | 1648 | | 1649 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 0 1 2 3 1654 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 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | Message Type |1|1|0|0|0|C|Rsv| Message Size | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | Originator Address | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | Hop Limit | | 1661 +-+-+-+-+-+-+-+-+ | 1662 | Message Body | 1663 | | 1664 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 | | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 0 1 2 3 1668 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 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 | Message Type |0|0|1|0|0|C|Rsv| Message Size | 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | Hop Count | | 1673 +-+-+-+-+-+-+-+-+ | 1674 | Message Body | 1675 | | 1676 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 0 1 2 3 1681 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 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | Message Type |1|0|1|0|0|C|Rsv| Message Size | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 | Originator Address | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | Hop Count | | 1688 +-+-+-+-+-+-+-+-+ | 1689 | Message Body | 1690 | | 1691 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 0 1 2 3 1696 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 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Message Type |0|1|1|0|0|C|Rsv| Message Size | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Hop Limit | Hop Count | | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1702 | | 1703 | Message Body | 1704 | | 1705 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 0 1 2 3 1709 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 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Message Type |1|1|1|0|0|C|Rsv| Message Size | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Originator Address | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | Hop Limit | Hop Count | | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1717 | | 1718 | Message Body | 1719 | | 1720 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 | | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 0 1 2 3 1725 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 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 | Message Type |0|0|0|1|N|C|Rsv| Message Size | 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 | Message Sequence Number | | 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1731 | | 1732 | Message Body | 1733 | | 1734 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 | | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 0 1 2 3 1739 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 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | Message Type |1|0|0|1|N|C|Rsv| Message Size | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | Originator Address | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | Message Sequence Number | | 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1747 | | 1748 | Message Body | 1749 | | 1750 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 0 1 2 3 1754 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 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | Message Type |0|1|0|1|N|C|Rsv| Message Size | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | Hop Limit | Message Sequence Number | | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1760 | | 1761 | Message Body | 1762 | | 1763 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 0 1 2 3 1768 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 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | Message Type |1|1|0|1|N|C|Rsv| Message Size | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 | Originator Address | 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 | Hop Limit | Message Sequence Number | | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1776 | | 1777 | Message Body | 1778 | | 1779 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 0 1 2 3 1784 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 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | Message Type |0|0|1|1|N|C|Rsv| Message Size | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Hop Count | Message Sequence Number | | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1790 | | 1791 | Message Body | 1792 | | 1793 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 0 1 2 3 1797 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 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | Message Type |1|0|1|1|N|C|Rsv| Message Size | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | Originator Address | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | Hop Count | Message Sequence Number | | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1805 | | 1806 | Message Body | 1807 | | 1808 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | | 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 0 1 2 3 1813 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 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | Message Type |0|1|1|1|N|C|Rsv| Message Size | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | Hop Limit | Hop Count | Message Sequence Number | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | | 1820 | Message Body | 1821 | | 1822 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 0 1 2 3 1827 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 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | Message Type |1|1|1|1|N|C|Rsv| Message Size | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 | Originator Address | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | Hop Limit | Hop Count | Message Sequence Number | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | | 1836 | Message Body | 1837 | | 1838 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 D.3. Message Body 1844 Format of a message body (the element excluding its initial 1845 element). The message body includes one Message TLV 1846 Block (containing zero or more TLVs) and may include any number (zero 1847 or more) of Address Block and Address TLV Block pairs. 1849 0 1 2 3 1850 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 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | | 1853 | Message TLV Block | 1854 | +-+-+-+-+-+-+-+-+ 1855 | | | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1857 | | 1858 | Address Block | 1859 | | 1860 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | | | 1862 +-+-+-+-+-+-+-+-+ | 1863 | Address TLV Block | 1864 | | 1865 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | | | 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1868 | | 1869 : ... : 1870 | | 1871 | +-+-+-+-+-+-+-+-+ 1872 | | | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1874 | | 1875 | Address Block | 1876 | | 1877 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 | | | 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1880 | | 1881 | Address TLV Block | 1882 | | 1883 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 | | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 D.4. Address Block 1889 Possible options for the element. These are 1890 differentiated by their second (flags) octet. The number of Mid 1891 elements is equal to the number of addresses (except when mid-length 1892 is zero, when there are no Mid elements). Where a variable number of 1893 Prefix Length fields is shown, their number is equal to the number of 1894 addresses. 1896 0 1 2 3 1897 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 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | Number Addrs |0|0|0|0|0| Rsv | Mid | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | Mid (cont) | | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1903 | | 1904 : ... : 1905 | | 1906 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | | Mid | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 | Mid (cont) | 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 0 1 2 3 1913 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 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 | Number Addrs |1|0|0|0|0| Rsv | Head Length | Head | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | Head (cont) | Mid | | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1919 | | 1920 : ... : 1921 | | 1922 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | | Mid | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 0 1 2 3 1926 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 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | Number Addrs |0|1|0|0|0| Rsv | Tail Length | Tail | 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | Tail (cont) | Mid | | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1932 | | 1933 : ... : 1934 | | 1935 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 | | Mid | 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 0 1 2 3 1940 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 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 | Number Addrs |1|1|0|0|0| Rsv | Head Length | Head | 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | Head (cont) | Tail Length | Tail | 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 | Mid | | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1948 | | 1949 : ... : 1950 | | 1951 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 | | Mid | 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 0 1 2 3 1956 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 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 | Number Addrs |0|0|1|0|0| Rsv | Tail Length | Mid | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | Mid (cont) | | 1961 +-+-+-+-+-+-+-+-+ | 1962 | | 1963 : ... : 1964 | | 1965 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 | | Mid | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 0 1 2 3 1969 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 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | Number Addrs |1|0|1|0|0| Rsv | Head Length | Head | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | Head (cont) | Tail Length | Mid | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | | 1976 : ... : 1977 | | 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | Mid | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 0 1 2 3 1983 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 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | Number Addrs |0|0|0|1|0| Rsv | Mid | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | Mid (cont) | | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1989 | | 1990 : ... : 1991 | | 1992 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | | Mid | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | Mid (cont) | Prefix Length | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 0 1 2 3 1999 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 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | Number Addrs |1|0|0|1|0| Rsv | Head Length | Head | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | Head (cont) | Mid | | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2005 | | 2006 : ... : 2007 | | 2008 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | | Mid | Prefix Length | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 0 1 2 3 2012 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 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 | Number Addrs |0|1|0|1|0| Rsv | Tail Length | Tail | 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 | Tail (cont) | Mid | | 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2018 | | 2019 : ... : 2020 | | 2021 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | | Mid | Prefix Length | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 0 1 2 3 2026 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 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 | Number Addrs |1|1|0|1|0| Rsv | Head Length | Head | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | Head (cont) | Tail Length | Tail | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | Mid | | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2034 | | 2035 : ... : 2036 | | 2037 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | | Mid | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | Prefix Length | 2041 +-+-+-+-+-+-+-+-+ 2043 0 1 2 3 2044 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 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 | Number Addrs |0|0|1|1|0| Rsv | Tail Length | Mid | 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | Mid (cont) | | 2049 +-+-+-+-+-+-+-+-+ | 2050 | | 2051 : ... : 2052 | | 2053 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 | | Mid | Prefix Length | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 0 1 2 3 2057 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 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | Number Addrs |1|0|1|1|0| Rsv | Head Length | Head | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | Head (cont) | Tail Length | Mid | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | | 2064 : ... : 2065 | | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | Mid | Prefix Length | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 0 1 2 3 2071 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 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | Number Addrs |0|0|0|0|1| Rsv | Mid | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 | Mid (cont) | | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2077 | | 2078 : ... : 2079 | | 2080 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | | Mid | 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 | Mid (cont) | Prefix Length | | 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2085 | | 2086 : ... : 2087 | | 2088 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 | | Prefix Length | 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2091 0 1 2 3 2092 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 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | Number Addrs |1|0|0|0|1| Rsv | Head Length | Head | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | Head (cont) | Mid | | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2098 | | 2099 : ... : 2100 | | 2101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 | | Mid | Prefix Length | 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 | | 2105 : ... : 2106 | | 2107 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 | | Prefix Length | 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 0 1 2 3 2112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 | Number Addrs |0|1|0|0|1| Rsv | Tail Length | Tail | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 | Tail (cont) | Mid | | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2118 | | 2119 : ... : 2120 | | 2121 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 | | Mid | Prefix Length | 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | | 2125 : ... : 2126 | | 2127 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | | Prefix Length | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 0 1 2 3 2131 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 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 | Number Addrs |1|1|0|0|1| Rsv | Head Length | Head | 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | Head (cont) | Tail Length | Tail | 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | Mid | | 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2139 | | 2140 : ... : 2141 | | 2142 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 | | Mid | 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 | Prefix Length | | 2146 +-+-+-+-+-+-+-+-+ | 2147 : ... : 2148 | +-+-+-+-+-+-+-+-+ 2149 | | Prefix Length | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 0 1 2 3 2153 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 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 | Number Addrs |0|0|1|0|1| Rsv | Tail Length | Mid | 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 | Mid (cont) | | 2158 +-+-+-+-+-+-+-+-+ | 2159 | | 2160 : ... : 2161 | | 2162 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 | | Mid | Prefix Length | 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 | | 2166 : ... : 2167 | | 2168 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 | | Prefix Length | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 0 1 2 3 2172 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 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Number Addrs |1|0|1|0|1| Rsv | Head Length | Head | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | Head (cont) | Tail Length | Mid | 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | | 2179 : ... : 2180 | | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 | Mid | Prefix Length | | 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2184 | | 2185 : ... : 2186 | | 2187 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 | | Prefix Length | 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 D.5. TLV Block 2193 Format of a element. There may be any number (zero or 2194 more) of TLVs, with total length of the TLVs (in octets) equal to the 2195 Length field. 2197 0 1 2 3 2198 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 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 | Length | | 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2202 | | 2203 | TLV | 2204 | +-+-+-+-+-+-+-+-+ 2205 | | | 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2207 | | 2208 : ... : 2209 | | 2210 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 | | | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2213 | | 2214 | TLV | 2215 | +-+-+-+-+-+-+-+-+ 2216 | | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 D.6. TLV 2221 Possible options for the element. These are differentiated by 2222 their second (flags) octet. If there are no index fields then this 2223 may be a packet, message or address block TLV, if there are one or 2224 two index fields then this must be an address block TLV. The Length 2225 field gives the length of the value field (in octets). 2227 0 1 2 3 2228 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 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 | Type |0|0|0|0|0|0|Rsv| 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 0 1 2 3 2234 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 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | Type |1|0|0|0|0|0|Rsv| Type Ext | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 0 1 2 3 2240 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 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | Type |0|1|0|0|0|0|Rsv| Index Start | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 0 1 2 3 2246 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 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 | Type |1|1|0|0|0|0|Rsv| Type Ext | Index Start | 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 0 1 2 3 2252 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 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 | Type |0|0|1|0|0|0|Rsv| Index Start | Index Stop | 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 0 1 2 3 2257 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 2258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 | Type |1|0|1|0|0|0|Rsv| Type Ext | Index Start | 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 | Index Stop | 2262 +-+-+-+-+-+-+-+-+ 2264 0 1 2 3 2265 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 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2267 | Type |0|0|0|1|0|M|Rsv| Length | | 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2269 | | 2270 | Value | 2271 | | 2272 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | | 2274 +-+-+-+-+-+-+-+-+ 2276 0 1 2 3 2277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | Type |1|0|0|1|0|M|Rsv| Type Ext | Length | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | | 2282 | Value | 2283 | | 2284 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 | | 2286 +-+-+-+-+-+-+-+-+ 2288 0 1 2 3 2289 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 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 | Type |0|1|0|1|0|0|Rsv| Index Start | Length | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | | 2294 | Value | 2295 | | 2296 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2297 | | 2298 +-+-+-+-+-+-+-+-+ 2299 0 1 2 3 2300 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 2301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2302 | Type |1|1|0|1|0|0|Rsv| Type Ext | Index Start | 2303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2304 | Length | | 2305 +-+-+-+-+-+-+-+-+ | 2306 | Value | 2307 | | 2308 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 | | 2310 +-+-+-+-+-+-+-+-+ 2312 0 1 2 3 2313 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 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | Type |0|0|1|1|0|M|Rsv| Index Start | Index Stop | 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 | Length | | 2318 +-+-+-+-+-+-+-+-+ | 2319 | Value | 2320 | | 2321 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 | | 2323 +-+-+-+-+-+-+-+-+ 2325 0 1 2 3 2326 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 2327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 | Type |1|0|1|1|0|M|Rsv| Type Ext | Index Start | 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 | Index Stop | Length | | 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2332 | | 2333 | Value | 2334 | | 2335 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | | 2337 +-+-+-+-+-+-+-+-+ 2338 0 1 2 3 2339 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 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 | Type |0|0|0|0|1|M|Rsv| Length | 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 | | 2344 | Value | 2345 | | 2346 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | | 2348 +-+-+-+-+-+-+-+-+ 2350 0 1 2 3 2351 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 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 | Type |1|0|0|1|1|M|Rsv| Type Ext | Length | 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 | Length (cont) | | 2356 +-+-+-+-+-+-+-+-+ | 2357 | Value | 2358 | | 2359 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 | | 2361 +-+-+-+-+-+-+-+-+ 2363 0 1 2 3 2364 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 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2366 | Type |0|1|0|1|1|0|Rsv| Index Start | Length | 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 | Length (cont) | | 2369 +-+-+-+-+-+-+-+-+ | 2370 | | 2371 | Value | 2372 | | 2373 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 | | 2375 +-+-+-+-+-+-+-+-+ 2376 0 1 2 3 2377 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 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 | Type |1|1|0|1|1|0|Rsv| Type Ext | Index Start | 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 | Length | | 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2383 | | 2384 | Value | 2385 | | 2386 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 | | 2388 +-+-+-+-+-+-+-+-+ 2390 0 1 2 3 2391 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 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 | Type |0|0|1|1|1|M|Rsv| Index Start | Index Stop | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | Length | | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2397 | | 2398 | Value | 2399 | | 2400 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | | 2402 +-+-+-+-+-+-+-+-+ 2404 0 1 2 3 2405 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 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 | Type |1|0|1|1|1|M|Rsv| Type Ext | Index Start | 2408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2409 | Index Stop | Length | | 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2411 | | 2412 | Value | 2413 | | 2414 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 | | 2416 +-+-+-+-+-+-+-+-+ 2418 Appendix E. Complete Example 2420 The following example packet, using IPv4 addresses (hence address- 2421 length is four octets) is included with the intent to exemplify how 2422 packet and message headers are constructed, and how addresses and 2423 attributes are encoded using address blocks and TLV blocks. This 2424 example is specifically not constructed to exhibit maximum message or 2425 packet size reduction. Appendix D contains illustrations of all 2426 syntactical elements. 2428 The packet header has the phasseqnum flag set of its flags field set 2429 (value 8), and hence has a Packet Sequence Number, but no packet TLV 2430 block. 2432 The packet contains a single message with length 54 octets. This 2433 message has the mhasorig, mhashoplimit, mhashopcount and mhasseqnum 2434 flags of its flags octet set (value 240), and hence includes an 2435 Originator Address, a Hop Limit, a Hop Count and a Message Sequence 2436 Number (which is type independent). The message has a message TLV 2437 block with content length 9 octets, containing a single message TLV. 2438 This TLV has the thasvalue flag of its flags octet set (value 16), 2439 and hence contains a Value field, with preceding value length 6 2440 octets. The message then has two address blocks each with a 2441 following address TLV block. 2443 The first address block contains 2 address prefixes. It has the 2444 ahaszerotail and ahassingleprelen flags of its flags octet set (value 2445 48), and hence has no head (head-length is zero octets). It has a 2446 tail-length of 2 octets, hence mid-length is two octets. The two 2447 tail octets of each address are not included (since ahaszerotail is 2448 set) and have value zero. The address block has a single Prefix 2449 Length. The following address TLV block is empty (content length 0 2450 octets). 2452 The second address block contains 3 addresses. It has the ahashead 2453 flag of its flags octet set (value 128), and has head length 2 2454 octets, no tail (tail-length is zero octets) and hence mid-length is 2455 two octets. It is followed by an address TLV block, with content 2456 length 9 octets, containing two address block TLVs. The first of 2457 these TLVs has the thasvalue flag of its flags octet set (value 16), 2458 and has a single Value of length 2 octets, which applies to all of 2459 the addresses in the address block. The second of these TLVs has the 2460 thasmultiindex flag of its flags octet set (value 32), and hence has 2461 no value length or value fields. It has two index fields (Index 2462 Start and Index Stop), which indicate those addresses this TLV 2463 applies to (inclusive range, counting from zero). 2465 0 1 2 3 2466 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 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type | 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 |1 1 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr | 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 | Originator Address (cont) | Hop Limit | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0| 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 |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| 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2478 | Value | 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 | Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0| 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 |0 0 0 0 0 0 1 0| Mid | Mid | 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 | Mid (cont) | Prefix Length |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 2485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 |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 | 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 | Head (cont) | Mid | Mid | 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 | Mid (cont) | Mid |0 0 0 0 0 0 0 0| 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 |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| 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | Value | TLV Type |0 0 1 0 0 0 0 0| 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 | Index Start | Index Stop | 2497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 Appendix F. Contributors 2501 This specification is the result of the joint efforts of the 2502 following contributors from the OLSRv2 Design Team, listed 2503 alphabetically: 2505 o Cedric Adjih, INRIA, France, 2507 o Emmanuel Baccelli, INRIA, France, 2509 o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, 2510 2512 o Justin W. Dean, NRL, USA 2514 o Christopher Dearlove, BAE Systems, UK, 2515 2517 o Satoh Hiroki, Hitachi SDL, Japan, 2518 2520 o Philippe Jacquet, INRIA, France, 2522 o Monden Kazuya, Hitachi SDL, Japan, 2523 2525 Appendix G. Acknowledgments 2527 The authors would like to acknowledge the team behind OLSR [RFC3626], 2528 including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot 2529 (both at INRIA, France), and Amir Qayyum (Center for Advanced 2530 Research in Engineering, Pakistan) for their contributions. 2532 The authors would like to gratefully acknowledge the following people 2533 for intense technical discussions, early reviews and comments on the 2534 specification and its components (listed alphabetically): 2536 o Brian Adamson (NRL) 2538 o Teco Boot (Infinity Networks) 2540 o Florent Brunneau (LIX) 2542 o Ian Chakeres (Motorola) 2544 o Alan Cullen (BAE Systems) 2546 o Ulrich Herberg (LIX) 2548 o Joe Macker (NRL) 2550 o Yasunori Owada (Niigata University) 2552 o Charlie E. Perkins (WiChorus) 2554 o Andreas Schjonhaug (LIX) 2556 and the entire IETF MANET working group. 2558 Authors' Addresses 2560 Thomas Heide Clausen 2561 LIX, Ecole Polytechnique, France 2563 Phone: +33 6 6058 9349 2564 EMail: T.Clausen@computer.org 2565 URI: http://www.thomasclausen.org/ 2567 Christopher M. Dearlove 2568 BAE Systems Advanced Technology Centre 2570 Phone: +44 1245 242194 2571 EMail: chris.dearlove@baesystems.com 2572 URI: http://www.baesystems.com/ 2574 Justin W. Dean 2575 Naval Research Laboratory 2577 Phone: +1 202 767 3397 2578 EMail: jdean@itd.nrl.navy.mil 2579 URI: http://pf.itd.nrl.navy.mil/ 2581 Cedric Adjih 2582 INRIA Rocquencourt 2584 Phone: +33 1 3963 5215 2585 EMail: Cedric.Adjih@inria.fr 2586 URI: http://menetou.inria.fr/~adjih/ 2588 Full Copyright Statement 2590 Copyright (C) The IETF Trust (2008). 2592 This document is subject to the rights, licenses and restrictions 2593 contained in BCP 78, and except as set forth therein, the authors 2594 retain all their rights. 2596 This document and the information contained herein are provided on an 2597 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2598 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2599 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2600 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2601 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2602 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2604 Intellectual Property 2606 The IETF takes no position regarding the validity or scope of any 2607 Intellectual Property Rights or other rights that might be claimed to 2608 pertain to the implementation or use of the technology described in 2609 this document or the extent to which any license under such rights 2610 might or might not be available; nor does it represent that it has 2611 made any independent effort to identify any such rights. Information 2612 on the procedures with respect to rights in RFC documents can be 2613 found in BCP 78 and BCP 79. 2615 Copies of IPR disclosures made to the IETF Secretariat and any 2616 assurances of licenses to be made available, or the result of an 2617 attempt made to obtain a general license or permission for the use of 2618 such proprietary rights by implementers or users of this 2619 specification can be obtained from the IETF on-line IPR repository at 2620 http://www.ietf.org/ipr. 2622 The IETF invites any interested party to bring to its attention any 2623 copyrights, patents or patent applications, or other proprietary 2624 rights that may cover technology that may be required to implement 2625 this standard. Please address the information to the IETF at 2626 ietf-ipr@ietf.org.