Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home network renumb ering

From: "Powell, Ken" <[email-masked]>
Date: Mon, 6 Nov 2000 13:49:46 -0500

Hi John,

I had originally intended to copy the R bit and full IP address
as you suggested. When I reread the definition of the R bit in
section 6.2 again, I noticed:

  "When set, indicates that the prefix field, in addition
   to advertising the indicated prefix, contains a
   complete IP address of the sending router."
                              ==============

Copying the R bit and its associated IP address from another
router would violate this definition. In addition, section 10.17
indicated that a mobile node does the following with this field:

    -  If the Home Agents List entry for the link-local address of
       the home agent sending this Advertisement was not deleted as
       described above, determine any global address(es) of the home
       agent based on each Prefix Information option received in
       this Advertisement in which the Router Address (R) bit is set
       (Section 6.2).  For each such global address determined from
       this Advertisement, add this global address to the list of
       global addresses for this home agent in this Home Agents List
       entry.                ===============

Once again, this would be broken if we passed the R bit and the
IP address of another router.

I suppose special processing for a tunneled router advertisement
could be defined, but I don't see any way for a mobile node to tell
which of multiple possible routers on the home network a particular
address belongs to.

Ken

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Monday, November 06, 2000 12:11 PM
To: [email-masked]
Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home network
renumbering

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.

"John F. Leser" wrote:
>
> 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"
>
> On Fri, 3 Nov 2000, Charlie Perkins wrote:
>
> > 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"
> >
> > Ken suggested:
> >
> > > 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.
> >
> > 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.
> >
>
> -------------------------------------------------------------------
> 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: "John F. Leser" <[email-masked]>
Date: Mon, 6 Nov 2000 14:04:53 -0500

Ken,

Giving it more thought, I agree - better not to include the information.