idnits 2.17.1 draft-perkins-aodv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 100: '...ed words such as MUST, SHOULD, etc., t...' RFC 2119 keyword, line 252: '... the IPv6 header MUST be set to a valu...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2463 (ref. '2') (Obsoleted by RFC 4443) ** Downref: Normative reference to an Informational RFC: RFC 2375 (ref. '3') -- No information found for draft-ietf-manet--aodv - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- Unexpected draft version: The latest known version of draft-ietf-manet-bcast is -00, but you're referring to -02. (However, the state information for draft-ietf-manet--aodv is not up-to-date. The last update was unsuccessful) -- Possible downref: Normative reference to a draft: ref. '5' Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad Hoc Networking Working Group Charles E. Perkins 2 INTERNET DRAFT Nokia Research Center 3 10 November 2000 Elizabeth M. Royer 4 University of California, Santa Barbara 5 Samir R. Das 6 University of Cincinnati 8 Ad hoc On-Demand Distance Vector (AODV) Routing for IP version 6 9 draft-perkins-aodv6-01.txt 11 Status of This Memo 13 This document is a submission by the Mobile Ad Hoc Networking Working 14 Group of the Internet Engineering Task Force (IETF). Comments should 15 be submitted to the manet@itd.nrl.navy.mil mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The Ad Hoc On-Demand Distance Vector (AODV) routing protocol has 38 been proposed for use with IPv4 as a network-layer protocol linking 39 together mobile nodes in an ad hoc network. It offers quick 40 adaptation to dynamic link conditions, low processing and memory 41 overhead, low network utilization, and determines unicast routes 42 between sources and destinations. It uses destination sequence 43 numbers to ensure loop freedom at all times. In this specification, 44 we detail the necessary modifications to the messages given in the 45 IPv4 specification so that AODV will be able to work for nodes using 46 IPv6 addresses. 48 Contents 50 Status of This Memo i 52 Abstract i 54 1. Introduction 1 56 2. AODV Terminology 2 58 3. Route Request (RREQ) Message Format 2 60 4. Route Reply (RREP) Message Format 3 62 5. Route Error (RERR) Message Format 4 64 6. Route Reply Acknowledgment (RREP-ACK) Message Format 4 66 7. AODV for IPv6 Operation 5 68 8. Extensions 5 70 9. Configuration Parameters 5 72 10. Flooding Data to a Specific Destination 5 73 10.1. Flood Data Option . . . . . . . . . . . . . . . . . . . . 6 74 10.2. Flood Data Reply Option . . . . . . . . . . . . . . . . . 6 76 11. Security Considerations 7 78 1. Introduction 80 The operation of AODV for IP version 6 (IPv6) is intended to mirror 81 the operation of AODV for IP version 4 [4], with changes necessary to 82 allow for transmission of 128-bit addresses in use with IPv6 instead 83 of the more traditional 32-bit addresses. The reader is referred 84 to [4] for most of the terminology, and the specification of the 85 following protocol operations: 87 - Route discovery 88 - Sequence number maintenance 89 - Maintaining local connectivity 90 - Notifying precursors about broken routes 91 - Route expiry and deletion 92 - Actions after reboot 94 Transmission to all nodes in the ad-hoc network is handled in AODV 95 for IPv6 as specified in [5]. 97 2. AODV Terminology 99 This protocol specification uses conventional meanings [1] for 100 capitalized words such as MUST, SHOULD, etc., to indicate requirement 101 levels for various protocol features. 103 3. Route Request (RREQ) Message Format 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Type |J|R|G| Reserved | Hop Count | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | 32-bit Flooded Packet ID | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | 32-bit Destination Sequence Number | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | 32-bit Source Sequence Number | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | | 117 : 128-bit Destination IP Address : 118 | | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | | 121 : 128-bit Source IP Address : 122 | | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 The format of the IPv6 Route Request message (RREQ) is illustrated 126 above, and contains the same fields with the same functions as the 127 RREQ message defined for IP version 4 (in [4]), except as follows: 129 Type 16 131 Destination IP Address 132 The 128-bit IPv6 address of destination for which a 133 route is desired. 135 Source IP Address 136 The 128-bit IPv6 address of the node which 137 originated the Route Request. 139 Note also that the order of the fields has been changed to enable 140 alignment along 128-bit boundaries. 142 4. Route Reply (RREP) Message Format 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Type |R|A| Reserved | Prefix Size | Hop Count | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | 32-bit Destination Sequence Number | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | | 152 : 128-bit Destination IP Address : 153 | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | | 156 : 128-bit Source IP Address : 157 | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Lifetime | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 The format of the IPv6 Route Reply message (RREP) is illustrated 163 above, and contains the same fields with the same functions as the 164 RREP message defined for IP version 4 (in [4]), except as follows: 166 Type 17 168 Prefix Size The Prefix Size is 7 bits instead of 5, to account 169 for the 128-bit IPv6 address space. 171 Destination Sequence Number 172 The destination sequence number associated to the 173 route. 175 Destination IP Address 176 The 128-bit IP address of the destination for which 177 a route is supplied. 179 Source IP Address 180 The 128-bit IP address of the source node which 181 issued the RREQ for which the route is supplied. 183 Note also that the order of the fields has been changed for better 184 alignment. 186 5. Route Error (RERR) Message Format 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Type |N| Reserved | DestCount | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Unreachable Destination Sequence Number (1) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 195 | | 196 : Unreachable Destination IPv6 Address (1) (128 bits) : 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |Additional Unreachable Destination Sequence Numbers (if needed)| 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | 202 : Additional Unreachable Destination IPv6 Addresses (if needed) : 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Type TBD 208 The format of the Route Error message is illustrated above, and is 209 identical to the format for the IPv4 RERR message except that the IP 210 addresses are 128 bits, not 32 bits, and the Type is TBD. The order 211 of the fields for the IPv6 addresses and the associated sequence 212 numbers has been changed to enable alignment along 64-bit boundaries. 214 6. Route Reply Acknowledgment (RREP-ACK) Message Format 216 0 1 217 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type | Reserved | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Type 19 224 Reserved Sent as 0; ignored on reception. 226 The RREP-ACK message is used to acknowledge receipt of an RREP 227 message. It is used in cases where the link over which the RREP 228 message is sent may be unreliable. It is identical in format to the 229 RREP-ACK message for IPv4, except that the type is 19. 231 7. AODV for IPv6 Operation 233 The handling of AODV for IPv6 messages in sections 3,4,5,6 is 234 analogous to the operation of AODV for IPv4 [4], except that the 235 RREQ, RREP, RERR, and RREP-ACK messages in this document are to be 236 used instead; these messages have the formats appropriate for use 237 with 128-bit IPv6 addresses. 239 Whenever AODV for IPv4 specifies use of ICMP, the operation for IPv6 240 requires that the analogous messages from ICMPv6 [2] are to be used 241 instead. 243 8. Extensions 245 RREQ and RREP messages for IPv6 use extensions with the same numbers 246 and format as those extensions defined for IPv4. 248 9. Configuration Parameters 250 The configuration parameters and default values used by AODV for IPv6 251 are the same as those used by AODV for IPv4. The Hop Limit field of 252 the IPv6 header MUST be set to a value no greater than NET_DIAMETER 253 for each AODV message. 255 10. Flooding Data to a Specific Destination 257 For situations in which a message has to be transmitted to a 258 particular destination, the RREQ/RREP route discovery cycle may 259 require a round trip across the entire ad hoc network and back before 260 any data can be delivered. In many circumstances, this represents a 261 significant and unwanted delay. The fewer packets that need to be 262 transmitted to the destination, the more unwelcome the initial delay 263 may be. This first round trip delay appears as an especially large 264 fraction of the total transaction time between endpoints when only a 265 few bytes of data have to be delivered, which could all fit within a 266 single flooded packet. 268 To avoid this problem, a Flood Data hop-by-hop option is specified 269 that allows a packet to be targeted to a particular destination even 270 when the source does not have a route to that destination. AODV 271 furthermore specifies that this hop-by-hop option starts the route 272 discovery process. Then the route request can be satisfied at an 273 intermediate node after it unicasts the data packet towards the 274 destination. 276 When the destination responds to such flooded data packets, it 277 typically needs to stabilize the reverse path back to the source. It 278 does so by inserting a Route Reply hop-by-hop option into the return 279 data packet. 281 10.1. Flood Data Option 283 The format of the Flood Data Option is as follows: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Option Type | Option Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 |J|R|G| Reserved | Hop Count | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | 32-bit Flooding ID | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | 32-bit Destination Sequence Number | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | 32-bit Source Sequence Number | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | 128-bit Destination IP Address | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Sub-Options... 301 +-+-+-+-+-+-+-+-+-+-+-+- 303 The fields of this hop-by-hop option are defined as for the RREQ 304 message (see section 3), except that there is no longer any need to 305 have the source IPv6 address in the option data. That fields are 306 available in the IPv6 header. The destination IPv6 address in the 307 IP header is set to be the ``All Nodes Address'' lnk-local multicast 308 address (FF02:0:0:0:0:0:0:1) [3], which cannot be forwarded. The 309 Hop Limit field of the IPv6 header is set to a value no greater than 310 NET_DIAMETER [4], with smaller values often preferred in order to 311 limit the dissemination of the RREQ to nearby nodes only. 313 The rules for setting up reverse path route entries to the source 314 IPv6 node are the same as for the RREQ message, which are the same 315 as the rules for the analogous IPv4 messages [4]. Just as with 316 the analogous IPv4 message, the Flooding-ID field is used to avoid 317 extraneous retransmissions for flooded packets. 319 10.2. Flood Data Reply Option 321 The Flood Data Reply hop-by-hop option is used to return data to the 322 source of a data packet containing the Flood Data hop-by-hop option. 324 The format of the Flood Data Reply Option is as follows: 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Option Type | Option Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |R|A| Reserved | Prefix Size | Hop Count | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | 32-bit Destination Sequence Number | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Lifetime | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Sub-Options... 338 +-+-+-+-+-+-+-+-+-+-+-+- 340 The fields of this option are defined in the same way as for the 341 Route Reply (RREP) message (see section 4). The rules for setting 342 up forward path route entries to the destination IPv6 node are the 343 same as for the RREP message, which are the same as the rules for the 344 analogous IPv4 messages [4]. 346 11. Security Considerations 348 Currently, AODV does not specify any special security measures. 349 Route protocols, however, are prime targets for impersonation 350 attacks, and must be protected by use of authentication techniques 351 involving generation of unforgeable and cryptographically strong 352 message digests or digital signatures. It is expected that, in 353 environments where security is an issue, that IPSec authentication 354 headers will be deployed along with the necessary key management to 355 distribute keys to the members of the ad hoc network using AODV. 357 References 359 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 360 Levels. Request for Comments (Best Current Practice) 2119, 361 Internet Engineering Task Force, March 1997. 363 [2] A. Conta and S. Deering. Internet Control Message Protocol 364 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 365 Specification. Request for Comments (Draft Standard) 2463, 366 Internet Engineering Task Force, December 1998. 368 [3] R. Hinden and S. Deering. IPv6 Multicast Address Assignments. 369 Request for Comments (Informational) 2375, Internet Engineering 370 Task Force, July 1998. 372 [4] C. Perkins, E. Royer, and S. Das. Ad Hoc On Demand Distance 373 Vector (AODV) Routing (work in progress). Internet Draft, 374 Internet Engineering Task Force. 375 draft-ietf-manet--aodv-09.txt, November 2001. 377 [5] Charles E. Perkins, Elizabeth M. Royer, and Samir R. 378 Das. IP Broadcast in Ad hoc Networks (work in progress). 379 draft-ietf-manet-bcast-02.txt, November 2001. 381 Author's Addresses 383 Questions about this memo can be directed to: 385 Charles E. Perkins 386 Communications Systems Laboratory 387 Nokia Research Center 388 313 Fairchild Drive 389 Mountain View, CA 94303 390 USA 391 +1 650 625 2986 392 +1 650 625 2502 (fax) 393 charliep@iprg.nokia.com 395 Elizabeth M. Belding-Royer 396 Dept. of Computer Science 397 University of California, Santa Barbara 398 Santa Barbara, CA 93106 399 +1 805 893 3411 400 +1 805 893 8553 (fax) 401 ebelding@cs.ucsb.edu 403 Samir R. Das 404 Department of Electrical and Computer Engineering 405 & Computer Science 406 University of Cincinnati 407 Cincinnati, OH 45221-0030 408 +1 513 556 2594 409 +1 513 556 7326 (fax) 410 sdas@ececs.uc.edu