idnits 2.17.1 draft-ietf-ipv6-optimistic-dad-00.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 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 182: '... such, the Optimistic algorithm SHOULD...' RFC 2119 keyword, line 265: '...s 6.3.7) A node MUST NOT send a Route...' RFC 2119 keyword, line 266: '... address. Router Solicitations SHOULD...' RFC 2119 keyword, line 268: '... they MAY be sent from a Tentat...' RFC 2119 keyword, line 271: '...s 7.2.2) A node MUST NOT use a Tentat...' (24 more instances...) 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.) -- The document date (23 March 2004) is 7338 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 section? 'RFC2119' on line 514 looks like a reference -- Missing reference section? 'RFC2461' on line 523 looks like a reference -- Missing reference section? 'RFC2462' on line 527 looks like a reference -- Missing reference section? 'SOTO' on line 550 looks like a reference -- Missing reference section? 'KOODLI' on line 546 looks like a reference -- Missing reference section? 'RFC2464' on line 531 looks like a reference -- Missing reference section? 'RFC1750' on line 510 looks like a reference -- Missing reference section? 'SEND-CGA' on line 558 looks like a reference -- Missing reference section? 'RFC3041' on line 535 looks like a reference -- Missing reference section? 'RFC2373' on line 519 looks like a reference -- Missing reference section? 'MIPV6' on line 542 looks like a reference -- Missing reference section? 'SEND' on line 554 looks like a reference -- Missing reference section? 'Note 1' on line 497 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 15 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 23 March 2004 6 Optimistic Duplicate Address Detection 7 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/lid-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Definitions of requirements keywords are in accordance with the IETF 30 Best Current Practice - RFC2119 [RFC2119] 32 Abstract 34 Optimistic Duplicate Address Detection is an interoperable 35 modification of the existing IPv6 Neighbour Discovery (RFC2461) and 36 Stateless Address Autoconfiguration (RFC2462) process. The intention 37 is to minimize address configuration delays in the successful case 38 without greatly increasing disruption in the less likely failure 39 case, and while remaining interoperable with unmodified nodes. 41 Table of Contents 43 Status of this Memo ......................................... 1 44 Abstract .................................................... 1 45 Table of Contents ........................................... 2 46 1. Introduction ............................................. 2 47 1.1 Problem Statement ............................... 3 48 1.2 History ......................................... 3 49 1.3 Definitions ..................................... 4 50 1.4 Abbreviations ................................... 4 51 2. Optimistic Behaviours .................................... 5 52 3. Modifications to RFC-compliant behaviour ................. 7 53 3.1 Modifications to RFC 2461 Neighbour Discovery ... 7 54 3.2 Modifications to RFC 2462 SAA ................... 7 55 3.3 Address Generation............................... 8 56 3.4 DIID vs DAD ..................................... 9 57 4. Protocol Operation ....................................... 9 58 4.1 Simple case ..................................... 10 59 4.2 Collision case .................................. 10 60 4.3 Interoperation cases ............................ 11 61 4.4 Pathological cases .............................. 11 62 5. Security Considerations .................................. 12 63 Notes ....................................................... 12 64 References .................................................. 13 65 Acknowledgments ............................................. 14 66 Author's Address ............................................ 14 68 1. Introduction 70 Optimistic Duplicate Address Detection (DAD) is a modification of the 71 existing IPv6 Neighbour Discovery (ND) [RFC2461] and Stateless 72 Address Autoconfiguration (SAA) [RFC2462] process. The intention is 73 to minimize address configuration delays in the successful case, and 74 to reduce disruption as far as possible in the failure case. 76 Optimistic DAD is a useful optimization because DAD is far more 77 likely to succeed than fail for a well-distributed random address 78 [SOTO]. Disruption is minimized by limiting nodes' participation in 79 Neighbour Discovery while their addresses are still Tentative. 81 It is not the intention of this draft to improve the security, 82 reliability or robustness of DAD beyond that of existing standards, 83 merely to provide a method to make it faster. 85 1.1 Problem Statement 87 The existing IPv6 address configuration mechanisms provide adequate 88 collision detection mechanisms for the static hosts they were 89 designed for. However, a growing population of nodes need to 90 maintain continuous network access despite frequently changing their 91 network attachment. Optimizations to the DAD process are required to 92 provide these nodes with sufficiently fast address configuration. 94 An optimized DAD method needs to: 96 * provide interoperability with nodes using the current standards. 98 * remove the RetransTimer delay during address configuration. 100 * ensure the probability of address collision is not increased. 102 * improve the resolution mechanisms for address collisions. 104 * minimize disruption in the case of a collision. 106 It is not sufficient to merely reduce RetransTimer in order to reduce 107 the handover delay, as values of RetransTimer long enough to 108 guarantee detection of a collision are too long to avoid disruption 109 of time-critical services. 111 1.2 History 113 There is some precedent for this work in previous drafts [KOODLI], 114 and in discussions in the MobileIP WG mailing list and at IETF-54. 115 This version of Optimistic DAD differs somewhat from previous 116 versions in that it uses no additional flags or message types beyond 117 those already defined, therefore allowing interoperation between 118 Optimistic and Standard nodes. 120 Earlier versions of this work were presented by the author to the 121 MobileIP WG at IETF-56, and to the IPv6 WG at IETF-59. 123 Working implementations of earlier versions of this draft have been 124 made by the author as a freely-available patch to Linux 2.4.18, and 125 by Ed Remmel of Elmic Systems. 127 1.3 Definitions 129 Tentative - an address for which a node has not yet completed DAD is 130 regarded as Tentative: a single Neighbour Advertisement 131 defending this address will cause the node to deconfigure the 132 address and cease using it. 134 Optimistic - An Optimistic node assumes that DAD will succeed, and 135 allows higher-layer communications on an address even while that 136 address is still Tentative. 138 Standard - A Standard node is one which is compliant with RFCs 2461 139 and 2462. 141 Link - A communication facility or medium over which nodes can 142 communicate at the link layer. 144 Neighbours - Nodes on the same link, which may therefore be competing 145 for the same addresses. 147 1.4 Abbreviations 149 DAD - Duplicate Address Detection. Technique used for SAA. See 150 [RFC2462] section 5.4. 152 ICMP Redirect - See [RFC2461] section 4.5. 154 NA - Neighbour Advertisement. See [RFC2461] sections 4.4 and 7. 156 NC - Neighbour Cache. See [RFC2461] section 5.1 and 7.3. 158 ND - Neighbour Discovery. The process described in [RFC2461] 160 NS - Neighbour Solicitation. See [RFC2461] sections 4.3 and 7. 162 ON - Optimistic Node. A node which is behaving according to the 163 rules of this draft. 165 RA - Router Advertisement. See [RFC2462] sections 4.2 and 6. 167 RS - Router Solicitation. See [RFC2461] sections 4.1 and 6. 169 SAA - Stateless Address Autoconfiguration. The process described in 170 [RFC2462] 172 SLLAO - Source Link Layer Address Option - an option to NS, RA and RS 173 messages, which gives the link layer address of the source of 174 the message. See [RFC2461] section 4.6.1. 176 TLLAO - Target Link Layer Address Option - an option to ICMP redirect 177 messages. See [RFC2461] sections 4.5 and 4.6.1. 179 2. Optimistic Behaviours 181 Optimistic DAD is only a useful optimization when the probability of 182 collision is very small. As such, the Optimistic algorithm SHOULD 183 NOT be used for manually assigned addresses, where the collision 184 probability is likely to be much higher than that for random 185 addresses due to human error. 187 Modifications are required only to Optimistic nodes -- Optimistic 188 nodes will interoperate with Standard nodes without significant 189 advantage or incompatibility. 191 In order to do this, it is important that an Optimistic node does 192 not, while Tentative, send any messages which will override its 193 neighbours' Neighbour Cache (NC) entries for the address it is trying 194 to configure: doing so would disrupt the rightful owner of the 195 address in the case of a collision. 197 This is achieved by: 199 * clearing the 'Override' flag in Neighbour Advertisements for 200 Tentative addresses, which prevents neighbours from overriding 201 their existing NC entries. The 'Override' flag is already 202 defined [RFC2461] and used for Proxy Neighbour Advertisement. 204 * Never sending Neighbour Solicitations from a Tentative address. 205 NSs include a Source Link Layer Address Option (SLLAO), which 206 may cause Neighbour Cache disruption. NSs sent as part of DAD 207 are sent from the unspecified address, without a SLLAO. 209 * Never using a Tentative address as the source address of a Router 210 Solicitation with an SLLAO. Another address, or the unspecified 211 address, may be used, or the RS may be sent without an SLLAO. 212 An address collision with a router may cause neighbours' 213 IsRouter flags for that address to be cleared, however the RA 214 sent in response will reset the IsRouter flag. 216 It may be desirable for a Neighbour, for example the router, to 217 rapidly establish communication with the newly configured 218 Optimistic Node (ON). To do so, it must learn of the ON's 219 arrival as soon as possible. To avoid having to wait for 220 Neighbour Discovery, the ON may wish to send unsolicited 221 Neighbour Advertisements (with the Override flag set 222 appropriately), but for this to be effective the Neighbour must 223 either: 225 * be expecting the ON to arrive (eg: due to predictive 226 mechanisms), and thus already have a NC entry for the peer, 227 in state INCOMPLETE. 229 * be willing to cache unsolicited NAs (for a short period of 230 time), so that an entry will have been created with state 231 STALE. 233 These modifications are beyond the scope of this draft. 235 The ON may choose to send unsolicited NAs to the All Nodes Multicast, 236 to the All Routers Multicast, or Unicast to the source of the RA 237 which alerted it to this new prefix. This allows flexibility with 238 regard to Layer 2 multicast transmission costs. 240 The case where the ON wants to contact its router is handled by the 241 SLLAO of the RA, where this is supplied. However, the router may 242 choose not to include the SLLAO (the example given in RFC2462 is "to 243 facilitate in-bound load balancing over replicated interfaces"). In 244 this case, the ON cannot discover its router until it is no longer 245 Tentative. Routers which do not include the SLLAO are not especially 246 suitable for use with Optimistic DAD. 248 When the ON wants to contact another neighbour, but it cannot because 249 the neighbour is not in its NC, it should instead forward the packet 250 to the router, relying on the router to forward the packet. The 251 router should then provide the ON with an ICMP redirect, which may 252 include a Target Link Layer Address Option (TLLAO). If it does, this 253 will update the ON's NC, and direct communication can begin. 255 Because Optimistic DAD allows nodes to communicate despite being 256 Tentative, RetransTimer may be left at the default 1000ms without 257 significant penalty. It is also possible to increase 258 DupAddrDetectTransmits and thus reduce the probability of an 259 undetected address collision due to packet loss. 261 3. Modifications to RFC-mandated behaviour 263 3.1 Modifications to RFC 2461 Neighbour Discovery 265 * (modifies 6.3.7) A node MUST NOT send a Router Solicitation with 266 an SLLAO from a Tentative address. Router Solicitations SHOULD 267 be sent from a non-Tentative or the Unspecified address, however 268 they MAY be sent from a Tentative address as long as the SLLAO 269 is not included. 271 * (modifies 7.2.2) A node MUST NOT use a Tentative address as the 272 source address of a Neighbour Solicitation. 274 * (modifies 7.2.2) When a node has a unicast packet to send from a 275 Tentative address to a neighbour, but does not know the 276 neighbour's link-layer address, it MUST NOT perform Neighbour 277 Discovery but instead SHOULD forward the packet to the router of 278 that network. 280 * (adds to 7.2.6) The Optimistic node MAY send an unsolicited 281 Neighbour Advertisement to All Nodes when it first configures an 282 address. The Override flag on this advertisement MUST be cleared 283 (O=0). 285 * (adds to 7.2.6) The Optimistic node MAY send an unsolicited NA to 286 All Nodes when it completes DAD. The Override flag on this 287 advertisement SHOULD be set (O=1). 289 3.2 Modifications to RFC 2462 Stateless Address Autoconfiguration 291 * (modifies 5.5) When an Optimistic node decides to configure an 292 address, it appends a suffix generated as per Section 3.3 to a 293 prefix received from a Router Advertisement. 295 * (modifies 5.4) As soon as the initial Neighbour Solicitation (and 296 optional unsolicited Neighbour Advertisement) is sent, the 297 address is configured on the interface and available for use 298 immediately. 300 * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for 301 its address from the unspecified address with a Neighbour 302 Advertisement to the All Nodes address. If the solicitation is 303 for an address which is still Tentative, the reply MUST have the 304 Override flag cleared (O=0). 306 * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for 307 its address from a unicast address, even while Tentative, but 308 the reply MUST have the Override flag cleared (O=0). 310 * (modifies 5.4.5) A Tentative address that is determined to be a 311 duplicate MUST be deconfigured immediately. If the address is a 312 link-local address formed from an interface identifier based on 313 the hardware address (e.g. EUI-64), the interface SHOULD be 314 disabled. Otherwise, if the address was automatically 315 configured, DAD SHOULD be restarted with a new address generated 316 as per "Address Generation" below. 318 * DupAddrDetectTransmits SHOULD be increased where there is a 319 significant probability of packet loss. 321 3.3 Address Generation 323 In order for Optimistic DAD to be a useful optimization, the 324 probability of a collision must be very small, as a collision may 325 cause temporary disruption to the collidee, and will require the 326 collidor to reconfigure. 328 Some interfaces (for example, Ethernet [RFC2464]) offer methods to 329 create an address based on a globally unique Interface Identifier, 330 however it is conceivable that due to manufacturer or user error that 331 the generated address may not in fact be unique. 333 * The Optimistic algorithm SHOULD NOT be used on manually configured 334 addresses, as the probability of collision for manually 335 configured addresses is considerably higher than that for other 336 methods. 338 * If the interface offers a method to create a globally unique IPv6 339 address from a unique interface identifier, (eg: an EUI-64 340 Interface Identifier) this address MAY be used for the first 341 attempt. 343 * Otherwise, or when creating a new address in the case of a 344 collision, a new suffix is created. The algorithm used MUST 345 have a uniform distribution to minimize the chance of address 346 collision. 348 * The suffix MAY be chosen using a random number generator. 349 (see [RFC1750] for more information on random number 350 generation), 352 * The suffix MAY be derived from a hash function, as in [SEND- 353 CGA]. 355 * The algorithm used MAY be one of those documented in 356 [RFC3041]. 358 * A randomly generated address SHOULD have the Universal/Local bit 359 and the Individual/Group bit set to 0 to indicate a Unicast 360 address which is not globally unique (see [RFC2373]). 362 * The first time DAD fails, a new suffix is generated and the node 363 SHOULD retry immediately. 365 * A delay of at least RETRANS_TIMER (as used in [RFC2461]) 366 milliseconds MUST be introduced between further retries, to 367 minimize the effect of DoS attacks. An exponential backoff 368 SHOULD be used. 370 3.4 DAD vs DIID 372 This section has been removed as the issue has been reviewed for 373 RFC2462bis. 375 4. Protocol Operation 377 The following cases all consider an Optimistic Node (ON) receiving a 378 Router Advertisement containing a new prefix and deciding to 379 autoconfigure a new address on that prefix. 381 The following cases assume that the RA contains a SLLAO, for reasons 382 explained in Section 2. 384 The ON will immediately send out a Neighbour Solicitation to 385 determine if its new address is already in use, and a Neighbour 386 Advertisement (with the Override flag cleared) for the address. This 387 NA allows communication with neighbours to begin immediately. 389 4.1 Simple case 391 In the non-collision case, the address being configured by the new 392 node is unused and not present in the Neighbour Caches of any of its 393 neighbours. 395 Therefore, there will be no response to its NS, and the NA with O=0 396 will be sufficient to create Neighbour Cache entries in already 397 interested neighbours. 399 The Optimistic Node already has the link-layer address of the router 400 (from the RA), and the router either already knows the link-layer 401 address of the ON from the unsolicited NA, or can determine it 402 through standard NUD. Communications can begin as soon as the router 403 and the ON have each others' link-layer addresses. 405 After the appropriate DAD delay, the address is marked as non- 406 Tentative, and another NA is sent, this time with O=1. This will 407 ensure that all Neighbour Caches are up-to-date. 409 4.2 Collision cases 411 In the simplest collision case, the address being configured by the 412 new node is already in use by another node, and present in the 413 Neighbour Caches (NCs) of neighbours which are communicating with 414 this node. 416 Since the Optimistic advertisement has O=0, it will not override 417 existing NC entries. An NA with O=0,S=0 and with a SLLAO may [Note 418 1], however cause the NC entry to be set to STALE, causing NUD to be 419 performed on the address. 421 Nodes with no interest in communicating with the new address "SHOULD" 422 silently discard the NA [RFC2461 7.2.5], and so will likely be 423 undisturbed. 425 If a neighbour is just preparing to begin communication with the 426 address, eg: it has a NC entry for the address in state 'INCOMPLETE', 427 the optimistic advertisement may cause an incorrect NC entry to be 428 created in state 'STALE' and queued packets to be sent to an 429 incorrect destination. 431 In general, the defending NA will have the Override flag set (O=1), 432 and so this will correct the incorrect entry almost immediately. 433 However, if the defending NA has the Override flag cleared (for 434 example when the address is in use by proxy) the defending 435 advertisement will not override this incorrect NC entry. In any case, 436 the NC entry will remain in state 'STALE', and thus the disruption 437 will be recoverable, albeit slowly, by the standard Neighbour 438 Unreachability Detection mechanism. 440 Of course, in the meantime the ON may have sent packets which 441 identify it as the owner of its new Tentative address (for example, 442 Binding Updates in [MIPV6]). This may incur some penalty to the ON, 443 in the form of broken connections, and some penalty to the rightful 444 owner of the address, since it will receive (and potentially reply 445 to) the misdirected packets. It is for this reason that Optimistic 446 DAD should only be used where the probability of collision is 447 exceedingly low. 449 4.3 Interoperation cases 451 Once the Optimistic Node has completed DAD, it acts exactly like a 452 Standard node, and so interoperation cases only arise while an 453 Optimistic Node is Tentative. 455 If an Optimistic Node attempts to configure an address currently 456 Tentatively assigned to a Standard Node, the Standard Node will see 457 the Neighbour Solicitation and deconfigure the address. In contrast, 458 if a node attempts to configure an address currently Tentatively 459 assigned to an Optimistic Node, the Optimistic Node will not 460 deconfigure the address, and instead defend with a Neighbour 461 Advertisement, causing the newcomer to reconfigure. This gives the 462 Optimistic Node a slight advantage over Standard nodes, however this 463 is justified since the Optimistic node may have already established 464 connections while Tentative. 466 4.4 Pathological cases 468 Optimistic DAD suffers from similar problems to Standard DAD, for 469 example duplicates are not guaranteed to be detected if packets are 470 lost, and if two nodes configure simultaneously, they may each miss 471 the other's NS. 473 These problems exist, and are not gracefully recoverable, in Standard 474 DAD. The probability of such a collision is reduced in Optimistic DAD 475 due to the pair of messages (NS, NA) sent. The probability can be 476 further reduced by increasing the RFC2462 DupAddrDetectTransmits 477 variable to greater than 1. 479 This version of Optimistic DAD is dependant on the details of the 480 router behaviour, eg: if it includes SLLAOs in RAs, and if it is 481 willing to redirect traffic for the ON. Where the router does not 482 behave in this way, the behaviour of Optimistic DAD reverts to that 483 of Standard DAD. 485 5. Security Considerations 487 There are existing security concerns with Neighbour Discovery and 488 Stateless Address Autoconfiguration, and this draft does not purport 489 to fix them. However, this draft does not significantly increase 490 security concerns either. 492 Further work will be required to integrate Optimistic DAD with Secure 493 Neighbour Discovery [SEND]. 495 Notes 497 [Note 1] RFC 2461 is unclear on this, with [RFC2461 7.2.5] specifying 498 "the advertisement prompts future Neighbour Unreachability 499 Detection [...] by changing the state in the cache entry" 500 whereas [RFC2461 Appendix C] specifies the state as "unchanged". 501 Many arguments have been made on the list (see 502 ) 503 for one interpretation or the other. For the purposes of this 504 draft, I have assumed that either behaviour is possible. 506 This issue is to be addressed in RFC2461bis. 508 RFC References 510 [RFC1750] D. Eastlake, S. Crocker, J. Schiller. "Randomness 511 Recommendation for Security." Request for Comments 1750, 512 Internet Engineering Task Force, December 1994. 514 [RFC2119] S. Bradner. "Key words for use in RFCs to Indicate 515 Requirement Levels." Request for Comments (Best Current 516 Practice) 2119 (BCP 14), Internet Engineering Task Force, March 517 1997. 519 [RFC2373] R. Hinden, S. Deering. "IP Version 6 Addressing 520 Architecture." Request for Comments (Proposed Standard) 2373, 521 Internet Engineering Task Force, July 1998. 523 [RFC2461] T. Narten, E.Nordmark, W. Simpson. "Neighbor Discovery for 524 IP Version 6 (IPv6)." Request for Comments (Draft Standard) 525 2461, Internet Engineering Task Force, December 1998. 527 [RFC2462] S. Thomson, T. Narten. "IPv6 Stateless Address 528 Autoconfiguration." Request for Comments (Draft Standard) 2462, 529 Internet Engineering Task Force, December 1998. 531 [RFC2464] M. Crawford. "Transmission of IPv6 Packets over Ethernet 532 Networks." Request for Comments (Proposed Standard) 2464, 533 Internet Engineering Task Force, December 1998. 535 [RFC3041] T. Narten, R. Draves. "Privacy Extensions for Stateless 536 Address Autoconfiguration in IPv6." Request for Comments 537 (Proposed Standard) 3041, Internet Engineering Task Force, 538 January 2001. 540 Internet Draft References 542 [MIPV6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6, 543 revision 24 (draft-ietf-mobileip-ipv6-24). June 2003 ... 544 Expired December 2003. 546 [KOODLI] R. Koodli, C. Perkins. Fast Handovers in Mobile IPv6, 547 revision 00 (draft-koodli-mobileip-fastv6-00). October 2000 ... 548 Expired April 2001. 550 [SOTO] M. Bagnulo, I. Soto, A. Garcia-Martinez, A. Azcorra. Random 551 generation of interface identifiers, revision 00. (draft-soto- 552 mobileip-random-iids-00). January 2002 ... Expired July 2002. 554 [SEND] J. Arkko, J. Kempf, B. Sommerfeld, B.Zill, P. Nikander. 555 SEcure Neighbor Discovery (SEND), revision 03. (draft-ietf- 556 send-ndopt-03). January 2004 ... Expires July 2004. 558 [SEND-CGA] T. Aura, Cryptographically Generated Addresses (CGA), 559 revision 01. (draft-ietf-send-cga-01). August 1, 2003. 561 Acknowledgments 563 Thanks to Greg Daley, Brett Pentland and Ahmet Sekercioglu at Monash 564 Uni CTIE for their feedback and encouragement. More information is 565 available at . 567 Thanks to all the MobileIP and IPng/IPv6 WG members who contributed 568 to the debate. Especially and alphabetically: Jari Arkko, JinHyeock 569 Choi, Youn-Hee Han, James Kempf, Thomas Narten, Richard Nelson, Pekka 570 Nikander, Soohong 'Daniel' Park, Ed Remmel, Pekka Savola, Hesham 571 Soliman, Ignatious Souvatzis, Jinmei Tatuya, Pascal Thubert, 572 Vladislav Yasevich and Alper Yegin. 574 This work has been supported by the Australian Telecommunications 575 Cooperative Research Centre (ATcrc) 576 578 Author's Address: 580 Nick 'Sharkey' Moore 581 or 582 Centre for Telecommunications and Information Engineering 583 Monash University 3800 584 Victoria, Australia