Subject: [mobile-ip] closing issue #79 (too drastic collision acftion)

From: Jari Arkko <[email-masked]>
Date: Wed, 25 Sep 2002 00:36:49 +0300

I'm trying to close issue #79 which dealt RFC 2462's
rules on how to behave when a DAD collision is detected.
Please see info & recommendation below:

BACKGROUND

In Hesham's scenario, the mobile node has, e.g., an EUI based address.
When away from home, the node runs into a collision. This collision
could be a real one, or perhaps caused by the bad guys. As a
result, RFC 2462 says (Sections 4 and 5.4.5) that the node
should stop using the address, wait for reconfiguration, and
if the collision happened for a link-local address, even disable
the interface.

PROBLEM

These actions are too drastic for a mobile node, and cause
several problems:

    1) One visit to a network that has the same address will
       render the mobile node's link-local address unusable even
       if the address could still be used in other networks.

    2) Disabling the interface is certainly an overkill.

    3) If we were sure there were no bad guys in the world,
       we could perhaps live with the above and trust the
       vendors to get their EUIs right. However, until we
       have SEcure Neighbor Discovery, it seems quite easy
       to launch attacks against mobile nodes: just drive
       through the city with a WLAN base station and respond
       to every DAD request you get. Everyone who sees your
       responses will disable themselves, waiting for
       reconfiguration.

    4) If the collision on a the link-local address leads
       to discarding the home address based on the same
       interface identifier (DAD vs. DIID) then the mobile
       node loses its home address, as well as the ability
       to talk to the home agent (as the security associations
       are per address).

RECOMMENDATION

Add a new section 7.6.

7.6. Changes to Duplicate Address Detection

Upon failing Duplicate Address Detection, RFC 2462 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 IPv6 extends this behaviour as follows. Upon failing
Duplicate Address Detection while away from home, a mobile node SHOULD
generate a new random interface identifier and use it for assigning
itself a new link-local address (again in the manner specified
by RFC 2462). The mobile node SHOULD NOT wait for reconfiguration
or disable the interface. The mobile node MUST NOT discard the
home address based on a failure of a link-local address with the
same interface identifier.

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 25 Sep 2002 10:09:02 -0400

Jari

Jari Arkko wrote:
> by RFC 2462).

RFC 2462 does not talk about what's required to generate a random IID.
Perhaps you meant to reference 3041 for how to generate a random IID?

> The mobile node SHOULD NOT wait for reconfiguration

What should happen to the link-local address that failed DAD?  Should
it remain "tentative" untill the node moves again and then retry DAD?

-vlad
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07