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