Subject: [mobile-ip] Mipv6 issue #157: Collision action

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Nov 2002 23:47:38 +0200

Here's a proposed solution, based on what Hesham suggested in Atlanta.
The problem with the current text in 7.7 is that the ADs felt that
there's a conflict between the IPv6 RFCs and draft 19 regarding the
collision action, i.e. to stop and disable vs. continue.

Hesham's suggestion was to use RFC 3041 to avoid this problem.
Apparently we need to retain a part of Section 7.7 in order
to explain how to do RFC 3041 for link-local addresses. This
is fine, however, as it is an extension not a conflict with
the IPv6 RFCs. RFC 2462 indicates that the drastic collision
actions need to be taken if the address was based on an IID.
I think we can interpret this so that it means a EUI or other
forms of stable IIDs. Therefore, if a collision is detected
the procedures outlined in RFC 3041 are used and hence our
problem is avoided.

Here's the text proposal:

    Upon failing Duplicate Address Detection, [13] requires IPv6 nodes to
    stop using the address and wait for reconfiguration. In addition, if
    the failed address was a link-local address formed from an interface
    identifier, the interface should be disabled.

    Mobile nodes that wish to avoid this situation MAY use temporary
    link-local addresses as follows. The mobile node SHOULD generate
    a random interface identifier and use it for assigning itself a
    link-local address. In order to do this, the mobile node applies
    to the link-local address the procedure described in [17] for
    global addresses.  At most 5 consecutive attempts SHOULD be
    performed to generate such addresses and test them through
    Duplicate Address Detection.  If after these attempts
    no unique address was found, the mobile node SHOULD log a system
    error and give up attempting to find a link-local address on that
    interface, until the node moves to a new link.

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 28 Nov 2002 11:02:05 +1100

> Hesham's suggestion was to use RFC 3041 to avoid this problem.

It's something I've considered in my Optimistic DAD draft too ...
the stop-and-disable behaviour doesn't really make sense for
mobile nodes.  Some kind of randomized addressing in the 
case of collision would be more sensible, and at the risk of
inflaming the discussion ("NO NEW FEATURES!"), here's what
I did in draft-moore-ipv6-optimistic-dad-01

   * If the interface offers a method to create a supposedly globally
        unique IPv6 address, this address MAY be used for the initial
        attempt.

   * Otherwise, or when creating a new address in the case of a
        collision, a suffix MUST be chosen based on a strongly random
        algorithm (see [RFC1750] for more information on random number
        generation).

   * The algorithm used MAY be 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 not globally
        unique Unicast address (see [RFC2373]).

   * In order to minimize the effect of DoS attacks, a delay of at least
        RETRANS_TIMER (as used in [RFC2461]) milliseconds MUST be
        introduced between attempts if DAD has already failed more than
        once.  An exponential backoff SHOULD be used.

cheers,
	Nick