(Sorry for the delayed response...I hope you still remember the context) >>>>> On Thu, 17 Nov 2005 13:06:20 -0500, >>>>> "Soliman, Hesham" <[EMAIL PROTECTED]> said:
> Sending in hibernate mode. >> I'm not sure if this one is correctly addressed: >> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05107.html >> (BTW: msg05107 is a comment on version 03, and I could not get a 04 >> version. Has that version been issued, or is the version number >> bumped?) >> >> 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). 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 (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. 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. >> It also does not cover the case where a Redirect message (w/o target >> link-layer address option) caused the situation in question. In > => This might be something to discuss. Could you elaborate? Are you saying > there > is a Redirect message without the LLAO (that itself is not a problem AFAIK) ? See above. >> addition, I don't understand the following entry (added in 05): >> >> + INCOMPLETE NA, Solicited=any, Send ICMP error >> unchanged >> + Override=any, No (if router) or >> + Link-layer address log error (if host) >> + >> >> Which ICMP error is expected to be sent in this case? > => Destination unreachable. > Why do we >> separate the case for router and host? > => 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. 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 --------------------------------------------------------------------
