At Tue, 10 Jul 2007 07:43:34 -0400,
James Carlson <[EMAIL PROTECTED]> wrote:
> > 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, but care
> > should be taken so that the advertisement will not affect the
> > normal Neighbor Discovery [RFC4861] processing.
>
> This seems better to me, as it clarifies the scope, though I'm
> somewhat unclear on what the last clause actually implies.
>
> 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).
> I might have worded it something like this:
>
> How to handle such a case is beyond the scope of this
> document, but implementations that take any action other than
> discarding the message MUST take measures to avoid an infinite
> series of advertisements triggered by reception of such
> messages.
>
> Or just:
>
> How to handle such a case is beyond the scope of this
> document, and implementations MAY log and discard such
> messages.
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)?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
