Subject: [mobile-ip] Mobile Prefix Advertisement Interval -- let's update it.

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 25 Sep 2002 12:05:09 -0700

Hi everyone,

There have been a few questions about the Mobile Prefix Advertisement
definition in terms of how often MPAs should be sent to mobile nodes. So, I
would like to write this e-mail to summarize the current situation and suggest
some easy improvements and fixes. I apologize in advance if the message is a
bit long.

Since we re-wrote Tunneled Router Advertisements into Mobile Prefix
Advertisements in order to simplify things, some things have changed in the
draft. Most notably, security procedures have been vastly improved, exposing
many smaller questions about how to secure messages, MPAs included. We have
also had some implementation experience from our group and one or two others,
who have implemented MPS/MPA and seen some potential improvements.

First of all, let's review why MPAs are needed. The requirement is two-fold:

1. Support the MN configuring all of the addresses it would have in the home
link (since this is a MIP design philosophy).
1a. A subset of this goal is to support the "bootstrapping" procedure for a
mobile node to configure its home address. So the MPA must contain enough info
for this to happen.

2. Renumbering. The MPA must allow a MN which is away from home, but registered
during the renumbering period, to get prefix info about the new prefix it
should start using and info to deprecate the old one.

So for task {1}, there are certain times that the MN must receive prefix info:

{1}A. After the MN establishes a binding, it should receive all of the prefix
info. (I.e. not at every BU, but just the first one that creates a BCE).
{1}B. When a prefix changes that is on the link of the MN's home addr, the MN
should be sent an MPA with at least that changed prefix info.

The Router Advertisement is sent periodically because it's impossible to tell
who is on the home link. However, the HA always knows which MNs are roaming, so
the rules for {1} are easy and there is no periodicity, per se. However, since
the MPAs are unguaranteed ICMP messages, we should introduce another rule for
periodic transmission, called {1}C. Sending this every 1.5s is too often, but
perhaps a retransmission interval of MIN(RtrAdvInterval,
Some_Constant_Like_15s) might be OK.

{1}C. Retransmit the full list every MIN(HomeRtrAdvInterval, 15s) - optional?

For task {1a}, people have made suggestions on the list that this info might be
insecure, since there may not be an SA between the MN and HA. It was commented
that perhaps we can use some form of Dynamic Home Agent Discovery or Secure DNS
to construct at least one home address, set up a binding, and then get the rest
of the prefixes. I like this idea, since it could make a shorter path to
establish the SA, and then we could proceed with the rules for case {1}.

For task {2}, we assume that task {1} is already complete, and there is a
current binding. So this case really falls into a special case of {1}B, with
the requirement that {1}C (retransmissions) also occurs, at least until a new
BU is received. In fact, the MPA can be sent with a Binding Request, as
specified.

So in summary, it might ease implementation if, at some convenient point, we
streamline the rules further according to what is outlined above. Of course
this does not address the issue of how to build the list of prefixes, which
might also be improved after there is more interop testing and more
implementations.

How do other implementors feel about these refinements?

-TJ

And P.S., if you, gentle reader, have actually *implemented* MPAs, or are in
the process of doing so, please send me an e-mail.

-- 
        T.J. Kniveton 
   Communication Systems Lab
     Nokia Research Center

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 25 Sep 2002 15:59:12 -0400

T.J.

One question

> {1}C. Retransmit the full list every MIN(HomeRtrAdvInterval, 15s) - optional?

The way I underestood the above is that there is no upper limit
to the retransmissions, i.e every ~15s the HA will send the
Prefix Adv.

Was that the intent?

-vlad
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 25 Sep 2002 14:26:54 -0700

> to the retransmissions, i.e every ~15s the HA will send the

The intent is to give a minimum threshold so that the MPA will not be sent
overly often, especially over a resource-constrained link. So if the
HomeRtrAdvInterval is less than the threshold, the HA will just hold off on
sending an MPA.

-TJ

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 25 Sep 2002 17:48:40 -0400

> HomeRtrAdvInterval is less than the threshold, the HA will just hold off on

But that's not was it looks like we get.  The default HomeRtrAdvInterval is
3600s.  So unless the default is changed, you'll be sending full MPAs to
all mobile nodes every 15s (according to the MIN in your rule).  I don't
think you want to do that.

Also, rereading the draft, it looks like there is already a retransmission
with exponential backoff time specified for unsolicited MPAs.

-vlad

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 25 Sep 2002 17:02:04 -0700

> with exponential backoff time specified for unsolicited MPAs.

Ah, I see your point. I meant to have a minimum interval, which would mean a
MAX() of the interval and a specified amount. But the MPA spec as it stands,
should be OK for this. We have an interval specified of 10 minutes as you point
out.

There is also a randomized delay (up to 1,000 seconds) so that when prefix info
changes, not all MPAs are sent out at once. But that's a bit different than an
exponential backoff, and since there is no ACK/NAK for these, it wouldn't be
possible to "back off" anyway. So the periodic announcements would seem to
occur every 10min+ (and are optional). This still seems OK to me.

-TJ

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 25 Sep 2002 17:04:14 -0700

> with exponential backoff time specified for unsolicited MPAs.

Doh! I forgot about the exponential backoff and hit "send" too fast. :) You are
right about that!

-TJ