[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-moore-ipv6-optimistic-dad) 00 01 02 03 04 05 06 07 RFC 4429

IPv6 Working Group                                 Nick 'Sharkey' Moore
INTERNET-DRAFT                                   Monash University CTIE
                                                           28 June 2004




            Optimistic Duplicate Address Detection for IPv6
                <draft-ietf-ipv6-optimistic-dad-01.txt>



Status of this Memo


   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.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Copyright Notice


   Copyright (C) The Internet Society (2004).  All Rights Reserved.



Abstract


   Optimistic Duplicate Address Detection is an interoperable
   modification of the existing IPv6 Neighbour Discovery (RFC2461) and
   Stateless Address Autoconfiguration (RFC2462) process.  The intention
   is to minimize address configuration delays in the successful case
   without greatly increasing disruption in the less likely failure
   case, and while remaining interoperable with unmodified nodes.






Nick 'Sharkey' Moore    Expires: 28 December 2004               [Page 1]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



Table of Contents


   Status of this Memo .........................................  1
   Abstract ....................................................  1
   Table of Contents ...........................................  2
   1. Introduction .............................................  3
           1.1 Problem Statement ...............................  3
           1.2 History .........................................  4
           1.3 Definitions .....................................  4
           1.4 Abbreviations ...................................  5
   2. Optimistic Behaviours ....................................  6
           2.1 Probability of Collision ........................  6
           2.2 Optimistic Address Flag .........................  6
           2.3 Avoiding Disruption .............................  7
           2.4 Rapid Establishment .............................  7
           2.5 Router Redirection ..............................  8
           2.6 Improving Detection .............................  8
   3. Modifications to RFC-compliant behaviour .................  9
           3.1 Modifications to RFC 2461 Neighbour Discovery ...  9
           3.2 Modifications to RFC 2462 SAA ................... 10
   4. Protocol Operation ....................................... 11
           4.1 Simple case ..................................... 11
           4.2 Collision case .................................. 12
           4.3 Interoperation cases ............................ 13
           4.4 Pathological cases .............................. 13
   5. Security Considerations .................................. 13
   6. IANA Considerations ...................................... 14
   Appendix A: Address Generation .............................. 14
   Notes ....................................................... 14
   Normative References ........................................ 15
   Informative References ...................................... 15
   Author's Address ............................................ 16
   Acknowledgments ............................................. 16
   Full Copyright Statment ..................................... 17
   Intellectual Property Statement ............................. 17
   Disclaimer of Validity ...................................... 17
















Nick 'Sharkey' Moore    Expires: 28 December 2004               [Page 2]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



1. Introduction


   Optimistic Duplicate Address Detection (DAD) is a modification of the
   existing IPv6 Neighbour Discovery (ND) [RFC2461] and Stateless
   Address Autoconfiguration (SAA) [RFC2462] process.  The intention is
   to minimize address configuration delays in the successful case, and
   to reduce disruption as far as possible in the failure case.


   Optimistic DAD is a useful optimization because DAD is far more
   likely to succeed than fail for a well-distributed random address
   [SOTO].  Disruption is minimized by limiting nodes' participation in
   Neighbour Discovery while their addresses are still Optimistic.


   It is not the intention of this draft to improve the security,
   reliability or robustness of DAD beyond that of existing standards,
   merely to provide a method to make it faster.



1.1 Problem Statement


   The existing IPv6 address configuration mechanisms provide adequate
   collision detection mechanisms for the static hosts they were
   designed for.  However, a growing population of nodes need to
   maintain continuous network access despite frequently changing their
   network attachment.  Optimizations to the DAD process are required to
   provide these nodes with sufficiently fast address configuration.


   An optimized DAD method needs to:


   * provide interoperability with nodes using the current standards.


   * remove the RetransTimer delay during address configuration.


   * ensure the probability of address collision is not increased.


   * improve the resolution mechanisms for address collisions.


   * minimize disruption in the case of a collision.


   It is not sufficient to merely reduce RetransTimer in order to reduce
   the handover delay, as values of RetransTimer long enough to
   guarantee detection of a collision are too long to avoid disruption
   of time-critical services.









Nick 'Sharkey' Moore    Expires: 28 December 2004               [Page 3]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



1.2 History



   There is some precedent for this work in previous drafts [KOODLI],
   and in discussions in the MobileIP WG mailing list and at IETF-54.
   This version of Optimistic DAD differs somewhat from previous
   versions in that it uses no additional flags or message types beyond
   those already defined, therefore allowing interoperation between
   Optimistic and Standard nodes.


   Earlier versions of this work were presented by the author to the
   MobileIP WG at IETF-56, and to the IPv6 WG at IETF-59.


   Working implementations of draft versions of this memo have been made
   by the author as a freely-available patch to Linux 2.4.18, and by Ed
   Remmel of Elmic Systems.


   An implementation of this version by the author is in progress.


1.3 Definitions


   Definitions of requirements keywords ('MUST NOT', 'SHOULD NOT',
   'MAY', 'SHOULD', 'MUST') are in accordance with the IETF Best Current
   Practice - RFC2119 [RFC2119]


   Tentative Address - an address for which a node has not yet completed
        DAD is regarded as Tentative: a single Neighbour Solicitation
        for this address or a single Neighbour Advertisement defending
        this address will cause the node to deconfigure the address and
        cease using it.


   Deprecated Address - an address which should not be used if an
        alternative is available.


   Preferred Address - an address which is neither Tentative or
        Deprecated.


   Optimistic Address - an address which is available for use despite
        DAD not being fully complete.  This memo places restrictions on
        the use of Optimistic Addresses.  A single Neighbour
        Advertisement for this address will cause the node to
        deconfigure the address and cease using it.  Optimistic
        Addresses should also be regarded as Deprecated.


   Optimistic Node - An Optimistic Node assumes that DAD will succeed,
        and allows higher-layer communications on an address while DAD
        completes.





Nick 'Sharkey' Moore    Expires: 28 December 2004               [Page 4]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



   Standard Node - A Standard Node is one which is compliant with RFCs
        2461 and 2462.


   Link - A communication facility or medium over which nodes can
        communicate at the link layer.


   Neighbours - Nodes on the same link, which may therefore be competing
        for the same addresses.



1.4 Abbreviations



   DAD - Duplicate Address Detection.  Technique used for SAA.  See
        [RFC2462] section 5.4.


   ICMP Redirect - See [RFC2461] section 4.5.


   NA - Neighbour Advertisement.  See [RFC2461] sections 4.4 and 7.


   NC - Neighbour Cache.  See [RFC2461] section 5.1 and 7.3.


   ND - Neighbour Discovery.  The process described in [RFC2461]


   NS - Neighbour Solicitation.  See [RFC2461] sections 4.3 and 7.


   ON - Optimistic Node.  A node which is behaving according to the
        rules of this memo.


   RA - Router Advertisement.  See [RFC2462] sections 4.2 and 6.


   RS - Router Solicitation.  See [RFC2461] sections 4.1 and 6.


   SAA - Stateless Address Autoconfiguration.  The process described in
        [RFC2462]


   SLLAO - Source Link Layer Address Option - an option to NS, RA and RS
        messages, which gives the link layer address of the source of
        the message.  See [RFC2461] section 4.6.1.


   TLLAO - Target Link Layer Address Option - an option to ICMP redirect
        messages.  See [RFC2461] sections 4.5 and 4.6.1.










Nick 'Sharkey' Moore    Expires: 28 December 2004               [Page 5]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



2. Optimistic DAD Behaviours



   This section provides some discussion of Optimistic DAD Behaviours.
   Section 3 provides more specific information on changes to RFC-
   mandated behaviours.



2.1 Probability of Collision


   Optimistic DAD is only a useful optimization when the probability of
   collision is very small.  As such, the Optimistic algorithm should
   not be used for manually assigned addresses, where the collision
   probability is likely to be much higher than that for random
   addresses due to human error.


   Modifications are required only to Optimistic nodes -- Optimistic
   nodes will interoperate with Standard nodes without significant
   advantage or incompatibility.



2.2 Optimistic Address Flag


   [RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated
   (in 5.5.4) Addresses.  Addresses which are neither are said to be
   Preferred.  Tentative addresses may not be used for communication,
   and Deprecated addresses should not be used for new communications.
   These status flags may also be used by other standards documents, for
   example Default Address Selection [RFC3484] uses these flags.


   This draft introduces a new address state, 'Optimistic', which is
   used to mark an address which is available for use but which has not
   completed DAD.  Protocols which do not understand this state should
   treat it equivalently to 'Deprecated', to indicate that the address
   is available for use but should not be used if another suitable
   address is available.  If address states are recorded as individual
   flags, this can easily be achieved by setting 'Deprecated' when
   'Optimistic' is set.  When the DAD timer completes without incident,
   the address becomes a Preferred address.













Nick 'Sharkey' Moore    Expires: 28 December 2004               [Page 6]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



2.3 Avoiding Disruption


   In order to avoid interference, it is important that an Optimistic
   node does not send any messages from an Optimistic Address which will
   override its neighbours' Neighbour Cache (NC) entries for the address
   it is trying to configure: doing so would disrupt the rightful owner
   of the address in the case of a collision.


   This is achieved by:


   * clearing the 'Override' flag in Neighbour Advertisements for
        Optimistic addresses, which prevents neighbours from overriding
        their existing NC entries. The 'Override' flag is already
        defined [RFC2461] and used for Proxy Neighbour Advertisement.


   * Never sending Neighbour Solicitations from an Optimistic Address.
        NSs include a Source Link Layer Address Option (SLLAO), which
        may cause Neighbour Cache disruption.  NSs sent as part of DAD
        are sent from the unspecified address, without a SLLAO.


   * Never using a Optimistic Address as the source address of a Router
        Solicitation with an SLLAO.  Another address, or the unspecified
        address, may be used, or the RS may be sent without an SLLAO.


        An address collision with a router may cause neighbouring
        router's IsRouter flags for that address to be cleared.
        However, routers do not appear to use the IsRouter flag for
        anything, and the NA sent in response to the collision will
        reassert the IsRouter flag.



2.4 Rapid Establishment


   It may be desirable for a Neighbour, for example the router, to
   rapidly establish communication with the newly configured Optimistic
   Node (ON). To do so, it must learn of the ON's arrival as soon as
   possible.  To avoid having to wait for Neighbour Discovery, the ON
   may wish to send unsolicited Neighbour Advertisements (with the
   Override flag cleared if the address is still Optimistic), but for
   this to be effective the Neighbour must either:


        * be expecting the ON to arrive (eg: due to predictive
           mechanisms), and thus already have a NC entry for the peer,
           in state INCOMPLETE.


        * be willing to cache unsolicited NAs (for a short period of
           time), so that an entry will have been created with state
           STALE.




Nick 'Sharkey' Moore    Expires: 28 December 2004               [Page 7]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



        These modifications are beyond the scope of this memo.


   The ON may choose to send unsolicited NAs to the All Nodes Multicast,
   to the All Routers Multicast, or Unicast to the source of the RA
   which alerted it to the new prefix.  This allows flexibility with
   regard to Layer 2 multicast transmission costs.


   The case where the ON wants to contact its router is handled by the
   SLLAO of the RA, where a SLLAO is supplied.  However, the router may
   choose not to include the SLLAO (the example given in RFC2462 is "to
   facilitate in-bound load balancing over replicated interfaces").  In
   this case, the ON cannot discover its router until it is no longer
   Optimistic.



2.5 Router Redirection


   When the ON wants to contact another neighbour, but it cannot because
   the neighbour is not in its NC, it should instead forward the packet
   to the router, relying on the router to forward the packet.  The
   router should then provide the ON with an ICMP redirect, which may
   include a Target Link Layer Address Option (TLLAO). If it does, this
   will update the ON's NC, and direct communication can begin.



2.6 Improving Detection


   Because Optimistic DAD allows nodes to communicate immediately,
   RetransTimer may be left at the default 1000ms without significant
   penalty.  It is also possible to increase DupAddrDetectTransmits and
   thus reduce the probability of an undetected address collision due to
   packet loss.




















Nick 'Sharkey' Moore    Expires: 28 December 2004               [Page 8]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



3. Modifications to RFC-mandated behaviour



3.1 Modifications to RFC 2461 Neighbour Discovery



   * (modifies 6.3.7)  A node MUST NOT send a Router Solicitation with
        an SLLAO from an Optimistic Address.  Router Solicitations
        SHOULD be sent from a non-Optimistic or the Unspecified Address,
        however they MAY be sent from an Optimistic Address as long as
        the SLLAO is not included.


   * (modifies 7.2.2)  A node MUST NOT use an Optimistic Address as the
        source address of a Neighbour Solicitation.


   * (modifies 7.2.2)  When a node has a unicast packet to send from an
        Optimistic Address to a neighbour, but does not know the
        neighbour's link-layer address, it MUST NOT perform Neighbour
        Discovery but instead SHOULD forward the packet to the router of
        that network.


   * (adds to 7.2.6)  The Optimistic node MAY send an unsolicited
        Neighbour Advertisement to All Nodes when it first configures an
        address. The Override flag on this advertisement MUST be cleared
        (O=0).


   * (adds to 7.2.6)  The Optimistic node MAY send an unsolicited NA to
        All Nodes when it completes DAD. The Override flag on this
        advertisement SHOULD be set (O=1).























Nick 'Sharkey' Moore    Expires: 28 December 2004               [Page 9]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



3.2 Modifications to RFC 2462 Stateless Address Autoconfiguration



   * (modifies 5.5) When an Optimistic node decides to configure an
        address, it generates a suffix and combines it with a prefix
        received from a Router Advertisement.  Appendix A provides some
        suggestions for suffix generation.


   * (modifies 5.4)  As soon as the initial Neighbour Solicitation (and
        optional unsolicited Neighbour Advertisement) is sent, the
        address is configured on the interface and available for use
        immediately.  The address MUST be flagged as 'Optimistic'.
        Protocols which do not understand this state SHOULD treat it
        equivalently to 'Deprecated'.


   * When the DAD timer expires on an Optimistic Address, the
        'Optimistic' flag MUST be cleared, and the address becomes a
        Preferred Address.


   * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for
        its address from the unspecified address with a Neighbour
        Advertisement to the All Nodes address.  If the solicitation is
        for an Optimistic Address, the reply MUST have the Override flag
        cleared (O=0).


   * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for
        an Optimstic Address from a unicast address, but the reply MUST
        have the Override flag cleared (O=0).


   * (modifies 5.4.5) An Optimistic Address that is determined to be a
        duplicate MUST be deconfigured immediately.  If the address is a
        link-local address formed from an interface identifier based on
        the hardware address (e.g. EUI-64), the interface SHOULD be
        disabled.  Otherwise, if the address was automatically
        configured, DAD SHOULD be restarted with a new address.
        (Appendix A suggests methods for generating a new address)


   * DupAddrDetectTransmits SHOULD be increased where there is a
        significant probability of packet loss.













Nick 'Sharkey' Moore    Expires: 28 December 2004              [Page 10]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



4. Protocol Operation



   The following cases all consider an Optimistic Node (ON) receiving a
   Router Advertisement containing a new prefix and deciding to
   autoconfigure a new address on that prefix.


   The following cases assume that the RA contains a SLLAO, for reasons
   explained in Section 2.


   The ON will immediately send out a Neighbour Solicitation to
   determine if its new address is already in use, and a Neighbour
   Advertisement (with the Override flag cleared) for the address. This
   NA allows communication with neighbours to begin immediately.



4.1 Simple case


   In the non-collision case, the address being configured by the new
   node is unused and not present in the Neighbour Caches of any of its
   neighbours.


   Therefore, there will be no response to its NS, and the NA with O=0
   will be sufficient to create Neighbour Cache entries in already
   interested neighbours.


   The Optimistic Node already has the link-layer address of the router
   (from the RA), and the router either already knows the link-layer
   address of the ON from the unsolicited NA, or can determine it
   through standard NUD.  Communications can begin as soon as the router
   and the ON have each others' link-layer addresses.


   After the appropriate DAD delay, the address's Optimistic flag is
   cleared and another NA is sent, this time with O=1. This will ensure
   that all Neighbour Caches are up-to-date.

















Nick 'Sharkey' Moore    Expires: 28 December 2004              [Page 11]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



4.2 Collision cases


   In the simplest collision case, the address being configured by the
   new node is already in use by another node, and present in the
   Neighbour Caches (NCs) of neighbours which are communicating with
   this node.


   Since the Optimistic advertisement has O=0, it will not override
   existing NC entries.  An NA with O=0,S=0 and with a SLLAO may [Note
   1], however cause the NC entry to be set to STALE, causing NUD to be
   performed on the address.


   Nodes with no interest in communicating with the new address "SHOULD"
   silently discard the NA [RFC2461 7.2.5], and so will likely be
   undisturbed.


   If a neighbour is just preparing to begin communication with the
   address, eg: it has a NC entry for the address in state 'INCOMPLETE',
   the optimistic advertisement may cause an incorrect NC entry to be
   created in state 'STALE' and queued packets to be sent to an
   incorrect destination.


   In general, the defending NA will have the Override flag set (O=1),
   and so this will correct the incorrect entry almost immediately.
   However, if the defending NA has the Override flag cleared (for
   example when the address is in use by proxy) the defending
   advertisement will not override this incorrect NC entry. In any case,
   the NC entry will remain in state 'STALE', and thus the disruption
   will be recoverable, albeit slowly, by the standard Neighbour
   Unreachability Detection mechanism.


   Of course, in the meantime the ON may have sent packets which
   identify it as the owner of its new Optimistic Address (for example,
   Binding Updates in [MIPV6]).  This may incur some penalty to the ON,
   in the form of broken connections, and some penalty to the rightful
   owner of the address, since it will receive (and potentially reply
   to) the misdirected packets.  It is for this reason that Optimistic
   DAD should only be used where the probability of collision is very
   low.













Nick 'Sharkey' Moore    Expires: 28 December 2004              [Page 12]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



4.3 Interoperation cases


   Once the Optimistic Address has completed DAD, it acts exactly like a
   normal address, and so interoperation cases only arise while the
   address is Optimistic.


   If an Optimistic Node attempts to configure an address currently
   Tentatively assigned to a Standard Node, the Standard Node will see
   the Neighbour Solicitation and deconfigure the address.  In contrast,
   if a node attempts to configure an Optimistic Node's Optimistic
   Address, the Optimistic Node will not deconfigure the address, and
   instead defend with a Neighbour Advertisement, causing the newcomer
   to reconfigure.  This gives the Optimistic Node a slight advantage
   over Standard nodes, however this is justified since the Optimistic
   node may have already established connections to Optimistic
   Addresses.



4.4 Pathological cases


   Optimistic DAD suffers from similar problems to Standard DAD, for
   example duplicates are not guaranteed to be detected if packets are
   lost, and if two nodes configure simultaneously, they may each miss
   the other's NS.


   These problems exist, and are not gracefully recoverable, in Standard
   DAD. The probability of such a collision is reduced in Optimistic DAD
   due to the pair of messages (NS, NA) sent.  The probability can be
   further reduced by increasing the RFC2462 DupAddrDetectTransmits
   variable to greater than 1.


   This version of Optimistic DAD is dependant on the details of the
   router behaviour, eg: if it includes SLLAOs in RAs, and if it is
   willing to redirect traffic for the ON.  Where the router does not
   behave in this way, the behaviour of Optimistic DAD reverts to that
   of Standard DAD.


5. Security Considerations


   There are existing security concerns with Neighbour Discovery and
   Stateless Address Autoconfiguration, and this memo does not purport
   to fix them.  However, this memo does not significantly increase
   security concerns either.


   Further work will be required to integrate Optimistic DAD with Secure
   Neighbour Discovery [SEND].






Nick 'Sharkey' Moore    Expires: 28 December 2004              [Page 13]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



6. IANA Considerations


   This document has no actions for IANA.


Appendix A: Address Generation



   In order for Optimistic DAD to be a useful optimization, the
   probability of a collision must be very small, as a collision may
   cause temporary disruption to the collidee, and will require the
   collidor to reconfigure.


   Some interfaces (for example, Ethernet [RFC2464]) offer methods to
   create an address based on a globally unique Interface Identifier,
   however it is conceivable that due to manufacturer or user error that
   the generated address may not in fact be unique.  An address
   generated in this manner may be used for a first attempt.


   If an interface does not offer such a method, or if a new addres
   needs to be created, an address should be created by an algorithm
   with a uniform distribution to minimize the chance of address
   collision.  This algorithm could be a random number generator (see
   [RFC1750] for more information on random number generation), or a
   hash function as in [SEND-CGA] or one of those documented in
   [RFC3041].  A randomly generated address should have the
   Universal/Local bit and the Individual/Group bit set to 0 to indicate
   a Unicast address which is not globally unique (see [RFC3513]).


   The first time DAD fails, a new suffix is generated and the node can
   retry immediately.  A delay of at least RETRANS_TIMER (as used in
   [RFC2461]) milliseconds can be introduced between further retries, to
   minimize the effect of DoS attacks.  An exponential backoff should be
   used.



Notes



   [Note 1] RFC 2461 is unclear on this, with [RFC2461 7.2.5] specifying
        "the advertisement prompts future Neighbour Unreachability
        Detection [...] by changing the state in the cache entry"
        whereas [RFC2461 Appendix C] specifies the state as "unchanged".
        Many arguments have been made on the list (see
        <ftp://playground.sun.com/pub/ipng/mail-archive/ipng.199912>)
        for one interpretation or the other. For the purposes of this
        memo, I have assumed that either behaviour is possible.


        This issue is to be addressed in RFC2461bis.




Nick 'Sharkey' Moore    Expires: 28 December 2004              [Page 14]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



Normative References



   [RFC2119] S. Bradner.  "Key words for use in RFCs to Indicate
        Requirement Levels." Request for Comments (Best Current
        Practice) 2119 (BCP 14), Internet Engineering Task Force, March
        1997.


   [RFC3513] R. Hinden, S. Deering. "IP Version 6 Addressing
        Architecture." Request for Comments (Proposed Standard) 3513,
        Internet Engineering Task Force, April 2003.


   [RFC2461]  T. Narten, E.Nordmark, W. Simpson. "Neighbor Discovery for
        IP Version 6 (IPv6)." Request for Comments (Draft Standard)
        2461, Internet Engineering Task Force, December 1998.


   [RFC2462] S. Thomson, T. Narten. "IPv6 Stateless Address
        Autoconfiguration."  Request for Comments (Draft Standard) 2462,
        Internet Engineering Task Force, December 1998.


   [RFC2464] M. Crawford. "Transmission of IPv6 Packets over Ethernet
        Networks." Request for Comments (Proposed Standard) 2464,
        Internet Engineering Task Force, December 1998.




Informative References



   [RFC1750] D. Eastlake, S. Crocker, J. Schiller. "Randomness
        Recommendation for Security." Request for Comments
        (Informational) 1750, Internet Engineering Task Force, December
        1994.


   [RFC3041] T. Narten, R. Draves. "Privacy Extensions for Stateless
        Address Autoconfiguration in IPv6." Request for Comments
        (Proposed Standard) 3041, Internet Engineering Task Force,
        January 2001.


   [RFC3484] R. Draves. "Default Address Selection for Internet Protocol
        version 6 (IPv6)".  Request for Comments (Proposed Standard)
        3484, Internet Engineering Task Force, February 2003.


   [MIPV6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6,
        revision 24 (draft-ietf-mobileip-ipv6-24).  June 2003 ...
        Expired December 2003.


   [KOODLI] R. Koodli, C. Perkins. Fast Handovers in Mobile IPv6,




Nick 'Sharkey' Moore    Expires: 28 December 2004              [Page 15]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



        revision 00 (draft-koodli-mobileip-fastv6-00).  October 2000 ...
        Expired April 2001.


   [SOTO] M. Bagnulo, I. Soto, A. Garcia-Martinez, A. Azcorra.  Random
        generation of interface identifiers, revision 00.  (draft-soto-
        mobileip-random-iids-00).  January 2002 ... Expired July 2002.


   [SEND]  J. Arkko, J. Kempf, B. Sommerfeld, B.Zill, P. Nikander.
        SEcure Neighbor Discovery (SEND), revision 03.  (draft-ietf-
        send-ndopt-03).  January 2004 ... Expires July 2004.


   [SEND-CGA] T. Aura, Cryptographically Generated Addresses (CGA),
        revision 01.  (draft-ietf-send-cga-01).  August 1, 2003.



Author's Address:


   Nick 'Sharkey' Moore
   <nick.moore@eng.monash.edu.au> or <sharkey@zoic.org>
   Centre for Telecommunications and Information Engineering
   Monash University 3800
   Victoria, Australia


   Comments should be sent to either of the above email addresses.



Acknowledgments


   Thanks to Greg Daley, Brett Pentland, Richard Nelson and Ahmet
   Sekercioglu at Monash Uni CTIE for their feedback and encouragement.
   More information is available at:
        <http://www.ctie.monash.edu.au/ipv6/fastho/>


   Thanks to all the MobileIP and IPng/IPv6 WG members who have
   contributed to the debate.  Especially and alphabetically: Jari
   Arkko, JinHyeock Choi, Youn-Hee Han, James Kempf, Thomas Narten,
   Richard Nelson, Pekka Nikander, Soohong 'Daniel' Park, Ed Remmel,
   Pekka Savola, Hesham Soliman, Ignatious Souvatzis, Jinmei Tatuya,
   Pascal Thubert, Vladislav Yasevich and Alper Yegin.


   This work has been supported by the Australian Telecommunications
   Cooperative Research Centre (ATcrc):
        <http://www.telecommunications.crc.org.au/>


   Funding for the RFC Editor function is currently provided by the
   Internet Society.






Nick 'Sharkey' Moore    Expires: 28 December 2004              [Page 16]

INTERNET-DRAFT               Optimistic DAD                 28 June 2004



Full Copyright Statement



   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.



Intellectual Property Statement



   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in IETF Documents can be
   found in BCP 78 and 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org.



Disclaimer of Validity



   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.








Nick 'Sharkey' Moore    Expires: 28 December 2004              [Page 17]

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/