>>>>> 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.
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
--------------------------------------------------------------------
