Subject: [rfc2462bis issue 280] interface failure upon DAD failure

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 06 Feb 2004 00:53:13 +0900

To address the issue "the requirement that the interface SHOULD be
disabled upon DAD failure is too strong", I simply added the following
line to Section 5.4.5:

   An implementation MAY try an automatic recovery technique
   from this failure and re-enable the interface.

in the proposed resolution.

But I then noticed that the issue was not that simple; I missed a
discussion in last November (which I should have joined, actually...).

By catching up the discussion, my impression is:

- many people agreed that the "SHOULD" for the interface is too
  strong.  The MUST NOT for the address is enough.

- one motivation to remove the SHOULD for the interface is the
  possibility of DoS attacks.  But it seems to me that it's not very
  convincing; as Thomas (Narten) said, the attacker can continue the
  attack even if we re-enable the interface.

- Thomas made a good point about the rationale of the SHOULD (DAD
  failure for an EUI-64 based address likely indicates MAC address
  duplication).  We should also note that John (Loughney) pointed out
  the assumption in 2462 is not necessarily met for the 3GPP case (I
  don't know what exactly he wanted to say, though)

and my current feeling about the resolution is:

+ keep SHOULD for the interface if the interface identifier is derived
  from the layer 2 address, with the original intention Thomas
  explained.
+ allow MAY for the other cases (does this help the 3GPP case?)
+ remove the current resolution: "MAY try an automatic recovery"

Does this make sense to others?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Soliman Hesham <[email-masked]>
Date: Fri, 6 Feb 2004 08:02:37 -0500

> + allow MAY for the other cases (does this help the 3GPP case?)

=> Agreed with the above. Basically the 3GPP case is just an example where
MAC addresses are not assigned to interfaces, which is very different from
Ethernet. In other words, you can think of it as a link layer that has no
MAC
addresses (seen by the IP layer). So address duplication is completely
decoupled from MAC address duplication.

 > + remove the current resolution: "MAY try an automatic recovery"

=> I'm fine with explaining the two cases above. This makes it clear that 
any address not derived from a MAC address can be disabled without 
disabling the interface. A host can then generate another address and 
try again.

Hesham

---

From: [email-masked]
Date: Tue, 10 Feb 2004 15:32:14 +0200

Hi Jinmei,

> The new revision revised this section as follows:
> 
> 5.4.5 When Duplicate Address Detection Fails
> 
>    A tentative address that is determined to be a duplicate as described
>    above MUST NOT be assigned to an interface and the node SHOULD log a
>    system management error. 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. In this case, the
>    IP address duplication probably means duplicate hardware addresses
>    are in use, and trying to recover from it by configuring another IP
>    address will not result in a usable network. In fact, it probably
>    makes things worse by creating problems that are harder to diagnose
>    than just shutting down the interface; the user will see a partially
>    working network where some things work, and other things will not. On
>    the other hand, if the duplicated link-local address is not formed
>    from an interface identifier based on the hardware address, the
>    interface MAY continue to be used.
> 
> Would you live with this?

Yes, this is OK.

thanks,
John