On 23/07/2013 18:32, JINMEI Tatuya / 神明達哉 wrote:
> At Tue, 23 Jul 2013 13:09:50 +1200,
> Brian E Carpenter <[email protected]> wrote:
>
>>> I have one comment that may improve the clarity of the document: the
>>> latter half of Section 4 is not very understandable to me:
>>>
>>> There is one case in RFC 4862 that requires additional consideration:
>>>
>>> "On the other hand, if the duplicate link-local address is not formed
>>> from an interface identifier based on the hardware address, which is
>>> supposed to be uniquely assigned, IP operation on the interface MAY
>>> be continued."
>> To be honest, I have great difficulty understanding this sentence,
>> because I can't imagine any case in which continuing operation would
>> be OK. It seems to me that disaster is guaranteed. However, somebody
>> in the WG asked us to discuss this case.
>
> For example, there may be other, manually assigned address that is
> unique in the subnet.
Ah. Now I understand what is intended, but the text needs to say:
...IP operation on the interface MAY be continued _using another
address that is not a duplicate_.
OK, we can clean up the text in the next version.
Brian
Or you might assign some once you notice the
> duplicate. If it's less likely due to MAC address collision, I see it
> makes some sense (but RFC 4862 does not necessarily recommend it; it
> just does not prohibit it by saying MAY).
>
> (BTW, I noticed the phrase of ", which is supposed to be uniquely
> assigned," in the above snippet from RFC 4862 may be confusing. I'm
> not sure how it was inserted, but it's probably a copy-paste error).
>
>>> The main intent of this part of RFC 4862 was that if a link-local
>>> address created based on a MAC address is detected to be a duplicate,
>>> that very strongly suggests there's MAC address collision, and it's
>>> better to take some specific action (i.e, disabling the IP operation).
>>> In all other cases, the IP address duplicate may or may not be because
>>> of MAC address collision, and since there's no strong indication of
>>> MAC address collision, RFC 4862 leaves it to the implementor (hence
>>> the MAY).
>> But it doesn't matter. If you have duplicate IIDs, you have
>> unintentionally created a link-local anycast address, whether it's
>> MAC collision or otherwise. Surely there is no way forward?
>
> See above. Surely there's no way of using that link-local address any
> more (I believe RFC 4862 is very clear about that). But there can be
> other reasonable way of recovery from that situation at layer 3 if
> it's not MAC collision.
>
> --
> JINMEI, Tatuya
> .
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
