>>>>> On Fri, 2 Dec 2005 10:42:02 -0500,
>>>>> "Soliman, Hesham" <[EMAIL PROTECTED]> said:
> => Agreed. In addition to Appendix C, we also agreed on the list to add a
> paragraph to
> section 7.2 (text from Greg Daley) to clarify the general
> handling. This was also added.
OK so far.
> So, the change to APPENDIX C should cover the
>> case of
>>
>> - an unsolicited ND message does not contain source/target LLAO
>> - the receiving node does not have a neighbor cache entry for the
>> source/target
>>
>> for RA, RS, NS and redirect.
>>
>> That's why I made this comment. Again, if the source of the
>> change to
>> 05 is different than this discussion, please specify a pointer to the
>> real source.
> => Your comment seemed to indicate that the non-existence of the cache entry
> was a separate issue, but I don't think it is. The reception of an ND message
> without
> the SLLAO is only a problem if no entry existed. In other words, we wouldn't
> have
> registered this issue from the beginning if it were related to cases where
> the receiving
> node already had an entry.
Yes, that's correct. Perhaps I was not clear in my previous message,
but I actually meant:
the change to APPENDIX C should cover the case of
an unsolicited ND message does not contain source/target LLAO,
AND the receiving node does not have a neighbor cache entry for
the source/target
(there are two conditions for a single 'case')
Is this now clear and does that match your (our) understanding?
Then, let's revisit the change to APPENDIX C in 2461bis-05. My point
of the first message of this thread is that the change does not cover
cases where a neighbor cache entry does not exist when the unsolicited
message arrives (see the diff I attached to a previous message
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05861.html).
More specifically, I'd like to see new entries like:
State Event Action New state
- RS, no link-layer - -
address
...hmm..., perhaps your intent was that such cases should be covered
new entries like this one:
INCOMPLETE NS, RS No link-layer - unchanged
address
If so, I see your position, but I don't think this is 100% correct,
because the 'non-existent' entry cannot be in any state (INCOMPLETE in
this case). I believe using '-' for the 'State' field in these cases
should make more sense.
> If you only mean: "Add the case for REDIRECT received without SLLAO" that's
> ok with me.
Yes, that's my point.
>> If you really want to treat the two cases separately in APPENDIX C, I
>> don't necessarily object to that particular decision. However, the
>> decision should at least be consistent throughout the appendix.
> => Good points. I agree with that. So to keep it consistent, I'll remove this
> distinction
> between host and router.
Okay, but please clarify my first question, too:
>> First of all, which part of the main text specifies this behavior? As
>> far as I can see, the only text that explicitly mentions ICMPv6
>> destination unreachable error to be sent is in Section 7.2.2, where
>> the error is sent upon retransmit timeout for NS messages (which is
>> clearly a different scenario than this one).
Thanks,
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
--------------------------------------------------------------------
