Subject: RE: Sending ICMP error upon receiving an NA without SLLAO in 2461bis

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 9 Jan 2006 22:22:03 -0500

> > 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.
 > 
 > It took me a while to figure out what you are proposing. To 
 > summarize:
 > in the case where where a node receives an NA without an 
 > SLLAO, but it
 > is expecting an SLLAO (so it can complete the Neighbor Cache Entry),
 > such a received NA is "an error". In the case where a regular data
 > packet is queued pending completion of the NCE, you'd like to be able
 > to send back an ICMP error indicating "dest unreachable". Right?

=> Yes. 

 > 
 > This seems like a fairly minor optimization and one that deals with a
 > a potential "implementation error" (since I understand this situation
 > would normally only arise of the sender of the NA 
 > incorrectly left off
 > the SLLAO).  If this is the case, IMO, it's not worth modifying the
 > spec to allow this. Indeed, I'd have to think a bit to 
 > convince myself
 > that it couldn't lead to potential cases where an ICMP error would be
 > (incorrectly) sent when simply ignoring the faulty NA is actually the
 > more correct response (i.e., if proxies are present and more than one
 > NA is generated).
 > 
 > Is this a situation that has come up in actual testing/usage?

=> Christian Vogt raised this issue so perhaps he (or someone else) 
can answer this question. Personally, I've never encountered this case.

Hesham

 > Thomas

===========================================================
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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Derek Smalls <[email-masked]>
Date: Mon, 9 Jan 2006 18:18:31 -0800 (PST)

According to RFC 2492 SLLAO option should not be used
in an ATM PVC environment, yet the NA may be
transmitted as a part of DAD which is still required.
Thus with this proposal we can have an ICMP error
generated in a scenario where no error condition has
occurred. 

--- Thomas Narten wrote:

> > 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 
> It took me a while to figure out what you are
> proposing. To summarize:
> in the case where where a node receives an NA
> without an SLLAO, but it
> spec to allow this. Indeed, I'd have to think a bit
> to convince myself
> Administrative Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6
>

__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 16 Jan 2006 13:57:11 -0500

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-masked] [mailto:[email-masked]]On 
 > 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. 
 > 
 > 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-masked] [mailto:[email-masked]]On 
 >  > 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-masked]
 >  >  > 
 >  >