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

>> 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?

> 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.

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
> 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).

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to