Erik Nordmark repopens the DAd delay discussion from issue #154: > Except that we still are debating the delay before initiating DAD. > Following the RFCs to the letter, I think Vijay is technically > right: if we are not initializing or re-initializing then we don't > have to delay... just that noone has defined initialization in any > exact sense. Clearly, if you turn off and on your interface then > thats reinitialization. What if you WLAN card starts to hear another > base station, is that reinitialization? I think it is fair to say that the authors of RFC 2461 didn't think to deeply about the exact definitions in the light of wireless links, but I do think that we considered it ok to send an RS when the IP stack gets an indication that a the link has come up after having been down - something which might happen when there is a handover. And if that is ok, then even without an explicit indication from L2 it should be ok to do the RS. >From a definition perspective observe that "interface" in RFC 2460 is subtly different than "interface" in an implementation - at least the way I read things. A link is basically defined by the set of nodes that attach to it. Thus if the set of neigbors the node sees is different for the old AP and the new AP, then it is a different interface. Of course, in the implementation it is the same "wlan0" interface independently of the set of neighbors. So just a new AP doesn't mean that you are on a new link - you might have multiple APs on the same link but only hear some of them. > On the other hand, I also think Greg and others are right in the > sense that there is a possibility of simultaneous movements which > could cause a storm of DAD requests. I talked to some radio experts > about this and they didn't have any papers that would tell us how > bad the problem is. They did say, however, that ten years ago there > was a concern that fast trains etc would cause a similar problem > for cellular systems but that in practise this hasn't happened. And > yes, James, there's probably some safety features in lower layers > to deal with these things. WLANs have exponential back-off for > collisions, for instance, and I suspect many wireless techniques > have some inherently random delays before they can switch to > another base station. The RFC 2461 randomization concern was due to the power failure case when lots of nodes with identical software and handware might boot in lock step. I can see that similar things might happen during "bulk" handover in theory unless there is something in the process of detecting the movement at L2, doing the L2 handover, or detecting the movement at L3, that randomize things. I guess we don't have data on whether there are technologies where there is in practise no randomizations. Clearly (?) when movement detection is driven by a multicast RA, there can be a high risk of multiple nodes detecting the movement from the same RA. But it is too early to say whether this is problematic. Thus being conservative while allowing hosts to have a local mechanism for the L2 (driver) to indicate that the L2 has random delays in its handover timing would make sense to me. > There's also the question of how does the IP stack *know* that it > has re-initialized an interface? Remember that many current > drivers in Linux etc do not tell the IP stack that there's been a > switch to a new base station. So, the IP stack learns that > there's a new router and prefix, and it probably also sees that > the flow of packets from the previous router has stopped... > is this interface re-initialization or did someone turn off > the router and installed a new one? And the initialization delay > comes then at a time when we have received at least one RA and > sent perhaps many NUD-related messages. I think the synchronization risk comes from either an L2 handover that happens more or less at the same time for a set of nodes and an L2 "link up" notification to the IP stack, or no L2 notification but a multicast RA that has the same effect. In those cases it makes sense to ensure that there is some randomization somewhere before the node sends its first IP packet (could be a DAD probe and/or a RS). Of course, experimenting with L2s e.g. by putting N PDAs with WLAN interfaces in a box and moving them around will give an indication of to what extent the L2 handovers happen at the same time. > How about this (Section 11.5.2, paragraphs 5 & 6) for choice 3 above: > > RFC 2462 [ref] specifies that in normal processing for Duplicate > Address Detection, the node SHOULD delay sending the > initial Neighbor Solicitation message by a random delay between > 0 and MAX_RTR_SOLICITATION_DELAY. Since delaying > DAD can result in significant delays in configuring a new care > of address when the Mobile Node moves to a new link, the > Mobile Node preferably SHOULD NOT delay DAD when > configuring a new care of address. The Mobile Node SHOULD > delay according to the mechanisms specified in RFC 2462 > if the Mobile IP stack cannot distinguish between the normal > process of moving to a new link and reinitializing the interface, or > if the link layer does not include adequate local collision and > congestion control mechanisms. I don't see what the "distinguish" above is distinguishing between. Is it "moving to a new link" and "reinitializing the interface"? That doesn't make sense. It is the potential synchronizing events we care about (at least until we have more experimental data for real L2 behavior). Thus it makes more sense to me to say The Mobile Node SHOULD delay according to the mechanisms specified in RFC 2462 unless the implementation has a behavior that desynchronizes the steps that happen before the DAD in the case that multiple nodes experience handover at the same time. Such desynchronizing behaviors might be due to random delays in the L2 protocols or device drivers, or due to the movement detection mechanism that is used. -------------------- Jari Arkko: Your text sounds fine. -------------------- -------------------- --------------------