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

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 2 Dec 2005 10:42:02 -0500

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

=> No probs, I remember it clearly.

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

=> Sure, this is what triggered the issue.

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

=> Correct.

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

=> Agreed. In addition to Appendix C, we also agreed on the list to add a paragraph to
section 7.2 (text from Greg Daley) to clarify the general handling. This was also added.

   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.

=> Your comment seemed to indicate that the non-existence of the cache entry
was a separate issue, but I don't think it is. The reception of an ND message without
the SLLAO is only a problem if no entry existed. In other words, we wouldn't have
registered this issue from the beginning if it were related to cases where the receiving
node already had an entry. 
I might have misunderstood your comment but you also seemed to indicate that there 
was a difference between the following two cases:
 - Receiving an NS without SLLAO, which was triggered by the reception of a REDIRECT (at the sending node)
- Receiving an NS without SLLAO for other reasons. 

As far as the spec is concerned both cases are the same, do you disagree?

If you only mean: "Add the case for REDIRECT received without SLLAO" that's ok with me. I can add that
but I don't see any other distinction. 

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

=> Good points. I agree with that. So to keep it consistent, I'll remove this distinction
between host and router. 

Hesham

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 05 Dec 2005 16:54:53 +0900

>>>>> On Fri, 2 Dec 2005 10:42:02 -0500, 
>>>>> "Soliman, Hesham" <[email-masked]> said:

> handling. This was also added.

OK so far.

> node already had an entry. 

Yes, that's correct.  Perhaps I was not clear in my previous message,
but I actually meant:

  the change to APPENDIX C should cover the case of
    an unsolicited ND message does not contain source/target LLAO,
    AND the receiving node does not have a neighbor cache entry for
    the source/target
  (there are two conditions for a single 'case')

Is this now clear and does that match your (our) understanding?

Then, let's revisit the change to APPENDIX C in 2461bis-05.  My point
of the first message of this thread is that the change does not cover
cases where a neighbor cache entry does not exist when the unsolicited
message arrives (see the diff I attached to a previous message
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05861.html).

More specifically, I'd like to see new entries like:

   State           Event                   Action             New state

   -               RS, no link-layer       -                  -
                   address

...hmm..., perhaps your intent was that such cases should be covered
new entries like this one:

   INCOMPLETE      NS, RS No link-layer    -                   unchanged
                   address

If so, I see your position, but I don't think this is 100% correct,
because the 'non-existent' entry cannot be in any state (INCOMPLETE in
this case).  I believe using '-' for the 'State' field in these cases
should make more sense.

> If you only mean: "Add the case for REDIRECT received without SLLAO" that's ok with me.

Yes, that's my point.

Okay, but please clarify my first question, too:

>> First of all, which part of the main text specifies this behavior?  As

Thanks,

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