idnits 2.17.1 draft-ietf-manet-packetbb-03.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 1290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1314. ** 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 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 411 has weird spacing: '...-length is a ...' == Line 420 has weird spacing: '...-length is a ...' == Line 428 has weird spacing: '...-length is a ...' == Line 528 has weird spacing: '...ex-stop are v...' == Line 555 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 29, 2007) is 6298 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 (~~), 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: August 2, 2007 BAE Systems Advanced Technology 6 Centre 7 J. Dean 8 Naval Research Laboratory 9 C. Adjih 10 INRIA Rocquencourt 11 January 29, 2007 13 Generalized MANET Packet/Message Format 14 draft-ietf-manet-packetbb-03 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 August 2, 2007. 41 Copyright Notice 43 Copyright (C) The Internet Society (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 hop-by-hop and are not forwarded. A packet contains 149 zero or more messages, and may contain a packet header. 151 Message - the fundamental entity carrying protocol information, in 152 the form of addresses and TLVs. Messages are transmitted in 153 packets, and may be forwarded based on their header information. 155 Address - an address of the same length as the source IP address in 156 the IP datagram carrying the packet. 158 TLV - a Type-Length-Value structure. This is a generic way in which 159 an attribute can be represented and correctly parsed, without the 160 parser having to understand the attribute. 162 element - a syntactic entity defined in the regular expression 163 specification, represented using the notation . 165 - if is an 8 or 16 bit field then is also used to 166 represent the value of that field. 168 ? - zero or one occurrences of the preceding element. 170 * - zero or more occurrences of the preceding element. 172 bar - a variable, usually obtained through calculations based on the 173 value(s) of field(s). Variables are introduced into the 174 specification solely as a means to clarify the description. 176 address-length - a variable whose value is the length of an address 177 in octets, it is 4 if using IPv4, 16 if using IPv6. 179 3. Applicability Statement 181 This specification describes a generic multi-message packet format, 182 for carrying MANET routing protocol signals. The specification has 183 been developed from that used by OLSR (The Optimized Link State 184 Routing Protocol) [4]. 186 The specification is designed specifically with IP (IPv4/IPv6) in 187 mind. All addresses within a control message are assumed to be of 188 the same size, deduced from IP. In the case of mixed IPv6 and IPv4 189 addresses, IPv4 addresses are carried in IPv6 as specified in [2]. 191 The messages defined by this specification are designed to carry 192 routing protocol signals between MANET routers, and to support scope 193 limited diffusion, as well as point to point signaling in a multi-hop 194 network. 196 The packets defined by this specification are designed to carry a 197 number of messages between neighboring nodes in a single transmission 198 and over a single logical hop. The packets may use any transport 199 mechanism (unicast, multicast) and transport protocol (TCP, UDP, ...) 200 appropriate to the protocol using this specification. When the 201 diffusion mechanism enabled by this specification is employed, UDP 202 may be most appropriate. 204 This specification is particularly appropriate for extensible 205 protocols. It offers external extensibility in the form of new 206 message types. It offers internal extensibility in the form of TLVs, 207 which may be added to existing message types. 209 A protocol using the multi-message packet format defined by this 210 specification may constrain the syntax (for example requiring a full 211 message header) and features (for example specifying the suggested 212 diffusion mechanism) that it will employ. 214 4. Protocol Overview and Functioning 216 This specification does not describe a protocol. It describes a 217 packet format, which may be used by any mobile ad hoc network routing 218 or other protocol. 220 5. Signaling Framework 222 This section provides syntactical specification of a packet, 223 represented by the element and the elements from which it is 224 composed. The specification is given in the form of regular 225 expressions. Illustrations of specified elements are given in 226 Appendix A. 228 The length of a is obtained as the size of the payload of 229 the transport protocol employed. 231 5.1. Packets 233 is defined by: 235 = {*}? 236 {*}* 238 where is defined in Section 5.2, and is defined 239 in Section 5.4. The packet is parsed until all octets are used. 241 is defined by: 243 = 244 245 ? 246 ? 248 where: 250 is an 8 bit field with all bits cleared ('0'). This field 251 serves to identify that the packet starts with a packet header. 253 is an 8 bit field, specifying the composition of 254 the packet header: 256 bit 0 (pnoseqnum): if cleared ('0'), then the packet header 257 contains a . If set ('1'), then the packet 258 header does not include a . 260 bit 1 (ptlv): if cleared ('0'), then the packet header does not 261 include a TLV block. If set ('1'), then the packet header 262 includes a TLV block. 264 bits 2-7: are RESERVED, and MUST each be cleared ('0') to be in 265 conformance with this version of the specification. 267 is omitted if the pnoseqnum bit is set ('1'), 268 otherwise is a 16 bit field, specifying a packet sequence number. 270 is omitted if the ptlv bit is cleared ('0'), and is 271 otherwise defined in Section 5.3. 273 Note that since the message type zero is reserved (see Section 7), 274 the presence or absence of a packet header can be determined by 275 inspecting the first octet of the packet. 277 5.2. Messages 279 Information is carried through messages. Messages contain: 281 o A message header. 283 o A message TLV block that contains zero or more TLVs, associated 284 with the whole message. 286 o Zero or more address blocks, each containing one or more 287 addresses. 289 o A TLV block, containing zero or more TLVs, following each address 290 block. 292 is defined by: 294 = 295 296 {}* 298 = 299 300 301 303 = ? 304 ? 305 ? 306 ? 308 where: 310 is defined in Section 5.3. 312 is defined in Section 5.2.1. 314 is an 8 bit field, specifying the type of message. A 315 type with all bits cleared ('0') MUST NOT be used. 317 is an 8 bit field, specifying the interpretation of 318 the remainder of the message header: 320 bit 0 (noorig): if cleared ('0'), then and 321 are included in . If set 322 ('1'), then and are not 323 included in ; this reduced message header does 324 not provide for duplicate suppression. 326 bit 1 (nohops): if cleared ('0'), then and are included in the . If set ('1'), 328 then and are not included in the ; this reduced message header does not provide for 330 scope-delimited forwarding. 332 bit 2 (typedep): if cleared ('0'), then the message sequence 333 number in the message is type-independent. If set ('1'), then 334 the message sequence number contained in the message is type 335 dependent (the message originator maintains a sequence number 336 specific to ). This bit MUST be cleared ('0') if the 337 noorig bit is set ('1'). 339 bits 3-7: are RESERVED and MUST each be cleared ('0') to be in 340 conformance with this version of the specification. 342 is a 16 bit field, specifying the size of the , 343 counted in octets. 345 is an identifier of length equal to address- 346 length, which serves to uniquely identify the node that originated 347 the message. 349 is an 8 bit field, which contains the maximum number of 350 hops a message should be further transmitted. 352 is an 8 bit field, which contains the number of hops a 353 message has traveled. 355 is a 16 bit field, which contains a unique number, 356 generated by the originator node. The , , and, if the typedep bit in the field 358 is set, the of a message serves to uniquely identify 359 the message in the network. 361 5.2.1. Address Blocks 363 An address is specified as a sequence of address-length octets of the 364 form head:mid:tail. An address block is an ordered set of addresses 365 sharing the same head and tail, and having individual mids. 367
is defined by: 369 = 370 371 ? 372 ? 373 ? 374 ? 375 * 377 where: 379 is an 8 bit field containing the number of addresses 380 represented in the address block, which MUST NOT be zero. 382 is an 8 bit field specifying the interpretation of 383 the remainder of the address block: 385 bit 0 (nohead): if cleared ('0'), then is included 386 in , and may be included in . If set ('1'), then and are not 388 included in . 390 bit 1 (notail) and bit 2 (zerotail): MUST NOT both be set ('1'). 391 Otherwise, they are interpreted according to Table 1. 393 +--------+----------+---------------+-----------------+ 394 | notail | zerotail | | | 395 +--------+----------+---------------+-----------------+ 396 | 0 | 0 | included | may be included | 397 | | | | | 398 | 0 | 1 | included | not included | 399 | | | | | 400 | 1 | 0 | not included | not included | 401 +--------+----------+---------------+-----------------+ 403 Table 1 405 bits 3-7: are RESERVED and MUST each be cleared ('0') to be in 406 accordance with this version of the specification. 408 if present is an 8 bit field, which contains the total 409 length (in octets) of the head of all of the addresses. 411 head-length is a variable, defined to equal if 412 present, or 0 otherwise. 414 is omitted if head-length == 0, otherwise it is a field of 415 the head-length leftmost octets of all the addresses. 417 if present is an 8 bit field, which contains the total 418 length (in octets) of the tail of all of the addresses. 420 tail-length is a variable, defined to equal if 421 present, or 0 otherwise. 423 is omitted if tail-length == 0 or if the zerotail bit is set 424 ('1'), otherwise it is a field of the tail-length rightmost octets 425 of all the addresses. If the zerotail bit is set ('1') then the 426 tail-length rightmost octets of all the addresses are all 0. 428 mid-length is a variable, which MUST be non-negative, defined by: 430 * mid-length = address-length - head-length - tail-length 432 is omitted if mid-length == 0, otherwise each is a field 433 of length mid-length octets, representing the mid of the 434 corresponding address in the address block. 436 5.3. TLVs and TLV Blocks 438 A TLV block is defined by: 440 = 441 * 443 where: 445 is a 16 bit field, which contains the total length (in 446 octets) of the immediately following elements. 448 is defined in Section 5.3.1. 450 5.3.1. TLVs 452 There are three kinds of TLV, each represented by an element : 454 o A packet TLV, included in a packet header. 456 o A message TLV, included in a message before all address blocks. 458 o An address block TLV, included in a TLV block following an address 459 block. An address block TLV applies to: 461 * all addresses in the address block; OR 463 * any continuous sequence of addresses in the address block; OR 465 * a single address in the address block. 467 is defined by: 469 = 470 471 ? 472 ? 473 ? 474 ? 476 where: 478 is an 8 bit field, specifying the type of the TLV, 479 specific to the TLV kind (i.e. packet- message- or address block 480 TLV). 482 is an 8 bit field specifying the interpretation of 483 the remainder of the TLV: 485 bit 0 (extended) and bit 1 (novalue): MUST NOT both be set ('1'). 486 Otherwise, they are interpreted according to Table 2. 488 +----------+---------+--------------+--------------+ 489 | extended | novalue | | | 490 +----------+---------+--------------+--------------+ 491 | 0 | 0 | 8 bits | included | 492 | | | | | 493 | 0 | 1 | not included | not included | 494 | | | | | 495 | 1 | 0 | 16 bits | included | 496 +----------+---------+--------------+--------------+ 498 Table 2 500 bit 2 (noindex) and bit 3 (singleindex): MUST NOT both be set 501 ('1'). The former MUST be set ('1') and the latter MUST be 502 cleared ('0') for packet or message TLVs. They are interpreted 503 according to Table 3. 505 +---------+-------------+---------------+--------------+ 506 | noindex | singleindex | | | 507 +---------+-------------+---------------+--------------+ 508 | 0 | 0 | included | included | 509 | | | | | 510 | 0 | 1 | included | not included | 511 | | | | | 512 | 1 | 0 | not included | not included | 513 +---------+-------------+---------------+--------------+ 515 Table 3 517 bit 4 (multivalue): this bit serves to specify how the 518 field is interpreted, as specified below. This bit MUST be 519 cleared ('0') for packet or message TLVs, if the singleindex 520 bit is set ('1'), or if the novalue bit is set ('1'). 522 bits 5-7: are RESERVED and MUST each be cleared ('0') to be in 523 accordance with this version of the specification. 525 and when present are each an 8 bit field, 526 interpreted as follows: 528 index-start and index-stop are variables, defined according to 529 Table 4. The variable end-index is defined as follows: 531 + For message and packet TLVs: 533 - end-index = 0 535 + For address block TLVs: 537 - end-index = - 1 539 +---------+-------------+---------------+---------------+ 540 | noindex | singleindex | index-start = | index-stop = | 541 +---------+-------------+---------------+---------------+ 542 | 0 | 0 | | | 543 | | | | | 544 | 0 | 1 | | | 545 | | | | | 546 | 1 | 0 | 0 | end-index | 547 +---------+-------------+---------------+---------------+ 549 Table 4 551 For an address block TLV, the TLV applies to the addresses from 552 position index-start to position index-stop (inclusive) in the 553 address block, where the first address has position zero. 555 number-values is a variable, defined by: 557 + number-values = index-stop - index-start + 1 559 is omitted or is a 8 or 16 bit field according to Table 2. 560 If present it MUST NOT be zero. If the multivalue bit is set 561 ('1') then MUST be an integral multiple of number-values, 562 and the variable single-length is defined by: 564 * single-length = / number-values 566 If the multivalue bit is cleared ('0'), then the variable single- 567 length is defined by: 569 * single-length = 571 if present (see Table 2) is a field of length 572 octets. In an address block TLV, is associated with the 573 addresses from index-start to index-stop, inclusive. If the 574 multivalue bit is cleared ('0') then the whole of this field is 575 associated with each of the indicated addresses. If the 576 multivalue bit is set ('1') then this field is divided equally 577 into number-values fields, each of length single-length octets and 578 these are associated, in order, with the indicated addresses. 580 5.3.2. Constraints 582 TLVs in the same TLV block MUST be sorted in ascending TLV type 583 order. 585 Two or more TLVs of the same type associated with the same address 586 block MUST NOT both cover any address. 588 TLVs of the same type associated with the same address block MUST be 589 sorted in ascending index-start order. 591 5.4. Padding 593 Packet headers and messages can be padded to ensure 32 bit alignment 594 of each message contained within the packet and of the overall packet 595 length. 597 All elements are an integer multiple of octets, hence padding can be 598 accomplished by inserting an integer number of elements 599 after the element that is to be 32 bit aligned. 601 The number of elements required to achieve this 32 bit 602 alignment is the smallest number (0 to 3) that, when added to the 603 size of the preceding elements, produces an integer multiple of 4. 605 is an 8 bit field with all bits cleared ('0'). 607 There is no need to indicate if padding is included, since a will always precede either a message or the end of the packet. 609 In the former case, the start of a message is indicated by the next 610 non-zero octet parsed. 612 The padding after a message may be freely changed when a message is 613 forwarded without affecting the message. 615 6. TLV specification 617 This document specifies one address block TLV, which is included to 618 allow a standardized way of representing network addresses. 620 6.1. Address Block TLV Specification 622 +----------------------+------+--------+----------------------------+ 623 | Name | Type | Length | Value | 624 +----------------------+------+--------+----------------------------+ 625 | PREFIX_LENGTH | 0 | 8 bits | Indicates that the address | 626 | | | | is a network address, | 627 | | | | rather than a host | 628 | | | | address. The value is the | 629 | | | | length of the | 630 | | | | prefix/netmask. | 631 +----------------------+------+--------+----------------------------+ 633 Table 5 635 An address in an address block without an associated PREFIX_LENGTH 636 TLV may be considered to have a prefix length equal to the address 637 length in bits (i.e. address-length times 8). 639 7. IANA Considerations 641 A new registry for message types must be created with initial 642 assignments as specified in Table 6. Future values in the range 643 5-127 can be allocated using standards action [3]. Additionally, 644 values in the range 128-255 are reserved for private/local use. 646 A new registry for packet TLV types must be created, with no initial 647 assignments. Future values in the range 0-127 can be allocated using 648 standards action [3]. Additionally, values in the range 128-255 are 649 reserved for private/local use. 651 A new registry for message TLV types must be created with no initial 652 assignments. Future values in the range 0-127 can be allocated using 653 standards action [3]. Additionally, values in the range 128-255 are 654 reserved for private/local use. 656 A new registry for address block TLV types must be created with 657 initial assignments as specified in Table 7. Future values in the 658 range 1-127 can be allocated using standards action [3]. 659 Additionally, values in the range 128-255 are reserved for private/ 660 local use. 662 +-------+----------------------------------------+ 663 | Value | Description | 664 +-------+----------------------------------------+ 665 | 0 | MUST NOT be allocated. | 666 | | | 667 | 1-4 | RESERVED | 668 +-------+----------------------------------------+ 670 Table 6 672 Message type 0 MUST NOT be allocated because a zero-octet signifies a 673 packet header and zero-octets are used for padding. Message types 1 674 to 4 are reserved because they are used by OLSR [4], which uses a 675 compatible packet/message header format. 677 +--------------------+-------+--------------------------------------+ 678 | Mnemonic | Value | Description | 679 +--------------------+-------+--------------------------------------+ 680 | PREFIX_LENGTH | 0 | Indicates that associated addresses | 681 | | | are network addresses, with given | 682 | | | prefix length. | 683 +--------------------+-------+--------------------------------------+ 685 Table 7 687 8. Security Considerations 689 Messages are designed to be carriers of protocol information and MAY, 690 at each hop, be forwarded and/or processed according to the 691 information in the message header by the protocol using this 692 specification. If forwarded messages are unchanged by this protocol, 693 then end-to-end security MAY be implemented, between nodes with an 694 existing security association, by including a suitable message TLV 695 containing a cryptographic signature to the message. Since and are the only fields that may be modified when 697 such a message is forwarded, this signature can be calculated based 698 on the entire message, including the message header, with the and fields set to zero ('0') if present. 701 Packets are designed to carry a number of messages between 702 neighboring nodes in a single transmission and over a single logical 703 hop. Hop-by-hop packet level security MAY be implemented, between 704 nodes with an existing security association, by including a suitable 705 packet TLV containing a cryptographic signature to the packet. Since 706 packets are received as transmitted, this signature can be calculated 707 based on the entire packet, or on parts thereof as appropriate. 709 9. References 711 9.1. Normative References 713 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 714 Levels", RFC 2119, BCP 14, March 1997. 716 [2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 717 Addressing Architecture", RFC 3513, April 2003. 719 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 720 Considerations Section in RFCs", October 1998. 722 9.2. Informative References 724 [4] Clausen, T. and P. Jacquet, "The Optimized Link State Routing 725 Protocol", RFC 3626, October 2003. 727 Appendix A. Illustrations 729 This informative appendix illustrates the elements, which are 730 normatively specified in Section 5 using regular expressions. 732 Bits labeled Reserved or Resv are cleared ('0'). Bits labeled N and 733 M may be cleared ('0') or set ('1'). Octets labeled Padding are 734 cleared ('0'), and are optional. 736 Appendix A.1. Packet 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | | 744 | Message + Padding | 745 | | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | | 748 : ... : 749 | | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | | 752 | Message + Padding | 753 | | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 |0 0 0 0 0 0 0 0| Reserved |0|1| Padding | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | | 762 | Message + Padding | 763 | | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | | 766 : ... : 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | | 770 | Message + Padding | 771 | | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 0 1 2 3 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 |0 0 0 0 0 0 0 0| Reserved |1|0| Packet Sequence Number | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | | 779 | Packet TLV Block | 780 | | 781 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | | Padding | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | | 785 | Message + Padding | 786 | | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | | 789 : ... : 790 | | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | | 793 | Message + Padding | 794 | | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 |0 0 0 0 0 0 0 0| Reserved |1|1| | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802 | | 803 | Packet TLV Block | 804 | | 805 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | | Padding | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | | 809 | Message + Padding | 810 | | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | | 813 : ... : 814 | | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | | 817 | Message + Padding | 818 | | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | | 824 | Message + Padding | 825 | | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | | 828 : ... : 829 | | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | | 832 | Message + Padding | 833 | | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Appendix A.2. Message and Padding 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Message Type | Resv |N|0|0| Message Size | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Originator Address | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Hop Limit | Hop Count | Message Sequence Number | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | | 848 | Message Body | 849 | | 850 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | | Padding | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Message Type | Resv |0|0|1| Message Size | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Hop Limit | Hop Count | | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 861 | | 862 | Message Body | 863 | | 864 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | | Padding | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Message Type | Resv |N|1|0| Message Size | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Originator Address | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Message Sequence Number | | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 876 | | 877 | Message Body | 878 | | 879 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | | Padding | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 0 1 2 3 884 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 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Message Type | Resv |0|1|1| Message Size | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | | 889 | Message Body | 890 | | 891 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | | Padding | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 Appendix A.3. Message Body 897 0 1 2 3 898 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 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | | 901 | Message TLV Block | 902 | +-+-+-+-+-+-+-+-+ 903 | | | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 905 | | 906 | Address Block | 907 | | 908 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | | | 910 +-+-+-+-+-+-+-+-+ | 911 | Address TLV Block | 912 | | 913 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | | | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 916 | | 917 : ... : 918 | | 919 | +-+-+-+-+-+-+-+-+ 920 | | | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 922 | | 923 | Address Block | 924 | | 925 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | | | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 928 | | 929 | Address TLV Block | 930 | | 931 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 Appendix A.4. Address Block 937 0 1 2 3 938 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 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Number Addrs | Resv |0|0|0| Head Length | Head | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Head (cont) | Tail Length | Tail | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Mid | | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 946 | | 947 : ... : 948 | | 949 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | | Mid | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 0 1 2 3 954 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Number Addrs | Resv |0|0|1| Tail Length | Tail | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Tail (cont) | Mid | | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 960 | | 961 : ... : 962 | | 963 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | | Mid | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 0 1 2 3 968 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 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Number Addrs | Resv |0|1|0| Head Length | Head | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Head (cont) | Mid | | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 974 | | 975 : ... : 976 | | 977 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | | Mid | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 0 1 2 3 981 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 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Number Addrs | Resv |0|1|1| Mid | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Mid (cont) | | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 987 | | 988 : ... : 989 | | 990 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | | Mid | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Mid (cont) | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 0 1 2 3 997 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 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Number Addrs | Resv |1|0|0| Head Length | Head | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | Head (cont) | Tail Length | Mid | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | | 1004 : ... : 1005 | | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Mid | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | Number Addrs | Resv |1|0|1| Tail Length | Mid | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Mid (cont) | | 1016 +-+-+-+-+-+-+-+-+ | 1017 | | 1018 : ... : 1019 | | 1020 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | | Mid | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 Appendix A.5. TLV Block 1026 0 1 2 3 1027 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 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Length | | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1031 | | 1032 | TLV | 1033 | +-+-+-+-+-+-+-+-+ 1034 | | | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1036 | | 1037 : ... : 1038 | | 1039 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | | | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1042 | | 1043 | TLV | 1044 | +-+-+-+-+-+-+-+-+ 1045 | | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 Appendix A.6. TLV 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Type |Resv |M|0|0|0|0| Index Start | Index Stop | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Length | | 1056 +-+-+-+-+-+-+-+-+ | 1057 | Value | 1058 | | 1059 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | | 1061 +-+-+-+-+-+-+-+-+ 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Type |Resv |M|0|0|0|1| Index Start | Index Stop | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Length | | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1069 | | 1070 | Value | 1071 | | 1072 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | | 1074 +-+-+-+-+-+-+-+-+ 1076 0 1 2 3 1077 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 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Type |Resv |0|0|0|1|0| Index Start | Index Stop | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 0 1 2 3 1083 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 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Type |Resv |M|0|1|0|0| Length | | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1087 | | 1088 | Value | 1089 | | 1090 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | | 1092 +-+-+-+-+-+-+-+-+ 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Type |Resv |M|0|1|0|1| Length | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | | 1100 | Value | 1101 | | 1102 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | | 1104 +-+-+-+-+-+-+-+-+ 1105 0 1 2 3 1106 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 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Type |Resv |0|0|1|1|0| 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 0 1 2 3 1112 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 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Type |Resv |0|1|0|0|0| Index Start | Length | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | | 1117 | Value | 1118 | | 1119 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | | 1121 +-+-+-+-+-+-+-+-+ 1123 0 1 2 3 1124 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 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Type |Resv |0|1|0|0|1| Index Start | Length | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Length (cont) | | 1129 +-+-+-+-+-+-+-+-+ | 1130 | | 1131 | Value | 1132 | | 1133 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | | 1135 +-+-+-+-+-+-+-+-+ 1137 0 1 2 3 1138 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 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Type |Resv |0|1|0|1|0| Index Start | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 Appendix B. Complete Example 1145 An example packet, using IPv4 addresses (length four octets) is 1146 shown. This packet has a header, with a packet sequence number but 1147 no packet TLV block, and contains a single message. The message has 1148 a complete message header, a message TLV block of content length 9 1149 octets containing a single TLV (with the noindex bit of its semantics 1150 octet set and value length 6 octets) and then two address blocks each 1151 with a following TLV block. The first address block contains 3 1152 addresses, has the notail bit of the its semantics octet set, and has 1153 head length 2 octets, hence mid length two octets. It is followed by 1154 a TLV block with content length 9 octets containing two TLVs. The 1155 first of these TLVs has the noindex bit of its semantics octet set 1156 and has a single value of length 2 octets, which applies to all of 1157 the addresses in the preceding address block. The second of these 1158 TLVs has the novalue bit of its semantics octet set and hence has no 1159 length or value fields (it does have index fields, which indicate 1160 those addresses this TLV applies to). The second address block 1161 contains 2 addresses, has the nohead and zerotail bits of its 1162 semantics octet set, and has tail length 2 octets, hence mid length 1163 two octets. The two tail octets of each address are zero. It is 1164 followed by a TLV block of content length 5 octets. This TLV block 1165 contains a single TLV of type PREFIX_LENGTH that has the multivalue 1166 and noindex bits of its semantics octet set and a value field length 1167 of 2 octets, indicating two values each of one octet length. There 1168 is one final padding octet that is not included in the message length 1169 of 59 octets. 1171 0 1 2 3 1172 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 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | Message Type | Resv |N|0|0|0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 1| 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Originator Address | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Hop Limit | Hop Count | Message Sequence Number | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type |Resv |0|0|1|0|0| 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 |0 0 0 0 0 1 1 0| Value | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | Value (cont) |0 0 0 0 0 0 1 1| 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0| Head | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Mid | Mid | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Mid |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | TLV Type |Resv |0|0|1|0|0|0 0 0 0 0 0 1 0| Value | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Value (cont) | TLV Type |Resv |0|0|0|1|0| Index Start | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | 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| 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | Mid | Mid | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| PREFIX_LENGTH |Resv |1|0|1|0|0| 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 |0 0 0 0 0 0 1 0| Value0 | Value1 |0 0 0 0 0 0 0 0| 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 Appendix C. Contributors 1209 This specification is the result of the joint efforts of the 1210 following contributors from the OLSRv2 Design Team -- listed 1211 alphabetically. 1213 o Cedric Adjih, INRIA, France, 1215 o Emmanuel Baccelli, Hitachi Labs Europe, France, 1216 1218 o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, 1219 1221 o Justin W. Dean, NRL, USA 1223 o Christopher Dearlove, BAE Systems, UK, 1224 1226 o Satoh Hiroki, Hitachi SDL, Japan, 1228 o Philippe Jacquet, INRIA, France, 1230 o Monden Kazuya, Hitachi SDL, Japan, 1232 Appendix D. Acknowledgements 1234 The authors would like to acknowledge the team behind OLSRv1, as 1235 specified in RFC 3626, including Anis Laouiti, Pascale Minet, Laurent 1236 Viennot (all at INRIA, France), and Amir Qayyum (Center for Advanced 1237 Research in Engineering, Pakistan) for their contributions. 1239 The authors would like to gratefully acknowledge the following people 1240 for intense technical discussions, early reviews and comments on the 1241 specification and its components: Joe Macker (NRL), Alan Cullen (BAE 1242 Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), Andreas 1243 Schjonhaug (LIX), Florent Brunneau (LIX), Yasunori Owada (Niigata 1244 University) and the entire IETF MANET working group. 1246 Authors' Addresses 1248 Thomas Heide Clausen 1249 LIX, Ecole Polytechnique, France 1251 Phone: +33 6 6058 9349 1252 Email: T.Clausen@computer.org 1253 URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ 1255 Christopher M. Dearlove 1256 BAE Systems Advanced Technology Centre 1258 Phone: +44 1245 242194 1259 Email: chris.dearlove@baesystems.com 1260 URI: http://www.baesystems.com/ocs/sharedservices/atc/ 1262 Justin W. Dean 1263 Naval Research Laboratory 1265 Phone: +1 202 767 3397 1266 Email: jdean@itd.nrl.navy.mil 1267 URI: http://pf.itd.nrl.navy.mil/ 1269 Cedric Adjih 1270 INRIA Rocquencourt 1272 Phone: +33 1 3963 5215 1273 Email: Cedric.Adjih@inria.fr 1274 URI: http://menetou.inria.fr/~adjih/ 1276 Full Copyright Statement 1278 Copyright (C) The Internet Society (2007). 1280 This document is subject to the rights, licenses and restrictions 1281 contained in BCP 78, and except as set forth therein, the authors 1282 retain all their rights. 1284 This document and the information contained herein are provided on an 1285 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1286 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1287 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1288 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1289 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1290 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1292 Intellectual Property 1294 The IETF takes no position regarding the validity or scope of any 1295 Intellectual Property Rights or other rights that might be claimed to 1296 pertain to the implementation or use of the technology described in 1297 this document or the extent to which any license under such rights 1298 might or might not be available; nor does it represent that it has 1299 made any independent effort to identify any such rights. Information 1300 on the procedures with respect to rights in RFC documents can be 1301 found in BCP 78 and BCP 79. 1303 Copies of IPR disclosures made to the IETF Secretariat and any 1304 assurances of licenses to be made available, or the result of an 1305 attempt made to obtain a general license or permission for the use of 1306 such proprietary rights by implementers or users of this 1307 specification can be obtained from the IETF on-line IPR repository at 1308 http://www.ietf.org/ipr. 1310 The IETF invites any interested party to bring to its attention any 1311 copyrights, patents or patent applications, or other proprietary 1312 rights that may cover technology that may be required to implement 1313 this standard. Please address the information to the IETF at 1314 ietf-ipr@ietf.org. 1316 Acknowledgment 1318 Funding for the RFC Editor function is provided by the IETF 1319 Administrative Support Activity (IASA).