idnits 2.17.1 draft-ietf-ipv6-optimistic-dad-04.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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 610. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 592), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == 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 (8 Feb 2005) is 7018 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: 'RFC3041' is mentioned on line 448, but not defined ** Obsolete undefined reference: RFC 3041 (Obsoleted by RFC 4941) == Unused Reference: 'KOODLI' is defined on line 541, but no explicit reference was found in the text ** 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 3315 (Obsoleted by RFC 8415) -- 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 Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Working Group Nick 'Sharkey' Moore 2 INTERNET-DRAFT Monash University CTIE 3 8 Feb 2005 5 Optimistic Duplicate Address Detection for IPv6 6 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 Optimistic Duplicate Address Detection is an interoperable 38 modification of the existing IPv6 Neighbor Discovery (RFC2461) and 39 Stateless Address Autoconfiguration (RFC2462) process. The intention 40 is to minimize address configuration delays in the successful case, 41 to reduce disruption as far as possible in the failure case and to 42 remain interoperable with unmodified hosts and routers. 44 Table of Contents 46 Status of this Memo ......................................... 1 47 Abstract .................................................... 1 48 Table of Contents ........................................... 2 49 1. Introduction ............................................. 3 50 1.1 Problem Statement ............................... 3 51 1.2 Definitions ..................................... 4 52 1.3 Abbreviations ................................... 5 53 2. Optimistic Behaviours .................................... 6 54 2.1 Optimistic Address Flag ......................... 6 55 2.2 Avoiding Disruption ............................. 6 56 2.3 Router Redirection .............................. 7 57 3. Modifications to RFC-compliant behaviour ................. 8 58 3.1 General ......................................... 8 59 3.2 Modifications to RFC 2461 Neighbor Discovery .... 8 60 3.3 Modifications to RFC 2462 SLAAC ................. 9 61 4. Protocol Operation ....................................... 10 62 4.1 Simple case ..................................... 10 63 4.2 Collision case .................................. 11 64 4.3 Interoperation cases ............................ 11 65 4.4 Pathological cases .............................. 12 66 5. Security Considerations .................................. 12 67 6. IANA Considerations ...................................... 12 68 Appendix A: Probability of Collision ........................ 13 69 A.1 The Birthday Paradox ............................ 13 70 A.2 Individual Moving Nodes ......................... 14 71 Normative References ........................................ 15 72 Informative References ...................................... 15 73 Author's Address ............................................ 16 74 Acknowledgments ............................................. 16 75 Full Copyright Statement .................................... 16 76 Intellectual Property Statement ............................. 17 77 Disclaimer of Validity ...................................... 17 79 1. Introduction 81 Optimistic Duplicate Address Detection (DAD) is a modification of the 82 existing IPv6 Neighbor Discovery (ND) [RFC2461] and Stateless Address 83 Autoconfiguration (SLAAC) [RFC2462] process. The intention is to 84 minimize address configuration delays in the successful case, and to 85 reduce disruption as far as possible in the failure case. 87 Optimistic DAD is a useful optimization because DAD is far more 88 likely to succeed than fail for a well-distributed random address 89 [SOTO]. Disruption is minimized by limiting nodes' participation in 90 Neighbor Discovery while their addresses are still Optimistic. 92 It is not the intention of this memo to improve the security, 93 reliability or robustness of DAD beyond that of existing standards, 94 merely to provide a method to make it faster. 96 1.1 Problem Statement 98 The existing IPv6 address configuration mechanisms provide adequate 99 collision detection mechanisms for the fixed hosts they were designed 100 for. However, a growing population of nodes need to maintain 101 continuous network access despite frequently changing their network 102 attachment. Optimizations to the DAD process are required to provide 103 these nodes with sufficiently fast address configuration. 105 An optimized DAD method needs to: 107 * provide interoperability with nodes using the current standards. 109 * remove the RetransTimer delay during address configuration. 111 * ensure the probability of address collision is not increased. 113 * improve the resolution mechanisms for address collisions. 115 * minimize disruption in the case of a collision. 117 It is not sufficient to merely reduce RetransTimer in order to reduce 118 the handover delay, as values of RetransTimer long enough to 119 guarantee detection of a collision are too long to avoid disruption 120 of time-critical services. 122 1.2 Definitions 124 Definitions of requirements keywords ('MUST NOT', 'SHOULD NOT', 125 'MAY', 'SHOULD', 'MUST') are in accordance with the IETF Best Current 126 Practice - RFC2119 [RFC2119] 128 Address Resolution - Process defined by [RFC2461] section 7.2. 130 Neighbor Unreachability Detection - Process defined by [RFC2461] 131 section 7.3. 133 Tentative Address - an address for which a node has not yet completed 134 DAD is regarded as Tentative: a single Neighbor Solicitation for 135 this address or a single Neighbor Advertisement defending this 136 address will cause the node to deconfigure the address and cease 137 using it. 139 Deprecated Address - an address which should not be used if an 140 alternative is available. 142 Optimistic Address - an address which is available for use despite 143 DAD not being fully complete. This memo places restrictions on 144 the use of Optimistic Addresses. 146 Preferred Address - an address which is neither Tentative, Deprecated 147 or Optimistic. 149 Optimistic Node - An Optimistic Node is one which is compliant with 150 the rules specified in this memo. 152 Standard Node - A Standard Node is one which is compliant with RFCs 153 2461 and 2462. 155 Link - A communication facility or medium over which nodes can 156 communicate at the link layer. 158 Neighbors - Nodes on the same link, which may therefore be competing 159 for the same IP addresses. 161 1.3 Abbreviations 163 DAD - Duplicate Address Detection. Technique used for SLAAC. See 164 [RFC2462] section 5.4. 166 ICMP Redirect - See [RFC2461] section 4.5. 168 NA - Neighbor Advertisement. See [RFC2461] sections 4.4 and 7. 170 NC - Neighbor Cache. See [RFC2461] section 5.1 and 7.3. 172 ND - Neighbor Discovery. The process described in [RFC2461] 174 NS - Neighbor Solicitation. See [RFC2461] sections 4.3 and 7. 176 ON - Optimistic Node. A node which is behaving according to the 177 rules of this memo. 179 RA - Router Advertisement. See [RFC2462] sections 4.2 and 6. 181 RS - Router Solicitation. See [RFC2461] sections 4.1 and 6. 183 SLAAC - StateLess Address AutoConfiguration. The process described 184 in [RFC2462] 186 SLLAO - Source Link Layer Address Option - an option to NS, RA and RS 187 messages, which gives the link layer address of the source of 188 the message. See [RFC2461] section 4.6.1. 190 TLLAO - Target Link Layer Address Option - an option to ICMP Redirect 191 messages and Neighbor Advertisements. See [RFC2461] sections 192 4.4, 4.5 and 4.6.1. 194 2. Optimistic DAD Behaviours 196 This non-normative section discusses Optimistic DAD behaviours. 198 2.1 Optimistic Addresses 200 [RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated 201 (in 5.5.4) Addresses. Addresses which are neither are said to be 202 Preferred. Tentative addresses may not be used for communication, 203 and Deprecated addresses should not be used for new communications. 204 These address states may also be used by other standards documents, 205 for example Default Address Selection [RFC3484]. 207 This memo introduces a new address state, 'Optimistic', that is used 208 to mark an address which is available for use but which has not 209 completed DAD. Protocols that do not understand this state should 210 treat it equivalently to 'Deprecated', to indicate that the address 211 is available for use but should not be used if another suitable 212 address is available. If address states are recorded as individual 213 flags, this can easily be achieved by setting 'Deprecated' when 214 'Optimistic' is set. In any case, it is important to note that the 215 address lifetime rules of [RFC2462] still apply, and so an address 216 may be Deprecated as well as Optimistic. When DAD completes without 217 incident, the address becomes a Preferred or Deprecated address, as 218 per [RFC2462]. 220 2.2 Avoiding Disruption 222 In order to avoid interference, it is important that an Optimistic 223 node does not send any messages from an Optimistic Address which will 224 override its neighbors' Neighbor Cache (NC) entries for the address 225 it is trying to configure: doing so would disrupt the rightful owner 226 of the address in the case of a collision. 228 This is achieved by: 230 * clearing the 'Override' flag in Neighbor Advertisements for 231 Optimistic Addresses, which prevents neighbors from overriding 232 their existing NC entries. The 'Override' flag is already 233 defined [RFC2461] and used for Proxy Neighbor Advertisement. 235 * Never sending Neighbor Solicitations from an Optimistic Address. 236 NSs include a Source Link Layer Address Option (SLLAO), which 237 may cause Neighbor Cache disruption. NSs sent as part of DAD 238 are sent from the unspecified address, without a SLLAO. 240 * Never using an Optimistic Address as the source address of a Router 241 Solicitation with a SLLAO. Another address, or the unspecified 242 address, may be used, or the RS may be sent without a SLLAO. 244 An address collision with a router may cause neighboring 245 router's IsRouter flags for that address to be cleared. 246 However, routers do not appear to use the IsRouter flag for 247 anything, and the NA sent in response to the collision will 248 reassert the IsRouter flag. 250 2.3 Router Redirection 252 Neighbor Solicitations cannot be sent from Optimistic Addresses, and 253 so an ON cannot directly contact a neighbor which is not already in 254 its Neighbor Cache. Instead, the ON forwards packets via its default 255 router, relying on the router to forward the packets to their 256 destination. In accordance with RFC2461, the router should then 257 provide the ON with an ICMP Redirect, which may include a Target Link 258 Layer Address Option (TLLAO). If it does, this will update the ON's 259 NC, and direct communication can begin. If it does not, packets 260 continue to be forwarded via the router until the ON has a non- 261 Optimistic address from which to send an NS. 263 3. Modifications to RFC-mandated behaviour 265 All normative text in this memo is contained in this section. 267 3.1 General 269 * Optimistic DAD SHOULD NOT be used to configure addresses unless the 270 probability of collision is exceedingly small. 272 * Nodes implementing Optimistic DAD SHOULD additionally implement 273 Secure Neighbor Discovery [SEND]. 275 3.2 Modifications to RFC 2461 Neighbor Discovery 277 * (modifies 6.3.7) A node MUST NOT send a Router Solicitation with a 278 SLLAO from an Optimistic Address. Router Solicitations SHOULD 279 be sent from a non-Optimistic or the Unspecified Address, 280 however they MAY be sent from an Optimistic Address as long as 281 the SLLAO is not included. 283 * (modifies 7.2.2) A node MUST NOT use an Optimistic Address as the 284 source address of a Neighbor Solicitation. 286 * If the ON isn't told the SLLAO of the router in an RA, and it 287 cannot determine this information without breaching the rules 288 above, it MUST wait until DAD completes despite being unable to 289 send any packets to the router. 291 * (modifies 7.2.2) When a node has a unicast packet to send from an 292 Optimistic Address to a neighbor, but does not know the 293 neighbor's link-layer address, it MUST NOT perform Address 294 Resolution. It SHOULD forward the packet to a default router on 295 the link in the hope that the packet will be redirected. 296 Otherwise it SHOULD buffer the packet until DAD is complete. 298 3.3 Modifications to RFC 2462 Stateless Address Autoconfiguration 300 * (modifies 5.5) A host MAY choose to configure a new address as an 301 Optimistic Address. A host which does not know the SLLAO of its 302 router SHOULD NOT configure a new address as Optimistic. A 303 router SHOULD NOT configure an Optimistic Address. 305 * (modifies 5.4) As soon as the initial Neighbor Solicitation is 306 sent, the Optimistic Address is configured on the interface and 307 available for use immediately. The address MUST be flagged as 308 'Optimistic'. 310 * When the DAD completes for an Optimistic Address, the address is no 311 longer Optimistic and it becomes Preferred or Deprecated 312 according to the rules of [RFC2462]. 314 * (modifies 5.4.3) The node MUST NOT reply to a Neighbor Solicitation 315 for an Optimistic Address from the unspecified address. This NS 316 indicates that the address is a duplicate, and it MUST be 317 deconfigured as per the behaviour specified in RFC2462 for 318 Tentative addresses. 320 * (modifies 5.4.3) The node MUST reply to a Neighbor Solicitation for 321 an Optimistic Address from a unicast address, but the reply MUST 322 have the Override flag cleared (O=0). 324 4. Protocol Operation 326 This non-normative section provides clarification of the interactions 327 between Optimistic Nodes, and between Optimistic Nodes and Standard 328 Nodes. 330 The following cases all consider an Optimistic Node (ON) receiving a 331 Router Advertisement containing a new prefix and deciding to 332 autoconfigure a new address on that prefix. 334 The ON will immediately send out a Neighbor Solicitation to determine 335 if its new address is already in use. 337 4.1 Simple case 339 In the non-collision case, the address being configured by the new 340 node is unused and not present in the Neighbor Caches of any of its 341 neighbors. 343 There will be no response to its NS (sent from ::), and this NS will 344 not modify the state of neighbors' Neighbor Caches. 346 The ON already has the link-layer address of the router (from the 347 RA), and the router can determine the link-layer address of the ON 348 through standard Address Resolution. Communications can begin as 349 soon as the router and the ON have each others' link-layer addresses. 351 After the appropriate DAD delay has completed, the address is no 352 longer Optimistic, and becomes either Preferred or Deprecated as per 353 RFC2462. 355 4.2 Collision case 357 In the collision case, the address being configured by the new node 358 is already in use by another node, and present in the Neighbor Caches 359 (NCs) of neighbors which are communicating with this node. 361 The NS sent by the ON has the unspecified source address, ::, and no 362 SLLAO. This NS will not cause changes to the NC entries of 363 neighboring hosts. 365 The ON will hopefully already know all it needs to about the router 366 from the initial RA. However, if it needs to it can still send an RS 367 to ask for more information, but it may not include a SLLAO. This 368 forces a broadcast response from the router, but will not disrupt 369 other nodes' NCs. 371 In the course of establishing connections, the ON might have sent NAs 372 in response to received NSs. Since NAs sent from Optimistic 373 Addresses have O=0, they will not have overridden existing NC 374 entries, although they may have resulted in a colliding entry being 375 changed to state STALE. This change is recoverable through standard 376 NUD. 378 When an NA is received from the collidee defending the address, the 379 ON immediately stops using the address and deconfigures it. 381 Of course, in the meantime the ON may have sent packets which 382 identify it as the owner of its new Optimistic Address (for example, 383 Binding Updates in [MIPV6]). This may incur some penalty to the ON, 384 in the form of broken connections, and some penalty to the rightful 385 owner of the address, since it will receive (and potentially reply 386 to) the misdirected packets. It is for this reason that Optimistic 387 DAD should only be used where the probability of collision is very 388 low. 390 4.3 Interoperation cases 392 Once the Optimistic Address has completed DAD, it acts exactly like a 393 normal address, and so interoperation cases only arise while the 394 address is Optimistic. 396 If an ON attempts to configure an address currently Tentatively 397 assigned to a Standard Node, the Standard Node will see the Neighbor 398 Solicitation and deconfigure the address. 400 If a node attempts to configure an ON's Optimistic Address, the ON 401 will see the NS and deconfigure the address. 403 4.4 Pathological cases 405 Optimistic DAD suffers from similar problems to Standard DAD, for 406 example duplicates are not guaranteed to be detected if packets are 407 lost. 409 These problems exist, and are not gracefully recoverable, in Standard 410 DAD. Their probability in both Optimistic and Standard DAD can be 411 reduced by increasing the RFC2462 DupAddrDetectTransmits variable to 412 greater than 1. 414 This version of Optimistic DAD is dependant on the details of the 415 router behaviour, eg: that the router includes SLLAOs in RAs, and 416 that the router is willing to redirect traffic for the ON. Where the 417 router does not behave in this way, the behaviour of Optimistic DAD 418 inherently reverts to that of Standard DAD. 420 5. Security Considerations 422 There are existing security concerns with Neighbor Discovery and 423 Stateless Address Autoconfiguration, and this memo does not purport 424 to fix them. However, this memo does not significantly increase 425 security concerns either. 427 Secure Neighbor Discovery [SEND] provides protection against the 428 threats to Neighbor Discovery described in [RFC3756]. Optimistic 429 Duplicate Address Detection does not introduce any additional threats 430 to Neighbor Discovery if SEND is used. 432 6. IANA Considerations 434 This document has no actions for IANA. 436 Appendix A: Probability of Collision 438 In assessing the usefulness of Duplication Address Detection, the 439 probability of collision must be considered. Various mechanisms such 440 as SLAAC [RFC2462] and DHCPv6 [RFC3315] attempt to guarantee the 441 uniqueness of the address. The uniqueness of SLAAC depends on the 442 reliability of the manufacturing process (so that duplicate L2 443 addresses are not assigned) and human factors if L2 addresses can be 444 manually assigned. The uniqueness of DHCPv6 assigned addresses 445 relies on the correctness of implementation to ensure that no two 446 nodes can be given the same address. 448 Privacy Extensions to SLAAC [RFC3041] avoids these potential error 449 cases by picking an Interface Identifier (IID) at random from 2^62 450 possible 64-bit IIDs (allowing for the reserved U and G bits). No 451 attempt is made to guarantee uniqueness, but the probability can be 452 easily estimated, and as the following discussion shows, probability 453 of collision is exceedingly small. 455 A.1 The Birthday Paradox 457 When considering collision probability, the Birthday Paradox is 458 generally mentioned. When randomly selecting k values from n 459 possibilities, the probability of two values being the same is: 461 Pb(n,k) = 1-( n! / [ (n-k)! . n^k] ) 463 Calculating the probability of collision with this method is 464 difficult, however, as one of the terms is n!, and (2^62)! is an 465 unwieldy number. [SOTO], now expired, presented an upper bound for 466 the probability of collision which is rather easier to calculate for 467 large n: 469 Pb(n,k) <= 1-( [(n-k+1)/n] ^ [k-1] ) 471 which lets us calculate that even for large networks the probability 472 of any two nodes colliding is very small indeed: 474 Pb(2^62, 500) <= 5.4e-14 475 Pb(2^62, 5000) <= 5.4e-12 476 Pb(2^62, 50000) <= 5.4e-10 477 Pb(2^62, 500000) <= 5.4e-08 479 A.2 Individual Nodes 481 When considering the effect of collisions on an individual node, we 482 do not need to consider the Birthday Paradox. When a node moves into 483 a network with K existing nodes, the probability that it will not 484 collide with any of the distinct addresses in use is simply 1-K/N. 485 If it moves to such networks M times, the probability that it will 486 not cause a collision on any of those moves is (1-K/N)^M, thus the 487 probability of it causing at least one collision is: 489 Pc(n,k,m) = 1-[(1-k/n)^m] 491 Even considering a very large number of moves (m = 600000, slightly 492 more than one move per minute for one year) and rather crowded 493 networks (k=50000 nodes per network), the odds of collision for a 494 given node are vanishingly small: 496 Pc(2^62, 5000, 600000) = 6.66e-10 497 Pc(2^62, 50000, 600000) = 6.53e-09 499 Each such collision affects two nodes, so the probability of being 500 effected by a collision is twice this. Even if the node moves into 501 networks of 50000 nodes once per minute for 100 years, the 502 probability of it causing or suffering a collision at any point are a 503 little over 1 in a million. 505 Pc(2^62, 50000, 60000000) * 2 = 1.3e-06 507 Normative References 509 [RFC2119] S. Bradner. "Key words for use in RFCs to Indicate 510 Requirement Levels." Request for Comments (Best Current 511 Practice) 2119 (BCP 14), Internet Engineering Task Force, March 512 1997. 514 [RFC2461] T. Narten, E.Nordmark, W. Simpson. "Neighbor Discovery for 515 IP Version 6 (IPv6)." Request for Comments (Draft Standard) 516 2461, Internet Engineering Task Force, December 1998. 518 [RFC2462] S. Thomson, T. Narten. "IPv6 Stateless Address 519 Autoconfiguration." Request for Comments (Draft Standard) 2462, 520 Internet Engineering Task Force, December 1998. 522 [SEND] J. Arkko (Ed.), J. Kempf, B. Sommerfeld, B.Zill, P. Nikander. 523 SEcure Neighbor Discovery (SEND), revision 06. (draft-ietf- 524 send-ndopt-06). July 17, 2004. 526 Informative References 528 [RFC3315] R. Droms (Ed.), J. Bound, B. Volz, T. Lemon, C. Perkins, M. 529 Carney. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" 530 Request for Comments (Proposed Standard) 3315, Internet 531 Engineering Task Force, July 2003. 533 [RFC3484] R. Draves. "Default Address Selection for Internet Protocol 534 version 6 (IPv6)". Request for Comments (Proposed Standard) 535 3484, Internet Engineering Task Force, February 2003. 537 [RFC3756] P. Nikander, J. Kempf, E. Nordmark. "IPv6 Neighbor 538 Discovery (ND) Trust Models and Threats". Request for Comments 539 (Informational) 3756, Internet Engineering Task Force, May 2004 541 [KOODLI] R. Koodli, C. Perkins. Fast Handovers in Mobile IPv6, 542 revision 00 (draft-koodli-mobileip-fastv6-00). October 2000 ... 543 Expired April 2001. 545 [MIPV6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6, 546 revision 24 (draft-ietf-mobileip-ipv6-24). June 2003 ... 547 Expired December 2003. 549 [SOTO] M. Bagnulo, I. Soto, A. Garcia-Martinez, A. Azcorra. Random 550 generation of interface identifiers, revision 00. (draft-soto- 551 mobileip-random-iids-00). January 2002 ... Expired July 2002. 553 Author's Address: 555 Nick 'Sharkey' Moore 556 or 557 Centre for Telecommunications and Information Engineering 558 Monash University 3800 559 Victoria, Australia 561 Comments should be sent to either of the above email addresses. 563 Acknowledgments 565 There is some precedent for this work in previous Internet Drafts and 566 in discussions in the MobileIP WG mailing list and at IETF-54. 568 Thanks to Greg Daley, Brett Pentland, Richard Nelson and Ahmet 569 Sekercioglu at Monash Uni CTIE for their feedback and encouragement. 570 More information is available at: 571 573 Thanks to all the MobileIP and IPng/IPv6 WG members who have 574 contributed to the debate. Especially and alphabetically: Jari 575 Arkko, JinHyeock Choi, Youn-Hee Han, James Kempf, Thomas Narten, 576 Richard Nelson, Pekka Nikander, Erik Nordmark, Soohong 'Daniel' Park, 577 Ed Remmel, Pekka Savola, Hesham Soliman, Ignatious Souvatzis, Jinmei 578 Tatuya, Dave Thaler, Pascal Thubert, Vladislav Yasevich and Alper 579 Yegin. 581 This work has been supported by the Australian Telecommunications 582 Cooperative Research Centre (ATcrc): 583 585 Funding for the RFC Editor function is currently provided by the 586 Internet Society. 588 Full Copyright Statement 590 Copyright (C) The Internet Society (2004). This document is subject 591 to the rights, licenses and restrictions contained in BCP 78 and 592 except as set forth therein, the authors retain all their rights. 594 Intellectual Property Statement 596 The IETF takes no position regarding the validity or scope of any 597 intellectual property or other rights that might be claimed to 598 pertain to the implementation or use of the technology described in 599 this document or the extent to which any license under such rights 600 might or might not be available; neither does it represent that it 601 has made any effort to identify any such rights. Information on the 602 IETF's procedures with respect to rights in IETF Documents can be 603 found in BCP 78 and 79. 605 Copies of IPR disclosures made to the IETF Secretariat and any 606 assurances of licenses to be made available, or the result of an 607 attempt made to obtain a general license or permission for the use of 608 such proprietary rights by implementers or users of this 609 specification can be obtained from the IETF on-line IPR repository at 610 http://www.ietf.org/ipr. 612 The IETF invites any interested party to bring to its attention any 613 copyrights, patents or patent applications, or other proprietary 614 rights which may cover technology that may be required to implement 615 this standard. Please address the information to the IETF at ietf- 616 ipr@ietf.org. 618 Disclaimer of Validity 620 This document and the information contained herein are provided on an 621 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 622 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 623 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 624 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 625 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 626 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.