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

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 3 Jan 2006 14:25:52 -0500

Sorry for the late response I was out of the office.

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

=> Not in the main text, which is why I suggested above that we can add it
to section 7.2.

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

=> I think you meant 7.2.5.

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

=> Understood. It would violate this part, but I wouldn't say that it doesn't
make sense to indicate that something is wrong to upper layers. I actually
think the text in 7.2.5 is too restrictive. It's useful to inform upper layers
of communication failures. 

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

=> Yes, it is a non-compliant behaviour. My point is that it's useful to inform whomever
is trying to communicate that something is wrong. ICMP is a good way of doing that.

  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.

=> I don't think that's a good way to handle it, but the current text inherited from 
2461 agrees with you. I don't think it breaks backward compatibility to mention this 
in the appendix as an optional behaviour (sending the ICMP error). Are you ok with
having this as an optional behaviour in the appendix? others?

Thoughts? 

Hesham

 > 
 > 					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: Thu, 05 Jan 2006 17:21:51 +0900

>>>>> On Tue, 3 Jan 2006 14:25:52 -0500, 
>>>>> "Soliman, Hesham" <[email-masked]> said:

> => Not in the main text, which is why I suggested above that we can add it

I see.  As I said in the previous message (see also below), we should
first make a consensus about whether this is to be added.  Then, if
the result is positive, we should explicitly add the corresponding
text to 7.2 (in general, the appendix should be a summary of the main
text, IMO).

(snip)

> having this as an optional behaviour in the appendix? others?

I don't have a strong opinion on either way (whether or not including
this feature).  As you said, it may help in some cases (e.g., an end
host may be able to give up connecting to a non-compliant remote host
faster).  But since this may require a change to the existing
implementation, I'd like to see an explicit consensus about the
additional behavior (i.e., 'no objection' would not suffice).

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