Ville Nuorvala writes: I just noticed some very strange lines of text in Section 11.4.2 of draft 20: The mobile node SHOULD send a Solicitation to the home agent when its home address will become invalid within MaxRtrAdvInterval seconds, where this value is acquired in a previous Mobile Prefix Advertisement from the home agent. If no such value is known, the value MAX_PFX_ADV_DELAY seconds is used instead (see Section 12). First of all, the MN doesn't get MaxRtrAdvInterval, since MPA:s don't have the Advertisement Interval Option. Should we allow it in MPA:s? Second, MAX_PFX_ADV_DELAY isn't specified anywhere in the specification. Third, if Adverisement Interval Options are allowed, isn't 0.07 seconds (minimum allowed value for MaxRtrAdvInterval, Section 7.6) a bit small for this purpose? You can't afford much latency in the network if you need roundtrip times of less than 0.07 seconds. How is the MN also supposed to cope with situations where either the MPS or the MPA gets lost on the way? It will at least not be able to resend the MPS before the prefix has expired, since INITIAL_SOLICIT_TIMER is defined as 3 seconds (Section 12). ------------------------- Sourajeet.Mohanty@lntinfotech.com writes: The following text in draft 20 section "11.4.2 Sending Mobile Prefix Solicitations" is old. "The mobile node SHOULD send a Solicitation to the home agent when its home address will become invalid within MaxRtrAdvInterval seconds, where this value is acquired in a previous Mobile Prefix Advertisement from the home agent. If no such value is known, the value MAX_PFX_ADV_DELAY seconds is used instead (see Section 12)." There is no MAX_PFX_ADV_DELAY in section 12. And there is no way to know MaxRtrAdvInterval in the MPA. Also it should be MaxMobPfxAdvInterval instead of MaxRtrAdvInterval. ------------------------- Jari Arkko writes: Yes. Ville Nuorvala reported a similar issue earlier, see http://www.piuha.net/~jarkko/publications/mipv6/issues/issue245.txt Basically, there's been an editing error for the interval constants somewhere around issue #120... I've been trying to look back in my issue and e-mail files to see exactly what was agreed. ------------------------- Jari Arkko continues: Here's an analysis of the current situation and problems: (1) The mobile node does not get MaxRtrAdvInterval, or any other indication of what the MPA interval from the home agent might be. However, current text in 11.4.2 requires this information to follow the instructions which dictate the exact timing for solicited prefix discovery. (2) Again in the timing for solicited prefix discovery, MAX_PFX_ADV_DELAY is not defined. Currently it is used as the default value if the information in (1) is not available. (3) Still inthe same timing instructions, MaxRtrAdvInterval maybe the wrong variable as the minimum lifetime of the home address before an MPS must be sent. This variable is for the on-link advertisements, not MPAs. MaxMobPfxAdvInterval should have been used instead. (4) The scheduling of advertisements is based on HomeRtrAdvInterval, default 3600, while the randomization process is based on {Min,Max}MobPfxAdvInterval, default 86400. That is, we schedule advertisements every hour but the random variation in the actual send times is in the order of a day. (5) The 10.6.2 instructions which tell us how to use HomeRtrAdvInterval are unclear. It does not clearly say whether the randomization process is a part of this kind of scheduled transmission. (6) HomeRtrAdvInterval reference from 10.6.2 points to the wrong section, should be 13 not 12. Looking back at issue #120, we agreed to replace MAX_PFX_ADV_DELAY with MaxMobPfxAdvInterval. But the former variable still appears in 11.4.2. In issue #120, we apparently also agreed to rename HomeRtrAdvInterval to MaxMobPfxAdvInterval, but both contansts still exist. In issue #207, we made the decision to remove the AI option along with the SLLA option from MPAs. The main reason for removing them was that there was no text that would describe how to use the results of the AI option by the MN. As can be seen from the above discussion we may actually need some functionality like this, but the problem with the old text was that it talked about the transmission of the MaxRtrAdvInterval through it, not the parameters related to prefix discovery. Here's one possible approach to fix the current mess with the advertisement intervals: 1. Relax the rules for mobile nodes regarding the exact timing of sending MPS messages. There does not appear to be a reason to require more exact timing than doing it well in advance of the prefix being deprecated. If we do this, we will also avoid the need to send any unsolicited MPA timing parameters from the home agent to the mobile node. And we will avoid the MaxRtrAdvInterval / MaxMobPfxAdvInterval problem, as well as get rid of MAX_PFX_ADV_DELAY. In any case, the home agent is in the best position to select the right frequency based on expected changes in prefixes. Also, the lifetimes of prefixes sent through MPA will force the mobile nodes to update their information at some point. 2. Remove HomeRtrAdvInterval and just use MaxMobPfxAdvInterval instead. 3. Make it clear that all unsolicited MPAs are under the same timing randomization rules. Solicited MPAs are sent immediately. Here's the text proposal related to the above solution: Changed contents in Section 10.6.2: 10.6.2 Scheduling Prefix Deliveries ... The home agent uses the following algorithm to determine when to send prefix information to the mobile node. o If a mobile node sends a solicitation, answer right away. o If the mobile node has not received the prefix information within the last MaxMobPfxAdvInterval (see Section 13) seconds, then ensure that a transmission is scheduled. The actual transmission time is randomized as described below. o If a prefix in the aggregate list that matches the mobile node's home registration is added, or if its information changes in any way that does not cause the mobile node's address to go deprecated, ensure that a transmission is scheduled. The actual transmission time is randomized as described below. o If a home registration expires, cancel any scheduled advertisements to the mobile node. ... New contents of Section 11.4.2: 11.4.2 Sending Mobile Prefix Solicitations When a mobile node has a home address that is about to become invalid, it SHOULD send a Mobile Prefix Solicitation to its home agent in an attempt to acquire fresh routing prefix information. The new information also enables the mobile node to participate in renumbering operations affecting the home network, as described in Section 10.6. The mobile node MUST use the Home Address destination option to carry its home address. The mobile node MUST support and SHOULD use IPsec to protect the solicitation. The mobile node MUST set the Identifier field in the ICMP header to a random value. As described in Section 11.7.2, Binding Updates sent by the mobile node to other nodes MUST use a lifetime no greater than the remaining ... New contents of Section 13: 13. Protocol Configuration Variables MaxMobPfxAdvInterval Default: 86,400 seconds MinDelayBetweenRAs Default: 3 seconds, Min: 0.03 seconds MinMobPfxAdvInterval Default: 600 seconds InitialBindackTimeoutFirstReg Default: 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. ... ------------------------- Gabriel Montenegro responds to Jari Arkko: Your proposed solution sounds good. Just one minor question and nit... > o If the mobile node has not received the prefix information within Did you mean?: "If prefix information has not been sent to the mobile node within" > o If a prefix in the aggregate list that matches the mobile node's > home registration is added, or if its information changes in any > way that does not cause the mobile node's address to go s/go/become/ ------------------------- TJ Kniveton responds to Jari Arkko: Sorry if the text from issue 120 didn't make it in the draft; somehow I thought it was supposed to, but it was a busy time for editing and I guess it got missed. However, luckily those e-mails and issue resolutions are still around and I think you used that to create your proposed (re-)solution. This fix sounds reasonable overall to me, though I haven't implemented those timing rules yet. I will try and do it some time soon. Gabriel Montenegro wrote: > Your proposed solution sounds good. Just one minor question and nit... > > Jari Arkko wrote: > > o If the mobile node has not received the prefix information within > > Did you mean?: > "If prefix information has not been sent to the mobile node within" > > > the last MaxMobPfxAdvInterval (see Section 13) seconds, then > > ensure that a transmission is scheduled. The actual transmission > > time is randomized as described below. I think the Home Agent was originally supposed to know that the mobile received the prefix information, because it responds with a binding update! > > o If a prefix in the aggregate list that matches the mobile node's > > home registration is added, or if its information changes in any > > way that does not cause the mobile node's address to go > > s/go/become/ or just drop the passive tense: "does not deprecate the mobile node's address" ------------------------- Jari Arkko responds to TJ Kniveton: Thanks for your comments Gabriel and TJ. Inline: > I think the Home Agent was originally supposed to know that the mobile > received the prefix information, because it responds with a binding > update! The unsolicited advertisements are still "acked", though with the reception of an MPS. So, the home agent not only knows when it has sent information but also knows what the mobile node has received. However, we don't want to formulate the rule so that it would keep scheduling new deliveries to a mobile node who is not responding. So I think we should base our delivery schedule on the latest MPS from the mobile, or the latest unsolicited MPA to the mobile, whichever was later. This turns out to be equivalent to the time of the last MPA (solicited or unsolicited) transmission to the mobile node in question. Modified text proposal below and also in the latest draft version in the web. Changed contents in Section 10.6.2: 10.6.2 Scheduling Prefix Deliveries ... The home agent uses the following algorithm to determine when to send prefix information to the mobile node. o If a mobile node sends a solicitation, answer right away. o If no Mobile Prefix Advertisement has been sent to the mobile node in the last MaxMobPfxAdvInterval (see Section 13) seconds, then ensure that a transmission is scheduled. The actual transmission time is randomized as described below. o If a prefix in the aggregate list that matches the mobile node's home registration is added, or if its information changes in any way that does not deprecate the mobile node's address, ensure that a transmission is scheduled. The actual transmission time is randomized as described below. o If a home registration expires, cancel any scheduled advertisements to the mobile node. ... New contents of Section 11.4.2: 11.4.2 Sending Mobile Prefix Solicitations When a mobile node has a home address that is about to become invalid, it SHOULD send a Mobile Prefix Solicitation to its home agent in an attempt to acquire fresh routing prefix information. The new information also enables the mobile node to participate in renumbering operations affecting the home network, as described in Section 10.6. The mobile node MUST use the Home Address destination option to carry its home address. The mobile node MUST support and SHOULD use IPsec to protect the solicitation. The mobile node MUST set the Identifier field in the ICMP header to a random value. As described in Section 11.7.2, Binding Updates sent by the mobile node to other nodes MUST use a lifetime no greater than the remaining ... New contents of Section 13: 13. Protocol Configuration Variables MaxMobPfxAdvInterval Default: 86,400 seconds MinDelayBetweenRAs Default: 3 seconds, Min: 0.03 seconds MinMobPfxAdvInterval Default: 600 seconds InitialBindackTimeoutFirstReg Default: 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. ... -------------------------