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 PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
