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

=> Yes. Except I didn't explicitly include the case where no entry exists at 
all.

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

=> Exactly.

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

=> Ok. This can be added. 


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

=> This can be added to the text at the beginning of 7.2., which discusses this 
issues. 

Hesham

 > 
 > Thanks,
 > 
 >                                      JINMEI, Tatuya
 >                                      Communication Platform Lab.
 >                                      Corporate R&D Center, 
 > Toshiba Corp.
 >                                      [EMAIL PROTECTED]
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to