Internet Engineering Task Force C. Perkins
INTERNET DRAFT IBM
22 February 1996
Mobile-IP Local Registration with Hierarchical Foreign Agents
<draft-perkins-mobileip-hierfa-00.txt>
Status of This Memo
This document is a submission to the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@SmallWorks.COM mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The base mobile-IP specification allows mobile computers to move
freely between various points of attachment to the Internet.
However, each time the mobile computer moves, a Registration Request
message has to be approved by the mobile node's Home Agent. In cases
where the home agent is far away, it may become too expensive or (in
the cases of network partition) even impossible to complete these
frequent registrations. In this draft document, we specify a new
variety of registration, using a Regional Registration Request and
Regional Registration Reply, that is no longer always required to be
transacted with the home agent.
Perkins Expires 22 August 1996 [Page i]
Internet Draft Hierarchical Foreign Agents 22 February 1996
Contents
Status of This Memo i
Abstract i
1. Introduction 1
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Operation 2
2.1. Finding the Right Foreign Agent . . . . . . . . . . . . . 2
2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Forwarding Datagrams to the Mobile Node . . . . . . . . . 5
3. Agent Advertisements 5
4. Regional Registration Request 7
5. Regional Registration Reply 9
6. Replay Protection 13
6.1. Replay Protection using Nonces . . . . . . . . . . . . . 13
Chair's Address 16
Author's Address 16
Perkins Expires 22 August 1996 [Page ii]
Internet Draft Hierarchical Foreign Agents 22 February 1996
1. Introduction
The base mobile-IP specification allows mobile computers to move
freely between various points of attachment to the Internet.
However, each time the mobile computer moves, a Registration Request
message has to be approved by the mobile node's Home Agent. In cases
where the home agent is far away, it may become too expensive or (in
the cases of network partition) even impossible to complete these
frequent registrations.
In this draft document, we specify a new variety of registration,
using a Regional Registration Request and Regional Registration
Reply, that is no longer always required to be transacted with the
home agent. Using this new registration technique, the foreign
agents in the local and/or regional area provide mobility services
to the mobile node and allow some degree of independence from the
home agent. The foreign agents are arranged hierarchically in the
regional topology, and the mobile node is then allowed to move from
one local area of the regional topology to another area of the same
regional topology without requiring approval by or rebinding at the
home agent.
In this document, when a mobile node changes its point of attachment
to the Internet, we say it "moves". Thus, a change in point of
attachment is a movement.
It is possible to make improvements by allowing a mobile node to
inform only local mobility agents each time it moves. However, the
local agents must then cooperate to allow the home agent to have
incomplete knowledge of the mobile node's true point of attachment.
For example, if the mobile node is currently located at one
care-of address, but the home agent stores another care-of address
in the mobile node's binding, then the two foreign agents offering
those two care-of addresses in question must cooperate to make sure
all datagrams tunneled to the latter care-of address are actually
delivered to the mobile node.
One approach to this problem is to allow the mobile node to send
Registration Requests to a regional foreign agent that tracks its
regional movements but does not forward the mobile node's Request
to its home agent. If the regional foreign agent is the tunnel
endpoint for datagrams encapsulated by the home agent, then the
regional foreign agent can make further arrangements for delivery of
the datagram. In this document, we further enhance this regional
handling by effectively allowing subregions of regions and so on,
and structuring the foreign agents which manage each region in a
hierarchy.
Perkins Expires 22 August 1996 [Page 1]
Internet Draft Hierarchical Foreign Agents 22 February 1996
Since Agent Advertisements can contain multiple care-of addresses,
a natural implementation of the hierarchy presents itself. Each
foreign agent simply includes its ancestors in the tree of regional
foreign agents in the list of care-of addresses in the Agent
Advertisement. In order to maintain compatibility with mobile nodes
that do not implement any processing for the foreign agent hierarchy,
each foreign agent must advertise its own care-of address first in
the list.
In this specification, the mobile node will re-register using a new
Registration Request that includes all the fields of the existing
Registration Request, but which includes more "care-of addresses and
places a different meaning on the address found in the Home Agent
field in the existing Registration Request. Put briefly, the Home
Agent address is replaced by the address of the nearest "regional
foreign agent" that has a previous registration with the mobile node.
1.1. Terminology
In addition to all the terminology in the base mobile-IP
specification, this document frequently uses the following terms:
Targeted Mobility Agent
The mobility agent to which a Regional Registration Request is
sent.
2. Operation
Conceptually, the mobile node attempts to minimize the amount of
tracking required to maintain its traffic flow. This amounts to
identifying the smallest region for which the mobile node has not
travesed any regional boundary. That amounts to finding the closest
ancestor to the foreign agent advertising the first care-of address
in the list in the Advertisement, which was also an ancestor at the
mobile node's last point of attachment. The mobile node may do this
as outlined below.
2.1. Finding the Right Foreign Agent
Each time a mobile node determines that it has moved, it keeps
track of the hierarchy of foreign agents serving its new point of
attachment. At least the first care-of address will be different in
the Agent Advertisements detected at the mobile node's new point of
attachment.
Perkins Expires 22 August 1996 [Page 2]
Internet Draft Hierarchical Foreign Agents 22 February 1996
When a mobile node moves to a new point of attachment, it checks the
list of care-of addresses, starting with the last one. If the last
care-of address is the same as the previous last care-of address, it
looks at the next-last care-of address. If that one is also the same
as the next-last care-of address at its previous point of attachment,
the mobile node checks the next-next-last care-of address, and so
on until a care-of address is found that is different than the
corresponding care-of address in the list which was advertised at the
mobile node's previous point of attachment.
Once the mobile node finds out the lowest level of the hierarchy,
which has a different care-of address, it notifies the foreign
agent at the next-higher level of the hierarchy about the different
care-of address. This is done by the new Registration Request
message, called the Regional Registration Request message. The
foreign agent nearest the mobile node (the first care-of address)
relays the Registration Request to next-higher level of the hierarchy
and thus along towards the target of the Registration Request, just
as if the target foreign agent (call it the targeted mobilitye agent)
were the home agent.
If the targeted mobility agent approves the Regional Registration
Request, it returns a Registration Reply of similar type and format
as inthe base mobile-IP specification.
The processing of the Regional Registration Request and Registration
Reply requires further refinement compared to the registration
processing in the base mobile-IP specification. When the foreign
agent receives the Request from the mobile node, it must pass the
Request along to its next nearest ancestor in the hierarchy along the
way to the agent listed as the Home Agent. In this way, each foreign
agent in the hierarchy between the mobile node and the home agent
will be able to maintain a binding for the mobile node. Similarly,
Regional Registration Replies are passed down from one level of the
hierarchy to the next along the way to the mobile node, so that
each foreign agent can determine the status of the corresponding
Registration Request and create the appropriate binding for the
mobile node. Note that each foreign agent's binding will be for
the care-of address at the next lower level of the hierarchy, not
necessarily the care-of address of the foreign agent advertising the
care-of address hierarchy to the mobile node.
2.2. Security
Note that home agent can be considered a "universal root" for all
such hierarchies of foreign agents as described above. In fact,
considered as an implicit care-of address, the home agent's address
Perkins Expires 22 August 1996 [Page 3]
Internet Draft Hierarchical Foreign Agents 22 February 1996
is an ancestor of every other care-of address, and the mobile node
is guaranteed of never straying from the boundaries of the region
defined by the home agent's "care-of address".
Thought of in this way, there is the same clear threat posed
by illicit Registration Requests, and thus the same need for
authenticating that Registration Requests.
Unfortunately, the mobile node and the home agent currently share
keys which are configured manually. Such manual configuration is
unrealistic with the Regional Registration Request. Fortunately, the
problem is analogous to the requirement in the Route Optimization [2]
protocol specification, for a mobile node's current foreign agent to
obtain a session key with the mobile node for as long as the mobile
node is on the foreign agent's visitor list.
As outlined in this document, when a mobile node registers with
its home agent, it "registers" with all the foreign agents in the
hierarchy between the home agent and the mobile node. When it
registers the top-level care-of address with its home agent, the
mobile node acquires a session key, using one of the extensions
specified for Route Optimization [2]. Suppose that each foreign
agent in the hierarchy shares the same session key that the home
agent sent to the foreign agent at the top level of the hierarchy.
Subsequent moves by the mobile node may require re-registration with
some (or all) of the foreign agents in the hierarchy without causing
any change to the home agent's binding for the mobile node. Since
each foreign agent between the mobile node's previous care-of address
and the home agent shares the same session key, when the mobile
re-registers an intermediate care-of address with an unchanged
care-of address immediately above it in the hierarchy, the mobile
node already shares a session key with the care-of address which
didn't change. To effect the move, then, the mobile node just has
to send the session key along with its registration through the
changed parts of the hierarchy, until the re-registration occurs at
the lowest-level care-of address which has not changed and which is
handled by a foreign agent which shares the same session key with the
mobile node.
Since each Regional Registration Request is passed to every foreign
agent between the mobile node and the "closest" foreign agent that
didn't change, when the Regional Registration Reply comes back, the
targeted mobility agent processing the Request can encode the session
key for each new foreign agent which will handle the Reply.
Perkins Expires 22 August 1996 [Page 4]
Internet Draft Hierarchical Foreign Agents 22 February 1996
2.3. Forwarding Datagrams to the Mobile Node
At each level of the hierarchy, the foreign agent advertising the
care-of address at that level has a binding for the mobile node. The
mobile node's binding shows that it is "regionally registered" at the
care-of address at the next lower level of the hierarchy.
Thus, a datagram arriving at the top of the hierarchy from the
home agent will (figuratively speaking) be decapsulated and
re-encapsulated with a new tunnel endpoint, viz. the care-of address
at the next lower level of the hierarchy. This decapsulation and
re-encapsulation occurs at each level of the hierarchy, until the
datagram reaches the last tunnel endpoint which is either the mobile
node itself (in case of a co-located care-of address) or a foreign
agent that can deliver the decapsulated datagram to the mobile node
with no further special mobile-IP handling.
Note that the actual decapsulation need not occur at each step of
the hierarchy. Instead, the foreign agent at that level can merely
change the source and destination IP addresses of the encapsulating
IP header.
3. Agent Advertisements
A foreign agent wishing to participate in a hierarchy of foreign
agents advertises its services using the Mobility Extension to
ICMP Router Advertisement which is defined in the base mobile-IP
document. However, a strict ordering is imposed on the list of
care-of addresses; the first care-of address is associated with
the advertising agent, and each successive care-of address must be
associated with the next-higher foreign agent in the hierarchy.
In addition, a new bit (the 'I' bit, for hIerarchical) is defined
in the "flags" field of the Agent Advertisement, so that the mobile
node can be assured that the advertising agent is indeed equipped to
handle the Regional Registration Request 4. The format is as follows
Perkins Expires 22 August 1996 [Page 5]
Internet Draft Hierarchical Foreign Agents 22 February 1996
(all other fields not defined here are unchanged from the definition
given in the base mobile-IP document [1]).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |R|B|H|F|M|G|V|I| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
I If set, the foreign agent is advertising
a hierarchy of care-of addresses, and can
properly process a Regional Registration
Request.
Perkins Expires 22 August 1996 [Page 6]
Internet Draft Hierarchical Foreign Agents 22 February 1996
4. Regional Registration Request
A mobile node registers with all of the hierarchical mobility agents
between itself and its home agent using a Regional Registration
Request message. When using a co-located care-of address as the
lowest level care-of address of the foreign agent hierarchy, the
mobile node may re-register with its previous care-of address if that
care-of address wasn't a co-located care-of address.
Each mobility agent receiving the Request relays it to the next
higher-level care-of address in the hierarchy. For each pending
Regional Registration Request, in addition to the information stored
for the processing of Registration Requests as required by the base
specification, each foreign agent stores the care-of address of the
next-lower foreign agent in the hierarchy. This address is available
in the Request message, as shown below.
Note the similarity between the Regional Registration Request and
the conventional Registration Request defined in the base mobile-IP
specification [1]. Unless specifically superseded in this document,
all processing of Regional Registration Requests by mobility agents
is required to be the same as the processing by mobility agents in
the base mobile-IP draft specification [1]. The UDP fields also are
the same as in the base draft specification.
IP fields:
Source Address Typically the interface address from which
the message is sent.
Destination Address Typically that of the mobility agent at
the next higher level of the hierarchy of
mobility agents.
Perkins Expires 22 August 1996 [Page 7]
Internet Draft Hierarchical Foreign Agents 22 February 1996
The UDP header is followed by the Mobile IP fields shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |S|B|D|M|G|V|rsv| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Addresses ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
All fields not listed here are definied just as in the base mobile-IP
document.
Type 8 (Regional Registration Request)
Mobility Agent The IP address of the targeted mobility agent,
which is the lowest-level foreign agent which
is present in Agent Advertisements received
both at the mobile node's previous and current
points of attachment.
Care-of Addresses The care-of addresses of the mobile node
sending the Regional Registration Request.
Extensions The fixed portion of the Regional Registration
Request is followed by one or more Extensions
which are applicable to Registration Requests.
The Registration Request MUST include an authentication extension
appropriate to the targeted mobility agent (either a Mobile-Home
Authentication Extension, or a Mobile-Foreign Authentication
Extension). In the case of the Mobile-Foreign Authentication
Extension the mobile node MAY use the Mobility Security Association
set up when it obtained a session key (e.g., using extension numbers
104 and 105 [2]). from a previous Regional Registration Extension it
Perkins Expires 22 August 1996 [Page 8]
Internet Draft Hierarchical Foreign Agents 22 February 1996
transacted with its home agent and all intervening foreign agents at
that time.
The same rules apply to the Regional Registration Request as
apply to the Registration Request, regarding the relative order in
which different extensions, when present, MUST be placed in a the
registration message.
Each foreign agent which receives a Regional Registration Request
compares its offered care-of address to the target mobility agent
listed in the Request. If they are the same, the foreign agent
determines whether or not to accept the request, and returns a
Regional Registration Reply with the appropriate status code,
as specified in 5. Otherwise, the foreign agent delivers the
Registration Request to the next-higher care-of address in the
hierarchy. The session-key extension selected by the mobile node is
processed appropriately at each level of the hierarchy, if necessary.
All foreign agents in the hierarchy between the mobile node and the
home agents can share the same session key.
Each foreign agent MUST check to make sure that its address is
included in the list of care-of addresses within the Request. If
not, it rejects the request with status code 70.
Otherwise, the foreign agent makes note of the next lower-level
care-of address, for future association with the mobile node's home
address.
5. Regional Registration Reply
A mobility agent returns a Regional Registration Reply message
to a mobile node which has sent a Regional Registration Request
(Section 4) message, and to the foreign agent at each intermediate
level of the hierarchy between itself and the mobile node. Each
foreign agent above the mobile node in the hierarchy will receive
the Regional Reply from the mobility agent at the next higher level
of the hierarchy. The Regional Reply message contains the necessary
codes to inform the mobile node about the status of its Request,
along with the lifetime granted by the targeted agent, which MUST
NOT be great enough to last longer than time at which the binding at
the home agent would expire, as determined by the original lifetime
granted by the mobile node's home agent in the last Registration
Request (or Regional Registration Request) approved by the home
agent.
When the foreign agent receives a successful Regional Registration
Reply, it updates its binding for the mobile node, using the
Perkins Expires 22 August 1996 [Page 9]
Internet Draft Hierarchical Foreign Agents 22 February 1996
next-lower care-of address in the hierarchy as the care-of address of
the mobile node.
The foreign agent MUST NOT increase the Lifetime selected by the
mobile node in the Regional Registration Request, since the Lifetime
is covered by an Authentication Extension. The targeted mobility
agent MUST NOT increase the Lifetime selected by the mobile node in
the Regional Registration Request, since doing so could increase
it beyond the maximum Registration Lifetime allowed by the foreign
agent. If the Lifetime received in the Regional Registration Reply
is greater than that in the Regional Registration Request, the
Lifetime in the Request MUST be used. When the Lifetime received in
the Regional Registration Reply is less than that in the Regional
Registration Request, the Lifetime in the Reply MUST be used.
Note the similarity between the Regional Registration Reply and
the conventional Registration Reply defined in the base mobile-IP
specification [1]. Unless specifically superseded in this document,
all processing of Regional Registration Replies by mobility agents
is specified to be the same as the processing by mobility agents
in the base mobile-IP draft specification [1]. This includes
determining the validity of the Registration Request, and selecting
the appropriate status code for the reply. The IP fields and UDP
fields are chosen just as with the Registration Reply message in the
base mobile-IP specification.
The UDP header is followed by the Mobile IP fields shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 9 (Regional Registration Reply)
Perkins Expires 22 August 1996 [Page 10]
Internet Draft Hierarchical Foreign Agents 22 February 1996
Code A value indicating the result of the
Regional Registration Request. See below
for a list of currently defined Code values.
Home Agent The IP address of the mobile node's home
agent.
Identification A 64-bit number used for matching
Registration Requests with Registration
Replies, and for protecting against replay
attacks of registration messages. The
value is based on the Identification field
from the Registration Request message
from the mobile node, and on the style of
replay protection used in the security
context between the mobile node and its home
agent (defined by the mobility security
association between them, and SPI value in
the Mobile-Home Authentication Extension).
See Section 6.
Extensions The fixed portion of the Regional
Registration Reply is followed by one or
more of Extensions. An authentication
extension MUST be included in all
Registration Replies returned by the
mobility agent.
Perkins Expires 22 August 1996 [Page 11]
Internet Draft Hierarchical Foreign Agents 22 February 1996
The following values are available for use within the Code field.
Registration successful:
0 registration accepted
1 registration accepted, but simultaneous mobility
bindings unsupported
Registration rejected:
64 reason unspecified
65 administratively prohibited
66 insufficient resources
67 mobile node failed authentication
68 mobility agent failed authentication
69 requested Lifetime too long
70 poorly formed Request
71 poorly formed Reply
72 requested encapsulation unavailable
73 requested Van Jacobson compression unavailable
80 home network unreachable (ICMP error received)
81 mobility agent host unreachable (ICMP error received)
82 mobility agent port unreachable (ICMP error received)
88 mobility agent unreachable (other ICMP error received)
133 registration Identification mismatch
135 too many simultaneous mobility bindings
136 unknown mobility agent address
144 Broadcast Preference Extension unsupported
145 Multicast Preference Extension unsupported
Up-to-date values of the Code field are specified in the most recent
"Assigned Numbers" [3].
Note that processing of the Identification field, as discussed in
Section 6, is significantly different than in the base mobile-IP
specification when nonces are to be used. Each foreign agent
receiving a successful Regional Registration Reply from the foreign
agent immediately above it in the foreign agent hierarchy MUST
replace any Identification stored and associated with the mobile
node, with the fresh Identification in the received Reply message.
Note also that, when the targeted mobility agent is unknown, the
Regional Registration Request works as well as the base mobile-IP
Registration Request in helping the mobile node to discover its
home agent's address. However, in that case the mobile node would
probably prefer to use the base Registration Request, since the
Request cannot be accepted anyway until the home agent's address is
known.
Perkins Expires 22 August 1996 [Page 12]
Internet Draft Hierarchical Foreign Agents 22 February 1996
6. Replay Protection
The Identification field is used to let the targeted mobility agent
verify that a registration message has been freshly generated by
the mobile node, not replayed by an attacker from some previous
registration. Two methods are described in the base mobile-IP
specification: timestamps (mandatory) and "nonces" (optional). All
mobile nodes and mobility agents using Regional Registration messages
MUST implement timestamp-based replay protection. These nodes MAY
also implement nonce-based replay protection.
The style of replay protection in effect between a mobile node and
its mobility agents is part of the mobile security association.
A mobile node and its mobility agent MUST agree on which method
of replay protection will be used. The interpretation of the
Identification field depends on the method of replay protection as
described in the subsequent subsections.
All requirements of the base mobile-IP specification regarding replay
protection must be followed by mobile nodes using the regional
registration procedures specified in this document. There is no
change to the replay procedures when timestamps are used. However,
for nonce-based replay protection additional refinements must be
instituted by the mobile node. Other mobility agents process nonces
as in the base protocol specification.
The Identification in a new Registration Request MUST NOT be the
same as in an immediately preceding Request, and SHOULD NOT repeat
while the same security context is being used between the mobile
node and the home agent. Retransmission as in the base mobile-IP
specification [1] is allowed.
6.1. Replay Protection using Nonces
The basic principle of nonce replay protection does not change from
that described in the base mobile-IP specification. However, since
there can now be multiple mobility agents all registering the same
mobile node, the mobile node must maintain a vector of nonces, one
for each mobility agent in its current hierarchy.
Whenever a targeted mobility agent receives a Regional Registration
Request, it selects a new nonce using the same methods described
for home agents selecting a new nonce in the base mobile-IP
specification. The mobility agent then inserts the resulting
Identification in the appropriate field of the Regional Registration
Reply. Each mobility agent at lower levels of the hierarchy copy,
when it receives the Reply, copies the new Identification for
Perkins Expires 22 August 1996 [Page 13]
Internet Draft Hierarchical Foreign Agents 22 February 1996
possible use in receiving future Regional Registration Requests
from the mobile node. In other words, new nonces from above in the
hierarchy supersede existing nonces stored by intermediate foreign
agents in the hierarchy.
When a mobile node receives a Regional Registration Reply, it in
turn associates the nonce from the Identification field with every
intermediate foreign agent between itself and the targeted mobility
agent to which it had sent the Regional Registration Request.
If a registration message is rejected because of an invalid
nonce, the Reply always provides the mobile node, and each other
intermediate foreign agent at lower levels than the targeted mobility
agent, with a new nonce to be used in the next registration. Thus
the nonce protocol is self-synchronizing.
Perkins Expires 22 August 1996 [Page 14]
Internet Draft Hierarchical Foreign Agents 22 February 1996
References
[1] IPv4 Mobility Support. ietf-draft-mobileip-protocol-15.txt -
work in progress, February 1996.
[2] David B. Johnson and Charles E. Perkins. Route Optimization in
Mobile-IP. draft-ietf-mobileip-optim-03.txt -- work in progress,
November 1995.
[3] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700,
October 1994.
Perkins Expires 22 August 1996 [Page 15]
Internet Draft Hierarchical Foreign Agents 22 February 1996
Chair's Addresses
The working group can be contacted via the current chairs:
Jim Solomon Tony Li
Motorola, Inc. cisco systems
1301 E. Algonquin Rd. 170 W. Tasman Dr.
Schaumburg, IL 60196 San Jose, CA 95134
Work: +1-847-576-2753 Work: +1-408-526-8186
E-mail: solomon@comm.mot.com E-mail: tli@cisco.com
Author's Address
Questions about this memo can be directed to:
Charles Perkins
Room J1-A25
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Work: +1-914-784-7350
Fax: +1-914-784-6205
E-mail: perk@watson.ibm.com
Perkins Expires 22 August 1996 [Page 16]