Network Working Group David B. Johnson
INTERNET DRAFT Carnegie Mellon University
7 July 1995 Charles Perkins
IBM Corporation
Route Optimization in Mobile IP
draft-ietf-mobileip-optim-02.txt
Status of This Memo
This document is a product of the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to working group mailing list at mobile-ip@tadpole.com.
Distribution of this document 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).
Johnson and Perkins Expires 7 January 1996 [Page i]
Internet Draft Route Optimization in Mobile IP 7 July 1995
Abstract
This document defines extensions to the operation of the base
Mobile IP protocol to allow for optimization of datagram routing from
a correspondent node to a mobile node. Without Route Optimization,
all datagrams destined to a mobile node are routed through that
mobile node's home agent, which then tunnels each datagram to the
mobile node's current location. The protocol extensions described
here provide a means for correspondent nodes that implement them
to cache the binding of a mobile node and to then tunnel their own
datagrams for the mobile node directly to that location, bypassing
the possibly lengthy route for each datagram to and from the mobile
node's home agent. Extensions are also provided to allow datagrams
in flight when a mobile node moves, and datagrams sent based on an
out-of-date cached binding, to be forwarded directly to the mobile
node's new binding.
Johnson and Perkins Expires 7 January 1996 [Page ii]
Internet Draft Route Optimization in Mobile IP 7 July 1995
Contents
Status of This Memo i
Abstract ii
1. Introduction 1
2. Route Optimization Overview 3
2.1. Binding Caching . . . . . . . . . . . . . . . . . . . . . 3
2.2. Foreign Agent Handoff . . . . . . . . . . . . . . . . . . 3
2.3. Binding Cache Updates . . . . . . . . . . . . . . . . . . 5
2.4. Registration Key Establishment Using the Home Agent . . . 7
2.5. Registration Key Establishment Using Diffie-Hellman . . . 7
3. Route Optimization Message Formats 10
3.1. Binding Warning Message . . . . . . . . . . . . . . . . . 11
3.2. Binding Request Message . . . . . . . . . . . . . . . . . 12
3.3. Binding Update Message . . . . . . . . . . . . . . . . . 13
3.4. Binding Acknowledge Message . . . . . . . . . . . . . . . 15
4. Route Optimization Extension Formats 16
4.1. Previous Foreign Agent Notification Extension . . . . . . 17
4.2. Route Optimization Authentication Extension . . . . . . . 19
4.3. Home Agent Registration Key Request Extension . . . . . . 20
4.4. Mobile Node Registration Key Reply Extension . . . . . . 21
4.5. Foreign Agent Registration Key Reply Extension . . . . . 22
4.6. Diffie-Hellman Registration Key Request Extension . . . . 23
4.7. Diffie-Hellman Registration Key Reply Extension . . . . . 24
5. Mobility Security Association Management 25
6. Binding Cache Considerations 27
6.1. Cache Management . . . . . . . . . . . . . . . . . . . . 27
6.2. Receiving Binding Warning Messages . . . . . . . . . . . 27
6.3. Receiving Binding Update Messages . . . . . . . . . . . . 28
6.4. Using Special Tunnels . . . . . . . . . . . . . . . . . . 28
7. Home Agent Considerations 30
7.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Receiving Binding Request Messages . . . . . . . . . . . 30
7.3. Receiving Registration Key Requests . . . . . . . . . . . 31
7.4. Receiving Special Tunnels . . . . . . . . . . . . . . . . 31
Johnson and Perkins Expires 7 January 1996 [Page iii]
Internet Draft Route Optimization in Mobile IP 7 July 1995
8. Foreign Agent Considerations 32
8.1. Establishing a Registration Key . . . . . . . . . . . . . 32
8.2. Previous Foreign Agent Notification . . . . . . . . . . . 32
8.3. Receiving Tunneled Datagrams . . . . . . . . . . . . . . 33
8.4. Sending Special Tunnels . . . . . . . . . . . . . . . . . 34
9. Mobile Node Considerations 35
9.1. Requesting a Registration Key . . . . . . . . . . . . . . 35
9.2. Notifying Previous Foreign Agents . . . . . . . . . . . . 35
References 37
Appendix A. Using a Master Key at the Home Agent 38
Chairs' Addresses 39
Authors' Addresses 40
Johnson and Perkins Expires 7 January 1996 [Page iv]
Internet Draft Route Optimization in Mobile IP 7 July 1995
1. Introduction
The base Mobile IP protocol [6] allows any mobile node to move about,
changing its point of attachment to the Internet, while continuing
to be addressed by its home IP address. Correspondent nodes sending
IP datagrams to a mobile node address them to the mobile node's home
address in the same way as to any destination.
While the mobile node is connected to the Internet away from its
home network, it is served by a "home agent" on its home network
and is associated with a "care-of address" indicating its current
location. The association between a mobile node's home address and
its care-of address is known as a "mobility binding". The care-of
address is generally the address of a "foreign agent" on the network
being visited by the mobile node, which forwards arriving datagrams
locally to the mobile node. Alternatively, the care-of address may
be temporarily assigned to the mobile node using DHCP [3] or other
means. All IP datagrams addressed to the mobile node are routed by
the normal IP routing mechanisms to the mobile node's home network,
where they are intercepted by the mobile node's home agent, which
then tunnels each datagram to the mobile node's current care-of
address. Datagrams sent by a mobile node use the foreign agent as a
default router but require no other special handling or routing.
This scheme allows transparent interoperation with mobile nodes,
but forces all datagrams for a mobile node to be routed through
its home agent; packets to the mobile node are often routed along
paths that are significantly longer than optimal. For example, if a
mobile node, say MN1, is visiting some subnet, even datagrams from
a correspondent node on this same subnet must be routed through the
Internet to MN1's home agent on MN1's home network, only to then
be tunneled back to the original subnet to MN1's foreign agent for
delivery to MN1. This indirect routing can significantly delay the
delivery of the datagram to MN1 and places an unnecessary burden on
the networks and routers along this path through the Internet. If
the correspondent node in this example is actually another mobile
node, say MN2, then datagrams from MN1 to MN2 must likewise be routed
through MN2's home agent on MN2's home network and back to the
original subnet for delivery to MN1.
This document defines extensions to the base Mobile IP protocol to
allow for the optimization of datagram routing from a correspondent
node to a mobile node. These extensions provide a means for nodes
that implement them to cache the binding of a mobile node and to then
tunnel their own datagrams directly to the care-of address indicated
in that binding, bypassing the possibly lengthy route to and from
that mobile node's home agent. Extensions are also provided to allow
datagrams in flight when a mobile node moves, and datagrams sent
Johnson and Perkins Expires 7 January 1996 [Page 1]
Internet Draft Route Optimization in Mobile IP 7 July 1995
based on an out-of-date cached binding, to be forwarded directly
to the mobile node's new care-of address. These extensions are
collectively referred to as Route Optimization in this document.
All operation of Route Optimization that changes the routing of IP
datagrams to the mobile node is authenticated using the same type of
authentication mechanism used in the base Mobile IP protocol. This
authentication generally relies on a "mobility security association"
established in advance between the node sending a message and the
node receiving the message that must authenticate it. When the
required mobility security association has not been established, a
Mobile IP implementation using Route Optimization operates in the
same way as the base Mobile IP protocol.
Section 2 of this document provides an overview of the operation of
Route Optimization. Section 3 defines the message types used by
Route Optimization, and Section 4 defines the message extensions
used. Section 5 discusses the problem of managing the mobility
security associations needed to provide authentication of all
messages that affect the routing of datagrams to a mobile node.
The final four sections of this document define in detail the
operation of Route Optimization from the point of view of each of the
entities involved: considerations for nodes maintaining a binding
cache are presented in Section 6, mobile node considerations in
Section 9, foreign agent considerations in Section 8, and home agent
considerations in Section 7.
Johnson and Perkins Expires 7 January 1996 [Page 2]
Internet Draft Route Optimization in Mobile IP 7 July 1995
2. Route Optimization Overview
2.1. Binding Caching
Route Optimization provides a means for any node that wishes to
optimize its own communication with mobile nodes to maintain a
"binding cache" containing the mobility binding of one or more mobile
nodes. When sending an IP datagram to a mobile node, if the sender
has a binding cache entry for the destination mobile node, it may
tunnel the datagram directly to the care-of address indicated in the
cached mobility binding.
In the absence of any binding cache entry, datagrams destined for
a mobile node will be routed to the mobile node's home network in
the same way as any other IP datagram, and are then tunneled to the
mobile node's current care-of address by the mobile node's home
agent. This is the only routing mechanism supported by the base
Mobile IP protocol. With Route Optimization, as a side effect of
this indirect routing of a datagram to a mobile node, the original
sender of the datagram may be informed of the mobile node's current
mobility binding, giving the sender an opportunity to cache the
binding.
A node may create a binding cache entry for a mobile node only when
it has received and authenticated the mobile node's mobility binding.
Likewise, a node may update an existing binding cache entry for a
mobile node, such as after the mobile node has moved to a new foreign
agent, only when it has received and authenticated the mobile node's
new mobility binding.
A binding cache will, by necessity, have a finite size. Any node
implementing a binding cache may manage the space in its cache
using any local cache replacement policy. If a datagram is sent
to a destination for which the cache entry has been dropped from
the cache, the datagram will be routed normally through the mobile
node's home network and will be tunneled to the mobile node's care-of
address by its home agent. This indirect routing to the mobile node
will result in the original sender of the datagram being informed of
the mobile node's current mobility binding, allowing it to add this
entry again to its binding cache.
2.2. Foreign Agent Handoff
When a mobile node moves and registers with a new foreign agent, the
base Mobile IP protocol does not notify the mobile node's previous
foreign agent. IP datagrams intercepted by the home agent after
the new registration are tunneled to the mobile node's new care-of
Johnson and Perkins Expires 7 January 1996 [Page 3]
Internet Draft Route Optimization in Mobile IP 7 July 1995
address, but datagrams in flight that had already been intercepted
by the home agent and tunneled to the old care-of address when the
mobile node moved are lost and are assumed to be retransmitted by
higher-level protocols if neeeded. The old foreign agent eventually
deletes the mobile node's registration after the expiration of the
lifetime period established when the mobile node registered there.
Route Optimization provides a means for the mobile node's previous
foreign agent to be reliably notified of the mobile node's new
mobility binding, allowing datagrams in flight to the mobile
node's previous foreign agent to be forwarded to its new care-of
address. This notification also allows any datagrams tunneled to the
mobile node's previous foreign agent from correspondent nodes with
out-of-date binding cache entries for the mobile node (that have not
yet learned that the mobile node has moved), to be forwarded to its
new care-of address. Finally, this notification allows any resources
consumed by the mobile node's binding at the previous foreign agent
(such as radio channel reservations) to be released immediately,
rather than waiting for the mobile node's registration to expire.
Optionally, during registration with a new foreign agent, the mobile
node and the foreign agent may establish a new shared secret key
as a "registration key". When the mobile node later registers
with a new foreign agent, if it established a registration key
during registration with its previous foreign agent, it may use
this key to notify the previous foreign agent that it has moved.
This notification may also optionally include the mobile node's new
care-of address, allowing the previous foreign agent to create a
binding cache entry for the mobile node to serve as a "forwarding
pointer" to its new location. Any tunneled datagrams for the mobile
node that arrive at this previous foreign agent after this binding
cache entry has been created will then be re-tunneled by this
foreign agent to the mobile node's new location using the mobility
binding in this binding cache entry. The registration key is used
to authenticate the notification sent to the previous foreign agent.
Other uses of the registration key are possible, such as for use as
an encryption key for providing privacy over a wireless link between
the mobile node and its foreign agent, but such uses are beyond the
scope of this document. Once established, the registration key for a
mobile node can be stored by the foreign agent with the mobile node's
visitor list entry.
As part of the registration procedure, the mobile node may
request that its new foreign agent attempt to notify its previous
foreign agent on its behalf, by including a Previous Foreign Agent
Notification extension in its Registration Request message sent to
the new foreign agent. The new foreign agent then builds a Binding
Update message and transmits it to the mobile node's previous foreign
Johnson and Perkins Expires 7 January 1996 [Page 4]
Internet Draft Route Optimization in Mobile IP 7 July 1995
agent as part of registration, requesting an acknowledgement from
the previous foreign agent. The Previous Foreign Agent Notification
extension includes only those values needed to construct the Binding
Update message that are not already contained in the Registration
Request message. The authenticator for the Binding Update message is
computed by the mobile node based on its registration key shared with
its previous foreign agent.
The mobile node is responsible for occasionally retransmitting a
Binding Update message to its previous foreign agent until the
matching Binding Acknowledge message is received, or until the mobile
node can be sure of the expiration of its registration with that
foreign agent.
The binding cache entry created at the mobile node's previous foreign
agent is treated in the same way as any other binding cache entry.
In particular, it is possible that this binding cache entry will be
deleted from the cache at any time. In this case, the foreign agent
will be unable to re-tunnel subsequently arriving tunneled datagrams
for the mobile node directly to its new location. Suppose a node
(for instance, such a previous foreign agent) receives a datagram
that has been tunneled to this node, but this node is unable to
deliver the datagram locally to the destination mobile node (the node
is not the mobile node itself, and it is not a foreign agent with a
visitor list entry for the mobile node). To attempt delivery of the
datagram in this case, the node must encapsulate the datagram as a
"special tunnel" datagram (Section 8.4), destined to the mobile node.
Otherwise, the datagram would eventually reach the mobile node's
home network, be intercepted by the mobile node's home agent, and be
tunneled to the mobile node's current care-of address. If the home
agent were to tunnel the datagram back to the same foreign agent, a
loop would be created.
2.3. Binding Cache Updates
When a mobile node's home agent intercepts a datagram from the
home network and tunnels it to the mobile node, the home agent may
deduce that the original source of the datagram has no binding
cache entry for the destination mobile node. In this case, the
home agent MAY send a Binding Update message to the original source
node, informing it of the mobile node's current mobility binding.
No acknowledgement for this Binding Update message is needed, since
additional future datagrams from this source node intercepted by the
home agent for the mobile node will cause transmission of another
Binding Update. In order for this Binding Update to be authenticated
by the original source node, the home agent and this source node must
have established a mobility security association.
Johnson and Perkins Expires 7 January 1996 [Page 5]
Internet Draft Route Optimization in Mobile IP 7 July 1995
Similarly, when any node receives a tunneled datagram that was
tunneled to this node, if it is not the current foreign agent
serving the destination (it has no visitor list entry for this mobile
node), the node receiving this tunneled datagram may deduce that
the tunneling node has an out-of-date binding cache entry for the
destination mobile node. In this case, the receiving node MAY send a
Binding Warning message to the tunneling node, advising it that its
binding cache entry for the mobile node is out-of-date. As in the
case of a Binding Update sent by the mobile node's home agent, no
acknowledgement of this Binding Warning is needed, since additional
future datagrams for the mobile node tunneled by the same node will
cause the transmission of another Binding Warning.
However, unlike the Binding Update message, no authentication of the
Binding Warning message is necessary, since it does not directly
affect the routing of IP datagrams to the mobile node. Instead, when
a node receives a Binding Warning message, that node sends a Binding
Request message to the indicated mobile node's home agent, requesting
the mobile node's current mobility binding. The home agent then
answers this Binding Request message with a Binding Update message;
when the Binding Update message is received, the node may then create
a binding cache entry for the mobile node. In order for this node
and the home agent to exchange these Binding Request and Binding
Update messages, they must have established a mobility security
association.
DISCUSSION: An alternative design would be to send a Binding
Warning-like message directly to the home agent, which would
then send a Binding Update to the correspondent node. This
accomplishes the same thing in 2 messages instead of 3
(Binding Warning, Binding Request, Binding Update), but the
authentication of the binding may be more difficult without
a request-update exchange between the correspondent node and
the home agent.
Each Binding Update message indicates the maximum lifetime of any
binding cache entry created from the Binding Update. When sending
the Binding Update message, the home agent SHOULD set this lifetime
to the remaining service lifetime associated with the mobile node's
current registration. Any binding cache entry established or updated
in response to this Binding Update message must be marked to be
deleted after the expiration of this period. A node wanting to
provide continued service with a particular binding cache entry may
attempt to reconfirm that mobility binding before the expiration of
this lifetime period. Such reconfirmation of a binding cache entry
may be appropriate when the node has indications (such as an open
transport-level connection to the mobile node) that the binding
cache entry is still needed. This reconfirmation is performed by
Johnson and Perkins Expires 7 January 1996 [Page 6]
Internet Draft Route Optimization in Mobile IP 7 July 1995
the node sending a Binding Request message to the mobile node's home
agent, requesting it to reply with the mobile node's current mobility
binding in a new Binding Update message.
2.4. Registration Key Establishment Using the Home Agent
One method of establishing a registration key is for the mobile node
to request its home agent to generate one during registration, and
for the home agent to send a copy of this key to both the mobile
node and its new foreign agent. The home agent in this case acts
as a "key distribution center" (KDC) for the mobile node and the
foreign agent. The mobile node requests this by including a Home
Agent Registration Key Request extension in its Registration Request
message. The home agent sends the generated key to the mobile node
and to its foreign agent by including a Mobile Node Registration Key
Reply extension and a Foreign Agent Registration Key Reply extension
its Registration Reply message. The Mobile Node Registration Key
Reply extension contains a copy of the chosen key encrypted under a
key and algorithm shared between the home agent and the mobile node,
and a Foreign Agent Registration Key Reply extension contains a copy
of the same key encrypted under a key and algorithm shared between
the home agent and the foreign agent.
In order for the registration key to be established using this
method, the foreign agent must have a mobility security association
with the home agent. For example, if mobile nodes from some home
network often visit this foreign agent, it may in general be worth
the effort of creating such a mobility security association between
this foreign agent and the home agent serving that home network. If
no mobility security association exists, a mobile node may instead be
able to establish a registration key with its home agent using the
alternative method described in the next section.
2.5. Registration Key Establishment Using Diffie-Hellman
An alternate method defined in this document for establishing a
registration key is for the mobile node and its foreign agent to
execute the Diffie-Hellman key exchange algorithm [2] as part of the
mobile node's registration. The Diffie-Hellman algorithm is a public
key cryptosystem that allows two parties to establish a shared secret
key, such that the shared secret key cannot be determined by other
parties overhearing the messages exchanged during the algorithm. It
is used, for example, in other protocols that require a key exchange,
such as in the Cellular Digital Packet Data (CDPD) system [1].
Briefly, the Diffie-Hellman algorithm involves the use of two large
public numbers, which must be known by both parties involved in the
Johnson and Perkins Expires 7 January 1996 [Page 7]
Internet Draft Route Optimization in Mobile IP 7 July 1995
algorithm, but need not be kept secret; the two public numbers may be
different for each execution of the algorithm and are not used once
the algorithm completes. Each party chooses a private random number,
computes a function of this number and the two public numbers, and
sends the result of this function in a message to the other party.
Each party then computes the (same) shared secret key using its own
private random number, the value received from the other party, and
the two public numbers.
To use this algorithm during registration with a foreign agent,
the mobile node includes a Diffie-Hellman Registration Key Request
extension in its Registration Request message, containing its
values for the two public numbers and the function of its own
private random number. When it receives the Registration Request
message, the foreign agent chooses its own private random number and
computes shared secret key value. The foreign agent also includes a
Diffie-Hellman Registration Key Reply extension in its Registration
Reply message to the mobile node, including the function of its own
private random number. The mobile node then also computes the shared
secret key value.
The Diffie-Hellman algorithm allows the mobile node and its foreign
agent to establish a registration key without any pre-existing
mobility security associations, but the Diffie-Hellman algorithm
itself is covered by a patent. The method of establishing a
registration key using Diffie-Hellman thus may not be usable by those
who have not licensed the patent.
Also, establishing a registration key using Diffie-Hellman is
computationally more expensive than the method described in
Section 2.4. The use of Diffie-Hellman described here, though, is
designed to allow the Diffie-Hellman computations to be overlapped
with other activities. The mobile node may choose the two public
numbers at any time, or may use the same two public numbers for
all registrations; for example, a mobile node may be configured by
the administrator of its home network with the two public numbers,
which the mobile node may continue to use until reconfigured by
its home network administrator. The mobile node may also choose
its private random number and compute its function of this and the
two public numbers at any time. For example, after completing one
registration, the mobile node may choose the random number for its
next registration and begin the computation on this random number,
such that it has completed this computation before it is needed in
its next registration; in its simplest form, the mobile node may
use the same random number and computed value for any number of
registrations, or even for all registrations. The foreign agent
may choose its random number and begin computation its based on
this number as soon as it receives the mobile node's Registration
Johnson and Perkins Expires 7 January 1996 [Page 8]
Internet Draft Route Optimization in Mobile IP 7 July 1995
Request message, and need only complete this computation before it
sends the matching Registration Reply message for the mobile node's
registration.
DISCUSSION: We could add a bit in the Agent Advertisement
message, indicating that this foreign agent supports the
Diffie-Hellman extension. This would save the mobile node
the effort of attempting Diffie-Hellman with a foreign agent
that did not support it.
DISCUSSION: This could be extended to support other similar
key exchange algorithms, either by adding a new Request
and Reply extension for each, or by adding a field in the
extensions to indicate which algorithm is to be used.
Diffie-Hellman seems the only obvious choice, though,
currently.
Johnson and Perkins Expires 7 January 1996 [Page 9]
Internet Draft Route Optimization in Mobile IP 7 July 1995
3. Route Optimization Message Formats
Route Optimization defines four message types used for management
of binding cache entries. Each of these messages begins with a
one-octet field indicating the type of the message.
The following Type codes are defined in this document:
16 = Binding Warning message
17 = Binding Request message
18 = Binding Update message
19 = Binding Acknowledge message
Johnson and Perkins Expires 7 January 1996 [Page 10]
Internet Draft Route Optimization in Mobile IP 7 July 1995
3.1. Binding Warning Message
A Binding Warning message is used to advise a node that it appears
to have either no binding cache entry or an out-of-date binding
cache entry for some mobile node. When any node receives a datagram
tunneled to itself, if it is not the current foreign agent for the
destination mobile node, it MAY send a Binding Warning message to the
node that originated the tunneled datagram.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
16
Reserved
Sent as 0; ignored on reception.
Mobile Node Home Address
The home address of the mobile node to which the Binding
Warning message refers.
Johnson and Perkins Expires 7 January 1996 [Page 11]
Internet Draft Route Optimization in Mobile IP 7 July 1995
3.2. Binding Request Message
A Binding Request message is used by a node to request a mobile
node's current mobility binding from the mobile node's home agent.
It is sent by a node upon receiving a Binding Warning message, or by
a node desiring to update the mobility binding in a binding cache
entry that it holds for the mobile node.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
17
Reserved
Sent as 0; ignored on reception.
Mobile Node Home Address
The home address of the mobile node to which the Binding
Request refers.
Identification
A 64-bit sequence number, assigned by the node sending the
Binding Request message, used to assist in matching requests
with replies, and in protecting against replay attacks.
Johnson and Perkins Expires 7 January 1996 [Page 12]
Internet Draft Route Optimization in Mobile IP 7 July 1995
3.3. Binding Update Message
The Binding Update message is used to notify another node of a mobile
node's current mobility binding. It MAY be sent by the mobile node's
home agent in response to a Binding Request message. It MAY also
be sent by a mobile node, or by the foreign agent with which the
mobile node is registering, when notifying the mobile node's previous
foreign agent that the mobile node has moved.
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 |A|I|M|G| Rsvd | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type
18
Acknowledge (A)
The Acknowledge (A) bit is set by the node sending the Binding
Update message to request a Binding Acknowledge message be
returned acknowledging its receipt.
Identification Present (I)
The Identification Present (I) bit is set by the node sending
the Binding Update message to indicate whether or not the
Identification field is present.
Minimal Encapsulation (M)
If the Minimal Encapsulation (M) bit is set, datagrams may be
tunneled to the mobile node using the minimal encapsulation
protocol used in the base Mobile IP protocol.
Johnson and Perkins Expires 7 January 1996 [Page 13]
Internet Draft Route Optimization in Mobile IP 7 July 1995
GRE Encapsulation (G)
If the GRE Encapsulation (G) bit is set, datagrams may be
tunneled to the mobile node using the GRE encapsulation
protocol [5].
Rsvd
Sent as 0; ignored on reception.
Lifetime
The number of seconds remaining before the binding cache entry
must be considered expired. A value of all ones indicates
infinity. A value of zero indicates that no binding cache
entry for the mobile node should be created, and any existing
binding cache entry (and visitor list entry, in the case of
a mobile node's previous foreign agent) for the mobile node
should be deleted. The lifetime is typically equal to the
remaining lifetime of the mobile node's registration.
Mobile Node Home Address
The home address of the mobile node to which the Binding Update
message refers.
Care-of Address
The current care-of address of the mobile node. When set equal
to the home address of the mobile node, the Binding Update
message instead indicates that no binding cache entry for the
mobile node should be created, and any existing binding cache
entry (and visitor list entry, in the case of a mobile node's
previous foreign agent) for the mobile node should be deleted.
Identification
If present, a 64-bit number, assigned by the node sending the
Binding Request message, used to assist in matching requests
with replies, and in protecting against replay attacks.
The Route Optimization Authentication extension (Section 4.2) is
required.
Johnson and Perkins Expires 7 January 1996 [Page 14]
Internet Draft Route Optimization in Mobile IP 7 July 1995
3.4. Binding Acknowledge Message
A Binding Acknowledge message is used to acknowledge receipt of a
Binding Update message. It is sent by a node receiving the Binding
Update message, if the Acknowledge (A) bit is set in the Binding
Update message.
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 |N| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
19
N
This bit is set if the acknowledgement is negative. For
instance, if the binding update was not accepted, but the
incoming datagram has the Acknowledge flag set, then the N bit
is set in this Binding Acknowledge message.
DISCUSSION: Alternatively, we could replace this bit with
a status code, as in the Registration Reply message. The
mobile node could log the error, but currently has no
real way to recover from it.
Reserved
Sent as 0; ignored on reception.
Mobile Node Home Address
Copied from the Binding Update message being acknowledged.
Identification
Copied from the Binding Update message being acknowledged, if
present there.
Johnson and Perkins Expires 7 January 1996 [Page 15]
Internet Draft Route Optimization in Mobile IP 7 July 1995
4. Route Optimization Extension Formats
Route Optimization defines the following Mobile IP message
extensions:
96 = Previous Foreign Agent Notification Extension
97 = Route Optimization Authentication Extension
98 = Home Agent Registration Key Request Extension
99 = Mobile Node Registration Key Reply Extension
100 = Foreign Agent Registration Key Reply Extension
101 = Diffie-Hellman Registration Key Request Extension
102 = Diffie-Hellman Registration Key Reply Extension
Johnson and Perkins Expires 7 January 1996 [Page 16]
Internet Draft Route Optimization in Mobile IP 7 July 1995
4.1. Previous Foreign Agent Notification Extension
The Previous Foreign Agent Notification extension may be included
in a Registration Request message sent to a foreign agent. It
requests the new foreign agent to send a Binding Update message on
behalf of the mobile node, to the mobile node's previous foreign
agent, to notify it that the mobile node has moved. The previous
foreign agent deletes the mobile node's visitor list entry, and also
creates a binding cache entry for the mobile node pointing to its new
care-of address if a new care-of address is included in the Binding
Update message. The Previous Foreign Agent Notification extension
contains only those values not otherwise already contained in the
Registration Request message, that are needed for the new foreign
agent to construct the Binding Update message.
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 | Cache Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Foreign Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Care-of Address Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
96
Length
10 plus the length of the Authenticator
Cache Lifetime
The number of seconds remaining before the binding cache entry
created by the previous foreign agent must be considered
expired. A value of all ones indicates infinity. A value
of zero indicates that the previous foreign agent should not
create a binding cache entry for the mobile node once it has
deleted the mobile node's visitor list entry. The Cache
Lifetime value is copied into the Lifetime field of the Binding
Update message.
Johnson and Perkins Expires 7 January 1996 [Page 17]
Internet Draft Route Optimization in Mobile IP 7 July 1995
Previous Foreign Agent Address
The IP address of the mobile node's previous foreign agent
to which the new foreign agent should send a Binding Update
message on behalf of the mobile node.
New Care-of Address
The new care-of address for the new foreign agent to send in
the Binding Update message to the previous foreign agent. This
SHOULD be either the care-of address being registered in this
new registration (i.e., to cause IP datagrams from the previous
foreign agent to be tunneled to the new foreign agent) or the
mobile node's home address (i.e., to cause the previous foreign
agent to only delete its visitor list entry for the mobile
node).
Authenticator
The authenticator value to be used in the Route Optimization
Authentication extension in the Binding Update message sent by
the new foreign agent to the mobile node's previous foreign
agent. This authenticator is calculated only over the Binding
Update message body.
Johnson and Perkins Expires 7 January 1996 [Page 18]
Internet Draft Route Optimization in Mobile IP 7 July 1995
4.2. Route Optimization Authentication Extension
The Route Optimization Authentication extension is used to
authenticate certain Route Optimization management messages.
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 | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
97
Length
The length of the Authenticator
Authenticator
(variable length) A hash value taken over a stream of bytes
including the shared secret, all prior extensions in their
entirety, the the Route Optimization management data, and
the type and length of this extension, but not including the
Authenticator field itself.
Johnson and Perkins Expires 7 January 1996 [Page 19]
Internet Draft Route Optimization in Mobile IP 7 July 1995
4.3. Home Agent Registration Key Request Extension
The Home Agent Registration Key Request extension may be used in
Registration Request messages to request a registration key from
the mobile node's home agent. The extension is authenticated along
with the rest of the Registration Request message, and thus no
additional authenticator is included in the extension. In response
to a Home Agent Registration Key Request extension, the home agent
MAY include a Mobile Node Registration Key extension and a Foreign
Agent Registration Key extension in its Registration Reply message,
containing encrypted copies of the registration key for the mobile
node the foreign agent, respectively.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
98
Length
0
The mobility security association assumed to exist between the home
agent and the mobile node will be used to encrypt the key sent in
the Mobile Node Registration Key Reply extension, unless a Key
Identification extension is also included with the Registration
Request message.
Johnson and Perkins Expires 7 January 1996 [Page 20]
Internet Draft Route Optimization in Mobile IP 7 July 1995
4.4. Mobile Node Registration Key Reply Extension
The Mobile Node Registration Key Reply extension may be used in
Registration Reply messages to send a registration key from the
mobile node's home agent to the mobile node. When used, the home
agent MUST also include a Foreign Agent Registration Key Reply
extension in the Registration Reply message, giving a copy of the
same key to the mobile node's new foreign agent. The Mobile Node
Registration Key Reply extension is authenticated along with the
rest of the Registration Reply message, and thus no additional
authenticator is included in the extension.
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 | Mobile Node Encrypted Key ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
99
Length
The length of the Mobile Node Encrypted Key
Mobile Node Encrypted Key
(variable length) The registration key, chosen by the home
agent, encrypted based on the mobility security association
between the home agent and the mobile node. The same key must
be sent, encrypted for the foreign agent in a Foreign Agent
Registration Key extension in this Registration Reply message.
Johnson and Perkins Expires 7 January 1996 [Page 21]
Internet Draft Route Optimization in Mobile IP 7 July 1995
4.5. Foreign Agent Registration Key Reply Extension
The Foreign Agent Registration Key Reply extension may be used
in Registration Reply messages to send a registration key from
the mobile node's home agent to the mobile node's new foreign
agent. When used, the home agent MUST also include a Mobile Node
Registration Key Reply extension in the Registration Reply message,
giving a copy of the same key to the mobile node. The Foreign Agent
Registration Key Reply extension is authenticated by including an
authenticator in the extension, computed based on the mobility
security association shared between the home agent and the foreign
agent.
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 | Foreign Agent Encrypted Key ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
100
Length
The length of the Foreign Agent Encrypted Key plus the length
of the Authenticator
Foreign Agent Encrypted Key
(variable length) The registration key, chosen by the home
agent, encrypted based on the mobility security association
between the home agent and the foreign agent. The same key
must be sent, encrypted for the mobile node in a Mobile Node
Registration Key extension in this Registration Reply message.
Authenticator
(variable length) A hash value taken over a stream of bytes
including the shared secret and the fields in this extension
other than the Authenticator field itself.
Johnson and Perkins Expires 7 January 1996 [Page 22]
Internet Draft Route Optimization in Mobile IP 7 July 1995
4.6. Diffie-Hellman Registration Key Request Extension
The Diffie-Hellman Registration Key Request extension may be included
in a Registration Request message sent to a foreign agent. It begins
the Diffie-Hellman key exchange algorithm [2] between the mobile node
and its new foreign agent, as described in Section 2.5. The foreign
agent SHOULD then include a Diffie-Hellman Registration Key Reply
extension in its Registration Reply message sent to the mobile node
in order to complete the key exchange.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| p ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| g ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| g**x mod p ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
101
Length
2 plus 3 times the length of each of p, g, and g**x mod p. The
values p, g, and g**x mod p must all be the same length, which
must be a multiple of 8 bits.
p
One of the two public numbers involved in the Diffie-Hellman
key exchange algorithm. The value p should be a large prime
number.
g
One of the two public numbers involved in the Diffie-Hellman
key exchange algorithm. The value g should be less than p, and
should be a primitive root of p.
g**x mod p
The mobile node chooses a large random number, x, and includes
the computed value g**x mod p in the extension.
Johnson and Perkins Expires 7 January 1996 [Page 23]
Internet Draft Route Optimization in Mobile IP 7 July 1995
4.7. Diffie-Hellman Registration Key Reply Extension
The Diffie-Hellman Registration Key Reply extension SHOULD be
included in a Registration Reply message sent by a foreign agent to
a mobile node that include a Diffie-Hellman Registration Key Request
extension in its Registration Request message to the foreign agent.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| g**y mod p ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
101
Length
2 plus the length of g**y mod p. The length of g**y mod p must
be a multiple of 8 bits.
g**x mod p
The foreign agent chooses a large random number, y, and
includes the computed value g**y mod p in the extension.
The values of g and p are taken from the Diffie-Hellman
Registration Key Request extension from the mobile node's
Registration Request message.
Johnson and Perkins Expires 7 January 1996 [Page 24]
Internet Draft Route Optimization in Mobile IP 7 July 1995
5. Mobility Security Association Management
One of the most difficult aspects of Route Optimization for Mobile IP
in the Internet today is that of providing authentication for all
messages that affect the routing of datagrams to a mobile node.
In the base Mobile IP protocol, all routing of datagrams to the
mobile node while away from its home network is controlled by the
home agent, since only the home agent is aware of the mobile node's
mobility binding and only the home agent tunnels datagrams to
the mobile node. Authentication is achieved based on a manually
established mobility security association between the home agent and
the mobile node. Since the home agent and the mobile node are both
owned by the same organization (both are assigned IP addresses within
the same IP subnet), this manual configuration is manageable, and
(for example) can be performed while the mobile node is at home.
However, with Route Optimization, authentication is more difficult
to manage, since a Binding Update may in general need to any node in
the Internet. Since no general authentication or key distribution
protocol is available in the Internet today, the Route Optimization
procedures defined in this document make use of the same type of
manually configured mobility security associations used in the base
Mobile IP protocol. For use with Route Optimization, a mobility
security association held by a correspondent node or a foreign agent
must in general include the same parameters as required by the base
Mobile IP protocol specification [6].
For a correspondent node to be able to create a binding cache entry
for a mobile node so that it can tunnel its own IP datagrams directly
to the mobile node at its current location, the correspondent node
and the mobile node's home agent must have established a mobility
security association. This mobility security association, though,
may be used in creating and updating binding cache entries at this
correspondent node for all mobile nodes served by this home agent.
This places the correspondent node in a fairly natural relationship
with respect to the mobile nodes served by this home agent. For
example, these mobile nodes may represent different people affiliated
with the organization owning the home agent and these mobile nodes,
with which the user of this correspondent node often collaborates.
In this case, the effort of establishing the necessary mobility
security association with this home agent may be justified. It is
similarly possible for a home agent to have a manually established
mobility security association with the foreign agents often used by
its mobile nodes, or for a particular mobile node to have a manually
established mobility security association with the foreign agents
serving the foreign networks that it often visits.
Johnson and Perkins Expires 7 January 1996 [Page 25]
Internet Draft Route Optimization in Mobile IP 7 July 1995
In general, if the movement and communication patterns of a mobile
node or the group of mobile nodes served by the same home agent are
sufficient to justify establishing a mobility security association
with the mobile node's home agent, users or network administrators
are likely to do so. Without establishing a mobility security
association, nodes will not currently be able to use the Route
Optimization extensions but can use the base Mobile IP protocol; in
this case, though, datagrams destined for a mobile node have to be
routed through the mobile node's home agent, to be tunneled to the
mobile node's current location.
Johnson and Perkins Expires 7 January 1996 [Page 26]
Internet Draft Route Optimization in Mobile IP 7 July 1995
6. Binding Cache Considerations
Any node may maintain a binding cache in order to optimize its own
communication with mobile nodes. When sending an IP datagram, if the
sending node has a binding cache entry for the destination node, it
MAY tunnel the datagram to the mobile node's care-of address using
the encapsulation techniques described for home agents in the base
Mobile IP protocol specification [6]. Any optional encapsulation
methods supported are indicated by flag bits in the Binding Update
message.
When a mobile node's home agent intercepts a datagram on the home
network and tunnels it to the mobile node, the originating node
generally has no binding cache entry for the destination mobile node.
In such cases, the home agent MAY send a Binding Update message to
the originator.
Similarly, when a node other than the foreign agent currently
serving a mobile node receives a datagram for a mobile node, and
this datagram has been tunneled to that node, the node tunneling
the datagram generally has an out-of-date binding for the mobile
node in its binding cache. In such cases, the node receiving the
tunneled datagram MAY send a Binding Warning message to the tunneling
node, which SHOULD then request a new binding for the mobile node by
sending a Binding Request message to the mobile node's home agent.
6.1. Cache Management
A node maintaining a binding cache may use any reasonable strategy
for managing the space within the cache. When a new entry needs to
be added to the binding cache, the node MAY choose to drop any entry
already in the cache, if needed, to make space for the new entry.
For example, a "least-recently used" (LRU) strategy for cache entry
replacement is likely to work well.
Each binding in the binding cache also has an associated lifetime,
specified by in the Binding Update message in which the node obtained
the binding. After the expiration of this time period, the binding
MUST be deleted from the cache.
6.2. Receiving Binding Warning Messages
A node maintaining and using a binding cache will receive a Binding
Warning message if its binding cache entry for a datagram it has
tunneled is out-of-date, as determined by the node which receives the
tunneled datagram. When a node receives a Binding Warning message,
Johnson and Perkins Expires 7 January 1996 [Page 27]
Internet Draft Route Optimization in Mobile IP 7 July 1995
it SHOULD request an updated binding for this mobile node from the
mobile node's home agent, using a Binding Request message. Included
in the Binding Request message is a 64-bit identification field, in
the same format described in the base Mobile IP protocol document,
for matching the request with the returned Binding Update message.
The node SHOULD silently discard any Binding Update messages that
do not correspond with its latest Binding Request message for this
mobile node.
6.3. Receiving Binding Update Messages
When a node receives a Binding Update message, it MUST verify
the authentication in the message, using the mobility security
association it shares with the mobile node's home agent. The
authentication data is found in the Route Optimization Authentication
extension (Section 4.2). If the authentication succeeds, then a
binding cache entry SHOULD be updated for use in future transmissions
of data to the mobile node. Otherwise, an authentication exception
SHOULD be raised.
6.4. Using Special Tunnels
Whenever any node receives a tunneled datagram for for which it has
no binding cache entry or visitor list entry for the datagram's
destination, the node may deduce then it has received the tunneled
datagram in error. In this case, the node should forward the
datagram to the destination mobile node's home agent. This tunneling
should be done using a special form of tunneling called a "special
tunnel", in which the tunneled datagram's destination address is
set equal to the destination address in the tunneled datagram.
Thus, both the "inner" and "outer" destination addresses are set to
the home address of the mobile node. The tunneled datagram will
thus be routed to the mobile node's home network, where it will be
intercepted by the mobile node's home agent in the same way as other
datagrams addressed to the mobile node.
The home agent should then tunnel the datagram to the current care-of
address for the mobile node. However, the home agent MUST NOT tunnel
the datagram to the current care-of address if the special tunnel
of the datagram originated at that care-of address. The use of the
special tunnel format allows the home agent to identify the node
that tunneled the datagram to it (as well as the original sender of
the datagram). If the home agent believes that the current care-of
address for the mobile node is the same as the source of the special
tunnel, then the home agent SHOULD discard the datagram; in this
case, the foreign agent serving the mobile node appears to have lost
Johnson and Perkins Expires 7 January 1996 [Page 28]
Internet Draft Route Optimization in Mobile IP 7 July 1995
its entry for the mobile node in its visitor list, for example, if
the foreign agent has crashed and rebooted.
After tunneling the datagram to the current care-of address for the
mobile node, the home agent MAY notify the source of the special
tunnel of the mobile node's current binding, by sending it a Binding
Update message.
Johnson and Perkins Expires 7 January 1996 [Page 29]
Internet Draft Route Optimization in Mobile IP 7 July 1995
7. Home Agent Considerations
The home agent will be the frequent source of Binding Update messages
sent to correspondent nodes that are communicating with its mobile
nodes. Any correspondent node that has no binding cache entry for a
mobile node, will send normal, untunneled datagrams through the home
agent by the normal routing in the Internet. When the home agent
first receives a datagram for a mobile node, it SHOULD also send a
Binding Update message to the originator of the datagram in hopes
that the originator will be able to create a binding cache entry for
that mobile node. Then, future datagrams sent by this node to the
mobile node should not need the involvement of the home agent.
As the Route Optimization extensions to the base Mobile IP protocol
become widely implemented and deployed, more and more Internet nodes
will be able to maintain a binding cache, and it is hoped that home
agents will need to be involved only rarely with routing datagrams to
mobile nodes. The home agent might usually need to be involved only
when a correspondent node first begins sending datagrams to a mobile
node to which it has not sent previous datagrams within some long
period of time.
7.1. Rate Limiting
A home agent must provide some mechanism to limit the rate at which
it sends Binding Update messages to to the same node about any given
mobility binding, after tunneling a datagram intercepted on the home
network. This is especially important because it is expected that,
within the short term, many Internet nodes will not be equipped with
a binding cache. In this case, continual transmissions of Binding
Warning messages to such a correspondent node will only exacerbate
the problem of the traffic bottleneck at the home agent, and will
unnecessarily waste Internet resources between the home agent and the
correspondent node.
7.2. Receiving Binding Request Messages
When the home agent receives a Binding Request message, it consults
its home list and determines the correct binding information to be
sent to the requesting node. Before satisfying the request, the
home agent must check whether or not the mobile node has allowed the
information to be disseminated. If the mobile node specified the 'P'
bit in its Registration Request message, then the home agent must not
satisfy any Binding Requests. In this case, the home agent SHOULD
return Binding Update in which both the care-of address and the
lifetime are set to zero. Such a Binding Update message indicates
Johnson and Perkins Expires 7 January 1996 [Page 30]
Internet Draft Route Optimization in Mobile IP 7 July 1995
that the binding cache entry for the specified mobile node should
be deleted. This situation can never arise by the action of any
correctly operating node maintaining a binding cache, but it is still
possible that an intelligent correspondent node might try to obtain
bindings for mobile nodes.
7.3. Receiving Registration Key Requests
When the home agent receives a Registration Request message, a Home
Agent Registration Key Request extension (Section 4.3) may be present
in the message, requesting the home agent to provide a registration
key to the mobile node and its foreign agent, as described in
Section 2.2. In that event, the home agent employs a good algorithm
for producing random keys [4] and encrypts the result separately for
use by the foreign agent and by the mobile node. The chosen key is
encrypted under a key and algorithm shared between the home agent and
the mobile node, and the encrypted key is placed in a Mobile Node
Registration Key Reply extension (Section 4.4) in the Registration
Reply message. The same key also is encrypted under a key and
algorithm shared between the home agent and the foreign agent, and
the encrypted key is placed in a Foreign Agent Registration Key Reply
extension (Section 4.5) in the Registration Reply message.
7.4. Receiving Special Tunnels
The home agent may also receive tunneled datagrams destined for the
mobile node. If the tunnel source is the same as the foreign agent
shown in the home list entry for the mobile node, then the home
agent MUST NOT send the datagram back to that same foreign agent.
Otherwise, the home agent can tunnel the tunneled datagram to the
current foreign agent, encapsulating the incoming tunneled datagram
in its entirety.
The home agent also, in this case, takes responsibility for sending
information to the originator of the datagram (whose source address
will be in the inner datagram header inside the encapsulation), to
allow that originator to update its binding cache entry for the
target mobile node. If the home agent has a mobility security
association with the correspondent node which originated the
datagram, an authenticated Binding Update message can be sent
directly.
Johnson and Perkins Expires 7 January 1996 [Page 31]
Internet Draft Route Optimization in Mobile IP 7 July 1995
8. Foreign Agent Considerations
In addition to managing the resources needed to handle registrations
in the base Mobile IP protocol, the foreign agent assisting with
Route Optimization assumes two additional responsibilities. The
first is the maintenance of a binding cache for forwarding datagrams
to mobile nodes as they switch connections to new foreign agents.
The second is a small modification to the registration procedure, to
allow for timely notification possible for previous foreign agents.
8.1. Establishing a Registration Key
As part of the registration procedure, a mobile node and its new
foreign agent can establish a registration key. This registration
key is, as described in Section 7.3, computed by the mobile node's
home agent and transmitted back to the foreign agent (and to
the mobile node) in the Registration Reply message. Within this
document, the registration key is used only for authentication of a
single Binding Update message; other uses for the registration key
are possible, but are outside the scope of this discussion. For
instance, the foreign agent and mobile node may negotiate to use
the registration key to provide privacy along the wireless link
connecting them.
The actual request for the registration key is made by the mobile
node (Section 2.2). When the foreign agent receives the Registration
Reply containing a Foreign Agent Registration Key Reply extension
and a Mobile Node Registration Key Reply extension, the foreign
agent removes the extension containing its own registration key,
and forwards the rest of the Registration Reply message to the
mobile node. The Foreign Agent Registration Key Reply extension
is covered by its own authentication, not by the authentication
covering the Registration Reply message itself, and thus removing the
Foreign Agent Registration Key Reply extension does not interfere
with the mobile node's ability to verify the authentication on the
Registration Reply message.
8.2. Previous Foreign Agent Notification
When a mobile node registers with a new foreign agent, it may request
that the new foreign agent send a Binding Update message to its
previous foreign agent. This Binding Update must be authenticated,
using the Route Optimization Authentication extension (Section 4.2),
as must all Binding Updates. The Acknowledge bit in this Binding
Update message must be set.
Johnson and Perkins Expires 7 January 1996 [Page 32]
Internet Draft Route Optimization in Mobile IP 7 July 1995
When the previous foreign agent receives the Binding Update, it will
use the mobility security association set up with the mobile node
during its previous registration to authenticate the message. If
the message authentication is correct, the old visitor list entry
will be deleted and a Binding Acknowledge message returned to the
sender. In addition, if a new care-of address was included with the
new binding, a binding cache entry will be created for it, and the
previous foreign agent can tunnel datagrams to the mobile node's
current care-of address using that binding cache, just as any node
maintaining a binding cache.
In particular, the previous foreign agent can tunnel the Binding
Acknowledge message back to the new care-of address specified in
the received binding. This creates an interesting problem for the
new foreign agent when it receives the acknowledgment before the
registration reply from the home agent. It is suggested that the new
foreign agent deliver the acknowledgment to the mobile node anyway,
even though the mobile node is technically unregistered. If there
is concern that this provides a loophole for unauthorized traffic
to the mobile node, the new foreign agent could limit the number of
datagrams delivered to the unregistered mobile node to this single
instance. Alternatively, a new extension to the Registration Reply
message can be defined to carry along the acknowledgement from the
previous foreign agent. This latter approach would have the benefit
that fewer datagrams would be transmitted over bandwidth-constrained
wireless media during registrations.
The lifetime associated with the binding cache, in this situation,
can be substantially shorter than other binding caches for several
reasons. First, the home agent is presumably tunneling datagrams to
the new foreign agent; second, any active correspondent node will
probably get a new binding cache entry for the mobile node after
receiving the Binding Warning message from the previous foreign
agent. Lastly, even if the binding cache entry expires prematurely,
the previous foreign agent can special tunnel any straggling
datagrams back to the home agent for further delivery.
8.3. Receiving Tunneled Datagrams
If the mobile node's current foreign agent receives a tunneled
datagram for the mobile node, it can be assumed that the tunneled
datagram was originated by a node maintaining a binding cache.
There may be pathological or special cases where this assumption is
false, but one would almost have to intentionally run custom code
to invalidate the assumption. Since the foreign agent currently
serving a mobile node can assume that the sending node forwarded the
datagram based on correct binding cache information, the foreign
Johnson and Perkins Expires 7 January 1996 [Page 33]
Internet Draft Route Optimization in Mobile IP 7 July 1995
agent can also assume that the sending cache agent has already issued
notification to the source of the original datagram. Thus, the
current foreign agent never needs to send a Binding Warning message
to the node which last tunneled the datagram.
On the other hand, a foreign agent which is tunneling received
datagrams on behalf of a mobile node not in its visitor list should,
just as any other node implementing Route Optimization, send Binding
Warning messages to the originator of these datagrams. If the
datagrams it receives are not tunneled, the foreign agent should
limit the rate at which it sends Binding Warning messages to the
originators, since those originators may be unable to interpret such
notifications. It is expected that reception of such un-tunneled
datagrams by any foreign agent will be rare.
8.4. Sending Special Tunnels
If a foreign agent receives a tunneled datagram for a mobile node
which is unknown, then the foreign agent can tunnel the datagram back
to the home agent. This requires special care at the home agent.
The foreign agent must use the mobile node's address as the tunnel
destination, and its own address as the tunnel source. The home
agent will then capture the special tunneled datagram and re-tunnel
it to the mobile node via its current foreign agent. The foreign
agent sending the special tunnel should not notify the originator of
the datagram about its out-of-date binding, as this will be done by
the home agent which receives the special tunnel datagram.
Johnson and Perkins Expires 7 January 1996 [Page 34]
Internet Draft Route Optimization in Mobile IP 7 July 1995
9. Mobile Node Considerations
9.1. Requesting a Registration Key
When a mobile node sends a Registration Request message, it can
also request a registration key to be established between itself
and the prospective foreign agent. The key will be used later to
authenticate the Binding Update sent to this foreign agent to notify
it that the mobile node has moved to a new care-of address. The
mobile node allows the home agent to pick the registration key,
because it is expected that the mobile node is less likely to have
good means for producing pseudo-random numbers [4]. The registration
key will be returned to the mobile node in a Mobile Node Registration
Key Reply extension to the Registration Reply message from the home
agent. A separate copy of the registration key is also returned to
the foreign agent in a Foreign Agent Registration Key Reply extension
to the Registration Reply message.
9.2. Notifying Previous Foreign Agents
If the mobile node wishes to instruct its prospective foreign agent
to send a Binding Update message to the mobile node's previous
foreign agent, it includes a Previous Foreign Agent Notification
extension (Section 4.1) in its Registration Request message. This
notification usually results in quicker establishment of a binding
cache entry at the previous foreign agent, because the previous
foreign agent is likely to be much closer to the new foreign agent
than the home agent is.
Since the prospective new foreign agent does not have access to
the registration key which was established between the mobile node
and its previous foreign agent, the mobile node must compute the
appropriate authentication value for use by the prospective foreign
agent. This authentication is computed over the fields of the
expected Binding Update message.
When the Binding Acknowledgment message from the previous foreign
agent is received by the new foreign agent, it detunnels it and
sends it to the mobile node. In this way, the mobile node can
still discover that its previous foreign agent has updated its
visitor list and binding cache. This is important, because otherwise
the previous foreign agent would often become a "black hole" for
datagrams destined for the mobile node. The new foreign agent has no
further responsibility for helping to update the binding cache at the
previous foreign agent.
Johnson and Perkins Expires 7 January 1996 [Page 35]
Internet Draft Route Optimization in Mobile IP 7 July 1995
The mobile node expects to eventually receive a Binding
Acknowledgement from its previous foreign agent, signifying that the
mobile node's entry has been erased from its visitor list. If the
acknowledgement has not been received after sufficient time, the
mobile node is responsible for retransmitting another Binding Update
message to its previous foreign agent. Although the previous foreign
agent may have already deleted the registration key from its records,
the mobile node should continue to retransmit its Binding Update
message until the previous foreign agent responds with a Binding
Acknowledgement.
Since the mobile node is responsible for handling the Binding
Acknowledgement from its previous foreign agent, there is no need
to add any status code or bit to the Registration Reply from its
prospective new foreign agent
Johnson and Perkins Expires 7 January 1996 [Page 36]
Internet Draft Route Optimization in Mobile IP 7 July 1995
References
[1] CDPD Forum. Cellular Digital Packet Data system specification.
Release 1.0, July 1993.
[2] W. Diffie and M. E. Hellman. New directions in cryptography.
IEEE Transactions on Information Theory, IT-22(6):644--654,
November 1976.
[3] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541,
October 1993.
[4] Donald E. Eastlake 3rd, Stephen D. Crocker, and Jeffrey I.
Schiller. Randomness recommendations for security. RFC 1750,
December 1994.
[5] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic
Routing Encapsulation (GRE). RFC 1701, October 1994.
[6] Charles Perkins, editor. IP mobility support. Internet Draft,
draft-ietf-mobileip-protocol-10.txt, May 1995. Work in progress.
Johnson and Perkins Expires 7 January 1996 [Page 37]
Internet Draft Route Optimization in Mobile IP 7 July 1995
Appendix A. Using a Master Key at the Home Agent
Rather than storing each mobility security association that it has
established with many different correspondent nodes and foreign
agents, a home agent may manage its mobility security associations so
that each of them can be generated from a single "master" key. With
the master key, the home agent could build a key for any given other
node by computing the node-specific key as
MD5(node-address || master-key || node-address)
where node-address is the IP address of the particular node for which
the home agent is building a key, and master-key is the single master
key held by the home agent for all mobility security associations it
has established with correspondent nodes. The node-specific key is
built by computing an MD5 hash over a string consisting of the master
key with the node-address concatenated as a prefix and as a suffix.
Using this scheme, when establishing each mobility security
association, the network administrator managing the home agent
computes the node-specific key and communicates this key to the
network administrator of the other node through some "secure"
channel, such as over the telephone. The mobility security
association is configured at this other node in the same way as any
mobility security association. At the home agent, though, no record
need be kept that this key has been given out. The home agent need
only be configured to know that this scheme is in use for all of its
mobility security associations.
When the home agent then needs a mobility security association as
part of the Route Optimization protocol, it builds the node-specific
key based on the master key and the IP address of the other node with
which it is attempting to authenticate. If the other node knows
the correct node-specific key, the authentication will succeed;
otherwise, it will fail as it should.
Johnson and Perkins Expires 7 January 1996 [Page 38]
Internet Draft Route Optimization in Mobile IP 7 July 1995
Chairs' Addresses
The working group can be contacted via the current chairs:
Tony Li
cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
Phone: +1-408-526-8186
E-mail: tli@cisco.com
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Road
Schaumburg, IL 60196
Phone: +1-708-576-2753
E-mail: solomon@comm.mot.com
Johnson and Perkins Expires 7 January 1996 [Page 39]
Internet Draft Route Optimization in Mobile IP 7 July 1995
Authors' Addresses
Questions about this document can also be directed to the authors:
David B. Johnson
Computer Science Department
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213-3891
Phone: +1-412-268-7399
Fax: +1-412-268-5576
E-mail: dbj@cs.cmu.edu
Charles Perkins
Room J1-A25
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Phone: +1-914-784-7350
Fax: +1-914-784-7007
E-mail: perk@watson.ibm.com
Johnson and Perkins Expires 7 January 1996 [Page 40]
