Folks, There were only two new emails on this subject. Given the overwhelming lack of interest in this issue and that both responders felt that it was ok to keep things as is (without adding ICMP errors), this issue is now closed and the suggestion in my email below is rejected. Therefore, the draft will be updated and the reference to ICMP errors in the state machine will be removed.
Thanks, Hesham > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Soliman, Hesham > Sent: Friday, January 06, 2006 10:31 AM > To: IPv6 WG > Subject: Sending ICMP error upon receiving an NA without > SLLAO in 2461bis > > > Hi all, > > This is a mini concensus call on the discussion I had with > Jinmei below. > > The basic issue left is whether we should allow a node to > send an ICMP error > due to the reception of an NA without the SLLAO. The reason > for sending the > ICMP error is to inform upper layers that the communication > has failed. > > The current spec says that such message SHOULD be silently discarded > (see section 7.2 and section 7.2.5 in > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-05.txt). > > However, it would be useful to inform upper layers of such > failures. ICMP is the > natural choice for transmitting the error message. > > Implementing this feature would be optional and should not > have problems with backward > compatibility. I don't know if this would be considered a > substantive change to the current > spec. IMHO it can easily pass as a clarification. > > Please express your opinion on whether we could add this > clarification to the spec or > keep it as is. > > Hesham > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Soliman, Hesham > > Sent: Thursday, January 05, 2006 6:09 AM > > To: JINMEI Tatuya / ???? > > Cc: IPv6 WG > > Subject: RE: Fwd: Request To Advance: > > <draft-ietf-ipv6-2461bis-05.txt> > > > > > > > > > > > > => Not in the main text, which is why I suggested above > > > that we can add it > > > > to section 7.2. > > > > > > I see. As I said in the previous message (see also > > below), we should > > > first make a consensus about whether this is to be added. > > Then, if > > > the result is positive, we should explicitly add the > corresponding > > > text to 7.2 (in general, the appendix should be a summary > > of the main > > > text, IMO). > > > > => Agreed. > > > > > > > > (snip) > > > > > > >> I > > > >> believe it makes more sense to discard the bogus packets > > > silently as > > > >> described in the body of the draft (Section 7.2.4) rather > > > than taking > > > >> a specific action like sending an ICMPv6 error message. > > > > > > > => I don't think that's a good way to handle it, but the > > > current text inherited from > > > > 2461 agrees with you. I don't think it breaks backward > > > compatibility to mention this > > > > in the appendix as an optional behaviour (sending the ICMP > > > error). Are you ok with > > > > having this as an optional behaviour in the appendix? others? > > > > > > I don't have a strong opinion on either way (whether or > > not including > > > this feature). As you said, it may help in some cases > > (e.g., an end > > > host may be able to give up connecting to a non-compliant > > remote host > > > faster). But since this may require a change to the existing > > > implementation, I'd like to see an explicit consensus about the > > > additional behavior (i.e., 'no objection' would not suffice). > > > > => That's fine. I'll send a separate email to ask if people > > agree with adding > > the ICMP part as an optional feature. > > > > Hesham > > > > > > > > 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 > > ipv6@ietf.org > > Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
