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

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

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.  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