Greg O'Shea writes: "...reply to the mobile node's subsequent Binding Update with a Binding Acknowledgement containing a Status of 134 (Duplicate Address Detection failed). In this case, the mobile node MUST NOT attempt to re-use the same home address" That's probably not what you want to do: whatever it was that was contesting the HoA could go away but we just abandoned the HoA and its associated state (IPSec) forever. It would be better to say not to retry the HoA for a configurable amount of time. ------------ Jari Arkko responds to Greg O'Shea: Yes. We could say "... MUST NOT attempt to re-use the same home address until the mobile node is reconfigured or a configurable amount of time elapses." But would this violate what RFC 2462 requires from DAD collisions? ------------ Greg Daley responds to Jari Arkko: I think that the HA won't actually harm any other node by attempting DAD and failing, but RFC-2462 does instruct that the interface is disabled on collision (don't retry). It is reasonable to have a retry timer, but it may have to be an arbitrary one defined in MIPv6. The Valid(&Preferred) Lifetime in the Prefix Information Option indicates how long a DAD'ed address is valid for on a fixed network (probably too long to use as a timer). Times where a CoA is in use could be a lot shorter if the holder of the address is another MN visiting the home network. So the main thing to accomplish with a timer is not to overload the HA or the network with DAD NS's. Nick Moore's optimistic-DAD draft suggests starting at RETRANS_TIMER, with exponential backoff on re-DAD attempts. How does this sound? ------------ Jari Arkko responds to Greg Daley: Sounds good to me even if the start time is a bit small. Anyway, the high-level issue is that we've gotten feedback earlier from the ADs when we tried to specify a not-so-drastic collision action for care-of addresses. That may have been a different case because we were changing the behaviour of ND directly. Here we are not doing that as we are operating through BUs... but still, is it going to be acceptable? I have Cced Erik and Thomas to get an opinion... I think the alternatives are: 1. Leave the spec as is, but when the optimistic DAD work progresses that can also define a new rule for home address collision retries. 2. As above, but change the rule in the spec so that reconfiguration or admin action allows the address to be used again. 3. Change the rule in the spec to a softer one, which says that an exponential back-off starting from, say, 10xRETRANS_TIMER should be applied for new registration attempts. I'm OK with either 2 or 3, with a preference on 3 if this would be acceptable to Erik and Thomas. ------------ Erik Nordmark responds to Jari Arkko: I'm missing context on what problem you are trying to solve. Quoting randomly... > > I think that the HA won't actually harm any other node > > by attempting DAD and failing, but RFC-2462 does instruct > > that the interface is disabled on collision (don't retry). Clearly the HA wouldn't disable its interface from a DAD failure for one of the MN's addresses. RFC 2462 is written in the context of a node doing a DAD for its own addresses which is quite different than the proxy case the HA is performing. > I think the alternatives are: > > 1. Leave the spec as is, but when the optimistic DAD work progresses > that can also define a new rule for home address collision > retries. > > 2. As above, but change the rule in the spec so that reconfiguration > or admin action allows the address to be used again. > > 3. Change the rule in the spec to a softer one, which says > that an exponential back-off starting from, say, 10xRETRANS_TIMER > should be applied for new registration attempts. Is this for HoA collisions detected by the HA? (The earlier discussion was about CoA collisions detected by the MN, which is different.) A duplicate HoA seems like a new problem to worry about. I think leaving the specification alone and looking at optimistic DAD ideas and also at the issues of what you bind the security to when the HoA is changing (whether due to DAD, renumbering the home link, temporary HoAs etc) makes the most sense. ------------ Jari Arkko responds to Erik Nordmark: > I'm missing context on what problem you are trying to solve. See http://www.piuha.net/~jarkko/publications/mipv6/issues/issue252.txt Basically, Greg O'Shea asks what happens if the mobile node gets a response from the home agent that its home address has been detected as a duplicate. > I think that the HA won't actually harm any other node > by attempting DAD and failing, but RFC-2462 does instruct > that the interface is disabled on collision (don't retry). > > Clearly the HA wouldn't disable its interface from a DAD failure > for one of the MN's addresses. Agreed ;-) > RFC 2462 is written in the context of a node doing a DAD for its own > addresses which is quite different than the proxy case the HA is performing. > > I think the alternatives are: > > 1. Leave the spec as is, but when the optimistic DAD work progresses > that can also define a new rule for home address collision > retries. > > 2. As above, but change the rule in the spec so that reconfiguration > or admin action allows the address to be used again. > > 3. Change the rule in the spec to a softer one, which says > that an exponential back-off starting from, say, 10xRETRANS_TIMER > should be applied for new registration attempts. > > > Is this for HoA collisions detected by the HA? Yes. > (The earlier discussion was about CoA collisions detected by the MN, which > is different.) Yes. > A duplicate HoA seems like a new problem to worry about. I think leaving the specification alone and looking at optimistic > DAD ideas and also at the issues of what you bind the security to when the > HoA is changing (whether due to DAD, renumbering the home link, > temporary HoAs etc) makes the most sense. OK! ------------ ------------ ------------