Subject: [mobile-ip] Mipv6 issue #243: Renewing registrations when lifetime approaches zero

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Feb 2003 13:31:58 +0200

Folks,

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.

The text changes for the above approach are given below.
Are they OK? Comments appreciated.

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.

Jari

---

From: Brian Haley <[email-masked]>
Date: Fri, 14 Feb 2003 10:52:43 -0500

Hi Jari,

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...

-Brian

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 14 Feb 2003 09:22:40 -0800

Brian & Jari -

> 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
>

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."

>     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."

> 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.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 14 Feb 2003 09:36:48 -0800

> says "I would like to do as few changes as possible since we are already

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.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: Brian Haley <[email-masked]>
Date: Fri, 14 Feb 2003 13:43:33 -0500

> that case, the CN/HA always has to send the BA anyways, so there is no

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.

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Feb 2003 21:21:21 +0200

Re: changes to the CN section. Strictly speaking, the status code
#2 isn't absolutely required even in the proposal I had. I was
just put the for consistency. But 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.

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 14 Feb 2003 15:07:53 -0800

Jari -

I'm OK with you adding just a single new BA status code to the CN/HA:

This avoids making changes to the CN. This simplifies your earlier proposed
text changes to:

       ...

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.

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.

Thanks.
- Ed Remmell
Elmic Systems, USA

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: Friday, February 14, 2003 11:21 AM
> To: Brian Haley
> Cc: Ed Remmell; Erik Nordmark; Gabriel Montenegro; Vijay Devarapalli;
> [email-masked]
> Subject: Re: [mobile-ip] Mipv6 issue #243: Renewing registrations when
> lifetime approacheszero
>
>

---

From: gabriel montenegro <[email-masked]>
Date: Sat, 15 Feb 2003 01:02:40 +0100

This looks good, yes, the single added BA status code.

-gabriel

---

From: Brian Haley <[email-masked]>
Date: Tue, 18 Feb 2003 00:37:15 -0500

I would be ok with this.

-Brian

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 10:53:04 +0100 (CET)

>        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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 10:59:48 +0100 (CET)

>     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.

  Erik

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 20 Feb 2003 10:08:31 -0800

Erik -

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.

Thanks.
- Ed Remmell
Elmic Systems, USA

> [mailto:[email-masked]]On Behalf Of Erik Nordmark
> Sent: Thursday, February 20, 2003 1:53 AM
> To: Jari Arkko
> Cc: Erik Nordmark; Gabriel Montenegro; Vijay Devarapalli;
> [email-masked]'
> Subject: [mobile-ip] Re: Mipv6 issue #243: Renewing registrations when
> lifetime approaches zero
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 19:52:14 +0100 (CET)

> "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 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.

  Erik

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 20 Feb 2003 12:49:27 -0800

Erik -

I'm just trying to help, since I was in context of this issue and felt you
deserved a response.

> when in fact they are two completely different things. Please see

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.

> prefix is deprecated for a long time (measured in days or weeks) before

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.

> 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...

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: Brian Haley <[email-masked]>
Date: Thu, 20 Feb 2003 17:00:17 -0500

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).

-Brian

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 10:09:40 +0100 (CET)

> 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?)

> 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
> 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
> 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

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.

> 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

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.

   Erik

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 21 Feb 2003 10:33:03 +0100

Ed Remmell wrote:
> You could change the verbage to say "pending

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.

-gabriel

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 16:52:54 +0100 (CET)

> 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...)

  Erik

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 21 Feb 2003 17:48:16 +0100

> 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.

> 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).

> (one could alternatively overload 132 for this perhaps...)

This would make sense (adding the explicit code) I think.

-gabriel

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 17:51:02 +0100 (CET)

> 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.

  Erik

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 21 Feb 2003 09:36:33 -0800

Erik -

> > problem and not realized it (as per my comments above).

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.

> This is problematic when it comes to the preferred lifetime

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.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: Jari Arkko <[email-masked]>
Date: Sun, 23 Feb 2003 15:29:44 +0200

Erik,

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.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Feb 2003 16:25:26 +0100 (CET)

>       before it has the full picture. (pre21)

With the preferred/valid lifetime clarifications II would work.

>       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).

>       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:
> 

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?

>        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.

 Erik

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Feb 2003 23:31:11 +0200

> receive and send packets using the deprecated address until the

Agreed. Just provided in the list for completeness...

> 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

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 ...

> 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.

Jari

---

From: Cedric Westphal <[email-masked]>
Date: Mon, 24 Feb 2003 15:24:06 -0800

Sorry if you receive multiple copies of this.

Here is the call for papers for ASWN 2003, that might

interest some of the people on this list. Bern is very scenic

in the summer, fwiw.

ASWN 2003 is the third workshop on Applications and Services in Wireless
Networks. The
first two events were held in France, and in 2003 the workshop will
take place in the capital of
Switzerland. ASWN 2003 aims at investigating new developments in wireless
networks focusing on applications and services. The workshop will provide
three-day presentations of invited and regular papers from manufacturers,
academia, and services providers. Authors are invited to submit full technical
papers on both theoretical and practical aspects of the ambit of the workshop.Tutorial
proposals are also requested.

Topics

Specific areas of interest in Applications and Services on Wireless Networks
include, but are not limited to, the following topics:

Media Distribution over Wireless Networks

New Data Services for Wireless Network

Audio-visual Applications for Home and Business

Inter Domain and Inter System Mobility

QoS Profiling and Pricing, end-to-end QoS

Security and AAA Aspects

Nomadic Services, Interface Management

Mobile ad-hoc Networks, Multihop Wireless Networks

Wireless Local Loop Technologies

Wireless Personal Area Networks

Software Radios

Enabling Technologies and Architectures, 3G and beyond

Service Development, Validation & Test

Service Creation and Discovery

Location-based Services

Middleware for Mobile Applications and Services

Mobile Multimedia

Performance of Mobile/Wireless Networks and Systems

Mobile Service Interworking

Context and Ambient Awareness

Cooperative Networks

Papers

Prospective authors are invited to submit for review, papers that neither
have been previously published nor are under review by another conference
or journal. Priority will be given for original contributions describing
recent and innovative research results or developments in the scope of the
workshop.

Papers must be written in English in two-column format, using font no smaller
than 10 points and not exceed 10 pages. Only PDF and PostScript formats
will be accepted, and all submissions will be handled electronically. Further
details on submission procedures will be described soon on the workshop
main page as Instructions
for submission

Tutorials

Proposals for tutorials including content description and CV of the presenter
should be sent to the Local Arrangements Chair.

Publications

Accepted papers will be published in the conference proceedings. Additionally,
the best papers of the workshop will be considered for publication in a special
issue of Elsevier's Computer
Communications Journal.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Feb 2003 12:37:52 +0100 (CET)

>        greater that the remaining valid lifetime for the subnet

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.

>      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.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Tue, 25 Feb 2003 14:40:08 +0200

> 	on the lifetime for the binding cache entry.

Ok.

> 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.

Jari