idnits 2.17.1 draft-ietf-ipv6-optimistic-dad-01.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 673. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 655), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 5) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (28 June 2004) is 7240 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) == Missing Reference: 'Note 1' is mentioned on line 551, but not defined ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-02) exists of draft-koodli-mobileip-fastv6-00 == Outdated reference: A later version (-06) exists of draft-ietf-send-ndopt-03 == Outdated reference: A later version (-06) exists of draft-ietf-send-cga-01 Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group Nick 'Sharkey' Moore 3 INTERNET-DRAFT Monash University CTIE 4 28 June 2004 6 Optimistic Duplicate Address Detection for IPv6 7 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 Optimistic Duplicate Address Detection is an interoperable 39 modification of the existing IPv6 Neighbour Discovery (RFC2461) and 40 Stateless Address Autoconfiguration (RFC2462) process. The intention 41 is to minimize address configuration delays in the successful case 42 without greatly increasing disruption in the less likely failure 43 case, and while remaining interoperable with unmodified nodes. 45 Table of Contents 47 Status of this Memo ......................................... 1 48 Abstract .................................................... 1 49 Table of Contents ........................................... 2 50 1. Introduction ............................................. 3 51 1.1 Problem Statement ............................... 3 52 1.2 History ......................................... 4 53 1.3 Definitions ..................................... 4 54 1.4 Abbreviations ................................... 5 55 2. Optimistic Behaviours .................................... 6 56 2.1 Probability of Collision ........................ 6 57 2.2 Optimistic Address Flag ......................... 6 58 2.3 Avoiding Disruption ............................. 7 59 2.4 Rapid Establishment ............................. 7 60 2.5 Router Redirection .............................. 8 61 2.6 Improving Detection ............................. 8 62 3. Modifications to RFC-compliant behaviour ................. 9 63 3.1 Modifications to RFC 2461 Neighbour Discovery ... 9 64 3.2 Modifications to RFC 2462 SAA ................... 10 65 4. Protocol Operation ....................................... 11 66 4.1 Simple case ..................................... 11 67 4.2 Collision case .................................. 12 68 4.3 Interoperation cases ............................ 13 69 4.4 Pathological cases .............................. 13 70 5. Security Considerations .................................. 13 71 6. IANA Considerations ...................................... 14 72 Appendix A: Address Generation .............................. 14 73 Notes ....................................................... 14 74 Normative References ........................................ 15 75 Informative References ...................................... 15 76 Author's Address ............................................ 16 77 Acknowledgments ............................................. 16 78 Full Copyright Statment ..................................... 17 79 Intellectual Property Statement ............................. 17 80 Disclaimer of Validity ...................................... 17 82 1. Introduction 84 Optimistic Duplicate Address Detection (DAD) is a modification of the 85 existing IPv6 Neighbour Discovery (ND) [RFC2461] and Stateless 86 Address Autoconfiguration (SAA) [RFC2462] process. The intention is 87 to minimize address configuration delays in the successful case, and 88 to reduce disruption as far as possible in the failure case. 90 Optimistic DAD is a useful optimization because DAD is far more 91 likely to succeed than fail for a well-distributed random address 92 [SOTO]. Disruption is minimized by limiting nodes' participation in 93 Neighbour Discovery while their addresses are still Optimistic. 95 It is not the intention of this draft to improve the security, 96 reliability or robustness of DAD beyond that of existing standards, 97 merely to provide a method to make it faster. 99 1.1 Problem Statement 101 The existing IPv6 address configuration mechanisms provide adequate 102 collision detection mechanisms for the static hosts they were 103 designed for. However, a growing population of nodes need to 104 maintain continuous network access despite frequently changing their 105 network attachment. Optimizations to the DAD process are required to 106 provide these nodes with sufficiently fast address configuration. 108 An optimized DAD method needs to: 110 * provide interoperability with nodes using the current standards. 112 * remove the RetransTimer delay during address configuration. 114 * ensure the probability of address collision is not increased. 116 * improve the resolution mechanisms for address collisions. 118 * minimize disruption in the case of a collision. 120 It is not sufficient to merely reduce RetransTimer in order to reduce 121 the handover delay, as values of RetransTimer long enough to 122 guarantee detection of a collision are too long to avoid disruption 123 of time-critical services. 125 1.2 History 127 There is some precedent for this work in previous drafts [KOODLI], 128 and in discussions in the MobileIP WG mailing list and at IETF-54. 129 This version of Optimistic DAD differs somewhat from previous 130 versions in that it uses no additional flags or message types beyond 131 those already defined, therefore allowing interoperation between 132 Optimistic and Standard nodes. 134 Earlier versions of this work were presented by the author to the 135 MobileIP WG at IETF-56, and to the IPv6 WG at IETF-59. 137 Working implementations of draft versions of this memo have been made 138 by the author as a freely-available patch to Linux 2.4.18, and by Ed 139 Remmel of Elmic Systems. 141 An implementation of this version by the author is in progress. 143 1.3 Definitions 145 Definitions of requirements keywords ('MUST NOT', 'SHOULD NOT', 146 'MAY', 'SHOULD', 'MUST') are in accordance with the IETF Best Current 147 Practice - RFC2119 [RFC2119] 149 Tentative Address - an address for which a node has not yet completed 150 DAD is regarded as Tentative: a single Neighbour Solicitation 151 for this address or a single Neighbour Advertisement defending 152 this address will cause the node to deconfigure the address and 153 cease using it. 155 Deprecated Address - an address which should not be used if an 156 alternative is available. 158 Preferred Address - an address which is neither Tentative or 159 Deprecated. 161 Optimistic Address - an address which is available for use despite 162 DAD not being fully complete. This memo places restrictions on 163 the use of Optimistic Addresses. A single Neighbour 164 Advertisement for this address will cause the node to 165 deconfigure the address and cease using it. Optimistic 166 Addresses should also be regarded as Deprecated. 168 Optimistic Node - An Optimistic Node assumes that DAD will succeed, 169 and allows higher-layer communications on an address while DAD 170 completes. 172 Standard Node - A Standard Node is one which is compliant with RFCs 173 2461 and 2462. 175 Link - A communication facility or medium over which nodes can 176 communicate at the link layer. 178 Neighbours - Nodes on the same link, which may therefore be competing 179 for the same addresses. 181 1.4 Abbreviations 183 DAD - Duplicate Address Detection. Technique used for SAA. See 184 [RFC2462] section 5.4. 186 ICMP Redirect - See [RFC2461] section 4.5. 188 NA - Neighbour Advertisement. See [RFC2461] sections 4.4 and 7. 190 NC - Neighbour Cache. See [RFC2461] section 5.1 and 7.3. 192 ND - Neighbour Discovery. The process described in [RFC2461] 194 NS - Neighbour Solicitation. See [RFC2461] sections 4.3 and 7. 196 ON - Optimistic Node. A node which is behaving according to the 197 rules of this memo. 199 RA - Router Advertisement. See [RFC2462] sections 4.2 and 6. 201 RS - Router Solicitation. See [RFC2461] sections 4.1 and 6. 203 SAA - Stateless Address Autoconfiguration. The process described in 204 [RFC2462] 206 SLLAO - Source Link Layer Address Option - an option to NS, RA and RS 207 messages, which gives the link layer address of the source of 208 the message. See [RFC2461] section 4.6.1. 210 TLLAO - Target Link Layer Address Option - an option to ICMP redirect 211 messages. See [RFC2461] sections 4.5 and 4.6.1. 213 2. Optimistic DAD Behaviours 215 This section provides some discussion of Optimistic DAD Behaviours. 216 Section 3 provides more specific information on changes to RFC- 217 mandated behaviours. 219 2.1 Probability of Collision 221 Optimistic DAD is only a useful optimization when the probability of 222 collision is very small. As such, the Optimistic algorithm should 223 not be used for manually assigned addresses, where the collision 224 probability is likely to be much higher than that for random 225 addresses due to human error. 227 Modifications are required only to Optimistic nodes -- Optimistic 228 nodes will interoperate with Standard nodes without significant 229 advantage or incompatibility. 231 2.2 Optimistic Address Flag 233 [RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated 234 (in 5.5.4) Addresses. Addresses which are neither are said to be 235 Preferred. Tentative addresses may not be used for communication, 236 and Deprecated addresses should not be used for new communications. 237 These status flags may also be used by other standards documents, for 238 example Default Address Selection [RFC3484] uses these flags. 240 This draft introduces a new address state, 'Optimistic', which is 241 used to mark an address which is available for use but which has not 242 completed DAD. Protocols which do not understand this state should 243 treat it equivalently to 'Deprecated', to indicate that the address 244 is available for use but should not be used if another suitable 245 address is available. If address states are recorded as individual 246 flags, this can easily be achieved by setting 'Deprecated' when 247 'Optimistic' is set. When the DAD timer completes without incident, 248 the address becomes a Preferred address. 250 2.3 Avoiding Disruption 252 In order to avoid interference, it is important that an Optimistic 253 node does not send any messages from an Optimistic Address which will 254 override its neighbours' Neighbour Cache (NC) entries for the address 255 it is trying to configure: doing so would disrupt the rightful owner 256 of the address in the case of a collision. 258 This is achieved by: 260 * clearing the 'Override' flag in Neighbour Advertisements for 261 Optimistic addresses, which prevents neighbours from overriding 262 their existing NC entries. The 'Override' flag is already 263 defined [RFC2461] and used for Proxy Neighbour Advertisement. 265 * Never sending Neighbour Solicitations from an Optimistic Address. 266 NSs include a Source Link Layer Address Option (SLLAO), which 267 may cause Neighbour Cache disruption. NSs sent as part of DAD 268 are sent from the unspecified address, without a SLLAO. 270 * Never using a Optimistic Address as the source address of a Router 271 Solicitation with an SLLAO. Another address, or the unspecified 272 address, may be used, or the RS may be sent without an SLLAO. 274 An address collision with a router may cause neighbouring 275 router's IsRouter flags for that address to be cleared. 276 However, routers do not appear to use the IsRouter flag for 277 anything, and the NA sent in response to the collision will 278 reassert the IsRouter flag. 280 2.4 Rapid Establishment 282 It may be desirable for a Neighbour, for example the router, to 283 rapidly establish communication with the newly configured Optimistic 284 Node (ON). To do so, it must learn of the ON's arrival as soon as 285 possible. To avoid having to wait for Neighbour Discovery, the ON 286 may wish to send unsolicited Neighbour Advertisements (with the 287 Override flag cleared if the address is still Optimistic), but for 288 this to be effective the Neighbour must either: 290 * be expecting the ON to arrive (eg: due to predictive 291 mechanisms), and thus already have a NC entry for the peer, 292 in state INCOMPLETE. 294 * be willing to cache unsolicited NAs (for a short period of 295 time), so that an entry will have been created with state 296 STALE. 298 These modifications are beyond the scope of this memo. 300 The ON may choose to send unsolicited NAs to the All Nodes Multicast, 301 to the All Routers Multicast, or Unicast to the source of the RA 302 which alerted it to the new prefix. This allows flexibility with 303 regard to Layer 2 multicast transmission costs. 305 The case where the ON wants to contact its router is handled by the 306 SLLAO of the RA, where a SLLAO is supplied. However, the router may 307 choose not to include the SLLAO (the example given in RFC2462 is "to 308 facilitate in-bound load balancing over replicated interfaces"). In 309 this case, the ON cannot discover its router until it is no longer 310 Optimistic. 312 2.5 Router Redirection 314 When the ON wants to contact another neighbour, but it cannot because 315 the neighbour is not in its NC, it should instead forward the packet 316 to the router, relying on the router to forward the packet. The 317 router should then provide the ON with an ICMP redirect, which may 318 include a Target Link Layer Address Option (TLLAO). If it does, this 319 will update the ON's NC, and direct communication can begin. 321 2.6 Improving Detection 323 Because Optimistic DAD allows nodes to communicate immediately, 324 RetransTimer may be left at the default 1000ms without significant 325 penalty. It is also possible to increase DupAddrDetectTransmits and 326 thus reduce the probability of an undetected address collision due to 327 packet loss. 329 3. Modifications to RFC-mandated behaviour 331 3.1 Modifications to RFC 2461 Neighbour Discovery 333 * (modifies 6.3.7) A node MUST NOT send a Router Solicitation with 334 an SLLAO from an Optimistic Address. Router Solicitations 335 SHOULD be sent from a non-Optimistic or the Unspecified Address, 336 however they MAY be sent from an Optimistic Address as long as 337 the SLLAO is not included. 339 * (modifies 7.2.2) A node MUST NOT use an Optimistic Address as the 340 source address of a Neighbour Solicitation. 342 * (modifies 7.2.2) When a node has a unicast packet to send from an 343 Optimistic Address to a neighbour, but does not know the 344 neighbour's link-layer address, it MUST NOT perform Neighbour 345 Discovery but instead SHOULD forward the packet to the router of 346 that network. 348 * (adds to 7.2.6) The Optimistic node MAY send an unsolicited 349 Neighbour Advertisement to All Nodes when it first configures an 350 address. The Override flag on this advertisement MUST be cleared 351 (O=0). 353 * (adds to 7.2.6) The Optimistic node MAY send an unsolicited NA to 354 All Nodes when it completes DAD. The Override flag on this 355 advertisement SHOULD be set (O=1). 357 3.2 Modifications to RFC 2462 Stateless Address Autoconfiguration 359 * (modifies 5.5) When an Optimistic node decides to configure an 360 address, it generates a suffix and combines it with a prefix 361 received from a Router Advertisement. Appendix A provides some 362 suggestions for suffix generation. 364 * (modifies 5.4) As soon as the initial Neighbour Solicitation (and 365 optional unsolicited Neighbour Advertisement) is sent, the 366 address is configured on the interface and available for use 367 immediately. The address MUST be flagged as 'Optimistic'. 368 Protocols which do not understand this state SHOULD treat it 369 equivalently to 'Deprecated'. 371 * When the DAD timer expires on an Optimistic Address, the 372 'Optimistic' flag MUST be cleared, and the address becomes a 373 Preferred Address. 375 * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for 376 its address from the unspecified address with a Neighbour 377 Advertisement to the All Nodes address. If the solicitation is 378 for an Optimistic Address, the reply MUST have the Override flag 379 cleared (O=0). 381 * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for 382 an Optimstic Address from a unicast address, but the reply MUST 383 have the Override flag cleared (O=0). 385 * (modifies 5.4.5) An Optimistic Address that is determined to be a 386 duplicate MUST be deconfigured immediately. If the address is a 387 link-local address formed from an interface identifier based on 388 the hardware address (e.g. EUI-64), the interface SHOULD be 389 disabled. Otherwise, if the address was automatically 390 configured, DAD SHOULD be restarted with a new address. 391 (Appendix A suggests methods for generating a new address) 393 * DupAddrDetectTransmits SHOULD be increased where there is a 394 significant probability of packet loss. 396 4. Protocol Operation 398 The following cases all consider an Optimistic Node (ON) receiving a 399 Router Advertisement containing a new prefix and deciding to 400 autoconfigure a new address on that prefix. 402 The following cases assume that the RA contains a SLLAO, for reasons 403 explained in Section 2. 405 The ON will immediately send out a Neighbour Solicitation to 406 determine if its new address is already in use, and a Neighbour 407 Advertisement (with the Override flag cleared) for the address. This 408 NA allows communication with neighbours to begin immediately. 410 4.1 Simple case 412 In the non-collision case, the address being configured by the new 413 node is unused and not present in the Neighbour Caches of any of its 414 neighbours. 416 Therefore, there will be no response to its NS, and the NA with O=0 417 will be sufficient to create Neighbour Cache entries in already 418 interested neighbours. 420 The Optimistic Node already has the link-layer address of the router 421 (from the RA), and the router either already knows the link-layer 422 address of the ON from the unsolicited NA, or can determine it 423 through standard NUD. Communications can begin as soon as the router 424 and the ON have each others' link-layer addresses. 426 After the appropriate DAD delay, the address's Optimistic flag is 427 cleared and another NA is sent, this time with O=1. This will ensure 428 that all Neighbour Caches are up-to-date. 430 4.2 Collision cases 432 In the simplest collision case, the address being configured by the 433 new node is already in use by another node, and present in the 434 Neighbour Caches (NCs) of neighbours which are communicating with 435 this node. 437 Since the Optimistic advertisement has O=0, it will not override 438 existing NC entries. An NA with O=0,S=0 and with a SLLAO may [Note 439 1], however cause the NC entry to be set to STALE, causing NUD to be 440 performed on the address. 442 Nodes with no interest in communicating with the new address "SHOULD" 443 silently discard the NA [RFC2461 7.2.5], and so will likely be 444 undisturbed. 446 If a neighbour is just preparing to begin communication with the 447 address, eg: it has a NC entry for the address in state 'INCOMPLETE', 448 the optimistic advertisement may cause an incorrect NC entry to be 449 created in state 'STALE' and queued packets to be sent to an 450 incorrect destination. 452 In general, the defending NA will have the Override flag set (O=1), 453 and so this will correct the incorrect entry almost immediately. 454 However, if the defending NA has the Override flag cleared (for 455 example when the address is in use by proxy) the defending 456 advertisement will not override this incorrect NC entry. In any case, 457 the NC entry will remain in state 'STALE', and thus the disruption 458 will be recoverable, albeit slowly, by the standard Neighbour 459 Unreachability Detection mechanism. 461 Of course, in the meantime the ON may have sent packets which 462 identify it as the owner of its new Optimistic Address (for example, 463 Binding Updates in [MIPV6]). This may incur some penalty to the ON, 464 in the form of broken connections, and some penalty to the rightful 465 owner of the address, since it will receive (and potentially reply 466 to) the misdirected packets. It is for this reason that Optimistic 467 DAD should only be used where the probability of collision is very 468 low. 470 4.3 Interoperation cases 472 Once the Optimistic Address has completed DAD, it acts exactly like a 473 normal address, and so interoperation cases only arise while the 474 address is Optimistic. 476 If an Optimistic Node attempts to configure an address currently 477 Tentatively assigned to a Standard Node, the Standard Node will see 478 the Neighbour Solicitation and deconfigure the address. In contrast, 479 if a node attempts to configure an Optimistic Node's Optimistic 480 Address, the Optimistic Node will not deconfigure the address, and 481 instead defend with a Neighbour Advertisement, causing the newcomer 482 to reconfigure. This gives the Optimistic Node a slight advantage 483 over Standard nodes, however this is justified since the Optimistic 484 node may have already established connections to Optimistic 485 Addresses. 487 4.4 Pathological cases 489 Optimistic DAD suffers from similar problems to Standard DAD, for 490 example duplicates are not guaranteed to be detected if packets are 491 lost, and if two nodes configure simultaneously, they may each miss 492 the other's NS. 494 These problems exist, and are not gracefully recoverable, in Standard 495 DAD. The probability of such a collision is reduced in Optimistic DAD 496 due to the pair of messages (NS, NA) sent. The probability can be 497 further reduced by increasing the RFC2462 DupAddrDetectTransmits 498 variable to greater than 1. 500 This version of Optimistic DAD is dependant on the details of the 501 router behaviour, eg: if it includes SLLAOs in RAs, and if it is 502 willing to redirect traffic for the ON. Where the router does not 503 behave in this way, the behaviour of Optimistic DAD reverts to that 504 of Standard DAD. 506 5. Security Considerations 508 There are existing security concerns with Neighbour Discovery and 509 Stateless Address Autoconfiguration, and this memo does not purport 510 to fix them. However, this memo does not significantly increase 511 security concerns either. 513 Further work will be required to integrate Optimistic DAD with Secure 514 Neighbour Discovery [SEND]. 516 6. IANA Considerations 518 This document has no actions for IANA. 520 Appendix A: Address Generation 522 In order for Optimistic DAD to be a useful optimization, the 523 probability of a collision must be very small, as a collision may 524 cause temporary disruption to the collidee, and will require the 525 collidor to reconfigure. 527 Some interfaces (for example, Ethernet [RFC2464]) offer methods to 528 create an address based on a globally unique Interface Identifier, 529 however it is conceivable that due to manufacturer or user error that 530 the generated address may not in fact be unique. An address 531 generated in this manner may be used for a first attempt. 533 If an interface does not offer such a method, or if a new addres 534 needs to be created, an address should be created by an algorithm 535 with a uniform distribution to minimize the chance of address 536 collision. This algorithm could be a random number generator (see 537 [RFC1750] for more information on random number generation), or a 538 hash function as in [SEND-CGA] or one of those documented in 539 [RFC3041]. A randomly generated address should have the 540 Universal/Local bit and the Individual/Group bit set to 0 to indicate 541 a Unicast address which is not globally unique (see [RFC3513]). 543 The first time DAD fails, a new suffix is generated and the node can 544 retry immediately. A delay of at least RETRANS_TIMER (as used in 545 [RFC2461]) milliseconds can be introduced between further retries, to 546 minimize the effect of DoS attacks. An exponential backoff should be 547 used. 549 Notes 551 [Note 1] RFC 2461 is unclear on this, with [RFC2461 7.2.5] specifying 552 "the advertisement prompts future Neighbour Unreachability 553 Detection [...] by changing the state in the cache entry" 554 whereas [RFC2461 Appendix C] specifies the state as "unchanged". 555 Many arguments have been made on the list (see 556 ) 557 for one interpretation or the other. For the purposes of this 558 memo, I have assumed that either behaviour is possible. 560 This issue is to be addressed in RFC2461bis. 562 Normative References 564 [RFC2119] S. Bradner. "Key words for use in RFCs to Indicate 565 Requirement Levels." Request for Comments (Best Current 566 Practice) 2119 (BCP 14), Internet Engineering Task Force, March 567 1997. 569 [RFC3513] R. Hinden, S. Deering. "IP Version 6 Addressing 570 Architecture." Request for Comments (Proposed Standard) 3513, 571 Internet Engineering Task Force, April 2003. 573 [RFC2461] T. Narten, E.Nordmark, W. Simpson. "Neighbor Discovery for 574 IP Version 6 (IPv6)." Request for Comments (Draft Standard) 575 2461, Internet Engineering Task Force, December 1998. 577 [RFC2462] S. Thomson, T. Narten. "IPv6 Stateless Address 578 Autoconfiguration." Request for Comments (Draft Standard) 2462, 579 Internet Engineering Task Force, December 1998. 581 [RFC2464] M. Crawford. "Transmission of IPv6 Packets over Ethernet 582 Networks." Request for Comments (Proposed Standard) 2464, 583 Internet Engineering Task Force, December 1998. 585 Informative References 587 [RFC1750] D. Eastlake, S. Crocker, J. Schiller. "Randomness 588 Recommendation for Security." Request for Comments 589 (Informational) 1750, Internet Engineering Task Force, December 590 1994. 592 [RFC3041] T. Narten, R. Draves. "Privacy Extensions for Stateless 593 Address Autoconfiguration in IPv6." Request for Comments 594 (Proposed Standard) 3041, Internet Engineering Task Force, 595 January 2001. 597 [RFC3484] R. Draves. "Default Address Selection for Internet Protocol 598 version 6 (IPv6)". Request for Comments (Proposed Standard) 599 3484, Internet Engineering Task Force, February 2003. 601 [MIPV6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6, 602 revision 24 (draft-ietf-mobileip-ipv6-24). June 2003 ... 603 Expired December 2003. 605 [KOODLI] R. Koodli, C. Perkins. Fast Handovers in Mobile IPv6, 606 revision 00 (draft-koodli-mobileip-fastv6-00). October 2000 ... 607 Expired April 2001. 609 [SOTO] M. Bagnulo, I. Soto, A. Garcia-Martinez, A. Azcorra. Random 610 generation of interface identifiers, revision 00. (draft-soto- 611 mobileip-random-iids-00). January 2002 ... Expired July 2002. 613 [SEND] J. Arkko, J. Kempf, B. Sommerfeld, B.Zill, P. Nikander. 614 SEcure Neighbor Discovery (SEND), revision 03. (draft-ietf- 615 send-ndopt-03). January 2004 ... Expires July 2004. 617 [SEND-CGA] T. Aura, Cryptographically Generated Addresses (CGA), 618 revision 01. (draft-ietf-send-cga-01). August 1, 2003. 620 Author's Address: 622 Nick 'Sharkey' Moore 623 or 624 Centre for Telecommunications and Information Engineering 625 Monash University 3800 626 Victoria, Australia 628 Comments should be sent to either of the above email addresses. 630 Acknowledgments 632 Thanks to Greg Daley, Brett Pentland, Richard Nelson and Ahmet 633 Sekercioglu at Monash Uni CTIE for their feedback and encouragement. 634 More information is available at: 635 637 Thanks to all the MobileIP and IPng/IPv6 WG members who have 638 contributed to the debate. Especially and alphabetically: Jari 639 Arkko, JinHyeock Choi, Youn-Hee Han, James Kempf, Thomas Narten, 640 Richard Nelson, Pekka Nikander, Soohong 'Daniel' Park, Ed Remmel, 641 Pekka Savola, Hesham Soliman, Ignatious Souvatzis, Jinmei Tatuya, 642 Pascal Thubert, Vladislav Yasevich and Alper Yegin. 644 This work has been supported by the Australian Telecommunications 645 Cooperative Research Centre (ATcrc): 646 648 Funding for the RFC Editor function is currently provided by the 649 Internet Society. 651 Full Copyright Statement 653 Copyright (C) The Internet Society (2004). This document is subject 654 to the rights, licenses and restrictions contained in BCP 78 and 655 except as set forth therein, the authors retain all their rights. 657 Intellectual Property Statement 659 The IETF takes no position regarding the validity or scope of any 660 intellectual property or other rights that might be claimed to 661 pertain to the implementation or use of the technology described in 662 this document or the extent to which any license under such rights 663 might or might not be available; neither does it represent that it 664 has made any effort to identify any such rights. Information on the 665 IETF's procedures with respect to rights in IETF Documents can be 666 found in BCP 78 and 79. 668 Copies of IPR disclosures made to the IETF Secretariat and any 669 assurances of licenses to be made available, or the result of an 670 attempt made to obtain a general license or permission for the use of 671 such proprietary rights by implementers or users of this 672 specification can be obtained from the IETF on-line IPR repository at 673 http://www.ietf.org/ipr. 675 The IETF invites any interested party to bring to its attention any 676 copyrights, patents or patent applications, or other proprietary 677 rights which may cover technology that may be required to implement 678 this standard. Please address the information to the IETF at ietf- 679 ipr@ietf.org. 681 Disclaimer of Validity 683 This document and the information contained herein are provided on an 684 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 685 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 686 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 687 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 688 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 689 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.