Erik Nordmark writes: I haven't parsed all of -20 yet so there is one part I'm not sure about. But most of the issue has gone away by remove s=20 registrations. It is mandatory for the MN to use MPS/MPA to discover the preferred and valid lifetime for its home addresses? If not the MN will have no idea why the BA's have such a short lifetime and the MN will continue to sending BUs to the HA to try to extend the binding lifetime as the prefix lifetime drops to zero. (when the valid lifetime goes towards zero) And without the MN knowing the preferred lifetime it can't do the right source address selection while away from home. --------------------- Yes. I think I understand the issue now. The crucial question is if the mobile node knows what's going on, or if it stubbornly tries to extend the binding "well before the binding expires" as required in Section 11.7.1. Currently, Section 10.3.1 allows the home agent to shrink the lifetime per local policy, without restrictions. So a mobile node who sends in a lifetime=3600s registration has no way of knowing if the returned lifetime=10s is due to the prefix lifetime or due to local policy. Unless it does prefix discovery, of course. I think there is an issue. How should we solve it? I'd like to avoid mandatory prefix discovery, if at all possible. (1) We could add a requirement for the home agent to not shrink the lifetime beyond certain limits just based on policy, and then require mobile nodes not try to renew registrations if the home agent set the lifetime very small. If this rule is "never renew again", then I fear we might get into a problem if for some reason the prefix lifetimes drop very short in the home network for a while and then return; the mobile node's use of the home address is effectively disabled as a result. If the rules "don't renew until expired" then we still have many mobile nodes contacting the home agent at the same time, even if we avoid the ever shortening lifetimes and attempts to reregister just before the expiration. (2) We could have the home agent provide an indication in the BA that the prefix is gone after the lifetime is over. Trouble is, how does the home agent know this? (3) Ignore the issue. So, if prefix distribution is not used then mobile nodes will be causing unnecessary traffic for expiring prefixes. But how important is this compared to an other effect of the prefix change: mobile nodes that don't use prefix distribution will be unable to take in use the new prefixes, and will likely be unable to communicate at all. It seems that the possibility of changing prefixes in the home network leads to the necessity to use prefix distribution in any case. (4) Something else, what? --------------------- I have thought about this further now. It seems that there are two separate cases: (a) The mobile node supports prefix discovery. In that case, it should use the information it has learned about the prefix lifetimes when trying to extend the registration lifetime. I suggest adding the following to 11.7.1: "... the mobile node SHOULD send a new Binding Update to it well before the expiration of this period, even if it is not changing its primary care-of address. (NEW TEXT:) However, if the mobile node has learned through prefix discovery that the home subnet prefix for the home address is about to expire, the mobile node SHOULD NOT try to extend the registration period." I also changed the original MUST to a SHOULD. (b) The mobile node does not support prefix discovery. We are headed for serious problems in any case if the prefixes start to expire. The mobile node will be left without service for its home address. What we are trying achieve in this discussion would amount to reducing the signaling load on the home agent right before this happens. My suggestion is that it isn't worth protecting for, but we should document the implications: "... Note that when home subnet prefixes expire, mobile nodes that do not support prefix discovery may be left without service. Such mobile nodes may also cause congestion for the home agent by repeatedly trying to extend the registration period." --------------------- Vijay Devarapalli responds to Jari Arkko: I think we are using MUST and SHOULD where they need not be used. instead lower case letters should be used. --------------------- Jari Arkko responds to Vijay Devarapalli: Ok --------------------- Erik Nordmark responds to Jari Arkko: > I think there is an issue. How should we solve it? I'd like > to avoid mandatory prefix discovery, if at all possible. One question in my mind is how the MN knows the preferred lifetime for its HoAs without doing prefix discovery? The binding ack could be made to optionally carry the preferred lifetime if it is less than the binding lifetime, and in that case the binding ack could also be made to optionally carry the valid lifetime if it is less than the binding lifetime. These two additional options would solve the problem without requiring prefix discovery. Call that number (0) in your list of ideas... > (2) We could have the home agent provide an indication > in the BA that the prefix is gone after the lifetime > is over. Trouble is, how does the home agent know this? I think the HA would know this because it, like any other router, has the knowledge (e.g. through router renumbering or manual config) whether or not AdvValidLifetime is decrementing in real time. Of course, the prefix might reappear after it has become invalid, but in that case the HA should work the same way as when a new prefix is introduced on the home link. > (b) The mobile node does not support prefix discovery. We > are headed for serious problems in any case if the > prefixes start to expire. The mobile node will be left > without service for its home address. What we are trying > achieve in this discussion would amount to reducing the > signaling load on the home agent right before this > happens. My suggestion is that it isn't worth protecting > for, but we should document the implications: > > "... Note that when home subnet prefixes expire, mobile > nodes that do not support prefix discovery may be left > without service. Such mobile nodes may also cause > congestion for the home agent by repeatedly trying to > extend the registration period." Isn't that basically mandating prefix discovery? And the MN still can't tell whether to invoke prefix discovery or the HA is just responding with a low binding lifetime for policy reasons? --------------------- Jari Arkko responds to Erik Nordmark: > One question in my mind is how the MN knows the preferred lifetime > for its HoAs without doing prefix discovery? > The binding ack could be made to optionally > carry the preferred lifetime if it is less than the binding lifetime, > and in that case the binding ack could also be made to optionally carry > the valid lifetime if it is less than the binding lifetime. > > These two additional options would solve the problem without requiring prefix > discovery. Call that number (0) in your list of ideas... Yes. But at the end of the day, if your prefix is deprecated and you don't have prefix discovery, your have a problem. What I'm saying is that while the above actions help, they still don't remove the main problem. If so, are they worth the trouble? >>(b) The mobile node does not support prefix discovery. We >> are headed for serious problems in any case if the >> prefixes start to expire. The mobile node will be left >> without service for its home address. What we are trying >> achieve in this discussion would amount to reducing the >> signaling load on the home agent right before this >> happens. My suggestion is that it isn't worth protecting >> for, but we should document the implications: >> >> "... Note that when home subnet prefixes expire, mobile >> nodes that do not support prefix discovery may be left >> without service. Such mobile nodes may also cause >> congestion for the home agent by repeatedly trying to >> extend the registration period." > > > Isn't that basically mandating prefix discovery? Well, I think we have the same idea about the implications of not having prefix discovery as we did previously. If prefixes change, disappear, or appear -- mobile nodes will not work very well. But still, such mobile nodes may work well in more stable environments. > And the MN still can't tell whether to invoke prefix discovery or > the HA is just responding with a low binding lifetime for policy reasons? We could add a lower limit on the policy-based lifetime reductions. Would that help? --------------------- Erik Nordmark responds to Jari Arkko: > Yes. But at the end of the day, if your prefix is deprecated > and you don't have prefix discovery, your have a problem. What > I'm saying is that while the above actions help, they still > don't remove the main problem. If so, are they worth the > trouble? But prefix discovery isn't sufficient when your HoA is gradually being replaced with a new HoA, since the MN and HA need to associate some secret (be it pre-shared key, cert, ...) with the new HoA. Thus unless I'm mising some magic, all that prefix discovery can provide is the ability to know that new prefixes are available and when the prefixes become depcrecated and invalid. I think we need to work on some form of provisioning step that takes care of setting up the association between the HoA and the MN/HA security in order to let the MN start using a new HoA without manual out-of-band communication. So yes, prefix discovery might not be worth the trouble until we understand how this provisioning step is going to work. It might be that prefix discovery is an important piece, but I can't yet say that it is. Hence my desire to make deprecation and also detecting that the HoA is becomining invalid something that can be done just looking at the BAck. --------------------- Erik Nordmark responds to Jari Arkko: > So your advice is to put the information in the back? And what should > we do with the prefix discovery? If it isn't too much pain it makes sense for me to add the options to the bind ack for carrying the valid and preferred lifetimes (only used when the respective lifetime is less than the binding lifetime). And then leave the prefix discovery as is. Later, when we understand how to securely renumber the WG can look at what needs to be done (if anything) to/with prefix discovery. --------------------- Gabriel Montenegro responds to Erik Nordmark: > And then leave the prefix discovery as is. Later, when we understand how > to securely renumber the WG can look at what needs to be done (if anything) > to/with prefix discovery. This strikes me as duplicating prefix discovery. Even if we do add the option above, from Jari's previous message, it seems like for a MN to do anything with this it would require IKE. If it implements IKE, it probably can also implement prefix discovery (which is already a SHOULD if memory serves). If it doesn't implement IKE, then it knows about its impending death but can't do much about it. Perhaps we can accomodate this in a more lightweight fashion. Instead of adding the preferred lifetimes to the BACK, we could just use return codes from the <128 range in the BACK (didn't Jari proposed this already?). These are success codes which add some info like: "your BU is ok, but the lifetime was reduced by local policy" "your BU is ok, but the lifetime was reduced by prefix lifetime" etc --------------------- Jari Arkko responds to Gabriel Montenegro: > These are success codes which add some info like: > > "your BU is ok, but the lifetime was reduced by local policy" > "your BU is ok, but the lifetime was reduced by prefix lifetime" > etc Works for me. --------------------- Erik Nordmark responds to Gabriel Montenegro: > "your BU is ok, but the lifetime was reduced by local policy" > "your BU is ok, but the lifetime was reduced by prefix lifetime" > etc How do you propose handling a deprecated prefix? I assume the "prefix lifetime" above is the valid lifetime, but the MN also needs to know which HoAs are preferred vs. deprecated. --------------------- Gabriel Montenegro responds to Erik Nordmark: > How do you propose handling a deprecated prefix? Given that this last status message means the associated prefix is dying, the MN should send an MPS. It it doesn't do that, it's out of luck. It's been warned. (But see below, it seems like it doesn't have a choice and it must implement prefix discovery...) If we duplicate all the prefix discovery (and DHAAD?) info in the BACK, presumably it's to cater to minimal devices. If they're so minimal, they won't implement IKE and they'll be hosed anyways, cuz in addition to dynamic discovery mechanisms, as Jari pointed out, to make this usable, the MN will need dynamic keying. > I assume the "prefix lifetime" above is the valid lifetime, yes, that's the idea. > but the MN > also needs to know which HoAs are preferred vs. deprecated. It'll also need DHAAD. If it doesn't implement it, too bad. At least there's a way to cope with this for systems that care about this possibility. Note that there's also the point of view that the base spec should not even provide the means to cope with such changing conditions (via prefix discovery/DHAAD) as documented in issue 232 ("DHAAD is feeping creaturism?"). But, I'm not sure I agree with taking out all that stuff. Actually, now that I look at the draft, I'm slightly confused, cuz contrary to what I had assumed, prefix discovery is a MUST implement at the mobile node: o The node MUST support receiving Mobile Prefix Advertisements (Section 11.4.3) and reconfiguring its home address based on the prefix information contained therein. This has been unchanged since version 16. Maybe I'm the only one confused, but I thought part of the debate here was on whether or not to make prefix discovery mandatory. It seems like this decision was done a long time ago. True the above imposes MPA at the MN but doesn't talk about MPS. Since we say an unsolicited MPA SHOULD not be taken face value and instead be followed by an MPS, the above bullet should also impose a MUST implement on MPS at the MN. Otherwise we're requiring a mechanism (MPA handling at the MN) and not guaranteeing that it can be used at all. --------------------- Jari Arkko writes: After a long discussion I think we understand the different aspects of this issue: - Even an individual home address registration is problematic given the requirement to update registrations "well in advance". - Its hard for mobile nodes to behave in the correct manner without knowing why the lifetime become short. - Mobile nodes should respect the valid & preferred lifetimes. Fortunately, we seem to agree on what needs to be done: - Provide enough information in the BAs that the MNs know there's a problem. - Let the mobile nodes use prefix discovery to figure out the actual parameters. - Mobile nodes are already required to support prefix discovery messages. It is important to clarify that while MNs need to fail gracefully when e.g. one of their ten home addresses is deprecated, there is no requirement to support full provisioning capabilities for new home addresses. In Section 6.1.8 (BA), add the following Status codes: 1 Accepted with reduced lifetime due to prefix deprecation 2 Accepted with reduced lifetime due to policy In Section 9.5.4 (sending BAs), add the following paragraph: The correspondent node MAY decrease the specified lifetime for the binding based on a local policy. In this case the Status field in the Binding Acknowledgement MUST be set to value 2 (Accepted with reduced lifetime due to policy). In the same section, change If the node rejects the Binding Update, a Binding Acknowledgement MUST be sent. If the node accepts the Binding Update, the Binding Acknowledgement SHOULD NOT be sent. to If the Status field would be set to zero, the Binding Acknowledgement SHOULD NOT be sent. Otherwise, the Binding Acknowledgement MUST be sent. In Section 10.3.1 (home registrations), change the lifetime determination paragraphs as follows: o The lifetime for the Binding Cache entry MUST NOT be greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address specified with the Binding Update. ... NEWTEXT: If the lifetime was reduced for this reason, the home agent MUST set the Status field to value 1 (Accepted with reduced lifetime due to prefix deprecation). END OF NEW TEXT ... o CHANGED TEXT: The home agent MAY further decrease the specified lifetime for the binding based on a local policy. NEW TEXT If the lifetime was reduced for this and only this reason, the home agent MUST set the Status field to value 2 (Accepted with reduced lifetime due to policy). END OF NEW TEXT ... In Section 11.7.1 (home registrations), change: Also, if the mobile node wants the services of the home agent beyond the current registration period, the mobile node MUST send a new Binding Update to it well before the expiration of this period, even if it is not changing its primary care-of address. to Also, if the mobile node wants the services of the home agent beyond the current registration period, the mobile node should send a new Binding Update to it well before the expiration of this period, even if it is not changing its primary care-of address. However, if the home agent returned a Binding Acknowledgement for the current registration with Status field set to 1 (accepted with reduced lifetime due to prefix deprecation), the mobile node should not try to register again before it has learned the validity of its home prefixes through prefix discovery. Add bullet items to Section 11.7.3 (receiving BAs): o Additionally, if the Status field value is 1 (Accepted with reduced lifetime due to prefix deprecation), the mobile node SHOULD send a Mobile Prefix Solitation message to update its information about the available prefixes. Add to the end of 11.4.3 (receiving prefix advertisements): This specification assumes that any security associations and security policy entries that may be needed for new prefixes have been pre-configured in the mobile node. Note that while dynamic key management avoids the need to create new security associations, it is still necessary to add policy entries to protect the communications involving the home address(es). Mechanisms for automatic set-up of these entries are outside the scope of this specification. --------------------- Brian Haley responds to Jari Arkko: I'm not sure we need all this new text, let me propose an alternate solution. 1. MN <-> CN bindings The correspondent node MAY decrease the specified lifetime for the binding based on a local policy. In this case a Binding Acknowledgement MUST be returned to indicate this lifetime, regardless of the setting of the Acknowledge (A) bit in the Binding Update. The mobile node can assume that the correspondent node reduced the lifetime due to local policy and SHOULD NOT try increasing the lifetime in future Binding Updates sent to this correspondent node. 2. MN <-> HA bindings When the mobile node receives a Binding Acknowledgement from its home agent with the lifetime shorter than it had requested, the mobile node SHOULD send a Mobile Prefix Solitation message to update its information about the available prefixes. If the preferred lifetime of its home prefix is the lifetime that was returned in the Binding Acknowledgment (with some small fudge factor for RTT?), then the mobile node can assume the lifetime was reduced due to prefix deprecation. If the lifetime was shorter than the preferred lifetime, then the mobile node can assume the lifetime was reduced due to local policy. In this case the mobile node SHOULD NOT try increasing the lifetime in future Binding Updates sent to this home agent. At the very least I think #1 above can get rid of the need for BAck status #2 you proposed. I would like to do as few changes as possible since we are already done with last call... --------------------- Ed Remmell responds to Brian Haley: > I'm not sure we need all this new text I like the fact that Brian's proposed solution doesn't require new BA status codes, however Brian does slip in an extra "SHOULD NOT" requirement on the MN that I think is too restrictive. In our implementation, we plan to let the user application specify the requested binding lifetime via a public API. Of course, internally I can always make the actual requested lifetime in the BU be less (I have to do this anyways for the case where the home address prefix valid lifetime is less than the lifetime the user requested), so I could implement Brian's proposed requirements text as worded below, but if there isn't a really good reason for introducing a brand new requirement (i.e. "MN SHOULD NOT try increasing the lifetime in future BUs sent to CN/HA") then I'd really prefer that you didn't, since after all as Brian says "I would like to do as few changes as possible since we are already done with last call". >, let me propose an alternate > solution. > > 1. MN <-> CN bindings > > The correspondent node MAY decrease the specified lifetime for the > binding based on a local policy. In this case a Binding > Acknowledgement MUST be returned to indicate this lifetime, > regardless of the setting of the Acknowledge (A) bit in the > Binding Update. The mobile node can assume that the correspondent > node reduced the lifetime due to local policy and SHOULD NOT > try increasing the lifetime in future Binding Updates sent to > this correspondent node. I like => "CN MUST send BA when requested lifetime is reduced." I don't like => "MN SHOULD NOT try increasing the lifetime in future BUs sent to CN." > 2. MN <-> HA bindings > > When the mobile node receives a Binding Acknowledgement from > its home agent with the lifetime shorter than it had requested, > the mobile node SHOULD send a Mobile Prefix Solitation message > to update its information about the available prefixes. If > the preferred lifetime of its home prefix is the lifetime that > was returned in the Binding Acknowledgment (with some small > fudge factor for RTT?), then the mobile node can assume the > lifetime was reduced due to prefix deprecation. If the lifetime > was shorter than the preferred lifetime, then the mobile node can > assume the lifetime was reduced due to local policy. In this case > the mobile node SHOULD NOT try increasing the lifetime in > future Binding Updates sent to this home agent. I like => "Lifetime in home agent BA shorter than requested lifetime, MN SHOULD send Mobile Prefix Solicitation." I don't like => "MN SHOULD NOT try increasing the lifetime in future BUs sent to HA." > I would like to do as few changes as possible since we are > already done with last call... I completely agree with this statement. Jari's proposed solution required changes to the CN implementation, it would be nice if we could keep the CN stuff stable and only require changes to the MN behavior in this case. Brian's proposed solution does that, however the extra "SHOULD NOT" requirement on the lifetime that the MN can specify in the BU is too restrictive for my liking. --------------------- Ed Remmell continues: BTW, the potential optimization that Brian is trying for to supress extra BAs on future BU/BA exchanges between the MN and CN/HA is a little dangerous, because the CN/HA is deciding (in this case) to shorten the binding lifetime based on "local policy" - that decision is local to the CN/HA, Brian is proposing that that same policy be extended to the MN to influence the lifetime in future BUs sent by the MN. As I said in my previous email, I'm not in favor of this extra requirement. The BU/BA exchange shouldn't be occuring that frequently (therefore the potential savings of this optimization is questionable), also many MN implementations will likely always register with the Acknowledge (A) bit set in the BU because they want confirmation from the CN/HA that their BU was actually applied (i.e. these messages can get dropped, especially over wireless). In that case, the CN/HA always has to send the BA anyways, so there is no optimization possible. --------------------- Brian Haley responds to Ed Remmell: Right, my goal was to suppress future BAs when not requested by the MN, the "SHOULD NOT try increasing the lifetime in future BUs" part was necessary to make this happen. The other, more radical approach would be to remove the A-bit all together and always require an Ack, that way the MN would always know the lifetime, but then we're wasting bandwidth, which is important to some. I actually don't know why we need this optimization at all since when the binding on the CN expires (short of the lifetime the MN expects), it will start sending packets to the MNs home, they'll get tunnelled, and another binding will get created. Telling the MN you granted a shorter lifetime is strictly an optimization, and we've removed other such things from the draft. Having the MN know about prefix lifetimes and how they relate to binding lifetimes seems more important. --------------------- Jari Arkko writes: Re: changes to the CN section. Strictly speaking, the status code #2 isn't absolutely required even in the proposal I had. I just put it there for consistency. But it doesn't change the MN behaviour. We could get rid of it, if we want to. Re: putting the send-the-ba-regardless-of-the-a-bit text into the treatment of the status code #2 vs. the bullet list in the start of Section 9.5.4. I really would like to keep the send-ba-or-not rules in the bullet list. Its too complex to be spread around. Re: returning the BA always. I have always been a proponent of this, but as I recall it was debated a long time ago and we got some pushback on it. Maybe we shouldn't reopen that discussion -- but our implementations will have A fixed to 1. Re: additional requirements that Ed complained about. I also think that we should avoid them. Re: a status code vs. doing prefix discovery whenever the lifetime is reduced. I'd rather avoid the extra messaging that results from the lack of knowledge why the reduction was done. Anyways, in conclusion we appear to agree very roughly about the very basic approach at least -- that once there is knowledge of lifetime reduction we go off and do prefix discovery. However, almost everything else is being debated. The important questions to answer at this stage are: * Should there be a status code or should the mobile node do the prefix discovery every time after a reduced lifetime? * Should we keep the CN text unchanged, or should we add other similar status codes in addition to #1? I am in favor of a status code, but I'm starting to think maybe code #2 should not be included. --------------------- Ed Remmell responds to Jari Arkko: I'm OK with you adding just a single new BA status code to the CN/HA: 1 Accepted with reduced lifetime due to prefix deprecation This avoids making changes to the CN. This simplifies your earlier proposed text changes to: In Section 6.1.8 (BA), add the following Status codes: 1 Accepted with reduced lifetime due to prefix deprecation In Section 10.3.1 (home registrations), change the lifetime determination paragraphs as follows: o The lifetime for the Binding Cache entry MUST NOT be greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address specified with the Binding Update. ... NEWTEXT: If the lifetime was reduced for this reason, the home agent MUST set the Status field to value 1 (Accepted with reduced lifetime due to prefix deprecation). END OF NEW TEXT ... In Section 11.7.1 (home registrations), change: Also, if the mobile node wants the services of the home agent beyond the current registration period, the mobile node MUST send a new Binding Update to it well before the expiration of this period, even if it is not changing its primary care-of address. to Also, if the mobile node wants the services of the home agent beyond the current registration period, the mobile node SHOULD send a new Binding Update to it well before the expiration of this period, even if it is not changing its primary care-of address. However, if the home agent returned a Binding Acknowledgement for the current registration with Status field set to 1 (accepted with reduced lifetime due to prefix deprecation), the mobile node SHOULD NOT try to register again before it has learned the validity of its home prefixes through prefix discovery. Add bullet items to Section 11.7.3 (receiving BAs): o Additionally, if the Status field value is 1 (Accepted with reduced lifetime due to prefix deprecation), the mobile node SHOULD send a Mobile Prefix Solitation message to update its information about the available prefixes. Add to the end of 11.4.3 (receiving prefix advertisements): This specification assumes that any security associations and security policy entries that may be needed for new prefixes have been pre-configured in the mobile node. Note that while dynamic key management avoids the need to create new security associations, it is still necessary to add policy entries to protect the communications involving the home address(es). Mechanisms for automatic set-up of these entries are outside the scope of this specification. NOTE: there is another part of section 10.3.1 you probably want to update as well: " Regardless of the setting of the Acknowledge (A) bit in the Binding Update, the home agent MUST return a Binding Acknowledgement to the mobile node, constructed as follows: o The Status field MUST be set to a value 0, indicating success." Obviously, other values besides 0 for status can now indicate success. Anyways, I'm OK with these changes. --------------------- Gabriel Montenegro responds to Ed Remmell: This looks good, yes, the single added BA status code. --------------------- Jari Arkko responds to Ed Remmell: > NOTE: there is another part of section 10.3.1 you probably want to update as > well: > > o The Status field MUST be set to a value 0, indicating success." > > Obviously, other values besides 0 for status can now indicate success. Yes. I changed the text to: " o The Status field MUST be set to a value indicating success. The value 0 MUST be used if not otherwise specified above. " --------------------- Brian Haley responds to Ed Remmell: I would be ok with this. --------------------- Erik Nordmark responds to Jari Arkko: > The lifetime for the Binding Cache entry MUST NOT be greater than > the remaining valid lifetime for the subnet prefix in the mobile > node's home address specified with the Binding Update. ... > NEWTEXT: If the lifetime was reduced for this reason, the home > agent MUST set the Status field to value 1 (Accepted with > reduced lifetime due to prefix deprecation). END OF NEW TEXT valid/preferred confusion above. With this approach I think it makes sense to have two additional status codes X Accepted with reduced lifetime due to prefix invalidation Y Accepted but the prefix is currently deprecated Thus assume that the prefix becomes deprecated at time 100 and invalid at time 300 and the normal binding lifetime would be 5. A BA at time zero would have a lifetime of 5 and code 0. A BA at time 96 would have a lifetime of 4 and code 1. A BA at time 99 would have a lifetime of 1 and code 1. A BA at time 100 would have a lifetime of 5 and code Y. A BA at time 296 would have a lifetime of 4 and code Y *and* X. And if the invalidation and deprecating time is the same (which isn't normal) the scenario would be slightly different. But I think the behavior at time 96-100 above is suboptimal. It would make more sense to me to keep the lifetime at 5 and include a "remaining preferred lifetime" option in the BAck because otherwise it seems like the MN needs to do more and more frequent registrations during that time interval. --------------------- Erik Nordmark responds to Brian Haley: > 2. MN <-> HA bindings > > When the mobile node receives a Binding Acknowledgement from > its home agent with the lifetime shorter than it had requested, > the mobile node SHOULD send a Mobile Prefix Solitation message > to update its information about the available prefixes. If > the preferred lifetime of its home prefix is the lifetime that > was returned in the Binding Acknowledgment (with some small > fudge factor for RTT?), then the mobile node can assume the > lifetime was reduced due to prefix deprecation. If the lifetime > was shorter than the preferred lifetime, then the mobile node can > assume the lifetime was reduced due to local policy. In this case > the mobile node SHOULD NOT try increasing the lifetime in > future Binding Updates sent to this home agent. But since the binding lifetime is still reduced this still means that the MN needs to repeat the BU multiple times even after it has performed prefix discovery to detect the reason for the short binding lifetime. So an alternate proposal is to add just 3 new codes to the BA and have the binding lifetime be completely unrelated to the lifetimes of the prefixes: 1 Please do prefix discovery to determine the prefix lifetimes since they are less than the binding lifetime. 2 The prefix is deprecated. Mark this home address as deprecated. 3 Both of 1 and 2 apply. In this case the binding lifetime would only be less than requested due to local policy. --------------------- Ed Remmell responds to Erik Nordmark: Here is part of your original issue text that wasn't directly addressed (and which you essentially reprise below): "It is mandatory for the MN to use MPS/MPA to discover the preferred and valid lifetime for its home addresses? If not the MN will have no idea why the BA's have such a short lifetime and the MN will continue to sending BUs to the HA to try to extend the binding lifetime as the prefix lifetime drops to zero. (when the valid lifetime goes towards zero)." This scenario (prefix invalidation) should not happen that frequently. If/when it does happen, the MN will have to stop using that home address. The change that has been made to the draft text for this issue has only a single added status code in the BA: "1 Accepted with reduced lifetime due to prefix deprecation" When this occurs, the MN SHOULD send a Mobile Prefix Solitation message to update its information about the available prefixes, which helps ensure that the MN is notified that a prefix is about to be invalidated, and also the MN SHOULD NOT try to register again before it has learned the validity of its home prefixes through prefix discovery. Also, when the MN does this Home Prefix Discovery, it discovers both the preferred and valid lifetimes of the prefix, so it knows if the prefix is preferred or deprecated. It is mandatory for the MN to be able to correctly process the Mobile Prefix Advertisement, but it is only a SHOULD requirement that the MN send the Mobile Prefix Solicitation. The home agent MUST also send unsolicited Mobile Prefix Advertisement messages to the MN "when the valid or preferred lifetime or the state of the flags changes for the prefix of the mobile node's registered home address" (section 10.6.2). So, even if your MN doesn't actively solicit this prefix information from the home agent, it will probably (i.e. assuming the MPA message reaches the MN) be notified by the home agent Mobile Prefix Advertisement when the valid or preferred lifetime of the home prefix changes. In any case, the new requirements text added to the spec for this issue (see above for the MN part) does help ensure that the prefix lifetime information is communicated to the MN when the prefix is soon to be invalidated. W/ regards to your concern that with short lifetimes, the MN will be frequently re-registering (per your example below), IMHO that is probably best taken care of as an implementation detail (i.e. not in the specification). In this case, the home address is about to be invalidated anyways, which is a hard failure. The fact that the MN may be frequently soliciting the home prefix information and reregistering during this period of time doesn't seem to be that big of a deal, since this is soon to become a hard failure condition anyways. --------------------- Erik Nordmark responds to Ed Remmell: > "1 Accepted with reduced lifetime due to prefix deprecation" You seem to be using "invalidation" and "deprecation" interchangeable when in fact they are two completely different things. Please see RFC 2462. > W/ regards to your concern that with short lifetimes, the MN will be > frequently re-registering (per your example below), IMHO that is probably > best taken care of as an implementation detail (i.e. not in the > specification). In this case, the home address is about to be invalidated > anyways, which is a hard failure. The fact that the MN may be frequently > soliciting the home prefix information and reregistering during this period > of time doesn't seem to be that big of a deal, since this is soon to become > a hard failure condition anyways. I don't understand what "soon" means to you. A reasonable approach to graceful renumbering involves a step where the old prefix is deprecated for a long time (measured in days or weeks) before it becomes invalidated. And what you call implementation detail seems to be a liberal interpretation of the binding lifetime in the bind ack (when the bind ack comes back with Y seconds and code 1 it is ok for the MN to assume the HA will retain the binding for X (> Y) seconds). If that is what the WG wants IMHO that aspect of protocol behavior should be written down in the spec. --------------------- Ed Remmell responds to Erik Nordmark: I'm just trying to help, since I was in context of this issue and felt you deserved a response. > > "1 Accepted with reduced lifetime due to prefix deprecation" > > You seem to be using "invalidation" and "deprecation" interchangeable > when in fact they are two completely different things. Please see > RFC 2462. A prefix is (usually) deprecated before it is invalidated. An invalid prefix cannot be used. Therefore, it only makes sense to refer to it as a deprecated prefix (I think). I had the same reaction to this verbage that you did when I first read it, but then I thought, "well, if it said prefix invalidation, then my home prefix is already invalid, I can't use it so I wouldn't be able to successfully register", so "prefix deprecation" seemed to be OK for the verbage. You could change the verbage to say "pending prefix invalidation" instead of "prefix deprecation" and that would perhaps be more accurate, personally I'd be OK with that change: 1 Accepted with reduced lifetime due to pending prefix invalidation But, I don't see it as a big deal one way or the other, the current text works just as well for me. > I don't understand what "soon" means to you. > A reasonable approach to graceful renumbering involves a step > where the old > prefix is deprecated for a long time (measured in days or weeks) before > it becomes invalidated. OK. So, let's say we get past the IPsec configuration hurdles w/ regards to implementing support for graceful renumbering. So, this home address that will be invalidated in 5 minutes (5 minutes is "soon" to me, so is 15 minutes for that matter) has a binding lifetime of 5 sent in the BA. I assume you meant 20 seconds, because the lifetime in the BA is in units of 4 seconds. Well, I would hope the home prefix for this home address is deprecated by now, and that the MN knows it is deprecated. Also, likely the home agent is advertising a new preferred home address prefix to the MN. Assuming that the MN already has the necessary IPsec configuration (or a new digital certificate, if certificate-based automated keying is being used) for the new preferred home address, it can then successfully register it with the HA. So, in that case the MN has two bindings - one for the deprecated address with a 20 second lifetime, and the 2nd for the preferred address with a significantly longer lifetime. Because the deprecated address is deprecated, and the MN also has a new preferred home address to use, your source address selection algorithm should be providing the preferred home address to the application running on the MN, and very likely there is no application socket using the old deprecated home address anymore (I'd expect that the preferred prefix has been advertised now for a week or so, if the old deprecated prefix is about to become invalidated). So, your MN is maintaining an active binding (with a very short lifetime) for a home address that will be invalidated in 5 minutes (and that home address very likely isn't even being used by the MN application), when it has another active binding for a preferred home address that will replace the deprecated address. Why do you maintain both bindings? Your MN implementation should not be trying to maintain the binding for the deprecated home address in this case. However, if there is no preferred home address to use (or if the new digital certificate is not available, or the necessary IPsec configuration for the new preferred home address hasn't been done yet on the MN), then the MN is stuck and can only continue to use the deprecated home address until it becomes invalidated since in this other scenario the MN has no replacement preferred home address. It seems like the HA could control this situation by not allowing short lifetimes to be sent in the BA it returns to the MN. Making this a specific requirement in the specification, however, I think is a mistake (IMHO). Any robust HA implementation will consider such issues. > And what you call implementation detail seems to be a liberal > interpretation of the binding lifetime in the bind ack > (when the bind ack comes back with Y seconds and code 1 it is > ok for the MN to assume the HA will retain the binding for X (> > Y) seconds). > > If that is what the WG wants IMHO that aspect of protocol > behavior should be > written down in the spec. Actually, I was not making any assumption that the MN assumes that the binding lifetime for the deprecated home address is greater than the binding lifetime in the BA; that wouldn't work very well anyways, since the HA will delete the binding after the lifetime expires. I have not tried (yet) to design this part of MN functionality myself, but I'd say the burden is on the MN in this case, I would not require anything extra from the HA (i.e. I'd be against extending the BA message to include any kind of "remaining preferred lifetime" option). There are two different scenarios I'm aware of: 1) MN has a registered home address with a very short lifetime due to prefix deprecation, and no new preferred home address to replace it. 2) MN has a registered home address with a very short lifetime due to prefix deprecation, but has a suitable preferred home address (also registered) to replace it. In the case of #1, you are pretty much hosed, IMHO it doesn't matter what you do. So "soon" meaning 5 minutes to go before your home address expires, does it matter if you can't get great throughput in that very last 5 minutes of use of that deprecated home address by the MN because the MN is frequently reregistering and sending Mobile Prefix Solicitation messages? Personally, I don't think it matters. This is a hard failure case for the MN. If it matters for anyone, it is the home agent, but then the home agent can avoid having a MN "spamming" it too frequently with reregistration requests by just not allowing such short (i.e. 20 seconds? or 5 seconds? both are too short except perhaps for testing purposes) lifetimes in the BAs that it returns to MNs. It could of course just shut up the MN immediately by sending it a Mobile Prefix Advertisement with a valid lifetime of 0 seconds for the home address prefix, that should cause the MN to immediately invalidate that deprecated home address and quit trying to register it. In the case of #2, well, I agree you need to have something in your MN design for this scenario to keep the MN from using up too much bandwidth trying to maintain an unneeded binding for a home address that is soon to be invalidated anyways when it already has an active binding for a preferred home address replacement. Does there need to be anything explicit in the MIPv6 specification giving extra guidance to MN implementors for this scenario? Perhaps. Personally, I'm OK with the current spec, it is long enough. If you want specific wording added to guide MN implementors in how to handle this scenario, please propose it to the list - hopefully, it isn't too late if you do it soon. However, I don't think you will be successful getting anyone to add new message options, and there will be even likely be some resistance to new BA status codes. Anyways, I've got to get some of my own design work done today... --------------------- Brian Haley writes: My alternative, alternative proposal is to not worry about prefix deprecation in the base draft and instead deal with it in another draft, obviously there are many things to think about, none of which are necessary for the protocol to work in a "normal" IPv6 network (is anyone renumbering their site today?). The only BAck status code would be zero (success). --------------------- Erik Nordmark responds to Ed Remmell: > A prefix is (usually) deprecated before it is invalidated. An invalid prefix > cannot be used. Therefore, it only makes sense to refer to it as a > deprecated prefix (I think). I had the same reaction to this verbage that > you did when I first read it, but then I thought, "well, if it said prefix > invalidation, then my home prefix is already invalid, I can't use it so I > wouldn't be able to successfully register", so "prefix deprecation" seemed > to be OK for the verbage. You could change the verbage to say "pending > prefix invalidation" instead of "prefix deprecation" and that would perhaps > be more accurate, personally I'd be OK with that change: Are you saying that "prefix deprecation" in the MIPv6 spec would mean something different than "deprecated" in RFC 2462? That would make no sense at all. While the prefix is deprecated you should be able to register with the HA but the MN needs to know that the prefix is deprecated so it can take it into account in its source address selection per draft-ietf-ipv6-default-addr-select-09.txt. Once the prefix is invalidated it makes sense for the HA to refuse registrations. So given this confusing use of terms I don't know when code 1 would be returned. > 1 Accepted with reduced lifetime due to pending prefix invalidation I still don't understand the exact semantics. Does it mean that at the point in time when the binding lifetime expires the prefix will be invalid at the HA? Or can be binding lifetime be reduced by arbitrary amounts? (e.g. the prefix will become invalid in 2 minutes so the HA returns a binding lifetime of 1 minute?) > OK. So, let's say we get past the IPsec configuration hurdles w/ regards to > implementing support for graceful renumbering. Even without assuming that it makes sense the protocol is well-behaved and well-defined as the prefix goes through becoming deprecated and later invalidated. > So, this home address that > will be invalidated in 5 minutes (5 minutes is "soon" to me, so is 15 > minutes for that matter) has a binding lifetime of 5 sent in the BA. I > assume you meant 20 seconds, because the lifetime in the BA is in units of 4 > seconds. I intentionally didn't supply time units in my example - they were for illustratory purposes. > Well, I would hope the home prefix for this home address is > deprecated by now, and that the MN knows it is deprecated. How did the MN discover it was deprecated and when it became deprecated? Based on assuming that code=1 means it will get deprecated when the "binding lifetime" has passed? > Because the deprecated address > is deprecated, and the MN also has a new preferred home address to use, your > source address selection algorithm should be providing the preferred home > address to the application running on the MN, and very likely there is no > application socket using the old deprecated home address anymore (I'd expect > that the preferred prefix has been advertised now for a week or so, if the > old deprecated prefix is about to become invalidated). This is a detail from MIPv6's perspective but important from a graceful renumbering perspective: the prefix needs to stay in deprecated state for a time long enough to 1) make the DNS RRs that contain it expire due to DNS ttl, 2) some fudge for applications that cache DNS responses without honoring the DNS ttl, 3) plus the time you want to support existing communication using the old addresses. This time is likely to be measure in days or weeks if a large site is renumbering. During that time period you'll have one deprecated HoA and one preferred HoA and you need to maintain home registrations for both for existing communication as well as new communication using the old address that hasn't timed out from the DNS yet. > Why do you maintain both bindings? Your MN implementation should > not be trying to maintain the binding for the deprecated home address in > this case. Because you want graceful renumbering. If you don't care if it is graceful then the site admin can immediately force the old prefix to be invalid without going through a deprecated state, or have a very short deprecated state. > 1) MN has a registered home address with a very short lifetime due to prefix > deprecation, and no new preferred home address to replace it. > > 2) MN has a registered home address with a very short lifetime due to prefix > deprecation, but has a suitable preferred home address (also registered) to > replace it. > > In the case of #1, you are pretty much hosed, IMHO it doesn't matter what > you do. So "soon" meaning 5 minutes to go before your home address expires, It is more likely to be a week than 5 minutes, and it makes sense for communication using the deprecated address to work during that week. (I can go to the office and get manually get SAs or certs for the new HoA for instance to be able to do home registrations for the new HoA, even if we don't come up with an automatic way of making this happen.) > However, I don't think you will be successful > getting anyone to add new message options, and there will be even likely be > some resistance to new BA status codes. The problem is that folks seem to be making incorrect assumptions about RFC 2462 and I'm trying to provide information to help the WG come up with a solution which is consistent with RFC 2462. Thus I don't care about a particular solution, but I do care that MIPv6 is not in conflict with RFC 2462 and the notion that addresses have preferred, depcrecated, and invalid states that need to be communicated to the MN when away from home the same way that RFC 2462 and DHCPv6 communicate this when the MN is at home. --------------------- Gabriel Montenegro responds to Ed Remmell: > You could change the verbage to say "pending prefix invalidation" > instead of "prefix deprecation" and that would perhaps be more > accurate, personally I'd be OK with that change: > > 1 Accepted with reduced lifetime due to pending prefix invalidation How about changing it to: 1 Accepted with reduced lifetime due to change in prefix information Notice that most of the time such a change will cause the HA to proactively send such info to the MN: http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#ha:renum-send At any rate, the MN obtains such prefix information and MUST process it (including preferred versus valid lifetimes in the Prefix Information option) as per: http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#mn:get-adv Do you, Erik, feel the above section is not enough? In this case, perhaps it is enough to mention that the MN's usage of its HoA should be consistent with autoconf (rfc2462) guidelines on preferred and valid prefix info? I'm hoping you'll suggest some text here. --------------------- Erik Nordmark responds to Gabriel Montenegro: > How about changing it to: > > 1 Accepted with reduced lifetime due to change in prefix information > > Notice that most of the time such a change will cause the HA to proactively > send such info to the MN: "change" is hard - doesn't it mean that the HA needs to know which is the last change that the MN has seen? What is the BAck is lost, etc. I was going to make a slightly different proposal which is light-weight. First of all the binding lifetime in the bind ack does not need to be limited by the remaining preferred or valid lifetimes of the prefix. But there are two new BAck codes: 1. Accepted but FYI the prefix is either deprecated or will become deprecated during the binding lifetime. 2. Accepted but FYI the prefix is either invalidated or will become invalidared during the binding lifetime. When the MN receives one of the above it might either conclude it isn't news (e.g. "I already know it is deprecated"). If it concludes it is news (i.e. it hasn't see that code for this HoA before) it will trigger MPS to determine the actual prefix preferred and valid lifetimes. Thus there is no "flood" of messages as the binding lifetime in the ACKs decrease (because it doesn't decrease), and the MN can track when the prefix becomes deprecated. If we want to reject bindings once a HoA prefix becomes invalid it would make sense to create a new error 139 The prefix for the home address is invalid (one could alternatively overload 132 for this perhaps...) --------------------- Gabriel Montenegro responds to Erik Nordmark: > "change" is hard - doesn't it mean that the HA needs to know which is > the last change that the MN has seen? What is the BAck is lost, etc. That's the point, that whatever this entails is already part of the draft, right:? From http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#ha:renum-send aka section 10.6.2: 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. The need to track changes on a per MN basis is specified in the third bullet. How often/when to retransmit, and up until when is already in the draft, right? Why not reduce the problem at hand to this one which is already done and agreed upon? Keeping track of changes is already there. If by some reason the HA doesn't get a chance of sending the unsolicited prefix info before it gets a chance to send a BAck with the "code 1: do prefix discovery" then by virtue of the MN's solitication, the first bullet above takes over and it's done. > I was going to make a slightly different proposal which is light-weight. > > First of all the binding lifetime in the bind ack does not need > to be limited by the remaining preferred or valid lifetimes of the > prefix. > > But there are two new BAck codes: > 1. Accepted but FYI the prefix is either deprecated or will become > deprecated during the binding lifetime. > 2. Accepted but FYI the prefix is either invalidated or will become > invalidared during the binding lifetime. > > When the MN receives one of the above it might either conclude it > isn't news (e.g. "I already know it is deprecated"). > If it concludes it is news (i.e. it hasn't see that code for this HoA > before) it will trigger MPS to determine the actual prefix preferred > and valid lifetimes. > > Thus there is no "flood" of messages as the binding lifetime in the ACKs > decrease (because it doesn't decrease), and the MN can track > when the prefix becomes deprecated. Although I'm not opposed to these 2 codes, I'd like to understand if we need them, of if, as I see it, we have already solved most of this problem and not realized it (as per my comments above). > If we want to reject bindings once a HoA prefix becomes invalid > it would make sense to create a new error > 139 The prefix for the home address is invalid > (one could alternatively overload 132 for this perhaps...) This would make sense (adding the explicit code) I think. --------------------- Erik Nordmark responds to Gabriel Montenegro: > Although I'm not opposed to these 2 codes, I'd like to understand > if we need them, of if, as I see it, we have already solved most of this > problem and not realized it (as per my comments above). Unless I've missed something the current proposed text still says that the binding lifetime is decremented based on the prefix lifetimes. This is problematic when it comes to the preferred lifetime approaching zero. --------------------- Ed Remmell responds to Gabriel Montenegro: I agree with Gabriel, we don't need these extra BA status codes IMO. Also, I do not think it is a good idea to add a new BA failure status code "139 The prefix for the home address is invalid" because: 1) Why should the home agent keep past history information on invalid prefixes? It is now invalid for use on that specific home network, why should it be tracked? 2) This "invalid" prefix has likely been reassigned and is valid somewhere else (i.e. on a different network). 3) What good is it for the MN to know that the reason why its registration request failed is because its home address is now invalid? How is that different from other types of registration failures? Does it contain any useful information that lets the MN recover? No - this is a hard failure, and can only be recovered from by reconfiguring the MN to use a different home address. 4) If the home address is invalid, then the IPsec security associations that the MN and HA use to protect the BU/BA exchange should also be invalid (since they are associated with the home address) - so, how can is it even possible for the MN to attempt to register the invalid home address in this case? Perhaps there could be some period of a couple of days or so when the home agent could "remember" the prefix invalidation and reflect this new status "139 The prefix for the home address is invalid" back to MNs that haven't been able to keep track of the prefix valid lifetime to know that it is invalid, assuming that my concern #4 above (IPsec interaction) is groundless, but I fail to see any significant advantage to requiring this extra complexity in the protocol and in the home agent. Please let's not add features if there isn't any significant reason to do so. > Unless I've missed something the current proposed text still says > that the binding lifetime is decremented based on the prefix lifetimes. > This is problematic when it comes to the preferred lifetime > approaching zero. The binding lifetime is bounded by the prefix valid lifetime, not by the prefix preferred lifetime. Per section 10.3.1 of the latest pre-21 draft: " o The lifetime for the Binding Cache entry MUST NOT be greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address specified with the Binding Update. The remaining valid lifetime for this prefix is determined by the home agent based on its own Prefix List entry for this prefix [12]. If the lifetime was reduced for this reason, the home agent MUST set the Status field to value 1 (Accepted with reduced lifetime due to prefix deprecation)." So, perhaps you meant to say "this is problematic when it comes to the valid lifetime approaching zero", that I would agree with. Assuming this is the case, I disagree with you, however, about what the MN behavior will typically be when the prefix is about to become invalid. Since the binding lifetime is bounded by the prefix valid lifetime (not the preferred lifetime), if the prefix still has 15 minutes left before it becomes invalid, when the MN registers a binding with the home agent for a home address with that prefix (assuming it requests a lifetime longer than the prefix valid lifetime) I would expect the home agent to send the BA with the actual binding lifetime being the prefix valid lifetime, i.e. 15 minutes. So, in this case the binding expires when the prefix expires. There is no extra traffic involved, except for the new MN behavior specified for this issue which has the MN commence Home Prefix Discovery upon receiving the BA with status = 1 (home prefix is currently deprecated), which should be the case here (i.e. with 15 minutes left for the prefix valid lifetime, the prefix should be deprecated by now, which causes the HA to return status=1 in the BA and then the MN SHOULD send the Mobile Prefix Solicitation message to the HA to rediscover its home prefixes and their associated lifetimes). I fail to see any significant benefit for the changes you are proposing, apart from increasing the complexity of the current draft. --------------------- Jari Arkko responds to Erik Nordmark: I plead guilty to confusing valid and preferred lifetimes in the current text. The text needs to get fixed. And yes, we need to align with what the ND RFCs are saying. Overall, in issue 243 we have a number of things that we have to worry about: 1. Flood of re-registrations to the home agent, trying to extend the lifetime "well before" it expires, in a situation where the lifetime is simply going to end. This was the initial reason why #243 discussion started. 2. Making sure mobile nodes can use both a deprecated and another, valid prefix while a renumbering is going on. This period may be long, such as a week. 3. Making sure the mobile node knows the current situation with respect to the lifetimes of the prefixes it uses. Before we start discussing how to fix things, I wanted to briefly mention how things are in the current (pre21) draft: 1. If we ignore the valid/preferred confusion for a moment, there's a mechanism in 11.7.1 that avoids repeated re-registrations: "... should send a new Binding Update to it well before the expiration of this period, even if it is not changing its primary care-of address. However, if the home agent returned a Binding Acknowledgement for the current registration with Status field set to 1, the mobile node should not try to register again before it has learned the validity of its home prefixes through prefix discovery." Remember also that 11.4.3 states PIs should be treated as in the ND RFCs, and that 11.7.1 states that the lifetime used should not exceed the lifetime of the prefix. 2. Deprecated/invalid distinction doesn't work well in the current draft. In particular: (a) The status code indicates deprecation while the lifetime reduction talks about invalidation. (b) If there's no invalidation yet, the current text does allow a warning to be sent about deprecation either. (c) 11.7.1 should be clearer about what lifetime of the prefix should not be exceeded. 3. If we again ignore the valid/preferred confusion then the mobile node is aware of the current lifetime situation through the status code and the prefix discovery that takes place afterwards. Several proposals have been made on how to fix things. Let's see if we can draw any conclusions: - The mobile node needs to be informed about deprecation as well as invalidation. - The mobile node needs to take in account the prefix lifetimes before insisting on additional lifetime for a registration. - The mobile node needs to apply the information about deprecation for source address selection. Note that we need to know not just that the prefix is going to be deprecated during the registration period, but also when. It seems there are the following types of solution proposals to avoid repeated re-registrations when the lifetime approaches zero: I. Don't reduce lifetimes in the home agent. (Erik) II. Reduce lifetimes, but provide a warning in the BA to the mobile node so that it doesn't try to re-register before it has the full picture. (pre21) Then we have some independent solutions for letting the mobile node know that it should consider the prefixes deprecated / invalid: III. Just wait for the next advertisement. (draft<19) IV. Provide a warning in the BA to the mobile node then mobile uses prefix discovery. (Erik) V. Return the actual remaining preferred and valid lifetimes in the BA. (one discussed alternative) Finally, we have solutions for allowing both deprecated and preferred prefixes to co-exist: VI. Allow bindings even when they are for a deprecated address (Erik). VII. Home agent disallows registrations of deprecated addresses.(one interpretation of pre21) What should we do then? Solution VI seems clearly preferrable over VII. I'd rather not duplicate prefix discovery functionality so I'd like to avoid solution V, and for the purposes of ensuring robustness, the warning approach in IV is probably better than just relying on the advertisements to always get through even under some strange condition which requires fast changes in the prefix information. Solution II seems to fit togethet with IV better than I. Furthermore, I think that making the home agent capable of keeping registrations on invalid prefixes could get us into trouble later. So my prosal for a solution is roughly the following: - Reduce returned lifetimes to the valid lifetime of the prefix. - If the prefix will become deprecated during the returned lifetime, issue a warning to the mobile node about this in a BA. - If the prefix will become invalid during the returned lifetime or precisely at its end, issue also a warning. - If the mobile has gotten either type of a warning, it needs to do prefix discovery. - If the mobile has gotten either type of a warning, it should not try to re-register until it knows the results of the prefix discovery. - The mobile should not request longer binding lifetime than the known valid lifetime of the prefix is. If you look at the above rules, you will see that the type of the warning really makes no difference. That is, one status code is sufficient as it will always just lead to doing prefix discovery to find out more. However, compared to the pre21 draft there's a significant difference: the lifetime reduction and the warning must be decoupled. If they are not decoupled, then we either can't use deprecated addresses at all, or we need multiple status codes to warn about preferred/valid lifetimes. If this approach is acceptable to all, the text changes would be as follows: - Section 6.1.8 will have a status code "1 Accepted but prefix discovery necessary". - Delete 10.3.1 text about the use of the status code 1. Instead, the following paragraph will defined what value to put in the BA: The Status field MUST be set to a value indicating success. The value 1 (accepted but prefix discovery necessary) MUST be used if the subnet prefix of the specified home address is deprecated, becomes deprecated during the lifetime of the binding, or becomes invalid at the end of the lifetime. The value 0 MUST be used otherwise. For the purposes of comparing the binding and prefix lifetimes, the prefix lifetimes are first converted units of four seconds by ignoring the two least significant bits. - Keep the 11.7.1 text about re-registration when status code 1 has been received. - Keep the 11.4.3 statement that PIs should be treated as in the ND RFCs. - Change the 11.7.1 statement about the lifetime to use in BUs to "...less than or equal to the remaining *valid* lifetime ... " I belive this should be sufficient. Note also one thing: I did not specify anything about the mobile node skipping PD if it already knew about the change. This is because knowing that the deprecation will occur at a time T does not imply that the next time we register it is still going to happen at that time. It could well be that the home network uses short preferred lifetimes, and a long lifetime would overlap with that; the mobile node performs prefix discovery and learns that there's still a long time until this actually happens. But later something happens and the home network is now scheduling the deprecation to occur sooner. The scheme above is robust against such changes, but implies that mobile nodes are likely to do prefix discovery after every movement during the transition period. --------------------- Erik Nordmark responds to Jari Arkko: > I. Don't reduce lifetimes in the home agent. (Erik) > II. Reduce lifetimes, but provide a warning in the BA to the > mobile node so that it doesn't try to re-register > before it has the full picture. (pre21) With the preferred/valid lifetime clarifications II would work. > Then we have some independent solutions for letting > the mobile node know that it should consider the > prefixes deprecated / invalid: > > III. Just wait for the next advertisement. (draft<19) > > IV. Provide a warning in the BA to the mobile node > then mobile uses prefix discovery. (Erik) > > V. Return the actual remaining preferred and valid > lifetimes in the BA. (one discussed alternative) There is also the option of the single warning message - I suggested two different messages (which don't seem to be required). > Finally, we have solutions for allowing both deprecated > and preferred prefixes to co-exist: > > VI. Allow bindings even when they are for a deprecated > address (Erik). > > VII. Home agent disallows registrations of deprecated > addresses.(one interpretation of pre21) VII is a non-starter. The MN needs to be able to continue to receive and send packets using the deprecated address until the address becomes invalid. > So my prosal for a solution is roughly > the following: > > - Reduce returned lifetimes to the valid lifetime of the > prefix. > - If the prefix will become deprecated during the returned > lifetime, issue a warning to the mobile node about this in a BA. > - If the prefix will become invalid during the returned > lifetime or precisely at its end, issue also a warning. > - If the mobile has gotten either type of a warning, > it needs to do prefix discovery. > - If the mobile has gotten either type of a warning, > it should not try to re-register until it knows > the results of the prefix discovery. > - The mobile should not request longer binding lifetime > than the known valid lifetime of the prefix is. As well as fixing what you listed above as VII in order to allow registrations of deprecated addresses. Does clarifying that require any text changes? > - Delete 10.3.1 text about the use of the status code 1. > Instead, the following paragraph will defined what value > to put in the BA: > > The Status field MUST be set to a value indicating success. > The value 1 (accepted but prefix discovery necessary) MUST > be used if the subnet prefix of the specified home address > is deprecated, becomes deprecated during the lifetime of > the binding, or becomes invalid at the end of the lifetime. > The value 0 MUST be used otherwise. For the purposes of > comparing the binding and prefix lifetimes, the prefix lifetimes > are first converted units of four seconds by ignoring the > two least significant bits. I have a question about the "is deprecated" above. Does this mean that during the week of deprecation every BAck for the deprecated address will have code 1? That will make the MN do a prefix discovery for every BU/BAck to home (every 5 minutes?) even though the deprecated status has not changed. But I guess there isn't a choice unless you add more status codes to the BAck. --------------------- Jari Arkko responds to Erik Nordmark: > VII is a non-starter. The MN needs to be able to continue to > receive and send packets using the deprecated address until the > address becomes invalid. Agreed. Just provided in the list for completeness... > > So my prosal for a solution is roughly > > the following: > > > > - Reduce returned lifetimes to the valid lifetime of the > > prefix. > > - If the prefix will become deprecated during the returned > > lifetime, issue a warning to the mobile node about this in a BA. > > - If the prefix will become invalid during the returned > > lifetime or precisely at its end, issue also a warning. > > - If the mobile has gotten either type of a warning, > > it needs to do prefix discovery. > > - If the mobile has gotten either type of a warning, > > it should not try to re-register until it knows > > the results of the prefix discovery. > > - The mobile should not request longer binding lifetime > > than the known valid lifetime of the prefix is. > > As well as fixing what you listed above as VII in order to allow I wanted to pick VI, i.e. your solution that allows deprecated addresses to be registered, not VII. > registrations of deprecated addresses. Does clarifying that require > any text changes? I don't think so. Here's what the current 10.3.1 says: o The lifetime for the Binding Cache entry MUST NOT be greater that the remaining valid lifetime for the subnet prefix ... > I have a question about the "is deprecated" above. > Does this mean that during the week of deprecation every BAck for the > deprecated address will have code 1? That will make the MN do a prefix > discovery for every BU/BAck to home (every 5 minutes?) even though the > deprecated status has not changed. Thats right. Well, the requirement to do prefix discovery is a SHOULD... Btw, home registrations can be longer than 5 minutes, but the actual times depend on movement frequency. This isn't really optimal. But I was trying to avoid a situation where the mobile node registers with a lifetime of, say, 1 day, and the home network is keeping the preferred lifetimes per policy at 12 hours. Then suddenly one of the prefixes changes status and will be deprecated soon, say in 10 minutes. If the mobile node trusts the previous results of pefix discovery, it could happily go on thinking that the deprecation is still hours away. On the other hand, as Gabriel noted the home agents *do* know when changes in the prefix information have occurred so in theory they could given the Status code 1 only once after a change... I don't know what to do. I guess the alternatives are: * Forget it, we shouldn't be optimizing renumbering... * Add a clause to the text about the changes (but then the BU processing code needs to interface with the piece that remembers changes in prefixes) * Allow the mobile node to remember the previous prefix discovery results, but rely on unsolicited MPAs to tell you about the changes. --------------------- Erik Nordmark responds to Jari Arkko: > I don't think so. Here's what the current 10.3.1 says: > > o The lifetime for the Binding Cache entry MUST NOT be > greater that the remaining valid lifetime for the subnet > prefix ... Since there has been some confusion about valid vs. preferred lifetime it might not be a completely bad idea to add that The remaining preferred lifetime SHOULD NOT have any impact on the lifetime for the binding cache entry. > I don't know what to do. I guess the alternatives are: > > * Forget it, we shouldn't be optimizing renumbering... > * Add a clause to the text about the changes (but then the BU > processing code needs to interface with the piece that remembers > changes in prefixes) > * Allow the mobile node to remember the previous prefix discovery > results, but rely on unsolicited MPAs to tell you about the changes. I'm fine with either one. Since we've solved the ever shorter lifetimes when the prefeered lifetime approaches zero I think the first of the above is ok. It wouldn't hurt to point out that the expected behavior is a prefix discovery per BU once the prefix is deprecated. --------------------- Jari Arkko responds to Erik Nordmark: > Since there has been some confusion about valid vs. preferred lifetime > it might not be a completely bad idea to add that > The remaining preferred lifetime SHOULD NOT have any impact > on the lifetime for the binding cache entry. Ok. >>I don't know what to do. I guess the alternatives are: >> >> * Forget it, we shouldn't be optimizing renumbering... >> * Add a clause to the text about the changes (but then the BU >> processing code needs to interface with the piece that remembers >> changes in prefixes) >> * Allow the mobile node to remember the previous prefix discovery >> results, but rely on unsolicited MPAs to tell you about the changes. > > > I'm fine with either one. > Since we've solved the ever shorter lifetimes when the prefeered > lifetime approaches zero I think the first of the above > is ok. > It wouldn't hurt to point out that the expected behavior > is a prefix discovery per BU once the prefix is deprecated. Ok. I added this text to Section 11.7.1: "... This is typically necessary every time this Status value is received, because information learned through prefix discovery on an earlier registration may have changed." Note that the text is formulated in a rather soft manner. This may be appropriate given that we don't have much practical experience yet from renumbering with mobility. --------------------- --------------------- --------------------- --------------------- --------------------- ---------------------