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 PROTECTED]>
To: [EMAIL PROTECTED]
From: Powell, Ken
Sent: Friday, October 27, 2000 5:05 PM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'; 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 PROTECTED]
--------------------------------------------------------------------
