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

Reply via email to