> 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)".
yup, i know this.
> > 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)?
yes, that is what i want to see. however, even in this case,
"disable" has multiple interpretations:
- disable the address which failed DAD
- disable the address which shares the same interface ID as the
DAD-failed linklocal
- disable the use of IPv6 (all addresses on the interface)
i would like to see your clarified text and then i may comment.
itojun
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
