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

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 7 Dec 2005 13:18:28 -0500

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

=> Yes. Except I didn't explicitly include the case where no entry exists at all.

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

=> Exactly.

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

=> Ok. This can be added. 

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

Hesham

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

===========================================================
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: Tue, 13 Dec 2005 17:04:50 +0900

>>>>> On Wed, 7 Dec 2005 13:18:28 -0500, 
>>>>> "Soliman, Hesham" <[email-masked]> said:

> => 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-masked]