>The main point Thomas made is that DAD failure for an EUI-64 based
>address is likely to indicate MAC address collision, in which case
>disabling the entire interface is better rather than trying hopeless
>recovery which may even make it harder to diagnose the real problem.
>(I believe the current text of rfc2462bis clearly made the point, BTW)
>
>In that sense, "try again with random-number-generated linklocal
>address" doesn't make sense. We could "call operator with a beep",
>but we'd not be able to do that via network if the MAC address
>collides. So, IMO, it is not very convincing to argue we could rely
>on such an outbound mechanism in a discussion about a network protocol
>specification.
>
>Meanwhile, we could also make a more fundamental question on whether
>the analysis that Thomas provided (i.e., DAD failure for EUI-64 based
>address probably means MAC collision) is valid. If not, this can be
>another reason to reconsider the current text. I personally think
>his analysis is quite reasonable though.
today we are using Ethernet-based technology, hence EUI64 is generated
by MAC address. however we don't know what kind of technology we
will be using for coming decade (it could be 10Tbase-TX, it could be
something else, we just cannot predict).
i personally think the analysis (by Thomas Narten) is short-sighted.
moreover, if MAC address is under collision, IPv4 does not work,
Appletalk does not work (i guess). so there's no point in IPv6
making a judgement call to disable *interface*. it is like IPv6 is
saying "i'm the law on this interface, other protocol must obey me".
if it is to disable *the use of IPv6 on the interface*, or disable
*the particular address which failed DAD*, it makes more sense.
itojun
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
