>>>>> On Wed, 07 Jul 2004 17:38:29 +0900,
>>>>> [EMAIL PROTECTED] said:
>> 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.
I respect the opinion, but I also think that kind of argument (i.e.,
we cannot tell future technologies, so we cannot do xxx) is too
generic (thus can always apply) to reverse this particular decision in
rfc2462bis. (For example, we have a similar decision on the
"almost-fixed" prefix length of 64 for address autoconfiguration while
we cannot be sure about future link types. But we'll probably not be
able to convince others to loosen the sense of the "almost constant"
by just saying "we cannot tell future link types on which the address
prefix length also depends, so the almost fixed number is
short-sighted")
Besides, the current text of rfc2462bis actually says "based on the
hardware address" instead of assuming EUI-64 unconditionally:
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.
I guess this wording already address your concern because the
description should mean a future link-layer technology can be an
exception to this rule if interface identifiers are not directly tied
with link-layer (hardware) addresses. I added "EUI-64" as an example
because it would provide concrete idea on what the "hardware address"
actually means for implementors. I think the current wording is
enough, but if you are still worried about future formats of EUI-64
that can be an exception, I could even say "(e.g., today's EUI-64
format for Ethernet links)".
> 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.
I've already proposed to use the interpretation of limiting the
meaning of "disabling" to IPv6 operation.
So...can you live with the current specification of "disabling the
entire interface" if we limit the effect to IPv6 (and clarify that
point in the document)?
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
--------------------------------------------------------------------
