On 2004-08-05, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: > >>>>> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said: > > > > Just to be sure, which possible bad effects do you mean? > > Umm...I think I've explained this 100 times...
You've claimed it several times. > basically, any operation > during the optimistic state which would not allow for pure-RFC2462 > hosts can cause bad effects. And I basically mean all such effects in > this kind of context. Okay, but specifically ... > In this particular case, sending an unsolicited > NAs can create an unnecessary neighbor cache on other nodes in the > link. If one of such nodes start to send packets to the optimistic > address and the address is actually a duplicate (i.e., another node > has been using the address), then the packets won't be delivered to > the legitimate node for some period. Okay, if that's the one you're worried about: Let's imagine that node A is preparing to start talking to node B when node C arrives and optimistically squats on the address of B. If C's NA(O=0) arrives while A has an NC entry in a receptive state, an incorrect entry will indeed be created. However, B's NA(O=1) will soon override this incorrect entry, and if it arrives _before_ C's NA(O=0) the incorrect entry will not be created. > I guess the reason why we have needed to this type of conversation so > many times is fundamental difference on the basic standpoint. I agree that there is a chance of collision, and I see where you're coming from. I think the probability of collision is negligible, but since the unsol NAs are only useful in predictive handovers case, I'm happy to drop them. Erik suggested replacement text elsewhere in this thread: I'm happy with that. It doesn't encourage sending the NAs in any way, but it does warn that if someone does decide to send them they MUST have O=0. That's fine by me -- the bit I really wanted to keep was the MUST have O=0 warning! Are you happy with Erik's text? -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
