Hi Jinmei.
[...] 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).
I agree that it would be good to address this issue on a general level. On the other hand, there are also related differences between RS handling and NS handling that need to be described on a separate basis anyway. For instance, RFC 2461[bis] specifies exactly when a NA is to be multicast and when it is to be unicast (section 7.2.4). This is a difference to RA's, which may be either multicast or unicast (if the RS's source address was not unspecified), even if there is no SLLAO.
Also, section 7.2.4 explicitly says what to do if a unicast NA is to be sent, but the recipient's link-layer address is unknown (i.e., invoke address resolution). So one may consider to put a similar note into section 6.2.6. I don't think this would be overspecification.
> [...]
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.
Ok, your point is the order implied in the text I suggested. I actually didn't mean to imply this. But yes, the text could potentially be misinterpreted. So maybe you whish to reduce it to the following?
[...] 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 a Neighbor Cache entry for the solicitation's sender exists (or is created) the entry's IsRouter flag MUST be set to FALSE.
Because Router Solicitations are not required to include a Source Link-Layer Address, it is possible that a router sending a solicited unicast Router Advertisement does not have a corresponding link- layer address for its neighbor in its Neighbor Cache. In such situations, a router will first have to use Neighbor Discovery to determine the link-layer address of its neighbor (i.e, send out a multicast Neighbor Solicitation).
In the above, the first paragraph specifies NC-state creation, and the second specifies the additional address-resolution procedure that may be required in the case of a unicast RA. This second paragraph is based on the corresponding existing paragraph in section 7.2.4. (Note the difference between "[unicast] Router Solicitations" and "[unicast] Router Advertisements", though.) This is good for conformity.
We don't need to explicitly address the case of a solicitation without SLLAO in the first paragraph, because (a) no NC state is created in case of a multicast RA, (b) the second paragraph describes address resolution and state creation in case of a unicast RA in conformance with section 7.2.4, and (c) the decision of whether to send a multicast or a unicast RA is already attended to in the beginning of section 6.2.6.
An aside with respect to the second paragraph: You may also want to modify this paragraph through a s/Neighbor Discovery/address resolution/ in both section 7.2.4 and, as suggested, section 6.2.6.
- Christian
-- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
