At Thu, 5 Jul 2007 10:24:21 -0400,
"Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote:
> If the word solicitation is replaced by advertisement in section 5.4.4,
> we are fine. I don't like the too much wordiness of section 5.4.4. So I
> have prepared a paragraph for this section having made the text shorter
> and replaced the solicitation by an advertisement. This is what the new
> para for section 5.4.4 of 2461bis -08 should look like:
>
> -----------------
> On receipt of a valid Neighbor Advertisement message on an interface,
> node behavior depends upon whether the target address is tentative or
> not. If the target address is not tentative, the advertisement is
> processed as described in [I-D.ietf-ipv6-2461bis]. If the target address
> is tentative, the tentative address is not unique.
> -----------------
Which part of [I-D.ietf-ipv6-2461bis] (which will be RFC4861) do you
think describes the processing? Although I mentioned the first para
of Section 7.2.5 (copied below), I don't think we can simply apply it
to this case. As I read it, this paragraph describes the case where
- host A somehow receives an NA with the target address of X
- host A does not have a neighbor cache for address X
- address X is (possibly) assigned to some other nodes, and
- host A is not performing DAD on X as its own tentative address or it
has not assigned X on its interface
The most likely case in this scenario is that host A receives an
unsolicited NA with a target address that host A is not interested in
(and thus it doesn't have a neighbor cache for it).
On the other hand, the situation described in Section 5.4.4 of 2462bis
is:
- host A somehow receives an NA with the target address of X
- host A has assigned address X (which is not tentative) to the
receiving interface
in this case most (if not all) implementations of the receiving host
do not have a "neighbor cache" for X (since it's one of its own
addresses), so we could superficially apply section 7.2.5 of
2461/2461bis. But I don't think it's always obvious for
implementors. I usually hate a redundant description, but in this
case I believe we should be specific in 2462bis.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
(Section 7.2.5, first para of RFC2461 for reference)
When a valid Neighbor Advertisement is received (either solicited or
unsolicited), the Neighbor Cache is searched for the target's entry.
If no entry exists, the advertisement SHOULD be silently discarded.
There is no need to create an entry if none exists, since the
recipient has apparently not initiated any communication with the
target.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
