Re: 6MAN WG Last Call: <draft-ietf-6man-ug-01.txt>

[Brian E Carpenter <[e-mail]>]

On 23/07/2013 18:32, JINMEI Tatuya / 神明達哉 wrote:
> At Tue, 23 Jul 2013 13:09:50 +1200,
> Brian E Carpenter <[e-mail]> 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
> .
>