idnits 2.17.1 draft-ietf-manet-packetbb-02.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 on line 1266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1243. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1256. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 28, 2006) is 6482 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: 4 errors (**), 0 flaws (~~), 2 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 Expires: January 29, 2007 C. Dearlove 5 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 C. Adjih 10 INRIA Rocquencourt 11 July 28, 2006 13 Generalized MANET Packet/Message Format 14 draft-ietf-manet-packetbb-02 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 January 29, 2007. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . 27 77 Appendix A.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . 27 78 Appendix B. Complete Example . . . . . . . . . . . . . . . . . . 30 79 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 32 80 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 33 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 82 Intellectual Property and Copyright Statements . . . . . . . . . . 35 84 1. Introduction 86 Signaling in a MANET (mobile ad hoc network) routing protocol 87 consists, mainly, of stating IP addresses and attributes associated 88 with such IP addresses. Since this is a task common to many such 89 protocols, this specification presents a generalized packet format, 90 suitable for signaling. This format may be employed both by mobile 91 ad hoc network routing protocols and by other protocols with similar 92 requirements. 94 This document is a specification of a multi-message packet format. 95 Messages encapsulate protocol information (including addresses and 96 their attributes), and are themselves are encapsulated in packets. 97 The structure of addresses, attributes, messages, and packets is 98 specified via regular expressions. This specification gives the 99 syntax, but not the interpretation, of the information carried within 100 a packet, other than the header information which may be used to 101 control the dissemination of the messages. Packets are intended to 102 be encapsulated by a suitable transport protocol, typically UDP, and 103 carried over IP (IPv4 or IPv6). 105 This document specifies: 107 o A packet format, allowing zero or more messages to be contained 108 within a single transmission, and optionally including a packet 109 header. 111 o A message format, where a message is composed of a message header 112 and a message body. 114 o A message header format containing *all* necessary information to 115 allow a node to make forwarding decisions without inspecting and 116 processing the message body. Message header information permits 117 single- and multi-hop message diffusion. 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 with associated attributes. 123 o An address block format, where an address block represents sets of 124 addresses in a compact (compressed) form. 126 o A generalized type-length-value (TLV) format representing 127 attributes. Multiple TLVs can be included and associated with a 128 packet, a message, an address, or a set of addresses. 130 The specification has been explicitly designed with the following 131 properties in mind: 133 Parsing logic - the regular expression specification facilitates 134 generic, protocol independent, parsing logic. 136 Extensibility - packets and messages defined by a protocol using this 137 specification are extensible through defining new message types 138 and new TLVs. Full backward compatibility can be maintained. 140 Efficiency - when reported addresses share common bit sequences (e.g. 141 prefixes or IPv6 interface identifiers) the address block 142 representation allows for a compact representation. 144 Separation of forwarding and processing - duplicate detection and 145 controlled scope message forwarding decisions can be made solely 146 using information contained in the message header, without 147 processing the message body. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119. [1]. 155 Additionally, this document uses the following terminology: 157 Packet - the top level entity in this specification. Packets are 158 transmitted hop-by-hop and are not forwarded. A packet contains 159 zero or more messages, and may contain a packet header. 161 Message - the fundamental entity carrying protocol information, in 162 the form of addresses and TLVs. Messages are transmitted in 163 packets, and may be forwarded based on their header information. 165 Address - an address of the same type and length as the source IP 166 address in the IP datagram carrying the packet. 168 TLV - a Type-Length-Value structure. This is a generic way in which 169 an attribute can be represented and correctly parsed, without the 170 parser having to understand the attribute. 172 element - a syntactic entity defined in the regular expression 173 specification, represented using the notation . 175 - if is an 8 or 16 bit field then is also used to 176 represent the value of that field. 178 ? - zero or one occurrences of the preceding element. 180 * - zero or more occurrences of the preceding element. 182 + - one or more occurrences of the preceding element. 184 bar - a variable, usually obtained through calculations based on the 185 value(s) of field(s). Variables are introduced in the 186 specification solely as a means to clarify the description. 188 address-length - a variable whose value is the length of an address 189 in octets, it is 4 if using IPv4, 16 if using IPv6. 191 3. Applicability Statement 193 This specification describes a generic multi-message packet format, 194 for carrying MANET routing protocol signals. The specification has 195 been developed from that used by OLSR (The Optimized Link State 196 Routing Protocol) [4]. 198 The specification is designed specifically with IP (IPv4/IPv6) in 199 mind. All addresses within a control message are assumed to be of 200 the same size, deduced from IP. In the case of mixed IPv6 and IPv4 201 addresses, IPv4 addresses are carried in IPv6 as specified in [2]. 203 The packets defined by this specification may use any transport 204 protocol appropriate to the protocol using this specification. When 205 the diffusion mechanism enabled by this specification is employed, 206 UDP may be most appropriate. 208 This specification is particularly appropriate for extensible 209 protocols. It offers external extensibility in the form of new 210 message types. It offers internal extensibility in the form of TLVs, 211 which may be added to existing message types. 213 4. Protocol Overview and Functioning 215 This specification does not describe a protocol. It describes a 216 packet format, which may be used by any mobile ad hoc network routing 217 or other protocol. 219 5. Signaling Framework 221 This section provides syntactical specification of a packet, 222 represented by the element and the elements from which it is 223 composed. The specification is given in the form of regular 224 expressions. Illustrations of specified elements are given in 225 Appendix A. 227 The length of a is obtained as the size of the payload of 228 the transport protocol employed. 230 5.1. Packets 232 is defined by: 234 = {*}? 235 {*}* 237 where is defined in Section 5.2, and is defined 238 in Section 5.4. The packet is parsed until all octets are used. 240 is defined by: 242 = 243 244 ? 245 ? 247 where: 249 is an 8 bit field with all bits cleared ('0'). This field 250 serves to identify that the packet starts with a packet header. 252 is an 8 bit field, specifying the composition of 253 the packet header: 255 bit 0 (pnoseqnum): if cleared ('0'), then the packet header 256 contains a . If set ('1'), then the packet 257 header does not include a . 259 bit 1 (ptlv): if cleared ('0'), then the packet header does not 260 include a TLV block. If set ('1'), then the packet header 261 includes a TLV block. 263 bits 2-7: are RESERVED, and MUST each be cleared ('0') to be in 264 conformance with this version of the specification. 266 is omitted if the pnoseqnum bit is set ('1'), 267 otherwise is a 16 bit field, specifying a packet sequence number. 269 is omitted if the ptlv bit is cleared ('0'), and is 270 otherwise defined in Section 5.3. 272 Note that since the message type zero is reserved (see Section 7), 273 the presence or absence of a packet header can be determined by 274 inspecting the first octet of the packet. 276 5.2. Messages 278 Information is carried through messages. Messages contain: 280 o A message header. 282 o A message TLV block that contains zero or more TLVs, associated 283 with the whole message. 285 o Zero or more address blocks, each containing one or more 286 addresses. 288 o A TLV block, containing zero or more TLVs, following each address 289 block. 291 is defined by: 293 = 294 295 {}* 297 = 298 299 300 302 = ? 303 ? 304 ? 305 ? 307 where: 309 is defined in Section 5.3. 311 is defined in Section 5.2.1. 313 is an 8 bit field, specifying the type of message. A type 314 with all bits cleared ('0') MUST NOT be used. The two most 315 significant bits have the following semantics: 317 bit 7 (msguser): message types with this bit cleared ('0') are 318 defined in this specification or can be allocated via standards 319 action. Message types with this bit set ('1') are reserved for 320 private/local use. 322 bit 6 (msgprot): for message types with the msg-user bit cleared 323 ('0'), this bit specifies, if cleared ('0'), that the message 324 type is protocol independent, i.e. is not specific to any one 325 protocol, or, if set ('1'), that the message type is specific 326 to the protocol for which it is defined. 328 is an 8 bit field, specifying the interpretation of 329 the remainder of the message header: 331 bit 0 (noorig): if cleared ('0'), then and 332 are included in . If set 333 ('1'), then and are not 334 included in ; this reduced message header does 335 not provide for duplicate suppression. 337 bit 1 (nohops): if cleared ('0'), then and 338 are included in the . If set ('1'), then 339 and are not included in the ; this reduced message header does not provide for 341 scope-delimited forwarding. 343 bit 2 (typedep): if cleared ('0'), then the message sequence 344 number in the message is type-independent. If set ('1'), then 345 the message sequence number contained in the message is type 346 dependent (the message originator maintains a sequence number 347 specific to ). This bit MUST be cleared ('0') if the 348 noorig bit is set ('1'). 350 bits 3-7: are RESERVED and MUST each be cleared ('0') to be in 351 conformance with this version of the specification. 353 is a 16 bit field, specifying the size of the , 354 counted in octets. 356 is an identifier of length equal to address- 357 length, which serves to uniquely identify the node that originated 358 the message. 360 is an 8 bit field, which contains the maximum number of 361 hops a message should be further transmitted. 363 is an 8 bit field, which contains the number of hops a 364 message has traveled. 366 is a 16 bit field, which contains a unique number, 367 generated by the originator node. The , , and, if the typedep bit in the field 369 is set, the of a message serves to uniquely identify 370 the message in the network. 372 5.2.1. Address Blocks 374 An address is specified as a sequence of octets of the form head:mid: 375 tail. An address block is an ordered set of addresses sharing the 376 same head and tail, and having individual mids. 378
is defined by: 380 = 381 382 ? 383 ? 384 ? 385 * 387 where: 389 is an 8 bit field containing the number of addresses 390 represented in the address block, which MUST NOT be zero. 392 is an 8 bit field, where: 394 bits 0-6: contain the length of the head. The corresponding 395 variable head-length is calculated by: 397 head-length = & 127 399 bit 7 (notail): if cleared ('0') then the address block contains a 400 . If set ('1') then no is included. 402 is omitted if head-length == 0, otherwise it is a field of the 403 head-length leftmost octets of all the addresses. 405 is omitted if the notail bit is set ('1'), otherwise it 406 is an 8 bit field, where: 408 bits 0-6: contain the length of the tail. The corresponding 409 variable tail-length is calculated by: 411 tail-length = & 127 413 bit 7 (zerotail): if cleared ('0'), then a is included. If 414 set ('1') then no is included, and the tail-length 415 rightmost octets of each address in the block are zero-valued. 417 If the is omitted then tail-length = 0. 419 is omitted if tail-length == 0 or the zerotail bit is set 420 ('1'), otherwise it is a field of the head-length leftmost octets 421 of all the addresses. 423 mid-length is a variable, which MUST be non-negative, calculated by: 425 mid-length = address-length - head-length - tail-length 427 is omitted if mid-length == 0, otherwise each is a field 428 of length mid-length octets, representing the mid of the 429 corresponding address in the address block. 431 5.3. TLVs and TLV Blocks 433 A TLV is defined by: 435 = 436 * 438 where: 440 is a 16 bit field, which contains the total length (in 441 octets) of the immediately following s. 443 is defined in Section 5.3.1. 445 5.3.1. TLVs 447 There are three kinds of TLV, each represented by an element : 449 o A packet TLV, included in a packet header. 451 o A message TLV, included in a message before all address blocks. 453 o An address block TLV, included in a TLV block following an address 454 block. An address block TLV applies to: 456 * all addresses in the address block; OR 458 * any continuous sequence of addresses in the address block; OR 460 * a single address in the address block. 462 is defined by: 464 = 465 466 ? 467 ? 468 ? 469 ? 471 where: 473 is an 8 bit field, specifying the type of the TLV. The 474 two most significant bits have the following semantics: 476 bit 7 (tlvuser): TLV types with this bit cleared ('0') are defined 477 in this specification or can be allocated via standards action. 478 TLV types with this bit set ('1') are reserved for private/ 479 local use. 481 bit 6 (tlvprot): for TLV types with the tlv-user bit cleared 482 ('0'), this bit specifies, if cleared ('0'), that the TLV type 483 is protocol independent, i.e. is not specific to any one 484 protocol, or, if set ('1'), that the TLV type is specific to 485 the protocol for which it is defined. 487 is an 8 bit field specifying the interpretation of 488 the remainder of the TLV: 490 bit 0 (extended) and bit 1 (novalue): must not both be set ('1'). 491 Otherwise, they are interpreted according to Table 1. 493 +----------+---------+--------------+--------------+ 494 | extended | novalue | length | value | 495 +----------+---------+--------------+--------------+ 496 | 0 | 0 | 8 bits | included | 497 | | | | | 498 | 0 | 1 | not included | not included | 499 | | | | | 500 | 1 | 0 | 16 bits | included | 501 +----------+---------+--------------+--------------+ 503 Table 1 505 bit 2 (noindex) and bit 3 (singleindex): must not both be set 506 ('1'). Otherwise, they are interpreted according to Table 2. 508 +---------+-------------+---------------+--------------+ 509 | noindex | singleindex | | | 510 +---------+-------------+---------------+--------------+ 511 | 0 | 0 | included | included | 512 | | | | | 513 | 0 | 1 | included | not included | 514 | | | | | 515 | 1 | 0 | not included | not included | 516 +---------+-------------+---------------+--------------+ 518 Table 2 520 bit 4 (multivalue): this bit serves to specify how the value field 521 is interpreted as specified below. This bit MUST be cleared 522 ('0') for packet or message TLVs, if the singleindex bit is set 523 ('1'), or if the novalue bit is set ('1'). 525 bits 5-7: are RESERVED and MUST each be cleared ('0') to be in 526 accordance with this version of the specification. 528 and are each an 8 bit field, interpreted 529 as follows: 531 index-start and index-stop are variables, defined according to 532 Table 3. The variable end-index is calculated as follows: 534 + For message and packet TLVs: 536 - end-index = 0 538 + For address block TLVs: 540 - end-index = - 1 542 +---------+-------------+---------------+---------------+ 543 | noindex | singleindex | index-start = | index-stop = | 544 +---------+-------------+---------------+---------------+ 545 | 0 | 0 | | | 546 | | | | | 547 | 0 | 1 | | | 548 | | | | | 549 | 1 | 0 | 0 | end-index | 550 +---------+-------------+---------------+---------------+ 552 Table 3 554 For an address block TLV, the TLV applies to the addresses from 555 position index-start to position index-stop (inclusive) in the 556 address block. 558 number-values is a variable, calculated by: 560 number-values = index-stop - index-start + 1 562 is omitted or is a 8 or 16 bit field according to Table 1. 563 If the multivalue bit is set ('1') then MUST be an 564 integral multiple of number-values, and the variable single-length 565 is calculated by: 567 single-length = / number-values 569 if the multivalue bit is cleared ('0'), the variable single-length 570 is defined by: 572 single-length = 574 if present (see Table 1), this is a field of length 575 octets. In an address block TLV, is associated with the 576 addresses from index-start to index-stop, inclusive. If the 577 multivalue bit is cleared ('0') then the whole of this field is 578 associated with each of the indicated addresses. If the 579 multivalue bit is set ('1') then this field is divided equally 580 into number-values fields, each of length single-length octets and 581 these are associated, in order, with the indicated addresses. 583 5.3.2. Constraints 585 TLVs in the same tlv block MUST be sorted in ascending TLV type 586 order. 588 Two or more TLVs of the same type associated with the same address 589 block MUST NOT both cover any address. 591 TLVs of the same type associated with the same address block MUST be 592 sorted in ascending index-start order. 594 5.4. Padding 596 Packet headers and messages can be padded to ensure 32 bit alignment 597 of each message contained within the packet and of the overall packet 598 length. 600 All syntactical elements are an integer multiple of octets, hence 601 padding can be accomplished by inserting an integer number of after the syntactical element that is to be 32 bit aligned. 604 The number of s required to achieve this 32 bit alignment 605 is calculated as the smallest number (0 to 3) that, when added to the 606 size of the preceding elements produces an integer multiple of 4. 608 is an 8 bit field with all bits cleared ('0'). 610 There is no need to indicate if padding is included, since a will always precede either a message or the end of the packet. 612 In the former case, the start of a message is indicated by the next 613 non-zero octet parsed. 615 The padding after a message may be freely changed when a message is 616 forwarded without affecting the message. 618 6. TLV specification 620 This document specifies one address block TLV, which is included to 621 allow a standardized way of representing network addresses. 623 6.1. Address Block TLV Specification 625 +----------------------+------+--------+----------------------------+ 626 | Name | Type | Length | Value | 627 +----------------------+------+--------+----------------------------+ 628 | PREFIX_LENGTH | 0 | 8 bits | Indicates that the address | 629 | | | | is a network address, | 630 | | | | rather than a host | 631 | | | | address. The value is the | 632 | | | | length of the | 633 | | | | prefix/netmask. | 634 +----------------------+------+--------+----------------------------+ 636 Table 4 638 An address in an address block without an associated PREFIX_LENGTH 639 TLV may be considered to have a prefix length equal to the address 640 length (in bits). 642 7. IANA Considerations 644 A new registry for message types must be created with initial 645 assignments as specified in Table 5. Future values in the range 646 5-127 of the Message Type can be allocated using standards action 647 [3]. Additionally, values in the range 128-255 are reserved for 648 private/local use. 650 A new registry for packet TLV types must be created, with no initial 651 assignments. Future values in the range 0-127 of the Message Type 652 can be allocated using standards action [3]. Additionally, values in 653 the range 128-255 are reserved for private/local use. 655 A new registry for message TLV types must be created with no initial 656 assignments. Future values in the range 0-127 of the Message Type 657 can be allocated using standards action [3]. Additionally, values in 658 the range 128-255 are reserved for private/local use. 660 A new registry for address block TLV types must be created with 661 initial assignments as specified in Table 6. Future values in the 662 range 1-127 of the Message Type can be allocated using standards 663 action [3]. Additionally, values in the range 128-255 are reserved 664 for private/local use. 666 +-------+----------------------------------------+ 667 | Value | Description | 668 +-------+----------------------------------------+ 669 | 0 | MUST NOT be allocated. | 670 | | | 671 | 1-4 | RESERVED | 672 +-------+----------------------------------------+ 674 Table 5 676 Message type 0 MUST NOT be allocated because a zero-octet signifies a 677 packet header and zero-octets are used for padding. Message types 1 678 to 4 are reserved because they are used by OLSR [4], which uses a 679 compatible packet/message header format. 681 +--------------------+-------+--------------------------------------+ 682 | Mnemonic | Value | Description | 683 +--------------------+-------+--------------------------------------+ 684 | PREFIX_LENGTH | 0 | Indicates that associated addresses | 685 | | | are network addresses, with given | 686 | | | prefix length. | 687 +--------------------+-------+--------------------------------------+ 689 Table 6 691 8. Security Considerations 693 Packets are designed to be transmitted only one hop, and not 694 forwarded. Hop-by-hop packet level security MAY be implemented, 695 between nodes with an existing security association, by including a 696 suitable packet TLV containing a cryptographic signature to the 697 packet. Since packets are received as transmitted, signatures can be 698 calculated based on the entire packet content, or on parts thereof as 699 appropriate. 701 Messages at each hop MAY be forwarded and/or processed, according to 702 the information in the message header and the protocol employing this 703 specification. With immutable messages, end-to-end security MAY be 704 implemented, between nodes with an existing security association, by 705 including a suitable message TLV containing a cryptographic signature 706 to the message. Since and are the only 707 fields that may be modified when such a message is forwarded, 708 signatures can be calculated based on the entire message, including 709 the message header with the and fields set to 710 zero ('0'). 712 9. References 714 9.1. Normative References 716 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 717 Levels", RFC 2119, BCP 14, March 1997. 719 [2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 720 Addressing Architecture", RFC 3513, April 2003. 722 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 723 Considerations Section in RFCs", October 1998. 725 9.2. Informative References 727 [4] Clausen, T. and P. Jacquet, "The Optimized Link State Routing 728 Protocol", RFC 3626, October 2003. 730 Appendix A. Illustrations 732 This informative appendix illustrates the elements, which are 733 normatively specified in Section 5 using regular expressions. 735 Bits labeled Reserved or Resv are cleared ('0'). Bits labeled N and 736 M may be cleared ('0') or set ('1'). Octets labeled Padding are 737 cleared ('0'), and are optional. 739 Appendix A.1. Packet 741 0 1 2 3 742 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | | 747 | Message + Padding | 748 | | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | | 751 : ... : 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | | 755 | Message + Padding | 756 | | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 0 1 2 3 760 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 |0 0 0 0 0 0 0 0| Reserved |0|1| Padding | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | | 765 | Message + Padding | 766 | | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | | 769 : ... : 770 | | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | | 773 | Message + Padding | 774 | | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 0 1 2 3 777 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 |0 0 0 0 0 0 0 0| Reserved |1|0| Packet Sequence Number | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | | 782 | Packet TLV Block | 783 | | 784 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | | Padding | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | | 788 | Message + Padding | 789 | | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | | 792 : ... : 793 | | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | | 796 | Message + Padding | 797 | | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 0 1 2 3 801 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 |0 0 0 0 0 0 0 0| Reserved |1|1| | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 805 | | 806 | Packet TLV Block | 807 | | 808 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | | Padding | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | | 812 | Message + Padding | 813 | | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | | 816 : ... : 817 | | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | | 820 | Message + Padding | 821 | | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 0 1 2 3 824 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | | 827 | Message + Padding | 828 | | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | | 831 : ... : 832 | | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | | 835 | Message + Padding | 836 | | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Appendix A.2. Message and Padding 841 0 1 2 3 842 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Message Type | Resv |N|0|0| Message Size | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Originator Address | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Hop Limit | Hop Count | Message Sequence Number | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | | 851 | Message Body | 852 | | 853 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | | Padding | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 0 1 2 3 858 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Message Type | Resv |0|0|1| Message Size | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Hop Limit | Hop Count | | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 864 | | 865 | Message Body | 866 | | 867 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | | Padding | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 0 1 2 3 871 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Message Type | Resv |N|1|0| Message Size | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Originator Address | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Message Sequence Number | | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 879 | | 880 | Message Body | 881 | | 882 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | | Padding | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 0 1 2 3 887 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Message Type | Resv |0|1|1| Message Size | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | | 892 | Message Body | 893 | | 894 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | | Padding | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 Appendix A.3. Message Body 900 0 1 2 3 901 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | | 904 | Message TLV Block | 905 | +-+-+-+-+-+-+-+-+ 906 | | | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 908 | | 909 | Address Block | 910 | | 911 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | | | 913 +-+-+-+-+-+-+-+-+ | 914 | Address TLV Block | 915 | | 916 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | | | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 919 | | 920 : ... : 921 | | 922 | +-+-+-+-+-+-+-+-+ 923 | | | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 925 | | 926 | Address Block | 927 | | 928 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | | | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 931 | | 932 | Address TLV Block | 933 | | 934 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 Appendix A.4. Address Block 940 0 1 2 3 941 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Number Addrs |0| Head Length | Head | 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 |1| Head Length | Head | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 |0| Tail Length | Tail | Mid | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Mid (cont) | | 962 +-+-+-+-+-+-+-+-+ | 963 | | 964 : ... : 965 | | 966 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | | Mid | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 0 1 2 3 971 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Number Addrs |1| Head Length | Head | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 |1| Tail Length | Mid | | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 977 | | 978 : ... : 979 | | 980 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | | Mid | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Appendix A.5. TLV Block 986 0 1 2 3 987 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Length | | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 991 | | 992 | TLV | 993 | +-+-+-+-+-+-+-+-+ 994 | | | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 996 | | 997 : ... : 998 | | 999 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | | | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1002 | | 1003 | TLV | 1004 | +-+-+-+-+-+-+-+-+ 1005 | | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 Appendix A.6. TLV 1010 0 1 2 3 1011 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Type |Resv |M|0|0|0|0| Index Start | Index Stop | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Length | | 1016 +-+-+-+-+-+-+-+-+ | 1017 | Value | 1018 | | 1019 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | | 1021 +-+-+-+-+-+-+-+-+ 1023 0 1 2 3 1024 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Type |Resv |0|0|0|0|1| Index Start | Index Stop | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 0 1 2 3 1029 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Type |Resv |M|0|0|1|0| Index Start | Index Stop | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Length | | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1035 | | 1036 | Value | 1037 | | 1038 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | | 1040 +-+-+-+-+-+-+-+-+ 1042 0 1 2 3 1043 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Type |Resv |M|0|1|0|0| Length | | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1047 | | 1048 | Value | 1049 | | 1050 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | | 1052 +-+-+-+-+-+-+-+-+ 1054 0 1 2 3 1055 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Type |Resv |0|0|1|0|1| 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 0 1 2 3 1061 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Type |Resv |M|0|1|1|0| Length | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | | 1066 | Value | 1067 | | 1068 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | | 1070 +-+-+-+-+-+-+-+-+ 1071 0 1 2 3 1072 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Type |Resv |0|1|0|0|0| Index Start | Length | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | | 1077 | Value | 1078 | | 1079 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | | 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 |0|1|0|0|1| Index Start | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 0 1 2 3 1090 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Type |Resv |0|1|0|1|0| Index Start | Length | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Length (cont) | | 1095 +-+-+-+-+-+-+-+-+ | 1096 | | 1097 | Value | 1098 | | 1099 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | | 1101 +-+-+-+-+-+-+-+-+ 1103 Appendix B. Complete Example 1105 An example packet, using IPv4 addresses (length four octets) is 1106 shown. This packet has a header, with a packet sequence number but 1107 no packet TLV block, and contains a single unfragmented message. The 1108 message has a complete message header, a message TLV block of content 1109 length 9 octets containing a single TLV (with the noindex bit of its 1110 semantics set and value length 6 octets) and then two address blocks 1111 each with a following TLV block. The first address block contains 3 1112 addresses (head length 2 octets, no tail, hence mid length two 1113 octets) and is followed by a TLV block of content length 9 octets 1114 containing two TLVs. The first of these TLVs has the noindex bit of 1115 its semantics set and has a single value of length 2 octets, which 1116 applies to all of the addresses in the preceding address block. The 1117 second of these TLVs has the novalue bit of its semantics set and 1118 hence has no length or value fields (it does have index fields, which 1119 indicate those addresses this TLV applies to). The second address 1120 block contains 2 addresses (head length 0 octets, hence no head 1121 octets, tail length 2 octets, zero-valued tail not included, hence 1122 mid length two octets) and is followed by a TLV block of content 1123 length 5 octets. This TLV block contains a single TLV of type 1124 PREFIX_LENGTH that has the multivalue and noindex bits of its 1125 semantics set and a value field length of 2 octets, indicating two 1126 values each of one octet length. There are two final padding octets 1127 that are not included in the message length of 62 octets. 1129 0 1 2 3 1130 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Message Type | Resv |N|0|0|0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0| 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Originator Address | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Hop Limit | Hop Count | Message Sequence Number | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type |Resv |0|0|1|0|0| 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 |0 0 0 0 0 1 1 0| Value | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Value (cont) |0 0 0 0 0 0 1 1| 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 |0 0 0 0 0 0 1 0| Head | Mid | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | Mid (cont) | Mid | Mid | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Mid (cont) |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 |Resv |0|0|1|0|0|0 0 0 0 0 0 1 0| Value | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | TLV Type |Resv |0|0|0|0|1| Index Start | Index Stop | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 |0 0 0 0 0 0 1 0|1 0 0 0 0 0 0 0|1 0 0 0 0 0 1 0| Mid | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Mid (cont) | Mid |0 0 0 0 0 0 0 0| 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 |0 0 0 0 0 1 0 1| PREFIX_LENGTH |Resv |1|0|1|0|0|0 0 0 0 0 0 1 0| 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Value0 | Value1 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 Appendix C. Contributors 1167 This specification is the result of the joint efforts of the 1168 following contributors from the OLSRv2 Design Team -- listed 1169 alphabetically. 1171 o Cedric Adjih, INRIA, France, 1173 o Emmanuel Baccelli, Hitachi Labs Europe, France, 1174 1176 o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, 1177 1179 o Justin W. Dean, NRL, USA 1181 o Christopher Dearlove, BAE Systems, UK, 1182 1184 o Satoh Hiroki, Hitachi SDL, Japan, 1186 o Philippe Jacquet, INRIA, France, 1188 o Monden Kazuya, Hitachi SDL, Japan, 1190 Appendix D. Acknowledgements 1192 The authors would like to acknowledge the team behind OLSRv1, as 1193 specified in RFC 3626, including Anis Laouiti, Pascale Minet, Laurent 1194 Viennot (all at INRIA, France), and Amir Qayuum (Center for Advanced 1195 Research in Engineering, Pakistan) for their contributions. 1197 The authors would like to gratefully acknowledge the following people 1198 for intense technical discussions, early reviews and comments on the 1199 specification and its components: Joe Macker (NRL), Alan Cullen (BAE 1200 Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), Andreas 1201 Schjonhaug (LIX), Florent Brunneau (LIX), and the entire IETF MANET 1202 working group. 1204 Authors' Addresses 1206 Thomas Heide Clausen 1207 LIX, Ecole Polytechnique, France 1209 Phone: +33 6 6058 9349 1210 Email: T.Clausen@computer.org 1211 URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ 1213 Christopher M. Dearlove 1214 BAE Systems Advanced Technology Centre 1216 Phone: +44 1245 242194 1217 Email: chris.dearlove@baesystems.com 1218 URI: http://www.baesystems.com/ocs/sharedservices/atc/ 1220 Justin W. Dean 1221 Naval Research Laboratory 1223 Phone: +1 202 767 3397 1224 Email: jdean@itd.nrl.navy.mil 1225 URI: http://pf.itd.nrl.navy.mil/ 1227 Cedric Adjih 1228 INRIA Rocquencourt 1230 Phone: +33 1 3963 5215 1231 Email: Cedric.Adjih@inria.fr 1232 URI: http://menetou.inria.fr/~adjih/ 1234 Intellectual Property Statement 1236 The IETF takes no position regarding the validity or scope of any 1237 Intellectual Property Rights or other rights that might be claimed to 1238 pertain to the implementation or use of the technology described in 1239 this document or the extent to which any license under such rights 1240 might or might not be available; nor does it represent that it has 1241 made any independent effort to identify any such rights. Information 1242 on the procedures with respect to rights in RFC documents can be 1243 found in BCP 78 and BCP 79. 1245 Copies of IPR disclosures made to the IETF Secretariat and any 1246 assurances of licenses to be made available, or the result of an 1247 attempt made to obtain a general license or permission for the use of 1248 such proprietary rights by implementers or users of this 1249 specification can be obtained from the IETF on-line IPR repository at 1250 http://www.ietf.org/ipr. 1252 The IETF invites any interested party to bring to its attention any 1253 copyrights, patents or patent applications, or other proprietary 1254 rights that may cover technology that may be required to implement 1255 this standard. Please address the information to the IETF at 1256 ietf-ipr@ietf.org. 1258 Disclaimer of Validity 1260 This document and the information contained herein are provided on an 1261 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1262 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1263 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1264 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1265 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1266 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1268 Copyright Statement 1270 Copyright (C) The Internet Society (2006). This document is subject 1271 to the rights, licenses and restrictions contained in BCP 78, and 1272 except as set forth therein, the authors retain all their rights. 1274 Acknowledgment 1276 Funding for the RFC Editor function is currently provided by the 1277 Internet Society.