Subject: Re: [mobile-ip] Mipv6 issue #179: Prefix distribution and DHAAD problems

From: Jari Arkko <[email-masked]>
Date: Mon, 03 Feb 2003 17:59:39 +0200

Jari Arkko wrote:
> Erik Nordmark wrote:
> 
>> 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)
> 
> 
> 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.

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

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 03 Feb 2003 12:03:10 -0800

Jari,

I think we are using MUST and SHOULD where they need not be 
used. instead lower case letters should be used.

>      I also changed the original MUST to a SHOULD.

we are describing the basic protocol behaviour. wouldnt it be
better if the text is 
   
   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 is not a optinal feature we are describing it, right?
if the MN wants the services of the HA to continue it has
to renew the binding. 

>       extend the registration period."

as far as the issue is concerned, I agree with your proposal.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Mon, 03 Feb 2003 22:53:44 +0200

> used. instead lower case letters should be used.

Ok.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 3 Feb 2003 21:58:07 +0100 (CET)

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

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

  Erik

   Erik

---

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Feb 2003 00:20:54 +0200

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

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

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

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 5 Feb 2003 14:35:14 +0100 (CET)

> don't remove the main problem. If so, are they worth the

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 05 Feb 2003 16:26:43 +0200

> in order to let the MN start using a new HoA without manual out-of-band 

This is true.

> discovery is an important piece, but I can't yet say that it is.

For dynamically established security associations, it seems rather
easy to take in account new prefixes: new SPD entries need to be
added but that's it. But yes, this isn't described in the current
specification.

> becomining invalid something that can be done just looking at the BAck.

So your advice is to put the information in the back? And what should
we do with the prefix discovery?

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 6 Feb 2003 19:43:47 +0100 (CET)

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

  Erik

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 07 Feb 2003 17:17:06 +0100

> 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

-gabriel

---

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

>   "your BU is ok, but the lifetime was reduced by prefix lifetime"

Works for me.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Feb 2003 09:30:02 +0100 (CET)

>    "your BU is ok, but the lifetime was reduced by prefix lifetime"

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.

  Erik

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 11 Feb 2003 11:15:17 +0100

> 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

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.

-gabriel

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Feb 2003 13:32:04 +0100 (CET)

> have a choice and it must implement prefix discovery...)

That's been my point.
Either we mandate prefix discovery on the MN (so that it can discover
when one of its HoAs is deprecated) or we add this information through some
new option in the BAck.

> to make this usable, the MN will need dynamic keying.

I can imagine ways to re-provision a MN using HTTP+SSL+password
so that it can establish a SA for a new HoA.
Yes, having an IETF standard for doing this type of thing would make
sense, but IKE itself doesn't address how to bind the authority to 
issue BUs for HoA1 to also be able to issue BUs for HoA2.
Being able to do this explicitly makes sense for renumbering as
well as RFC 3041 temporary HoAs.

> as documented in issue 232 ("DHAAD is feeping creaturism?").

What does DHAAD have to do with a prefix being deprecated?
Are you thinking about the end of the renumbering event when the MN
needs to start using the new address of the HA?
DHAAD doesn't really help with that since DHAAD assumes that the home
link prefix(es) are fixed and that isn't the true for a renumbering event.
To handle re-provisioning across a renumbering event the MN needs
to have some stable ID for its home. A domain name seems to make sense
since it can be kept stable across the home link renumbering event.

Thus being able to invoke a (re-)provisioning protocol to
ha.myisp.net and presenting the credentials for "[email-masked]"
could result in the MN being told about its home prefix, HAs, and result
in some binding between some secret the MN holds and the authorization to
do BUs for that HoA. Such a protocol (yet to be defined)
would solve the renumering problem.
But it doesn't solve how the MN knows when a given prefix/HoA becomes 
deprecated.
Do we want to mandate prefix discovery for the sole useful purpose of
determining when a HoA becomes deprecated? (and later invalid and useless)

> But, I'm not sure I agree with taking out all that stuff.

I'm not arguing for removing prefix discovery and DHAAD.
I'm merely arguing that we should think about being able to do the things
we know how to do (that doesn't require establishing/retargeting SAs)
without needing prefix discovery or DHAAD.

> to make prefix discovery mandatory.

Oops.
But the above bullet seems to be specifically about changing the HoA
and not about making the preferred/deprecated status be a function
of the prefix information.
Changing it to say
    o  The node MUST support receiving Mobile Prefix Advertisements           
  
       (Section 11.4.3) and configuring its home address(es) and home
prefix(es)
       according to the valid and preferred lifetimes per RFC 2462.
would make this a bit more explicit.

  Erik