idnits 2.17.1 draft-ietf-manet-packetbb-04.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 1291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1315. 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 412 has weird spacing: '...-length is a ...' == Line 421 has weird spacing: '...-length is a ...' == Line 429 has weird spacing: '...-length is a ...' == Line 529 has weird spacing: '...ex-stop are v...' == Line 556 has weird spacing: '...-values is a ...' -- 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 (January 2007) is 6310 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 3513 (ref. '2') (Obsoleted by RFC 4291) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) T. Clausen 3 Internet-Draft LIX, Ecole Polytechnique, France 4 Intended status: Standards Track C. Dearlove 5 Expires: July 5, 2007 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 C. Adjih 10 INRIA Rocquencourt 11 January 2007 13 Generalized MANET Packet/Message Format 14 draft-ietf-manet-packetbb-04 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 July 5, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document specifies a multi-message packet format that may be 48 used by mobile ad hoc network routing and other protocols. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 55 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 56 5. Signaling Framework . . . . . . . . . . . . . . . . . . . . . 8 57 5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5.2.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 11 60 5.3. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 12 61 5.3.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 5.3.2. Constraints . . . . . . . . . . . . . . . . . . . . . 16 63 5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 6. TLV specification . . . . . . . . . . . . . . . . . . . . . . 17 65 6.1. Address Block TLV Specification . . . . . . . . . . . . . 17 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 71 Appendix A. Illustrations . . . . . . . . . . . . . . . . . . . 21 72 Appendix A.1. Packet . . . . . . . . . . . . . . . . . . . . . . . 21 73 Appendix A.2. Message and Padding . . . . . . . . . . . . . . . . 23 74 Appendix A.3. Message Body . . . . . . . . . . . . . . . . . . . . 25 75 Appendix A.4. Address Block . . . . . . . . . . . . . . . . . . . 26 76 Appendix A.5. TLV Block . . . . . . . . . . . . . . . . . . . . . 28 77 Appendix A.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . 28 78 Appendix B. Complete Example . . . . . . . . . . . . . . . . . . 31 79 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 33 80 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 34 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 82 Intellectual Property and Copyright Statements . . . . . . . . . . 36 84 1. Introduction 86 This document specifies the syntax of a general purpose multi-message 87 packet format for information exchange between MANET routers. 88 Messages consist of a message header, which is designed for control 89 of message dissemination, and a message body, which contains protocol 90 information. Only the syntax of the message body is specified. All 91 syntactical entities, including messages and packets, are specified 92 using regular expressions. 94 This document specifies: 96 o A packet format, allowing zero or more messages to be contained 97 within a single transmission, and optionally including a packet 98 header. 100 o A message format, where a message is composed of a message header 101 and a message body. 103 o A message header format containing *all* necessary information to 104 allow a node to make forwarding decisions without inspecting and 105 processing the message body. Message header information permits 106 single- and multi-hop message diffusion. 108 o A message body format, containing attributes associated with the 109 message or the originator of the message, as well as blocks of 110 addresses with associated attributes. 112 o An address block format, where an address block represents sets of 113 addresses in a compact (compressed) form. 115 o A generalized type-length-value (TLV) format representing 116 attributes. Multiple TLVs can be included and associated with a 117 packet, a message, an address, or a set of addresses. 119 The specification has been explicitly designed with the following 120 properties in mind: 122 Parsing logic - the regular expression specification facilitates 123 generic, protocol independent, parsing logic. 125 Extensibility - packets and messages defined by a protocol using 126 this specification are extensible through defining new message 127 types and new TLVs. Full backward compatibility can be 128 maintained. 130 Efficiency - when reported addresses share common bit sequences 131 (e.g. prefixes or IPv6 interface identifiers) the address block 132 representation allows for a compact representation. 134 Separation of forwarding and processing - duplicate detection and 135 controlled scope message forwarding decisions can be made solely 136 using information contained in the message header, without 137 processing the message body. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119. [1]. 145 Additionally, this document uses the following terminology: 147 Packet - the top level entity in this specification. Packets are 148 transmitted over a single logical hop and are not forwarded. A 149 packet contains zero or more messages, and may contain a packet 150 header. 152 Message - the fundamental entity carrying protocol information, in 153 the form of addresses and TLVs. Messages are transmitted in 154 packets, and may be forwarded based on their header information. 156 Address - an address of the same length as the source IP address in 157 the IP datagram carrying the packet. 159 TLV - a Type-Length-Value structure. This is a generic way in which 160 an attribute can be represented and correctly parsed, without the 161 parser having to understand the attribute. 163 element - a syntactic entity defined in the regular expression 164 specification, represented using the notation . 166 - if is an 8 or 16 bit field then is also used to 167 represent the value of that field. 169 ? - zero or one occurrences of the preceding element. 171 * - zero or more occurrences of the preceding element. 173 bar - a variable, usually obtained through calculations based on the 174 value(s) of field(s). Variables are introduced into the 175 specification solely as a means to clarify the description. 177 address-length - a variable whose value is the length of an address 178 in octets, it is 4 if using IPv4, 16 if using IPv6. 180 3. Applicability Statement 182 This specification describes a generic multi-message packet format, 183 for carrying MANET routing protocol signals. The specification has 184 been developed from that used by OLSR (The Optimized Link State 185 Routing Protocol) [4]. 187 The specification is designed specifically with IP (IPv4/IPv6) in 188 mind. All addresses within a control message are assumed to be of 189 the same size, deduced from IP. In the case of mixed IPv6 and IPv4 190 addresses, IPv4 addresses are carried in IPv6 as specified in [2]. 192 The messages defined by this specification are designed to carry 193 routing protocol signals between MANET routers, and to support scope 194 limited diffusion, as well as point to point signaling in a multi-hop 195 network. 197 The packets defined by this specification are designed to carry a 198 number of messages between in a single transmission. The packets may 199 use any transport mechanism (unicast, multicast) and transport 200 protocol (TCP, UDP, ...) appropriate to the protocol using this 201 specification and may travel over a single logical hop which might 202 consist of one or more IP hops. When the diffusion mechanism enabled 203 by this specification is employed, UDP may be most appropriate. 205 This specification is particularly appropriate for extensible 206 protocols. It offers external extensibility in the form of new 207 message types. It offers internal extensibility in the form of TLVs, 208 which may be added to existing message types. 210 A protocol using the multi-message packet format defined by this 211 specification may constrain the syntax (for example requiring a full 212 message header) and features (for example specifying the suggested 213 diffusion mechanism) that it will employ. 215 4. Protocol Overview and Functioning 217 This specification does not describe a protocol. It describes a 218 packet format, which may be used by any mobile ad hoc network routing 219 or other protocol. 221 5. Signaling Framework 223 This section provides syntactical specification of a packet, 224 represented by the element and the elements from which it is 225 composed. The specification is given in the form of regular 226 expressions. Illustrations of specified elements are given in 227 Appendix A. 229 The length of a is obtained as the size of the payload of 230 the transport protocol employed. 232 5.1. Packets 234 is defined by: 236 = {*}? 237 {*}* 239 where is defined in Section 5.2, and is defined 240 in Section 5.4. The packet is parsed until all octets are used. 242 is defined by: 244 = 245 246 ? 247 ? 249 where: 251 is an 8 bit field with all bits cleared ('0'). This field 252 serves to identify that the packet starts with a packet header. 254 is an 8 bit field, specifying the composition of 255 the packet header: 257 bit 0 (pnoseqnum): if cleared ('0'), then the packet header 258 contains a . If set ('1'), then the packet 259 header does not include a . 261 bit 1 (ptlv): if cleared ('0'), then the packet header does not 262 include a TLV block. If set ('1'), then the packet header 263 includes a TLV block. 265 bits 2-7: are RESERVED, and MUST each be cleared ('0') to be in 266 conformance with this version of the specification. 268 is omitted if the pnoseqnum bit is set ('1'), 269 otherwise is a 16 bit field, specifying a packet sequence number. 271 is omitted if the ptlv bit is cleared ('0'), and is 272 otherwise defined in Section 5.3. 274 Note that since the message type zero is reserved (see Section 7), 275 the presence or absence of a packet header can be determined by 276 inspecting the first octet of the packet. 278 5.2. Messages 280 Information is carried through messages. Messages contain: 282 o A message header. 284 o A message TLV block that contains zero or more TLVs, associated 285 with the whole message. 287 o Zero or more address blocks, each containing one or more 288 addresses. 290 o A TLV block, containing zero or more TLVs, following each address 291 block. 293 is defined by: 295 = 296 297 {}* 299 = 300 301 302 304 = ? 305 ? 306 ? 307 ? 309 where: 311 is defined in Section 5.3. 313 is defined in Section 5.2.1. 315 is an 8 bit field, specifying the type of message. A 316 type with all bits cleared ('0') MUST NOT be used. 318 is an 8 bit field, specifying the interpretation of 319 the remainder of the message header: 321 bit 0 (noorig): if cleared ('0'), then and 322 are included in . If set 323 ('1'), then and are not 324 included in ; this reduced message header does 325 not provide for duplicate suppression. 327 bit 1 (nohops): if cleared ('0'), then and are included in the . If set ('1'), 329 then and are not included in the ; this reduced message header does not provide for 331 scope-delimited forwarding. 333 bit 2 (typedep): if cleared ('0'), then the message sequence 334 number in the message is type-independent. If set ('1'), then 335 the message sequence number contained in the message is type 336 dependent (the message originator maintains a sequence number 337 specific to ). This bit MUST be cleared ('0') if the 338 noorig bit is set ('1'). 340 bits 3-7: are RESERVED and MUST each be cleared ('0') to be in 341 conformance with this version of the specification. 343 is a 16 bit field, specifying the size of the , 344 counted in octets. 346 is an identifier of length equal to address- 347 length, which serves to uniquely identify the node that originated 348 the message. 350 is an 8 bit field, which contains the maximum number of 351 logical hops a message should be further transmitted. 353 is an 8 bit field, which contains the number of logical 354 hops a message has traveled. 356 is a 16 bit field, which contains a unique number, 357 generated by the originator node. The , , and, if the typedep bit in the field 359 is set, the of a message serves to uniquely identify 360 the message in the network. 362 5.2.1. Address Blocks 364 An address is specified as a sequence of address-length octets of the 365 form head:mid:tail. An address block is an ordered set of addresses 366 sharing the same head and tail, and having individual mids. 368
is defined by: 370 = 371 372 ? 373 ? 374 ? 375 ? 376 * 378 where: 380 is an 8 bit field containing the number of addresses 381 represented in the address block, which MUST NOT be zero. 383 is an 8 bit field specifying the interpretation of 384 the remainder of the address block: 386 bit 0 (nohead): if cleared ('0'), then is included 387 in , and may be included in . If set ('1'), then and are not 389 included in . 391 bit 1 (notail) and bit 2 (zerotail): MUST NOT both be set ('1'). 392 Otherwise, they are interpreted according to Table 1. 394 +--------+----------+---------------+-----------------+ 395 | notail | zerotail | | | 396 +--------+----------+---------------+-----------------+ 397 | 0 | 0 | included | may be included | 398 | | | | | 399 | 0 | 1 | included | not included | 400 | | | | | 401 | 1 | 0 | not included | not included | 402 +--------+----------+---------------+-----------------+ 404 Table 1 406 bits 3-7: are RESERVED and MUST each be cleared ('0') to be in 407 accordance with this version of the specification. 409 if present is an 8 bit field, which contains the total 410 length (in octets) of the head of all of the addresses. 412 head-length is a variable, defined to equal if 413 present, or 0 otherwise. 415 is omitted if head-length == 0, otherwise it is a field of 416 the head-length leftmost octets of all the addresses. 418 if present is an 8 bit field, which contains the total 419 length (in octets) of the tail of all of the addresses. 421 tail-length is a variable, defined to equal if 422 present, or 0 otherwise. 424 is omitted if tail-length == 0 or if the zerotail bit is set 425 ('1'), otherwise it is a field of the tail-length rightmost octets 426 of all the addresses. If the zerotail bit is set ('1') then the 427 tail-length rightmost octets of all the addresses are all 0. 429 mid-length is a variable, which MUST be non-negative, defined by: 431 * mid-length = address-length - head-length - tail-length 433 is omitted if mid-length == 0, otherwise each is a field 434 of length mid-length octets, representing the mid of the 435 corresponding address in the address block. 437 5.3. TLVs and TLV Blocks 439 A TLV block is defined by: 441 = 442 * 444 where: 446 is a 16 bit field, which contains the total length (in 447 octets) of the immediately following elements. 449 is defined in Section 5.3.1. 451 5.3.1. TLVs 453 There are three kinds of TLV, each represented by an element : 455 o A packet TLV, included in a packet header. 457 o A message TLV, included in a message before all address blocks. 459 o An address block TLV, included in a TLV block following an address 460 block. An address block TLV applies to: 462 * all addresses in the address block; OR 464 * any continuous sequence of addresses in the address block; OR 466 * a single address in the address block. 468 is defined by: 470 = 471 472 ? 473 ? 474 ? 475 ? 477 where: 479 is an 8 bit field, specifying the type of the TLV, 480 specific to the TLV kind (i.e. packet- message- or address block 481 TLV). 483 is an 8 bit field specifying the interpretation of 484 the remainder of the TLV: 486 bit 0 (extended) and bit 1 (novalue): MUST NOT both be set ('1'). 487 Otherwise, they are interpreted according to Table 2. 489 +----------+---------+--------------+--------------+ 490 | extended | novalue | | | 491 +----------+---------+--------------+--------------+ 492 | 0 | 0 | 8 bits | included | 493 | | | | | 494 | 0 | 1 | not included | not included | 495 | | | | | 496 | 1 | 0 | 16 bits | included | 497 +----------+---------+--------------+--------------+ 499 Table 2 501 bit 2 (noindex) and bit 3 (singleindex): MUST NOT both be set 502 ('1'). The former MUST be set ('1') and the latter MUST be 503 cleared ('0') for packet or message TLVs. They are interpreted 504 according to Table 3. 506 +---------+-------------+---------------+--------------+ 507 | noindex | singleindex | | | 508 +---------+-------------+---------------+--------------+ 509 | 0 | 0 | included | included | 510 | | | | | 511 | 0 | 1 | included | not included | 512 | | | | | 513 | 1 | 0 | not included | not included | 514 +---------+-------------+---------------+--------------+ 516 Table 3 518 bit 4 (multivalue): this bit serves to specify how the 519 field is interpreted, as specified below. This bit MUST be 520 cleared ('0') for packet or message TLVs, if the singleindex 521 bit is set ('1'), or if the novalue bit is set ('1'). 523 bits 5-7: are RESERVED and MUST each be cleared ('0') to be in 524 accordance with this version of the specification. 526 and when present are each an 8 bit field, 527 interpreted as follows: 529 index-start and index-stop are variables, defined according to 530 Table 4. The variable end-index is defined as follows: 532 + For message and packet TLVs: 534 - end-index = 0 536 + For address block TLVs: 538 - end-index = - 1 540 +---------+-------------+---------------+---------------+ 541 | noindex | singleindex | index-start = | index-stop = | 542 +---------+-------------+---------------+---------------+ 543 | 0 | 0 | | | 544 | | | | | 545 | 0 | 1 | | | 546 | | | | | 547 | 1 | 0 | 0 | end-index | 548 +---------+-------------+---------------+---------------+ 550 Table 4 552 For an address block TLV, the TLV applies to the addresses from 553 position index-start to position index-stop (inclusive) in the 554 address block, where the first address has position zero. 556 number-values is a variable, defined by: 558 + number-values = index-stop - index-start + 1 560 is omitted or is a 8 or 16 bit field according to Table 2. 561 If present it MUST NOT be zero. If the multivalue bit is set 562 ('1') then MUST be an integral multiple of number-values, 563 and the variable single-length is defined by: 565 * single-length = / number-values 567 If the multivalue bit is cleared ('0'), then the variable single- 568 length is defined by: 570 * single-length = 572 if present (see Table 2) is a field of length 573 octets. In an address block TLV, is associated with the 574 addresses from index-start to index-stop, inclusive. If the 575 multivalue bit is cleared ('0') then the whole of this field is 576 associated with each of the indicated addresses. If the 577 multivalue bit is set ('1') then this field is divided equally 578 into number-values fields, each of length single-length octets and 579 these are associated, in order, with the indicated addresses. 581 5.3.2. Constraints 583 TLVs in the same TLV block MUST be sorted in ascending TLV type 584 order. 586 Two or more TLVs of the same type associated with the same address 587 block MUST NOT both cover any address. 589 TLVs of the same type associated with the same address block MUST be 590 sorted in ascending index-start order. 592 5.4. Padding 594 Packet headers and messages can be padded to ensure 32 bit alignment 595 of each message contained within the packet and of the overall packet 596 length. 598 All elements are an integer multiple of octets, hence padding can be 599 accomplished by inserting an integer number of elements 600 after the element that is to be 32 bit aligned. 602 The number of elements required to achieve this 32 bit 603 alignment is the smallest number (0 to 3) that, when added to the 604 size of the preceding elements, produces an integer multiple of 4. 606 is an 8 bit field with all bits cleared ('0'). 608 There is no need to indicate if padding is included, since a will always precede either a message or the end of the packet. 610 In the former case, the start of a message is indicated by the next 611 non-zero octet parsed. 613 The padding after a message may be freely changed when a message is 614 forwarded without affecting the message. 616 6. TLV specification 618 This document specifies one address block TLV, which is included to 619 allow a standardized way of representing network addresses. 621 6.1. Address Block TLV Specification 623 +----------------------+------+--------+----------------------------+ 624 | Name | Type | Length | Value | 625 +----------------------+------+--------+----------------------------+ 626 | PREFIX_LENGTH | 0 | 8 bits | Indicates that the address | 627 | | | | is a network address, | 628 | | | | rather than a host | 629 | | | | address. The value is the | 630 | | | | length of the | 631 | | | | prefix/netmask. | 632 +----------------------+------+--------+----------------------------+ 634 Table 5 636 An address in an address block without an associated PREFIX_LENGTH 637 TLV may be considered to have a prefix length equal to the address 638 length in bits (i.e. address-length times 8). 640 7. IANA Considerations 642 A new registry for message types must be created with initial 643 assignments as specified in Table 6. Future values in the range 644 5-127 can be allocated using standards action [3]. Additionally, 645 values in the range 128-255 are reserved for private/local use. 647 A new registry for packet TLV types must be created, with no initial 648 assignments. Future values in the range 0-127 can be allocated using 649 standards action [3]. Additionally, values in the range 128-255 are 650 reserved for private/local use. 652 A new registry for message TLV types must be created with no initial 653 assignments. Future values in the range 0-127 can be allocated using 654 standards action [3]. Additionally, values in the range 128-255 are 655 reserved for private/local use. 657 A new registry for address block TLV types must be created with 658 initial assignments as specified in Table 7. Future values in the 659 range 1-127 can be allocated using standards action [3]. 660 Additionally, values in the range 128-255 are reserved for private/ 661 local use. 663 +-------+----------------------------------------+ 664 | Value | Description | 665 +-------+----------------------------------------+ 666 | 0 | MUST NOT be allocated. | 667 | | | 668 | 1-4 | RESERVED | 669 +-------+----------------------------------------+ 671 Table 6 673 Message type 0 MUST NOT be allocated because a zero-octet signifies a 674 packet header and zero-octets are used for padding. Message types 1 675 to 4 are reserved because they are used by OLSR [4], which uses a 676 compatible packet/message header format. 678 +--------------------+-------+--------------------------------------+ 679 | Mnemonic | Value | Description | 680 +--------------------+-------+--------------------------------------+ 681 | PREFIX_LENGTH | 0 | Indicates that associated addresses | 682 | | | are network addresses, with given | 683 | | | prefix length. | 684 +--------------------+-------+--------------------------------------+ 686 Table 7 688 8. Security Considerations 690 Messages are designed to be carriers of protocol information and MAY, 691 at each hop, be forwarded and/or processed according to the 692 information in the message header by the protocol using this 693 specification. If forwarded messages are unchanged by this protocol, 694 then end-to-end security MAY be implemented, between nodes with an 695 existing security association, by including a suitable message TLV 696 containing a cryptographic signature to the message. Since and are the only fields that may be modified when 698 such a message is forwarded, this signature can be calculated based 699 on the entire message, including the message header, with the and fields set to zero ('0') if present. 702 Packets are designed to carry a number of messages between 703 neighboring nodes in a single transmission and over a single logical 704 hop. Hop-by-hop packet level security MAY be implemented, between 705 nodes with an existing security association, by including a suitable 706 packet TLV containing a cryptographic signature to the packet. Since 707 packets are received as transmitted, this signature can be calculated 708 based on the entire packet, or on parts thereof as appropriate. 710 9. References 712 9.1. Normative References 714 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 715 Levels", RFC 2119, BCP 14, March 1997. 717 [2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 718 Addressing Architecture", RFC 3513, April 2003. 720 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 721 Considerations Section in RFCs", October 1998. 723 9.2. Informative References 725 [4] Clausen, T. and P. Jacquet, "The Optimized Link State Routing 726 Protocol", RFC 3626, October 2003. 728 Appendix A. Illustrations 730 This informative appendix illustrates the elements, which are 731 normatively specified in Section 5 using regular expressions. 733 Bits labeled Reserved or Resv are cleared ('0'). Bits labeled N and 734 M may be cleared ('0') or set ('1'). Octets labeled Padding are 735 cleared ('0'), and are optional. 737 Appendix A.1. Packet 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | | 745 | Message + Padding | 746 | | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | | 749 : ... : 750 | | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | | 753 | Message + Padding | 754 | | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 |0 0 0 0 0 0 0 0| Reserved |0|1| Padding | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | | 763 | Message + Padding | 764 | | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | | 767 : ... : 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | | 771 | Message + Padding | 772 | | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 |0 0 0 0 0 0 0 0| Reserved |1|0| Packet Sequence Number | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | | 780 | Packet TLV Block | 781 | | 782 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | | Padding | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | | 786 | Message + Padding | 787 | | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | | 790 : ... : 791 | | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | | 794 | Message + Padding | 795 | | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 |0 0 0 0 0 0 0 0| Reserved |1|1| | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 803 | | 804 | Packet TLV Block | 805 | | 806 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | | Padding | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | | 810 | Message + Padding | 811 | | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | | 814 : ... : 815 | | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | | 818 | Message + Padding | 819 | | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 0 1 2 3 822 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 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | | 825 | Message + Padding | 826 | | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | | 829 : ... : 830 | | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | | 833 | Message + Padding | 834 | | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 Appendix A.2. Message and Padding 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Message Type | Resv |N|0|0| Message Size | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Originator Address | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Hop Limit | Hop Count | Message Sequence Number | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | | 849 | Message Body | 850 | | 851 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | | Padding | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 0 1 2 3 856 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 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Message Type | Resv |0|0|1| Message Size | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Hop Limit | Hop Count | | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 862 | | 863 | Message Body | 864 | | 865 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | | Padding | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 0 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Message Type | Resv |N|1|0| Message Size | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Originator Address | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Message Sequence Number | | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 877 | | 878 | Message Body | 879 | | 880 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | | Padding | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Message Type | Resv |0|1|1| Message Size | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | | 890 | Message Body | 891 | | 892 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | | Padding | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 Appendix A.3. Message Body 898 0 1 2 3 899 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 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | | 902 | Message TLV Block | 903 | +-+-+-+-+-+-+-+-+ 904 | | | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 906 | | 907 | Address Block | 908 | | 909 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | | | 911 +-+-+-+-+-+-+-+-+ | 912 | Address TLV Block | 913 | | 914 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | | | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 917 | | 918 : ... : 919 | | 920 | +-+-+-+-+-+-+-+-+ 921 | | | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 923 | | 924 | Address Block | 925 | | 926 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | | | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 929 | | 930 | Address TLV Block | 931 | | 932 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 Appendix A.4. Address Block 938 0 1 2 3 939 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 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Number Addrs | Resv |0|0|0| Head Length | Head | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Head (cont) | Tail Length | Tail | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Mid | | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 947 | | 948 : ... : 949 | | 950 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | | Mid | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 0 1 2 3 955 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 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Number Addrs | Resv |0|0|1| Tail Length | Tail | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Tail (cont) | Mid | | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 961 | | 962 : ... : 963 | | 964 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | | Mid | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 0 1 2 3 969 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 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Number Addrs | Resv |0|1|0| Head Length | Head | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Head (cont) | Mid | | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 975 | | 976 : ... : 977 | | 978 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | | Mid | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 0 1 2 3 982 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 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Number Addrs | Resv |0|1|1| Mid | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Mid (cont) | | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 988 | | 989 : ... : 990 | | 991 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | | Mid | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Mid (cont) | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 0 1 2 3 998 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 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Number Addrs | Resv |1|0|0| Head Length | Head | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Head (cont) | Tail Length | Mid | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | | 1005 : ... : 1006 | | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | Mid | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 0 1 2 3 1012 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 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Number Addrs | Resv |1|0|1| Tail Length | Mid | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Mid (cont) | | 1017 +-+-+-+-+-+-+-+-+ | 1018 | | 1019 : ... : 1020 | | 1021 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | | Mid | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 Appendix A.5. TLV Block 1027 0 1 2 3 1028 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 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Length | | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1032 | | 1033 | TLV | 1034 | +-+-+-+-+-+-+-+-+ 1035 | | | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1037 | | 1038 : ... : 1039 | | 1040 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | | | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1043 | | 1044 | TLV | 1045 | +-+-+-+-+-+-+-+-+ 1046 | | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 Appendix A.6. TLV 1051 0 1 2 3 1052 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 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Type |Resv |M|0|0|0|0| Index Start | Index Stop | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Length | | 1057 +-+-+-+-+-+-+-+-+ | 1058 | Value | 1059 | | 1060 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | | 1062 +-+-+-+-+-+-+-+-+ 1063 0 1 2 3 1064 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 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Type |Resv |M|0|0|0|1| Index Start | Index Stop | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Length | | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1070 | | 1071 | Value | 1072 | | 1073 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | | 1075 +-+-+-+-+-+-+-+-+ 1077 0 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Type |Resv |0|0|0|1|0| Index Start | Index Stop | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 0 1 2 3 1084 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 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | Type |Resv |M|0|1|0|0| Length | | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1088 | | 1089 | Value | 1090 | | 1091 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | | 1093 +-+-+-+-+-+-+-+-+ 1095 0 1 2 3 1096 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 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Type |Resv |M|0|1|0|1| Length | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | | 1101 | Value | 1102 | | 1103 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | | 1105 +-+-+-+-+-+-+-+-+ 1106 0 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Type |Resv |0|0|1|1|0| 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 0 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Type |Resv |0|1|0|0|0| Index Start | Length | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | | 1118 | Value | 1119 | | 1120 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | | 1122 +-+-+-+-+-+-+-+-+ 1124 0 1 2 3 1125 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 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Type |Resv |0|1|0|0|1| Index Start | Length | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Length (cont) | | 1130 +-+-+-+-+-+-+-+-+ | 1131 | | 1132 | Value | 1133 | | 1134 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | | 1136 +-+-+-+-+-+-+-+-+ 1138 0 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Type |Resv |0|1|0|1|0| Index Start | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 Appendix B. Complete Example 1146 An example packet, using IPv4 addresses (length four octets) is 1147 shown. This packet has a header, with a packet sequence number but 1148 no packet TLV block, and contains a single message. The message has 1149 a complete message header, a message TLV block of content length 9 1150 octets containing a single TLV (with the noindex bit of its semantics 1151 octet set and value length 6 octets) and then two address blocks each 1152 with a following TLV block. The first address block contains 3 1153 addresses, has the notail bit of the its semantics octet set, and has 1154 head length 2 octets, hence mid length two octets. It is followed by 1155 a TLV block with content length 9 octets containing two TLVs. The 1156 first of these TLVs has the noindex bit of its semantics octet set 1157 and has a single value of length 2 octets, which applies to all of 1158 the addresses in the preceding address block. The second of these 1159 TLVs has the novalue bit of its semantics octet set and hence has no 1160 length or value fields (it does have index fields, which indicate 1161 those addresses this TLV applies to). The second address block 1162 contains 2 addresses, has the nohead and zerotail bits of its 1163 semantics octet set, and has tail length 2 octets, hence mid length 1164 two octets. The two tail octets of each address are zero. It is 1165 followed by a TLV block of content length 5 octets. This TLV block 1166 contains a single TLV of type PREFIX_LENGTH that has the multivalue 1167 and noindex bits of its semantics octet set and a value field length 1168 of 2 octets, indicating two values each of one octet length. There 1169 is one final padding octet that is not included in the message length 1170 of 59 octets. 1172 0 1 2 3 1173 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 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Message Type | Resv |N|0|0|0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 1| 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Originator Address | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Hop Limit | Hop Count | Message Sequence Number | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type |Resv |0|0|1|0|0| 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 |0 0 0 0 0 1 1 0| Value | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Value (cont) |0 0 0 0 0 0 1 1| 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0| Head | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | Mid | Mid | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | Mid |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | TLV Type |Resv |0|0|1|0|0|0 0 0 0 0 0 1 0| Value | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Value (cont) | TLV Type |Resv |0|0|0|1|0| Index Start | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | Index Stop |0 0 0 0 0 0 1 0|0 0 0 0 0 1 0 1|0 0 0 0 0 0 1 0| 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Mid | Mid | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| PREFIX_LENGTH |Resv |1|0|1|0|0| 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 |0 0 0 0 0 0 1 0| Value0 | Value1 |0 0 0 0 0 0 0 0| 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 Appendix C. Contributors 1210 This specification is the result of the joint efforts of the 1211 following contributors from the OLSRv2 Design Team -- listed 1212 alphabetically. 1214 o Cedric Adjih, INRIA, France, 1216 o Emmanuel Baccelli, Hitachi Labs Europe, France, 1217 1219 o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, 1220 1222 o Justin W. Dean, NRL, USA 1224 o Christopher Dearlove, BAE Systems, UK, 1225 1227 o Satoh Hiroki, Hitachi SDL, Japan, 1229 o Philippe Jacquet, INRIA, France, 1231 o Monden Kazuya, Hitachi SDL, Japan, 1233 Appendix D. Acknowledgements 1235 The authors would like to acknowledge the team behind OLSRv1, as 1236 specified in RFC 3626, including Anis Laouiti, Pascale Minet, Laurent 1237 Viennot (all at INRIA, France), and Amir Qayyum (Center for Advanced 1238 Research in Engineering, Pakistan) for their contributions. 1240 The authors would like to gratefully acknowledge the following people 1241 for intense technical discussions, early reviews and comments on the 1242 specification and its components: Joe Macker (NRL), Alan Cullen (BAE 1243 Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), Andreas 1244 Schjonhaug (LIX), Florent Brunneau (LIX), Yasunori Owada (Niigata 1245 University) and the entire IETF MANET working group. 1247 Authors' Addresses 1249 Thomas Heide Clausen 1250 LIX, Ecole Polytechnique, France 1252 Phone: +33 6 6058 9349 1253 Email: T.Clausen@computer.org 1254 URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ 1256 Christopher M. Dearlove 1257 BAE Systems Advanced Technology Centre 1259 Phone: +44 1245 242194 1260 Email: chris.dearlove@baesystems.com 1261 URI: http://www.baesystems.com/ocs/sharedservices/atc/ 1263 Justin W. Dean 1264 Naval Research Laboratory 1266 Phone: +1 202 767 3397 1267 Email: jdean@itd.nrl.navy.mil 1268 URI: http://pf.itd.nrl.navy.mil/ 1270 Cedric Adjih 1271 INRIA Rocquencourt 1273 Phone: +33 1 3963 5215 1274 Email: Cedric.Adjih@inria.fr 1275 URI: http://menetou.inria.fr/~adjih/ 1277 Full Copyright Statement 1279 Copyright (C) The IETF Trust (2007). 1281 This document is subject to the rights, licenses and restrictions 1282 contained in BCP 78, and except as set forth therein, the authors 1283 retain all their rights. 1285 This document and the information contained herein are provided on an 1286 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1287 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1288 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1289 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1290 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1291 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1293 Intellectual Property 1295 The IETF takes no position regarding the validity or scope of any 1296 Intellectual Property Rights or other rights that might be claimed to 1297 pertain to the implementation or use of the technology described in 1298 this document or the extent to which any license under such rights 1299 might or might not be available; nor does it represent that it has 1300 made any independent effort to identify any such rights. Information 1301 on the procedures with respect to rights in RFC documents can be 1302 found in BCP 78 and BCP 79. 1304 Copies of IPR disclosures made to the IETF Secretariat and any 1305 assurances of licenses to be made available, or the result of an 1306 attempt made to obtain a general license or permission for the use of 1307 such proprietary rights by implementers or users of this 1308 specification can be obtained from the IETF on-line IPR repository at 1309 http://www.ietf.org/ipr. 1311 The IETF invites any interested party to bring to its attention any 1312 copyrights, patents or patent applications, or other proprietary 1313 rights that may cover technology that may be required to implement 1314 this standard. Please address the information to the IETF at 1315 ietf-ipr@ietf.org. 1317 Acknowledgment 1319 Funding for the RFC Editor function is provided by the IETF 1320 Administrative Support Activity (IASA).