On 2004-07-27, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: > > Before going to the specific ones, I'd like to present the basic logic > I'd (personally) envision in this discussion. (It's my personal > opinion. I know opinions may vary on this.) > > The most important thing is to not cause disruption for non-optimistic > nodes. If there is any possibility of disruption, I basically want to > confirm consensus if it is acceptable for those who implemented > (and/or are operating) the "standard" behavior and is not particularly > interested in implementing/operating the optimistic behavior. The > logic like "this only matters in corner cases so it should be > acceptable" from the side that wants to introduce the optimistic > behavior is not justified, IMO.
Okay, we differ here: I think the aims of Optimistic DAD are to configure the address without delay; to remain interoperable with unmodified hosts and routers; and to mitigate disruption in the case of a collision with any node. Bear in mind that the RFC2462 DAD process is not 'perfect' either, as packet loss can cause collisions to go undetected. I don't believe Optimistic DAD significantly increases the risk of disruption in the case of a collision, and because it allows DupAddrDetectTransmits to be increased without significant penalty, it actually _reduces_ the probability of an undetected collision. > Next, if a proposed change for the optimistic behavior is > controversial, then the default policy should be conservative, as long > as it is crucial to make the optimistic behavior work. Sure, I'm happy to strip out the unsolicited NAs and leave that sort of thing to another draft or WG to consider, if that's the consensus of the group. > > However, when the collision is detected, the collidee will respond > > with an NA O=1 to all nodes, which will override the NC entries > > and reset them to STALE. > > This is not really correct because duplicate can also be detected when > two (colliding) nodes simultaneously perform DAD. In this case, there > will be no NA with O=1. I honestly think that the probability of simultaneous collisions is so miniscule as to be not worth considering. As per [SOTO], "a mobile phone user should be more worried about being killed by lightning than to have an interface identifier repeated." And that's the maths considering collisions with a network with several thousand nodes, not for simultaneous collisions. > I understand the motivation, but it is not convincing enough based on > my "basic logic". Also, if the motivation to optimize roaming between > a mobile node and a router that has the ability to support the MN, do > we really need to realize that by overloading the existing protocol > mechanism, with taking a risk to cause disruption? Can't we do that > with, e.g., a new ND option that only works for nodes that understand > it? ... and this gets back to my first point: one aim of Optimistic DAD is to provide an _interoperable_ solution, the kind of thing you can build into mobile nodes and use even if the router of the access network doesn't understand it. Our time in the WG is limited, but I'll try and work out some way of gauging the WGs feelings about these issues. -----Nick [SOTO] draft-soto-mobileip-random-iids-00, now expired: see http://www.watersprings.org/pub/id/draft-soto-mobileip-random-iids-00.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
