Subject: How Mobile IPv6 should handle home network renumbering

From: Charlie Perkins <[email-masked]>
Date: Fri, 03 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.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------