>>>>> On Thu, 8 Jul 2004 14:04:42 +0900 (JST),
>>>>> [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) said:
>> > 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.
The last one (see also a previous message of mine in this thread -
attached below). Or perhaps even more - for example, if a router
finds duplication on an interface, it won't forward packets to or from
that interface. This scenario is not directly related to "addresses"
on the interface.
If we can agree so far, I'll make specific wording for the next
revision of rfc2462bis.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- Begin Message ---
>>>>> On Tue, 6 Jul 2004 12:08:49 +0900 (JST),
>>>>> [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) said:
> i have objection to 5.4.5 "when duplicated address detection fails".
> the text suggest that hardware-address-based linklocal address fails
> on DAD test, "the interface SHOULD be disabled".
> first of all, what does it mean by "disable interface"? if the
> interface has IPv4 addess and IPv4 packets are going through the
> interface, should we kill IPv4 as well? what about AppleTalk?
> does "disable interface" require hardware disabled (turn IFF_UP to 0)
> or only software?
As I said in my previous response, I'll concentrate on this one in
this message.
I think this is a valid question, and rfc2462bis should clarify what
"disable" means (if we agree on the current decision on "disabling"
interface, of course).
Considering the original background is that DAD failure on an
MAC address based L3 address likely means MAC address collision, the
"ideal" interpretation would be "disabling any operation of any
network protocols, including IPv4/AppleTalk/IPX/whatever".
At the same time, however, this is probably overkilling particularly
because we are basically only talking about a specific network
protocol (IPv6) in this specification, and this can be regarded as
protocol-boundary violation in that sense.
So, I personally think "disabling" only affects IPv6 network
operation. I'd say disabling an interface means
- the node does not send any IPv6 packets on the interface
- the node silently discards any IPv6 packets, if any, received on the
interface
This should usually mean "disabling" is performed as a software
operation, but it's an implementation-specific issue and will be out
of scope of the protocol specification document IMO.
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
--------------------------------------------------------------------
--- End Message ---
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
