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

"Soliman, Hesham" <H.Soliman@flarion.com> Tue, 10 January 2006 03:22 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwA5e-00014i-Cc; Mon, 09 Jan 2006 22:22:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwA5Z-000146-Mw for ipv6@megatron.ietf.org; Mon, 09 Jan 2006 22:22:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26549 for <ipv6@ietf.org>; Mon, 9 Jan 2006 22:21:07 -0500 (EST)
Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwAC9-0001BE-LF for ipv6@ietf.org; Mon, 09 Jan 2006 22:29:16 -0500
Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Jan 2006 22:22:03 -0500
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 09 Jan 2006 22:22:03 -0500
Message-ID: <A11736FE943F1A408F8BBB1B9F5FE8AD03274B4B@ftmailserver.flariontech.com>
Thread-Topic: Sending ICMP error upon receiving an NA without SLLAO in 2461bis
Thread-Index: AcYVaASBABMO6yo5QJekaycqgOgvTAALMCIA
From: "Soliman, Hesham" <H.Soliman@flarion.com>
To: Thomas Narten <narten@us.ibm.com>
X-OriginalArrivalTime: 10 Jan 2006 03:22:03.0421 (UTC) FILETIME=[06C03CD0:01C61595]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 WG <ipv6@ietf.org>
Subject: RE: Sending ICMP error upon receiving an NA without SLLAO in 2461bis
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org


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