Thomas Narten writes: > its registration is accepted by one of these home agents. The mobile > node MUST, however, wait at least 1.5 times longer than (RetransTimer > * DupAddrDetectTransmits) before sending a Binding Update to the next > home agent. In trying each of the returned home agent addresses, the seems odd to base this off DupAddrDetectTransmits... And the values here are link-specific, so the MN needs to know what kind of link the HA is on in order to get these right. Seems like a tall order... > - If the mobile node is sending a Binding Update and it does not > have an existing binding at the home agent, it SHOULD use a value > for the initial retransmission timer that is at least 1.5 times > longer than (RetransTimer * DupAddrDetectTransmits). This value where are these defined (should cite ND here I think)? and 1.5 times this sounds odd. Should be based on RTT between HA and MN (not known) plus max DAD time. 1.5 times the latter would likely be much larger than the desired time. ---------------------- Charlie Perkins writes: From this issue, I could not think of much improvement to be made. A citation for RFC 2461 should be added to the relevant text, as suggested, but I don't see how to make the timing parameters better. > seems odd to base this off DupAddrDetectTransmits... And the values > here are link-specific, so the MN needs to know what kind of link the > HA is on in order to get these right. Seems like a tall order... It might take this long before the home agent would be able to accept the Binding Update because of DAD. Since the home agent is a router on the mobile node's home link, it is reasonable to assume that the mobile node has the needed timing information. Are there any suggestions about how to improve this? Otherwise, it might be the best we can do. > > - If the mobile node is sending a Binding Update and it does not > > have an existing binding at the home agent, it SHOULD use a value > > for the initial retransmission timer that is at least 1.5 times > > longer than (RetransTimer * DupAddrDetectTransmits). This value > > where are these defined (should cite ND here I think)? and 1.5 times > this sounds odd. Should be based on RTT between HA and MN (not known) > plus max DAD time. 1.5 times the latter would likely be much larger > than the desired time. Proposal: Citation should be added to the text. Typically, the DAD timeouts would be a lot larger than the RTT for signaling. The 1.5 factor should account for the RTT plus some extra time for other small uncertainties. ---------------------- Jari Arkko writes: Then to issue #181, about Thomas' complaint no basing switchover to another HA on DupAddrDetectTransmits. As Charlie noted, the main delay in getting an answer to a BU is DAD, and therefore both RetransTimer and DupAddrDetectTransmits certainly are factors in evaluating the required waiting time. The problem Thomas brought up was that the necessary values are the ones that appear on the home link, and the MN might be using some other values at the moment on its current link. For instance, a lossy visited link might have DupAddrDetectTransmits set to 3 instead of 1 at home, so which value would apply for our delay? It is true as Charlie noted that the mobile node could learn it from the home link. But I'm not sure all deployments of mobile IPv6 have links that you can actually go to, and we might even have virtual home links that can't be attached to. On the other hand the difficulties doing anything more that Charlie brough up are valid. At the time we need this information, we are trying to connect to our home agent, so the home agent can hardly tell us anything about them. We might use the information from our previous communications with the home agent as the alternative home agents are all on the same link (and therefore the information is the same). However, this still doesn't address the situation when we try to connect to the home agent for the first time. In conclusion I agree with Charlie that we can't do much more. However, I also agree with Thomas that the links in question are different. Perhaps the best we can do is to have a MIPv6 specific configuration variable for this timeout. This would have the following benefits: - Can be set if the home agent is for some reason running a "weird" link with a non-default DupAddrDetectTransmits - Can not be confused with the current link's properties - Leaves the possibility for us to later invent a way to communicate the value to the MN So the proposal is the introduction of a new configuration variable. The default is based on the defaults of Retranstimer and DupAddrDetectTransmits and the current formula. ---------------------- Jari Arkko writes: Here's the text proposal for the above. In Section 11.4.1, replace the text The mobile node MUST, however, wait at least 1.5 times longer than (RetransTimer * DupAddrDetectTransmits) before sending a Binding Update to the next home agent. => The mobile node MUST, however, wait at least FirstBindingBindAckTimeout seconds (see Section 13) before sending a Binding Update to the next home agent. And in Section 11.8, replace the text - If the mobile node is sending a Binding Update and it does not have an existing binding at the home agent, it SHOULD use a value for the initial retransmission timer that is at least 1.5 times longer than (RetransTimer * DupAddrDetectTransmits). This value is likely to be substantially longer than the otherwise specified value of INITIAL_BINDACK_TIMEOUT (see Section 12) that would be used by the mobile node. This longer retransmission interval will allow the home agent to complete the DAD procedure which is mandated in this case, as detailed in Section 11.7.1. => - If the mobile node is sending a Binding Update and it does not have an existing binding at the home agent, it SHOULD use FirstBindingBindAckTimeout as a value for the initial retransmission timer. This long retransmission interval will allow the home agent to complete the DAD procedure which is mandated in this case, as detailed in Section 11.7.1. And add a new Section 13, Protocol Configuration Variables: The configuration variables and their default values are as follows: HomeRtrAdvInterval 3,600 seconds MaxMobPfxAdvInterval 86,400 seconds MinMobPfxAdvInterval 600 seconds FirstBindingBindAckTimeout 1.5 seconds Home agents MUST allow the first three variables to be configured by system management, and mobile nodes MUST allow the last variable to be configured by system management. The default value for FirstBindingBindackTimeout has been calculated as 1.5 times the default value of RetransTimer [rfc2461] times the default value of DupAddrDetectTransmits [rfc2462]. ----------------------