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

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 6 Jan 2006 10:30:37 -0500

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

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

---

From: Thomas Narten <[email-masked]>
Date: Mon, 09 Jan 2006 16:59:46 -0500

> ICMP error is to inform upper layers that the communication has

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?

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?

Thomas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 10 Jan 2006 17:08:35 +0900

>>>>> On Mon, 09 Jan 2006 16:59:46 -0500, 
>>>>> Thomas Narten <[email-masked]> said:

> spec to allow this.

I agree.  This is actually the same as my impression when I first
noticed the change:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg06040.html

> Indeed, I'd have to think a bit to convince myself

Good point.  I also agree with you on this.

> Is this a situation that has come up in actual testing/usage?

I guess Hesham meant an old discussion (about a year ago) regarding
an optimistic DAD node.  But as far as I can see, even an optimistic
node does not send the NA in question here.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]