Hi Jinmei,
JINMEI Tatuya / çæéå wrote:
On Mon, 21 Feb 2005 20:06:45 +0100, Christian Vogt <[EMAIL PROTECTED]> said:
...to this...
[...] If there is no existing Neighbor Cache entry for the solicitation's sender and a Source Link-Layer Address option was present in the solicitation, the router creates a new Neighbor Cache entry, 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 does either one of the following:
- It performs address resolution on the solicitation's sender, creates a new Neighbor Cache entry, installs the link-layer address, sets its reachability state to STALE as specified in Section 7.3.3, and responds with a unicast Router Advertisement directed to the solicitation's sender.
I personally think this is overspecification. As I said in a separate message, the essential problem (IMO) is that the spec is unclear on the case where - an unsolicited ND message does not contain source/target LLAO - the receiving node does not have a neighbor cache entry for the source/target
(and this is a general issue, not specific to RS).
Once we clarify this point, I believe we can simply leave the other details to implementors. In this specific case, for example, if the router that receives the RS decides to respond to it with a unicast RA (this is already explicitly allowed in the current spec), the outgoing RA will create a new neighbor cache entry, causing link-layer address resolution (again, per the current specification). There'd be no difference on the external behavior.
Moreover, I even think specifying this level of details can be harmful for some implementations. In the case of BSD/KAME, it is a userland process (rtadvd) which would decide to respond to the RS with a unicast RA (although currently it only supports multicast RAs), while NS/NA exchanges can only happen inside the kernel. Thus, it is difficult for the implementation to follow the specified ordering:
1. it performs address resolution on the solicitation's sender 2. creates a new Neighbor Cache entry 3. installs the link-layer address 4. sets its reachability state to STALE (BTW: this is strange. after a successful address resolution, the state should be REACHABLE) 5. responds with a unicast Router Advertisement
because the kernel, which performs 1 through 4, cannot tell the application's decision beforehand.
Again, note that we can realize (almost) exactly the same external behavior without specifying this ordering. IMO, what we should do is to fix the real generic issue, and then there should be no ambiguity in further details.
I don't think the issue of Unsolicited NA is a big one, since there's
no implied response, and well known unreliability issues with
sending an unsolicited NA (people ignore it if there's no existing entry) which limit its use.
So if this is the case, we need to describe messages which request a response or change configuration state without having LLAOs.
How about a paragraph (maybe somewhere else) saying:
"... It is possible that a host may receive a solicitation or a router
advertisement without a link-layer address option included.
These messages will not create or update neighbor cache entries,
except with respect to the IsRouter flag as specified in
Sections XXX and YYY. If a neighbour cache entry does not exist for the source of such a
message, Address Resolution will be required before unicast
communications with that address to begin.
This is particularly relevant for unicast responses to
solicitations where an additional packet exchange is required for
advertisement delivery.
..."I'm not sure about whether this is better or not perhaps this could go into 7.2.X, in an effort to tie the exercise to address resolution, rather than reception of a particular message (considering that the document is basically broken into 3 sections: RD, ND, Redirect).
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
