> > (Sorry for the delayed response...I hope you still remember the > context)
=> No probs, I remember it clearly. > >> I've compared the difference of the state machine in Appendix C > >> between the 03 and 05 versions (attached below). At > least it doesn't > >> seem to cover the case where the neighbor cache entry > does not exist. > > > => This is not the issue you are pointing to above. This > issue above was about receiving > > a message without SLLAO. Whether a Neighbor cache entry > existed or not doesn't > > seem to affect this. > > Please re-read the thread starting at: > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04329.html > > I thought this discussion was the trigger of the change to APPENDIX C > in version 05. If not, please specify a pointer of the > source of this > particular set of change (e.g., ML archive). => Sure, this is what triggered the issue. > > Assuming the above discussion is the source, the essential point at > that time was 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 => Correct. > > (see one of my comments in the thread: > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04387.html > and the follow-ups to this message) > > while the very original message of msg04329.html specifically > mentioned RS, it is essentially common to all 'unsolicited' messages > (RA, NS, and redirects in addition to RS). If my memory correct, the > consensus at that time was that it would be good to clarify > this point > in the general form. => 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. 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. I might have misunderstood your comment but you also seemed to indicate that there was a difference between the following two cases: - Receiving an NS without SLLAO, which was triggered by the reception of a REDIRECT (at the sending node) - Receiving an NS without SLLAO for other reasons. As far as the spec is concerned both cases are the same, do you disagree? If you only mean: "Add the case for REDIRECT received without SLLAO" that's ok with me. I can add that but I don't see any other distinction. > > > => Because a host can't send it to anyone. A router would > send it to the off-link node > > trying to reach the router's neighbo (e.g. when this > happens during address resolution). > > Hmm..., this sounds strange to me in a couple of points. > > 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). > > Secondly, if we separate the case for routers and for hosts here, why > don't we do the same thing in this case? > > INCOMPLETE Retransmit timeout, Discard entry - > N or more Send ICMP error > retransmissions. > > (this one corresponds to the above 'retransmission timeout' case). > > In my understanding, the general sense of RFC2461 about the ICMPv6 > destination unreachable is that this 'error' is a conceptual one as > described in Section 2.1: > > ICMP destination unreachable indication > - an error indication returned to the original sender > of a packet that cannot be delivered for the reasons > outlined in [ICMPv6]. If the error occurs on a node > other than the node originating the packet, an ICMP > error message is generated. If the error occurs on > the originating node, an implementation is not > required to actually create and send an ICMP error > packet to the source, as long as the upper-layer > sender is notified through an appropriate mechanism > (e.g., return value from a procedure call). Note, > however, that an implementation may find it > convenient in some cases to return errors to the > sender by taking the offending packet, generating an > ICMP error message, and then delivering it (locally) > through the generic error handling routines. > > and the main text does not differentiate between the router case and > the host case. > > 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. Hesham =========================================================== 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 --------------------------------------------------------------------
