Vlad, Thanks for the explanation. This is precisely the explanation Wes Beebee gave me in person at Cisco but we still decided to ping IETF folks anyway to confirm any other reasons. OK, now that we all are convinced that a convoluted scenario can cause this situation of target address in NA to occur, notice that Vlad also agrees with myself and Wes that such an NA should not be silently discarded. I agree with Vlad that disabling the network is too severe for this case.
I think Tatuya first leaned towards the silent discard behavior because he wanted text in 2462bis to match text in first para of section 7.2.5 of 2461bis. However, I see that as matching apples with oranges. The NA in section 7.2.5 of 2461bis is silently discarded if the target address of NA does not exist in ND cache of the receiving interface. The NA in section 5.4.4 of 2462bis is being dropped because the target address in NA matches an address on the receiving interface - we have already asked, why is such a match not deemed as a duplicate and hence an error mgmt message raised? Thanks. Hemant -----Original Message----- From: Vlad Yasevich [mailto:[EMAIL PROTECTED] Sent: Thursday, July 05, 2007 4:47 PM To: Hemant Singh (shemant) Cc: Suresh Krishnan; [email protected]; JINMEI Tatuya / ???? Subject: Re: Revisit: one remaining corner case in DAD Hemant Singh (shemant) wrote: > Suresh, > > Yes, sorry, I had a typo wrt 2461 vs 2462. Thanks so much for > providing the para. Now I have a separate question to you folks. > > What IPv6 network has an interface receiving an NA where the target > address in the NA matched an assigned address on the receiving > interface given the fact the address that matched is not tentative? This is a convoluted scenario but it can happen when a previously routed network flattens out and merges into a swiched/bridged fabric. We've had this happen in our lab when testing different DAD features. >From my personal perspective, some kind of warning should be signaled. The NAs can be safely discarded though (just not silently). At this point in time completely disabling the network is too severe. -vlad -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
