JINMEI Tatuya / 神明達哉 writes:
> At Tue, 10 Jul 2007 07:43:34 -0400,
> James Carlson <[EMAIL PROTECTED]> wrote:
> > How should an implementor actually take care here? Are you perhaps
> > referring to the possibility of endless NA battles between a pair of
> > misconfigured systems? Or something else?
>
> I intended, for example, that implementations should not affect their
> neighbor caches as a result of processing the NA "as described in
> [RFC4861=2461bis]". I thought a naive implementation may be confused
> by the received NA and modify the link-layer address information of
> its own address (realized as a special type of neighbor cache).
Ah ... and "yikes!"
I hadn't considered that level of confusion. Yes, I agree that this
ought to be ruled out, and could perhaps be done explicitly.
"Such an unexpected advertisement MUST NOT be processed in a
way that modifies the neighbor cache entry for the conflicting
address."
> After understanding the proposed text was not really clear, I guess we
> should rather be silent and just state:
>
> 2. If the target address matches a unicast address assigned to the
> receiving interface, it would possibly indicate that the
> address is a duplicate but it has not been detected by the
> Duplicate Address Detection procedure (recall that Duplicate
> Address Detection is not completely reliable). How to handle
> such a case is beyond the scope of this document.
>
> This is probably enough since this bullet is clearly separated from
> bullet #3. Does this work for you (and others)?
That works for me.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
