>>>>> On Wed, 7 Dec 2005 13:18:28 -0500,
>>>>> "Soliman, Hesham" <[EMAIL PROTECTED]> said:
>> > => Good points. I agree with that. So to keep it
>> consistent, I'll remove this distinction
>> > between host and router.
>>
>> Okay, but please clarify my first question, too:
>>
>> >> First of all, which part of the main text specifies this
>> behavior? As
>> >> far as I can see, the only text that explicitly mentions ICMPv6
>> >> destination unreachable error to be sent is in Section
>> 7.2.2, where
>> >> the error is sent upon retransmit timeout for NS messages
>> (which is
>> >> clearly a different scenario than this one).
> => This can be added to the text at the beginning of 7.2., which discusses
> this issues.
Hmm, so the behavior corresponding to the following entry (shown again
just to be accurate) is not currently described in the draft:
INCOMPLETE NA, Solicited=any, Send ICMP error unchanged
Override=any, No (if router) or
Link-layer address log error (if host)
then...we should discuss whether this behavior makes sense in the
first place. Perhaps you added this entry based on a previous
discussion, but I don't remember such consensus. So it would be great
if you can provide a pointer to the discussion.
In any case, I personally don't think this behavior makes sense. It
at least violates a SHOULD requirement of Section 7.2.4 of
draft-ietf-ipv6-2461bis-05.txt:
If the target's Neighbor Cache entry is in the INCOMPLETE state when
the advertisement is received, one of two things happens. If the
link layer has addresses and no Target Link-Layer address option is
included, the receiving node SHOULD silently discard the received
^^^^^^^^^^^^^^^^^^^^^^^
advertisement. [...]
Since the state is INCOMPLETE, this node should be doing link-layer
address resolution by sending multicast NSs. In this case, the
responder MUST include the target link-layer address option per
Section 7.2.4:
If the
solicitation's IP Destination Address is a multicast address, the
Target Link-Layer option MUST be included in the advertisement.
So, the event of receiving an NS with no link-layer address in this
state indicates the responder shows a non-compliant behavior. 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.
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
--------------------------------------------------------------------
