>>>>> On Sun, 20 Feb 2005 18:23:12 -0500,
>>>>> "Soliman, Hesham" <[EMAIL PROTECTED]> said:
> The text now looks like this:
> Router Solicitations in which the Source Address is the unspecified
> address MUST NOT update the router's Neighbor Cache; solicitations
> with a proper source address update the Neighbor Cache as follows. If
> the router already has a Neighbor Cache entry for the solicitation's
> sender, the solicitation contains a Source Link-Layer Address option,
> and the received link-layer address differs from that already in the
> cache, the link-layer address SHOULD be updated in the appropriate
> Neighbor Cache entry, and its reachability state MUST also be set to
> STALE. If there is no existing Neighbor Cache entry for the
> solicitation's sender, the router creates one, installs the link-
> layer address and sets its reachability state to STALE as specified
> in Section 7.3.3. If there is no existing Neighbor Cache entry and no Source
> Link-Layer Address option was present in the solicitation, the router may
> respond with either a unicast or a multicast router advertisement. Whether or
> not a Source Link-Layer Address option
> is provided, if a Neighbor Cache entry for the solicitation's sender
> exists (or is created) the entry's IsRouter flag MUST be set to
> FALSE.
Hmm...although I'm not necessarily opposing to the proposed text per
se, I'm afraid we're missing the point. The general issue here, as I
see it, is the ND specification is not very clear about the case where
a (source or target) link-layer address is not provided in an
"unsolicited" messages (i.e., RS, RA, NS, redirects) and the receiving
node does not have a neighbor cache entry for the (source or target)
address.
For example, it's not clear about an NS in Section 7.3.3:
A Neighbor Cache entry enters the STALE state when created as a
result of receiving packets other than solicited Neighbor
Advertisements (i.e., Router Solicitations, Router Advertisements,
Redirects, and Neighbor Solicitations). These packets contain the
^^^^^^^^^^^^^^^^^^^^^^^^^
link-layer address of either the sender or, in the case of Redirect,
^^^^^^^^^^^^^^^^^^
the redirection target.
As we can see, the specification unconditionally assumes that these
packet contain a source or target LLAO.
So, I believe the more appropriate fix is to clarify how the node
should behave in this case in general.
As already pointed out, entering the STALE state doesn't make sense
without a link-layer address.
Again, as was pointed out in this thread, KAME/BSD creates a new entry
with its implementation-specific state "NOSTATE". This might be one
possible resolution to this issue. After re-reading the
specification, however, I now feel it makes more sense to do nothing
with neighbor cache (i.e., do not create a neighbor cache in the first
place).
If the receiving node then needs to send a unicast packet to the
(source or target) address, it will simply create a new entry with the
INCOMPLETE state. There is no additional delay here except some CPU
cycles in the sending procedure.
Once we clarify this point, I don't see a particular need for adding
something like:
If there is no existing Neighbor Cache entry and no Source
Link-Layer Address option was present in the solicitation, the
router may respond with either a unicast or a multicast router
advertisement.
Since this is already pretty clear from the first part of this section
under a more flexible condition (i.e., whether or not the solicitation
included SLLAO):
In addition to sending periodic, unsolicited advertisements, a router
sends advertisements in response to valid solicitations received on
an advertising interface. A router MAY choose to unicast the
response directly to the soliciting host's address (if the
solicitation's source address is not the unspecified address),
BTW: in any event, we'll also need to fix other similar cases (e.g.,
Section 7.3.3) and Appendix C.
And one last remark: "NOSTATE" was actually introduced for
implementation-specific reasons, rather than to deal with the gap in
the specification. So, we'll still keep this state as an internal
state specific to the implementation regardless of the result of this
discussion.
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
--------------------------------------------------------------------
