Subject: [MOBILE-IP] How Mobile IPv6 should handle home network renumbering

From: Charlie Perkins <[email-masked]>
Date: Fri, 3 Nov 2000 17:04:08 -0800

Hello everyone,

I'm forwarding to these lists some text supplied by Ken
Powell for updating relevant sections of the Mobile IPv6
draft.  I find that Ken's proposed modifications are
quite reasonable and answer many outstanding open issues.
In subsequent messages, I will elaborate on some details
about _when_ a home agent should send new prefix information
to the mobile node.  However, I thought it would be easiest
to reproduce Ken's original message in its entirety, so as
not to disrupt a very coherent presentation.

Regards,
Charlie P.

PS. It's taken me a week to study the material in Ken's
    message, as well as related messages from other people.
    Sorry for the additional delay.

-------- Original Message --------
Date: Fri, 3 Nov 2000 13:05:40 -0800 (PST)
From: Charles Perkins <[email-masked]>
To: [email-masked]

From:   Powell, Ken
Sent:   Friday, October 27, 2000 5:05 PM
To:     [email-masked]'
Cc:     [email-masked]'; Bound, Jim
Subject:        Mobile IPv6 contributions

Hi Charlie,

A few weeks ago you asked if I could provide any text for
the Mobile IPv6 Spec regarding the issues we discussed.
I apologize for the delay, but hope the following may still
be relevant to your planned changes. The areas covered are:

  1) How the home agent constructs an aggregate list
     of prefixes advertised by other routers on the
     home network.

  2) What triggers a home agent to send router
     advertisements to a mobile node, and what
     prefixes should be included in each advertisement.
     I primarily added aggregate list references and
     periodic transmission of all prefixes to the
     existing text. I believe you also mentioned
     using binding updates as a mechanism to rate-
     limit Router Advertisements, so I added that too.

  3) When and how to send a router solicitation from
     a mobile node to the home agent.

  4) How to receive a router solicitation from
     a mobile node to the home agent.

One other thought, my text uses a new configuration
variable to control the timing of periodic router
advertisements to mobile nodes called MobileRtrAdvInterval.
Such a variable could reasonably default to a relatively
long period of time, like an hour or more, but otherwise
work much like MaxRtrAdvInterval in the ND spec. I wasn't
sure how to introduce this.

I hope this text is helpful. Feel free to use, rewrite, cut,
as it makes sense. You're also welcome to forward this off to
the ipng or mobilip mailing lists if you like. Let me know
if you have any questions/concerns.

Ken

Item 1 (perhaps add into section 9.7)
=====================================

A mobile node on a remote network should autoconfigure the
same set of home addresses it would autoconfigure if it
were attached to the home network. To support this, the
home agent monitors prefixes advertised by other routers
on the home subnet and passes the aggregate list of
home subnet prefixes on to the mobile node in Router
Advertisements.

The home agent SHOULD construct the aggregate list of home
subnet prefixes as follows:

  o Copy prefix information defined in the home agent's
    AdvPrefixList on the home subnet's interfaces to the
    aggregate list. Also apply any changes made to the
    AdvPrefixList on the home agent to the aggregate list.

  o Check valid prefixes received in Router Advertisements
    from the home network for consistency with the home
    agent's AdvPrefixList per section 6.2.7 of RFC 2461 (ND).
    Do not update the aggregate list with any information
    from received prefixes that fail this check.

  o Add valid prefixes received in Router Advertisements
    from the home network that are not yet in the aggregate
    list to the aggregate list along with the value of their
    L and A flags. Clear the R flag and zero the interface
    id portion of the prefix field to prevent mobile
    nodes from treating another router's interface address
    as belonging to the home agent. Treat the lifetimes
    of these prefixes as "deprecating".

  o Do not perform consistency checks on valid prefixes
    received in Router Advertisements on the home network
    that do not exist in the home agent's AdvPrefixList.
    Instead, if the prefixes already exist in the aggregate
    list, update the prefix lifetime fields in the aggregate
    list according to the rules specified for hosts in
    section 6.3.4 of RFC 2461 (ND) and section 5.5.3 of
    RFC 2462 (stateless adderconf).

  o If the L or A flag is set on valid prefixes received in
    a Router Advertisement, and that prefix already exists
    in the aggregate list, set the corresponding flag in
    the aggregate list. Ignore the received L or A flag if
    it is clear.

  o Ignore the R flag and interface id portion of any
    prefix received in a Router Advertisement.

  o Delete prefixes from the aggregate list when
    their valid lifetimes expire. (***Did the
    group agree to keep advertising these prefixes
    for a period of time with a zero lifetime? **)

Item 2 (perhaps replace similar text in section 9.7)
====================================================

A home agent serving a mobile node SHOULD construct and
tunnel to the mobile node a new Router Advertisement when
any of the following conditions occur:

  o A valid or preferred lifetime of a prefix in the
    aggregate list of prefixes is suddenly reduced to
    less than HomeRtrAdvInterval.

  o The state of the flags for a prefix in the aggregate
    list changes.

  o A new prefix is created in the aggregate list.

The home agent constructs a new Router Advertisement message
containing no options other than the Prefix Information options
describing the prefixes for which one of the conditions above
has occurred since the last Router Advertisement tunneled to and
acknowledged by the mobile node.

In addition, the home agent MUST send a router advertisement
with all prefixes in the aggregate list to the mobile node at
least once per HomeRtrAdvInterval and upon receipt of a valid
Router Solicitation from the mobile node.

The home agent MAY (SHOULD?) rate limit the frequency at which it
sends Router Advertisements to the mobile node by delaying transmission
until receipt of a Binding Update option from the mobile node.
When multiple conditions occur at or near the same time, the
home agent SHOULD attempt to combine them into a single Router
Advertisement message to the mobile node.

Item 3
======

10.x Sending Router Solicitations to a Home Agent

A mobile node that uses stateless address auto configuration on
its home subnet could miss significant home subnet configuration
changes while disconnected. Such a mobile node MAY request updated
prefix information when it detects a possibility that its current
home subnet address information is inaccurate by sending a Router
Solicitation to the home agent. The mobile node must construct
such a Router Solicitation packet as follows:

 -  The Source Address in the packet's IPv6 header MUST be set
    to the mobile node's primary care-of address.

 -  The packet MUST be protected by IPsec [13, 11, 12] to guard
    against malicious Router Solicitations.  The IPsec protection
    MUST provide sender authentication, data integrity protection,
    and replay protection, covering the Router Solicitation.

 - The packet MUST include a Home Address destination option,
   giving the mobile node's home address for its current
   binding.

 - The packet MUST include a Binding Update destination option
   as described in section 10.6 if a current binding does not
   yet exist. Otherwise, it MAY include a Binding Update
   destination option.

 - The Router Solicitation's source link-layer address
   option MUST be omitted.

Item 4
======

6.x Receiving Router Solicitations from Mobile Nodes

Section xx describes how a mobile node on a remote network
may send a Router Solicitation to a home agent to request
all current address prefix information on the home subnet.

The Router Solicitation may include a Binding Update
destination option. The processing requirements described
here for the Router Solicitation assume the Binding Update
destination option was processed first. The home agent MAY
return a single packet containing both the resulting Binding
Acknowledgment destination option and a Router Advertisement.

When a home agent receives a Router Solicitation from a mobile
node on a remote network, it MUST validate it according to the
following tests:

 - A home registration binding cache entry exists for the
   mobile node.

 - The Source Address of the IP packet carrying the Router
   Solicitation is the same as the primary care-of address
   for the mobile node.

 - The Home Address destination option contains the same
   address as the home address specified in the binding cache
   entry for the mobile node.

 - The packet is protected by IPsec [13, 11, 12] to guard
   against malicious Router Advertisements.  The IPsec protection
   provides sender authentication, data integrity protection,
   and replay protection, covering the Router Advertisement.

Any received tunneled Router Solicitation not meeting all of
these tests MUST be silently discarded.

If a received tunneled Router Solicitation is not discarded
according to the tests listed above, the home agent MUST
generate and tunnel to the mobile node as described in
section 6.7 a set of Router Advertisement(s) which combined
contain all entries in the aggregate list of prefixes for
the mobile node's home network.

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 3 Nov 2000 17:40:03 -0800

Hello again,

In Ken's note, a proposal is made for how the home agent
should forward relevant router advertisement information to
the mobile node, when the mobile node is away from its
home network.

I have devised an algorithm by which a home agent can
delay the transmission of this information to the mobile
node, in hopes that the actual transmission can be avoided
entirely if the mobile node might send a Binding Update
to the home agent.  In that case, the home agent could
include all the relevant information in the Binding
Acknowledgement.

Item 2 is "What triggers a home agent to send router"

> Item 2 (perhaps replace similar text in section 9.7)

Instead of a specific rate-limiting feature, I suggest the following
algorithm:

===== How to send router advertisements to mobile nodes.

- If a mobile node sends a solicitation, answer with everything.

- If a prefix changes state in a way that causes a mobile node's
  address to go deprecated, send an advertisement right away.

- If the mobile node's binding expires before the advertised
  Preferred Lifetime, do not schedule the advertisement.
  The mobile node will get the revised information in its next
  Binding Acknowledgement.

- If a prefix is added, or if it changes in any way that does not
  cause the mobile node's address to go deprecated, ensure that
  a transmission is scheduled at time RAND_ADV_DELAY in the future.

- If a prefix advertisement is scheduled, and a Binding
  Update arrives, perform that advertisement and include
  the information in a Router Advertisement that has the
  Binding Acknowledgement as a Destination Option.  Remove
  the future scheduled advertisement.

===== How to compute RAND_ADV_DELAY, the offset from the
      current time for the scheduled transmission

If there is a transmission already scheduled, then
 if the current RAND_ADV_DELAY would cause another
 transmission BEFORE the Preferred Lifetime of the
 mobile node's home address derived from the prefix
 whose advertisement information has changed, then
               add the new information to be transmitted
               to the existing scheduled transmission
               -- return.
          otherwise,
               continue with the following computation,
               and add the data from the existing scheduled
               transmission to the newly scheduled transmission,
              deleting the previously scheduled transmission
               event.

If the mobile node's binding expires after the Preferred
Lifetime, then compute
           MAX_SCHEDULE_DELAY ==
                     min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
for the newly advertised Preferred Lifetime.
Then compute RAND_ADV_DELAY =
             MinRtrAdvInt + rand()*{MAX_SCHEDULE_DELAY - MinRtrAdvInt}

===================================================

Regards,
Charlie P.

---

From: Mattias Pettersson <[email-masked]>
Date: Mon, 6 Nov 2000 16:36:04 +0100

Hi,

Francis wrote in another thread:

> The issue is what happens if the home link is renumbered when the MN is
> stopped. In fact this depends on how the MN knows its home prefix(es):
>  - very stupid implementations believe the MN is started at home then
>    the home prefixes will be prefixes of the first attached link: no
>    problem with renumbering.
>  - stupid implementations use a static config in order to know home
>    prefixes then if the config is too old the MN will not be able to
>    find its home link (and a home agent).
>  - someone suggested in the list to use a name which can be updated
>    when the home prefix is renumbered (but not renamed :-). It is a
>    fine idea out of the scope of the mobile IPv6 draft.
> I think most implementations use the second way (static config)...
>

I've studied the thread above slightly and am a bit curious on the
effects
of the new additions to the I-D below. It's still the bootstrapping
procedure which is of most interest; the renumbering phase is a special
case of the former. So: how does the MN find it's home addresses and
it's
home agents?

1. The MN finds out its home prefix.
2. MN performs DHAAD to find unicast address of an HA.
3. MN sends RS to HA.
4. HA sends RA with prefix list to MN.
5. MN builds Home Addresses for all prefixes, by using address method
stated in prefix info.
6. MN registers each Home Address.
7. HA might help in address configuration (e.g. DAD)
8. DNS should be updated, depending on address configuration method (it
should be done by the MN at this point, not earlier, IMO).

Note that MN doesn't have a Home Address before step 5.

If home network renumbering occurs, while the MN is away from home, HA
normally takes care of informing the MN about new home prefixes. The MN
would run step 4-8 to synchronize with the renumbering.

However, in the case when the MN is turned off for an extended period,
the
MN won't be able to find it's HA again, and not even it's home prefix to
be
able to run DHAAD. This is the same case as initial bootstrapping. Step
1
has to be performed.

As Francis said above, most implementations assume a manual
configuration
of 1, i.e. the home prefix. From there on you can find out the home
agents'
anycast address and find a HA to register with. With Ken's contribution
we
now have a way to find out all home addresses (BTW, what's been done in
the
field of stateful autoconf of Home address and MIPv6?).

What we need at this stage is a new fall-back level, where the MN can
find
it's home prefix independently of IP. So this is where AAA comes in? MN
would only need to know it's name (NAI?). Everything else can be
resolved
from this.

/Mattias

---

From: "John F. Leser" <[email-masked]>
Date: Mon, 6 Nov 2000 11:55:56 -0500

Hi,

I'd like to make some suggestions to simplify this a bit and to reduce the
overhead of keeping the MN updated with information about the home
network:

My suggestion is that the HA only tunnel router advertisements in the
situations already given in section 9.7.  In addition, the HA includes a
router advertiment in every binding acknowledgement sent in response to a
successful home registration request.  Since the MN's home registration
binding will always have a lifetime that is less than the lifetime of its
home address, this mechanism will keep the MN's home address up-to-date.

In addition, whenever a home registration binding update passes IPSEC,
but fails for some other reason, it includes an RA with the binding ack
(rejection).  The MN will then reconfigure based on this information and
attempt the registration again.  This serves as a replacement for mobile
node's sending router solicitations to the home network.

Tunneled router advertisments are sent as described in 9.7, except that
all prefix information in the aggregate list is included.

Obviously in all cases the router advertisements must be covered by IPSEC.

What is the rationale for clearing the R bit and Router ID infomation
in the prefixes in the aggregate list?  Including this info could keep
this MN's home agent list updated with additional home agents to use if
the current one fails.  If the MN's processing for tunneled advertisements
is properly specified, I don't think there's a risk of this information
being misinterpreted.

There should be wording in the spec along the lines of "the Home Agent
MUST not include the prefix information in the aggregate list in its
router advertisements multicast on-link"

>              MinRtrAdvInt + rand()*{MAX_SCHEDULE_DELAY - MinRtrAdvInt}

-------------------------------------------------------------------
John Leser                      UNH InterOperability Lab
IP/Routing Consortium Engineer  Morse Hall, 39 College Rd, Room 332
Tel: (603) 862-0090 (8-5 EST)   Durham, NH 03824-3525
Fax: (603) 862-1761             Web: www.iol.unh.edu
-------------------------------------------------------------------

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 6 Nov 2000 09:11:05 -0800

Hello John,

I'm not comfortable with adding so much extra data to every
Binding Acknowledgement, especially when so many times it will
be useless, repetitive data.  That seems very uneconomical.
This wouldn't be an issue over wired links, but over wireless
links it seems unwise to me.  If you look at the situation at
the receiving end, where a single access router may be relaying
information to many mobile nodes from many home networks, you
can see that adding unnecessary baggage into Binding Acknowlegements
could cause unwelcome contention over the wide area airlink.

The rationale behind trying to spread out the router advertisements
after the local advertisements indicate a change, is to avoid
the situation where a home agent sends out 10,000 change notices
all at once.  I reckon we should design the protocol so that it
is operationally reasonable to allow a home agent to serve very
many mobile nodes.

I'll have to study the issue with the 'R' bit some more
(a "bit more", you might say) before further comment.

Regards,
Charlie P.

---

From: "John F. Leser" <[email-masked]>
Date: Mon, 6 Nov 2000 12:27:49 -0500

Mattias,

I'd say you have a valid point - if the MN is off, and renumbering takes
place, this cannot be recovered.  Maybe there should be an
additional bullet in 10.15 of the Mobility Spec,

- If a name service such as DNS is in use, The Mobile Node MAY perform a
reverse lookup on the global address of the Home Agent in order to cache
name information in the Home Agent List.  This MUST only be done once when
the home agents address is first added to the Home Agent List.

in 10.7

- If dynamic home agent discovery fails and the mobile node has cached the
name of one or more home agents it its Home Agent List, the mobile node
MAY attempt to resolve these names through whatever name services are
supported.  If the address returned by the name service is different from
the address stored in the Home Agent List, the mobile node MAY attempt to
register with the home agent at the new address.

---

From: "John F. Leser" <[email-masked]>
Date: Mon, 6 Nov 2000 12:35:58 -0500

Charlie,

Maybe have the RA send the prefix info the first time the MN registers
its COA, but thereafter just set a bit in the binding ack that means
"you're prefix information is unchanged."  The bit would cause the MN
to reset all of its prefix timers to what it saw in the last tunneled RA.

Thus the overhead is only high for the first move, which isn't so bad
since its very like onto a network only 1 hop away.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 6 Nov 2000 09:33:50 -0800

Hello Mattias and Francis,

> I think most implementations use the second way (static config)...

One is left to wonder if there are any intelligent alternatives!

I propose that the protocols and algorithms and procedures for getting
an initial IPv6 home address allocated to a mobile node should all
be declared out of scope, or otherwise we'll never get finished with
the spec.

>Mattias Pettersson wrote:

> I've studied the thread above slightly and am a bit curious on
> the effects of the new additions to the I-D below. It's still
> the bootstrapping procedure which is of most interest; the
> renumbering phase is a special case of the former. So: how does
> the MN find it's home addresses and it's home agents?

Likewise, I sincerely hope that these questions can be declared
out of scope for the current draft.  On the other hand, I think it's
a great discussion.

> 2. MN performs DHAAD to find unicast address of an HA.

That's a mighty big rabbit you just pulled out of that there hat ...

> should be done by the MN at this point, not earlier, IMO).

What is the mobile node uses DHCP to update DNS?

> Note that MN doesn't have a Home Address before step 5.

Presumably, that would mean that the protocol you design would
use a link-local address up until that point.

> would run step 4-8 to synchronize with the renumbering.

I'm not disagreeing with you, but my objective is to get the draft
done, and making such dependencies for resynchronization purposes
would be detrimental to that objective.

> the MN won't be able to find it's HA again, and not even it's home prefix
> to be able to run DHAAD. This is the same case as initial bootstrapping.
> Step 1 has to be performed.
>
> configuration of 1, i.e. the home prefix.  From there on you
> can find out the home agents' anycast address and find a HA
> to register with.  With Ken's contribution we now have a way
> to find out all home addresses (BTW, what's been done in the

I don't think a mobile node which is currently off-link can bootstrap
from zero.  It has to at least have a security association with the
home agent, and that has to depend on an IPv6 address, so you need to
have an IPv6 address.  We can all try to design a better bootstrapping
mechanism, which would clearly depend on finding new ways to identify
a mobile node (other than using its home address).

It took a year to standardize the Mobile IPv4 NAI extension, and there
are still questions coming up on it.  My goal is to get a new Mobile IPv6
Internet Draft done this week.  I hope we don't have to go down the
path of specifying off-link bootstrapping from zero.

> find it's home prefix independently of IP. So this is where AAA comes
> in? MN would only need to know it's name (NAI?). Everything else can be
> resolved from this.

Agreed -- but next year, not this one.

Regards,
Charlie P.

---

From: "John F. Leser" <[email-masked]>
Date: Mon, 6 Nov 2000 13:14:35 -0500

Comments below.

> be declared out of scope, or otherwise we'll never get finished with
I'd rather not see this completely unspecified.  I suggest the core
Mobility spec allow:

1.) Manual config.

2.) With stateless config, a 'button' that says "you are now home"  at
which point the NM takes the current link's stateless info to initialize
or replace its home address(es).

3.) Mention that other statefull mechanisms will likely define their own
way.

> out of scope for the current draft.  On the other hand, I think it's

I say either include a minor hack based on DNS as a MAY, or leave it
completely out of scope.  This is too rare a case to hold up the draft.
> What is the mobile node uses DHCP to update DNS?

Leave all DHCP issues to be resolved by DHCPv6 or a mobility extension to
DHCPv6.  Likewise with dynamic DNS updates.

If we adopt some incarnation of Ken's idea to keep the MN aware of all
stateless information on the home link, we should define the data
structure on the MN that holds this information so that statefull
protocols can update it.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 7 Nov 2000 09:15:51 +0100

In your previous mail you wrote:

   > ...

=> I agree, it is matter of configuration/management then it has nothing
to do with the protocol itself.

=> idem

=> DNS, DHCP, AAA, ... can be done with a care-of address or a limited
scope address (more site-local than link-local but it depends on the
existence of link proxies/relays/...`

=> renumbering is a rare and long duration event then to survive to
very long (ie. in months) down periods is IMHO out of the scope of
the mobile IPv6 document.

   from zero.

=> I don't understand what is exactly from zero... It can't work with
strictly zero-knowledge, for instance for the authentication phase
of IPsec, but a certificate with a suitable SubjectName is enough.

   It has to at least have a security association with the

=> of course a NAI is a better way to identify the mobile node but
it is more a security issue than a mobile IPv6 one.

=> just put this (or keep this) out of scope.

=> this should be in an AAA for mobile IPv6 document!

Thanks

[email-masked]

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 7 Nov 2000 14:38:50 +0100

Hi all,

>    be declared out of scope, or otherwise we'll never get finished with

I'd like to open up for a simple procedure, see below.

> existence of link proxies/relays/...`

My idea was to use the care-of address until the MN can determine its home
address. The point I want to make in the draft is to allow the MN to create its
home addresses both at initial bootstrapping on a foreign network or after a
home network renumbering while it was disconnected.

As I see it the MN MAY form its home addresses by the method stated in RAs on
the home link. Other alternatives are AAA or whatever, but I believe we should
try to allow autoconfiguration of an MN that may never attach directly to its
home network. What is needed for autoconfiguration is an RA from the home link
received by the MN; the rest is specified in the RA. The HA can send this to the
MN, can't it? So I bring back my scenario:

Ok. Let's agree on leaving the big issues out of scope. Step 1 should be in a
different document. Forget if I mentioned 8.

Still a remark of the configuration alternatives as was suggested could be
useful in the draft:
Home Prefix (needed to find Home Agents) conf alts:
1A. Manual:
    - won't survive home network renum when MN is off.
1B. Always start home or user interaction (button...):
    - same, plus need to start at home, a difficult demand
1C. AAA:
    - will survive anything.

Home Address conf alts:
2A. Manual:
    - not the best idea. MN can't check its Home Address for DAD.
    - What is the relationship between a manual address and the renumbered
autoconfigured address?
2B. Autoconf by RA from Home Link (either directly from Home Link or tunneled by
HA):
    - MN will be configured just as if it was home.
2C. AAA:
    - then addresses are configured and distributed by other means than IPv6 ND
autoconf (state{ful,less})
    - if renumbering occurs MN must get new address though AAA rather than RA.

What I want is to open up the possibility for the MN to go through step 2-5
without neither having a home address nor having been at home before:

> such a Router Solicitation packet as follows:

I want this also the first time when MN has never received an RA from its home
link.

>    yet exist. Otherwise, it MAY include a Binding Update

Here we have a problem. If the MN doesn't have a home address it can't provide
any at this point (step 3 above).

Is there a way we can leave this open for a lost MN with no home address?
However, we must still secure the protocol, of course, but we can do this
without a home address.

Are the Home Address Option and Binding Update really needed, unless the HA is
expecting an ack?

> the mobile IPv6 document.

We already have this feature due to the inclusion of Ken's section. I just
wanted to show you that Ken's proposal equals step 4-8 (or 3-4, giving 5-8).
This is what MIPv6 always claimed it had. I.e., nothing new.

> of IPsec, but a certificate with a suitable SubjectName is enough.

Exactly.

> it is more a security issue than a mobile IPv6 one.

You need a NAI, and a care-of address.

> => just put this (or keep this) out of scope.

We only need it for step 1, which is out of scope. Still the final solution
needs it.

> => this should be in an AAA for mobile IPv6 document!

Very much needed. But I agree this is out of scope.

/Mattias