Subject: Re: Fwd: Request To Advance: <draft-ietf-ipv6-2461bis-05.txt>

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 02 Dec 2005 22:36:04 +0900

(Sorry for the delayed response...I hope you still remember the
context)

>>>>> On Thu, 17 Nov 2005 13:06:20 -0500, 
>>>>> "Soliman, Hesham" <[email-masked]> said:

> Sending in hibernate mode.
>> I'm not sure if this one is correctly addressed:
>> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05107.html
>> (BTW: msg05107 is a comment on version 03, and I could not get a 04
>> version.  Has that version been issued, or is the version number
>> bumped?)
>> 
>> I've compared the difference of the state machine in Appendix C
>> between the 03 and 05 versions (attached below).  At least it doesn't
>> seem to cover the case where the neighbor cache entry does not exist.

> => This is not the issue you are pointing to above. This issue above was about receiving
> a message without SLLAO. Whether a Neighbor cache entry existed or not doesn't
> seem to affect this.

Please re-read the thread starting at:
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg04329.html

I thought this discussion was the trigger of the change to APPENDIX C
in version 05.  If not, please specify a pointer of the source of this
particular set of change (e.g., ML archive).

Assuming the above discussion is the source, the essential point at
that time was that the spec is unclear on the case where

  - an unsolicited ND message does not contain source/target LLAO
  - the receiving node does not have a neighbor cache entry for the
    source/target

(see one of my comments in the thread:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg04387.html
and the follow-ups to this message)

while the very original message of msg04329.html specifically
mentioned RS, it is essentially common to all 'unsolicited' messages
(RA, NS, and redirects in addition to RS).  If my memory correct, the
consensus at that time was that it would be good to clarify this point
in the general form.  So, the change to APPENDIX C should cover the
case of

  - an unsolicited ND message does not contain source/target LLAO
  - the receiving node does not have a neighbor cache entry for the
    source/target

for RA, RS, NS and redirect.

That's why I made this comment.  Again, if the source of the change to
05 is different than this discussion, please specify a pointer to the
real source.

>> It also does not cover the case where a Redirect message (w/o target
>> link-layer address option) caused the situation in question.  In

> => This might be something to discuss. Could you elaborate? Are you saying there
> is a Redirect message without the LLAO (that itself is not a problem AFAIK) ?

See above.

>> addition, I don't understand the following entry (added in 05):
>> 
>> +   INCOMPLETE      NA, Solicited=any,     Send ICMP error   
>> unchanged
>> +                   Override=any, No       (if router) or
>> +                   Link-layer address     log error (if host)
>> +
>> 
>> Which ICMP error is expected to be sent in this case?

> => Destination unreachable.

>    Why do we
>> separate the case for router and host?

> => Because a host can't send it to anyone. A router would send it to the off-link node
> trying to reach the router's neighbo (e.g. when this happens during address resolution). 

Hmm..., this sounds strange to me in a couple of points.

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

Secondly, if we separate the case for routers and for hosts here, why
don't we do the same thing in this case?

   INCOMPLETE      Retransmit timeout,    Discard entry          -
                   N or more              Send ICMP error
                   retransmissions.

(this one corresponds to the above 'retransmission timeout' case).

In my understanding, the general sense of RFC2461 about the ICMPv6
destination unreachable is that this 'error' is a conceptual one as
described in Section 2.1:

   ICMP destination unreachable indication
               - an error indication returned to the original sender
                 of a packet that cannot be delivered for the reasons
                 outlined in [ICMPv6].  If the error occurs on a node
                 other than the node originating the packet, an ICMP
                 error message is generated.  If the error occurs on
                 the originating node, an implementation is not
                 required to actually create and send an ICMP error
                 packet to the source, as long as the upper-layer
                 sender is notified through an appropriate mechanism
                 (e.g., return value from a procedure call).  Note,
                 however, that an implementation may find it
                 convenient in some cases to return errors to the
                 sender by taking the offending packet, generating an
                 ICMP error message, and then delivering it (locally)
                 through the generic error handling routines.

and the main text does not differentiate between the router case and
the host case.

If you really want to treat the two cases separately in APPENDIX C, I
don't necessarily object to that particular decision.  However, the
decision should at least be consistent throughout the appendix.

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

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