IPv6 Working Group                                 Nick 'Sharkey' Moore
INTERNET-DRAFT                                   Monash University CTIE
                                                       22 December 2005

            Optimistic Duplicate Address Detection for IPv6

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

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


   Optimistic Duplicate Address Detection is an interoperable
   modification of the existing IPv6 Neighbor Discovery (RFC2461) and
   Stateless Address Autoconfiguration (RFC2462) process.  The intention
   is to minimize address configuration delays in the successful case,
   to reduce disruption as far as possible in the failure case and to
   remain interoperable with unmodified hosts and routers.

Nick 'Sharkey' Moore      Expires: 22 June 2006                 [Page 1]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

Table of Contents

   Status of this Memo .........................................  1
   Abstract ....................................................  1
   Table of Contents ...........................................  2
   1. Introduction .............................................  3
           1.1 Problem Statement ...............................  3
           1.2 Definitions .....................................  4
           1.3 Address Types ...................................  4
           1.4 Abbreviations ...................................  5
   2. Optimistic Behaviours ....................................  6
           2.1 Optimistic Addresses ............................  6
           2.2 Avoiding Disruption .............................  6
           2.3 Router Redirection ..............................  7
           2.4 Contacting the Router ...........................  7
   3. Modifications to RFC-compliant behaviour .................  8
           3.1 General .........................................  8
           3.2 Modifications to RFC 2461 Neighbor Discovery ....  8
           3.3 Modifications to RFC 2462 SLAAC .................  9
   4. Protocol Operation ....................................... 10
           4.1 Simple case ..................................... 10
           4.2 Collision case .................................. 11
           4.3 Interoperation cases ............................ 12
           4.4 Pathological cases .............................. 12
   5. Security Considerations .................................. 13
   6. IANA Considerations ...................................... 13
   Appendix A: Probability of Collision ........................ 14
           A.1 The Birthday Paradox ............................ 14
           A.2 Individual Moving Nodes ......................... 15
   Normative References ........................................ 16
   Informative References ...................................... 16
   Author's Address ............................................ 17
   Acknowledgments ............................................. 17
   Full Copyright Statement .................................... 17
   Intellectual Property Statement ............................. 18
   Disclaimer of Validity ...................................... 18

Nick 'Sharkey' Moore      Expires: 22 June 2006                 [Page 2]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

1. Introduction

   Optimistic Duplicate Address Detection (DAD) is a modification of the
   existing IPv6 Neighbor Discovery (ND) [RFC2461] and Stateless Address
   Autoconfiguration (SLAAC) [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 in most cases DAD is
   far more likely to succeed than fail.  This is discussed further in
   Appendix A.  Disruption is minimized by limiting nodes' participation
   in Neighbor Discovery while their addresses are still Optimistic.

   It is not the intention of this memo 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 fixed 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: 22 June 2006                 [Page 3]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

1.2 Definitions

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

   Address Resolution - Process defined by [RFC2461] section 7.2.

   Neighbor Unreachability Detection - Process defined by [RFC2461]
        section 7.3.

   Optimistic Node - An Optimistic Node is one that is compliant with
        the rules specified in this memo.

   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.

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

1.3 Address Types

   Tentative address - an address whose uniqueness on a link is being
        verified, prior to its assignment to an interface.  A Tentative
        address is not considered assigned to an interface in the usual
        sense. An interface discards received packets addressed to a
        Tentative address, but accepts Neighbor Discovery packets
        related to Duplicate Address Detection for the Tentative

   Optimistic address - an address which is assigned to an interface and
        available for use, subject to restrictions, while its uniqueness
        on a link is being verified.  This memo introduces the
        Optimistic state and defines its behaviours and restrictions.

   Preferred address - an address assigned to an interface whose use by
        upper layer protocols is unrestricted. Preferred addresses may
        be used as the source (or destination) address of packets sent
        from (or to) the interface.

Nick 'Sharkey' Moore      Expires: 22 June 2006                 [Page 4]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

   Deprecated address - An address assigned to an interface whose use is
        discouraged, but not forbidden.  A Deprecated address should no
        longer be used as a source address in new communications, but
        packets sent from or to Deprecated addresses are delivered as
        expected.  A Deprecated address may continue to be used as a
        source address in communications where switching to a Preferred
        address causes hardship to a specific upper-layer activity
        (e.g., an existing TCP connection).

   Valid Address - a Preferred, Optimistic or Deprecated address. A
        valid address may appear as the source or destination address of
        a packet, and the internet routing system is expected to deliver
        packets sent to a valid address to their intended recipients.

1.4 Abbreviations

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

   ICMP Redirect - See [RFC2461] section 4.5.

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

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

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

   NS - Neighbor 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.

   SLAAC - 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 and Neighbor Advertisements.  See [RFC2461] sections
        4.4, 4.5 and 4.6.1.

Nick 'Sharkey' Moore      Expires: 22 June 2006                 [Page 5]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

2. Optimistic DAD Behaviours

   This non-normative section discusses Optimistic DAD behaviours.

2.1 Optimistic Addresses

   [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 address states may also be used by other standards documents,
   for example Default Address Selection [RFC3484].

   This memo introduces a new address state, 'Optimistic', that is used
   to mark an address which is available for use but which has not
   completed DAD.

   Unless noted otherwise, components of the IPv6 protocol stack should
   treat addresses in the Optimistic state equivalently to those in the
   Deprecated state, indicating that the address is available for use
   but should not be used if another suitable address is available.  For
   example, Default Address Selection [RFC3484] uses the address state
   to decide which source address to use for an outgoing packet.
   Implementations should treat an address in state Optimistic as if it
   were in state Deprecated.  If address states are recorded as
   individual flags, this can easily be achieved by also setting
   'Deprecated' when 'Optimistic' is set.

   It is important to note that the address lifetime rules of [RFC2462]
   still apply, and so an address may be Deprecated as well as
   Optimistic.  When DAD completes without incident, the address becomes
   either a Preferred or a Deprecated address, as per [RFC2462].

2.2 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 neighbors' Neighbor 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.

Nick 'Sharkey' Moore      Expires: 22 June 2006                 [Page 6]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

   This is achieved by:

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

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

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

   An address collision with a router may cause neighboring 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.3 Router Redirection

   Neighbor Solicitations cannot be sent from Optimistic Addresses, and
   so an ON cannot directly contact a neighbor which is not already in
   its Neighbor Cache.  Instead, the ON forwards packets via its default
   router, relying on the router to forward the packets to their
   destination.  In accordance with RFC2461, 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.  If it does not, packets
   continue to be forwarded via the router until the ON has a non-
   Optimistic address from which to send an NS.

2.4 Contacting the Router

   Router Solicitations cannot be sent from Optimistic Addresses, and
   thus a node which only has Optimistic Addresses cannot contact a
   router unless it already knows its Link-Layer Address.  This
   information is generally included in the RA, but this option "MAY be
   omitted to facilitate in-bound load balancing over replicated
   interfaces." [RFC2461].  In this case, the ON will be unable to
   communicate with the router until at least one of its addresses in no
   longer Optimistic.

Nick 'Sharkey' Moore      Expires: 22 June 2006                 [Page 7]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

3. Modifications to RFC-mandated behaviour

All normative text in this memo is contained in this section.

3.1 General

   * Optimistic DAD SHOULD only be used when the implementation is aware
        that the address is based on a most likely unique interface
        identifier (such as in [RFC2464]), generated randomly [RFC3041]
        or by a well-distributed hash function [RFC3972] or assigned by
        DHCPv6 [RFC3315].  Optimistic DAD SHOULD NOT be used for
        manually entered addresses.

3.2 Modifications to RFC 2461 Neighbor Discovery

   * (modifies 6.3.7)  A node MUST NOT send a Router Solicitation with a
        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 Neighbor Solicitation.

   * If the ON isn't told the SLLAO of the router in an RA, and it
        cannot determine this information without breaching the rules
        above, it MUST leave the address Tentative until DAD completes
        despite being unable to send any packets to the router.

   * (modifies 7.2.2)  When a node has a unicast packet to send from an
        Optimistic Address to a neighbor, but does not know the
        neighbor's link-layer address, it MUST NOT perform Address
        Resolution. It SHOULD forward the packet to a default router on
        the link in the hope that the packet will be redirected.
        Otherwise it SHOULD buffer the packet until DAD is complete.

Nick 'Sharkey' Moore      Expires: 22 June 2006                 [Page 8]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

3.3 Modifications to RFC 2462 Stateless Address Autoconfiguration

   * (modifies 5.5) A host MAY choose to configure a new address as an
        Optimistic Address.  A host which does not know the SLLAO of its
        router SHOULD NOT configure a new address as Optimistic.  A
        router SHOULD NOT configure an Optimistic Address.

   * (modifies 5.4.2) The host MUST join the all-nodes multicast address
        and the solicited-node multicast address of the tentative
        address.  The host SHOULD NOT delay before sending Neighbour
        Solicitation messages.

   * (modifies 5.4) The Optimistic Address is configured and available
        for use on the interface immediately.  The address MUST be
        flagged as 'Optimistic'.

   * When DAD completes for an Optimistic Address, the address is no
        longer Optimistic and it becomes Preferred or Deprecated
        according to the rules of RFC2462.

   * (modifies 5.4.3) The node MUST NOT reply to a Neighbor Solicitation
        for an Optimistic Address from the unspecified address.  Receipt
        of such an NS indicates that the address is a duplicate, and it
        MUST be deconfigured as per the behaviour specified in RFC2462
        for Tentative addresses.

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

Nick 'Sharkey' Moore      Expires: 22 June 2006                 [Page 9]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

4. Protocol Operation

   This non-normative section provides clarification of the interactions
   between Optimistic Nodes, and between Optimistic Nodes and Standard

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

   The ON will immediately send out a Neighbor Solicitation to determine
   if its new Optimistic Address is already in use.

4.1 Simple case

   In the non-collision case, the Optimistic Address being configured by
   the new node is unused and not present in the Neighbor Caches of any
   of its neighbors.

   There will be no response to its NS (sent from ::), and this NS will
   not modify the state of neighbors' Neighbor Caches.

   The ON already has the link-layer address of the router (from the
   RA), and the router can determine the link-layer address of the ON
   through standard Address Resolution.  Communications can begin as
   soon as the router and the ON have each others' link-layer addresses.

   After the appropriate DAD delay has completed, the address is no
   longer Optimistic, and becomes either Preferred or Deprecated as per

Nick 'Sharkey' Moore      Expires: 22 June 2006                [Page 10]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

4.2 Collision case

   In the collision case, the Optimistic Address being configured by the
   new node is already in use by another node, and present in the
   Neighbor Caches (NCs) of neighbors which are communicating with this

   The NS sent by the ON has the unspecified source address, ::, and no
   SLLAO.  This NS will not cause changes to the NC entries of
   neighboring hosts.

   The ON will hopefully already know all it needs to about the router
   from the initial RA.  However, if it needs to it can still send an RS
   to ask for more information, but it may not include a SLLAO.  This
   forces an all-nodes multicast response from the router, but will not
   disrupt other nodes' NCs.

   In the course of establishing connections, the ON might have sent NAs
   in response to received NSs.  Since NAs sent from Optimistic
   Addresses have O=0, they will not have overridden existing NC
   entries, although they may have resulted in a colliding entry being
   changed to state STALE.  This change is recoverable through standard

   When an NA is received from the collidee defending the address, the
   ON immediately stops using the address and deconfigures it.

   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 Mobile IPv6 [RFC3775]).  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: 22 June 2006                [Page 11]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

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 ON attempts to configure an address currently Tentatively
   assigned to a Standard Node, the Standard Node will see the Neighbor
   Solicitation and deconfigure the address.

   If a node attempts to configure an ON's Optimistic Address, the ON
   will see the NS and deconfigure the address.

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

   These problems exist, and are not gracefully recoverable, in Standard
   DAD.  Their probability in both Optimistic and Standard DAD can be
   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, e.g.: that the router includes SLLAOs in RAs, and
   that the router is willing to redirect traffic for the ON.  Where the
   router does not behave in this way, the behaviour of Optimistic DAD
   inherently reverts to that of Standard DAD.

Nick 'Sharkey' Moore      Expires: 22 June 2006                [Page 12]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

5. Security Considerations

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

   Secure Neighbor Discovery [RFC3971] provides protection against the
   threats to Neighbor Discovery described in [RFC3756].  Optimistic
   Duplicate Address Detection does not introduce any additional threats
   to Neighbor Discovery if SEND is used.

   Optimistic DAD takes steps to ensure that if another node is already
   using an address, the proper link-layer address in existing Neighbor
   Cache Entries is not replaced with the link-layer address of the
   Optimistic node. However, there are still scenarios where incorrect
   entries may be created, if only temporarily.  For example, if a
   router (while forwarding a packet) sends out a Neighbor Solicitation
   for an address, the optimistic node may respond first, and if the
   router has no pre-existing link-layer address for that IP address, it
   will accept the response and (incorrectly) forward any queued packets
   to the optimistic node. The optimistic node may then respond in an
   incorrect manner (e.g., sending a TCP RST in response to an unknown
   TCP connection). Such transient conditions should be short-lived, in
   most cases.

   Likewise, an Optimistic node can still inject IP packets into the
   Internet that will in effect be "spoofed" packets appearing to come
   from the legitimate node. In some cases, those packets may lead to
   errors or other operational problems, though one would expect that
   upper layer protocols would generally treat such packets robustly, in
   the same way they must treat old and other duplicate packets.

6. IANA Considerations

   This document has no actions for IANA.

Nick 'Sharkey' Moore      Expires: 22 June 2006                [Page 13]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

Appendix A:  Probability of Collision

   In assessing the usefulness of Duplication Address Detection, the
   probability of collision must be considered.  Various mechanisms such
   as SLAAC [RFC2462] and DHCPv6 [RFC3315] attempt to guarantee the
   uniqueness of the address.  The uniqueness of SLAAC depends on the
   reliability of the manufacturing process (so that duplicate L2
   addresses are not assigned) and human factors if L2 addresses can be
   manually assigned.  The uniqueness of DHCPv6 assigned addresses
   relies on the correctness of implementation to ensure that no two
   nodes can be given the same address.

   Privacy Extensions to SLAAC [RFC3041] avoids these potential error
   cases by picking an Interface Identifier (IID) at random from 2^62
   possible 64-bit IIDs (allowing for the reserved U and G bits).  No
   attempt is made to guarantee uniqueness, but the probability can be
   easily estimated, and as the following discussion shows, probability
   of collision is exceedingly small.

A.1 The Birthday Paradox

   When considering collision probability, the Birthday Paradox is
   generally mentioned.  When randomly selecting k values from n
   possibilities, the probability of two values being the same is:

        Pb(n,k) = 1-( n! / [ (n-k)! . n^k] )

   Calculating the probability of collision with this method is
   difficult, however, as one of the terms is n!, and (2^62)! is an
   unwieldy number.  We can, however, calculate an upper bound for the
   probability of collision:

        Pb(n,k) <= 1-( [(n-k+1)/n] ^ [k-1] )

   which lets us calculate that even for large networks the probability
   of any two nodes colliding is very small indeed:

        Pb(2^62,    500) <= 5.4e-14
        Pb(2^62,   5000) <= 5.4e-12
        Pb(2^62,  50000) <= 5.4e-10
        Pb(2^62, 500000) <= 5.4e-08

   The upper bound formula used above was taken from 'draft-soto-
   mobileip-random-iids-00' by M. Bagnulo, I. Soto, A. Garcia-Martinez
   and A. Azcorra and is used with the kind permission of the authors.

Nick 'Sharkey' Moore      Expires: 22 June 2006                [Page 14]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

A.2 Individual Nodes

   When considering the effect of collisions on an individual node, we
   do not need to consider the Birthday Paradox.  When a node moves into
   a network with K existing nodes, the probability that it will not
   collide with any of the distinct addresses in use is simply 1-K/N.
   If it moves to such networks M times, the probability that it will
   not cause a collision on any of those moves is (1-K/N)^M, thus the
   probability of it causing at least one collision is:

        Pc(n,k,m) = 1-[(1-k/n)^m]

   Even considering a very large number of moves (m = 600000, slightly
   more than one move per minute for one year) and rather crowded
   networks (k=50000 nodes per network), the odds of collision for a
   given node are vanishingly small:

        Pc(2^62,  5000,   600000)     = 6.66e-10
        Pc(2^62, 50000,   600000)     = 6.53e-09

   Each such collision affects two nodes, so the probability of being
   effected by a collision is twice this.  Even if the node moves into
   networks of 50000 nodes once per minute for 100 years, the
   probability of it causing or suffering a collision at any point are a
   little over 1 in a million.

        Pc(2^62, 50000, 60000000) * 2 = 1.3e-06

Nick 'Sharkey' Moore      Expires: 22 June 2006                [Page 15]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

Normative References

   [RFC2119] S. Bradner.  "RFC 2119: Key words for use in RFCs to
        Indicate Requirement Levels."

   [RFC2461]  T. Narten, E.Nordmark, W. Simpson.  "RFC 2461: Neighbor
        Discovery for IP Version 6 (IPv6)."

   [RFC2462] S. Thomson, T. Narten.  "RFC 2462: IPv6 Stateless Address

Informative References

   [RFC2464] M. Crawford.  "RFC 2464: Transmission of IPv6 Packets over
        Ethernet Networks."

   [RFC3041] T. Narten, R. Draves.  "RFC 3041: Privacy Extensions for
        Stateless Address Autoconfiguration in IPv6."

   [RFC3315] R. Droms (Ed.), J. Bound, B. Volz, T. Lemon, C. Perkins, M.
        Carney.  "RFC 3315: Dynamic Host Configuration Protocol for IPv6

   [RFC3484] R. Draves.  "RFC 3484: Default Address Selection for
        Internet Protocol version 6 (IPv6)."

   [RFC3756] P. Nikander, J. Kempf, E. Nordmark.  "RFC 3756: IPv6
        Neighbor Discovery (ND) Trust Models and Threats."

   [RFC3775] D. Johnson, C. Perkins, J. Arkko.  "RFC 3775: Mobility
        Support in IPv6."

   [RFC3971] J. Arkko (Ed.), J. Kempf, B.Zill, P. Nikander.  "RFC 3971:
        SEcure Neighbor Discovery (SEND)."

   [RFC3972] T. Aura.  "RFC 3972: Cryptographically Generated Addresses

Nick 'Sharkey' Moore      Expires: 22 June 2006                [Page 16]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

Author's Address:

   Nick 'Sharkey' Moore
   Centre for Telecommunications and Information Engineering
   Monash University 3800
   Victoria, Australia

   Comments should be sent to <sharkey@zoic.org> and/or the IPv6 Working
   Group mailing list.


   There is some precedent for this work in previous Internet Drafts and
   in discussions in the MobileIP WG mailing list and at IETF-54.  A
   similar concept occurs in the 'Optimistic' bit used by R. Koodli and
   C. Perkins in the now expired 'draft-koodli-mobileip-fastv6-00.txt'.

   Thanks to Greg Daley, Richard Nelson, Brett Pentland and Ahmet
   Sekercioglu at Monash University CTIE for their feedback and
   encouragement.  More information is available at:

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

   This work has been supported by the Australian Telecommunications
   Cooperative Research Centre (ATcrc):

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

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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.

Nick 'Sharkey' Moore      Expires: 22 June 2006                [Page 17]

INTERNET-DRAFT               Optimistic DAD             22 December 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 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

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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Nick 'Sharkey' Moore      Expires: 22 June 2006                [Page 18]