Mobile IP Working Group Rajeev Koodli
INTERNET DRAFT Charles E. Perkins
13 July 2000 Communication Systems Laboratory
Nokia Research Center
A Framework for Smooth Handovers with Mobile IPv6
draft-koodli-mobileip-smoothv6-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
This document is an individual submission for the mobile-ip Working
Group of the Internet Engineering Task Force (IETF). Comments should be
submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.
Distribution of this memo is unlimited.
Abstract
During handover from one access router to another, a wireless mobile
node may need to have a certain amount of state information passed from
the Previous-Router to the new one. This document specifies extensions
to Mobile IPv6 which allow additional control structures enabling the
transfer of the necessary state during handovers. This state transfer
allows the applications running on the mobile node to operate with
reduced latency, minimal disruption, and reduced packet loss during
handovers.
Koodli, Perkins Expires 13 January 2001 [Page i]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Overview 2
3. Smooth Handover Initiate (SHIN) Destination Option 5
4. Smooth Handover Request Message (SHREQ) 8
5. Smooth Handover Reply (SHREP) Message 9
6. Smooth Handover Acknowledgement (SHACK) Message 10
7. NCMA Hand-over 11
8. Configurable Parameters 12
9. Security Considerations 12
10. Acknowledgements 12
Addresses 13
Koodli, Perkins Expires 13 January 2001 [Page 1]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
1. Introduction
With the advent of real-time applications such as VoIP, it has become
extremely important to address efficient handovers in Mobile IP. When a
Mobile Node (MN) running a real-time application undergoes hand-over,
the hand-over not only needs to be fast, it also needs to support
such features as state transfer (e.g., for header compression state
relocation) and buffer management (in order to reduce packet loss for
glitch-free operation). For this, enhancements to Mobile IP are needed.
This document proposes a framework using Mobile IP that facilitates
"smooth" hand-overs with reduced latency, packet loss, and allows a MN
to operate with minimal disruption. We assume IPv6 in our presentation
here. Applicability of the proposed scheme for IPv4 is out of scope of
this specification, but might be done in a very similar way using some
newly specified extensions to be associated with the proposed Previous
Foreign Agent Notification extension [5].
2. Overview
Handover operations are complicated by the possible existence of
a substantial amount of state information associated with the mobile
node while it is attached to the local network links. When the mobile
node moves to a new point of attachment, it is likely (depending upon
the specific feature) that some or all of the state associated with
the mobile node for that feature will have to be transferred to the
mobility agent (i.e., the router) serving the mobile node's new point
of attachment. In this document, we specify common protocol structures
that are intended to handle all such context handover requirements.
Other documents are needed to specify the specific protocol structures
to be used for handling the context information associated with specific
features such as header compression, buffering, regional registration,
or Quality of Service.
We consider the scenario shown in Figure 1 as the basis for our
discussion. In Figure 1, a MN undergoes hand-over to a New-Router
(Nrtr) from a Previous-Router (Prtr). As a result of hand-over, the MN
requests transfer of information, both control state and data packets,
from the Previous-Router to the New-Router.
Broadly speaking, we classify hand-over scenarios into two cases. In
a "Network-Controlled, Mobile-Assisted" (NCMA) scenario, some entity
within the local network domain determines, and hence knows, which
router the MN will get attached to next due to handover. In this case,
the Previous-Router serving the mobile node can potentially set up the
required state at the New-Router almost as soon as (or even before) a
new link is established for the MN.
Koodli, Perkins Expires 13 January 2001 [Page 2]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
| MN +-----------+
+-+ | Previous | <
| | ---------- | Router | ------ > ----\
+-+ | (Prtr) | < \
| | \
| +-----------+ +--------+
| ^ IP | Corr. |
| | Network | Node |
V | +--------+
v /
| MN +-----------+ /
+-+ | New | < /
| | ---------- | Router | ------ > ----/
+-+ | (Nrtr) | <
| |
+-----------+
Figure 1: Reference Scenario for Hand-over
In the "Mobile-Controlled, Network-(un)Assisted" (MCNA) scenario
however, some mobile-aware entity in the local domain may notify the
MN's IP layer about an impending handover, so that the MN may prepare to
send Mobile IP(v6) messages right away. However, beyond this generic
notification, no other function is initiated regarding state transfer.
It is also possible that no indication of an impending handover is
detected by the IP layer in the MN. In both of these cases, the MN
performs necessary signaling for state transfer.
The first action after a mobile node moves to a new point of IPv6
attachment will be Neighbor Discovery [4]. To enable the effective use
of SHIN messages by the mobile node, the Router Advertisement messages
SHOULD carry information to guide the mobile node in its selection
of handover features. Since there are multiple features that may be
in use, each feature may be represented by using an appropriate data
structure in the Router Advertisement message. The representation and
use of such data structures is feature dependent and is beyond the scope
of this framework document.
After configuring a new Care-of Address, a mobile node using Mobile
IPv6 has to send a Binding Update to its home agent (or perhaps a nearer
regional mobility agent). The Binding Update is carried along with a
Smooth Handover INitiate (SHIN) that is delivered to the default router
Koodli, Perkins Expires 13 January 2001 [Page 3]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
(New-Router in Figure 1). The smooth handover request resides in a
Destination Option that contains suboptions for each desired feature.
The following figure shows the overall message structure: In the
+--------------------------------------------------------------+
| IPv6 header | SHIN option | IPv6 header | Binding Update |
+--------------------------------------------------------------+
Figure 2: Overall Message Structure for Smooth
Handover Initiate Message
figure, SHIN is a new destination option with suboptions for each
feature type. The Binding Update packet, addressed to the mobility
agent which maintains the care-of address of the mobile node, is
encapsulated with a new IPv6 header, and the new handover option is
placed in front of the encapsulated Binding Request.
The structure for suboptions to the SHIN Destination Option is as
follows:
1. SHIN Destination Options hdr
2. Suboptions for new router
3. Suboptions for use by both new and previous router
4. Authentication data
5. Suboptions for previous router
The encapsulating header is addressed to the New-Router, which then
takes charge of transferring context associated with the mobile node
from the previous point of attachment to the mobile node's new point
of attachment. This requires new messages to be sent between the two
routers. The content of these messages depends upon the particular
suboptions of the SHIN Destination Option as selected by the mobile
node.
In this document, we specify the SHIN Destination Option and some
generally useful suboptions. Other suboptions, useful only in the
context of specific features, are specified in other documents.
We start with the MCNA case first.
Koodli, Perkins Expires 13 January 2001 [Page 4]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
We consider two general cases: assisted handover and un-assisted
handover. In "assisted" handover, the MN detects that a new link layer
with a different network prefix is available. In this assisted case,
the MN sends an unsolicited Router Solicitation message, receives
a Router Advertisement message, and then sends a combined Smooth
Handover Initiate and Binding Update message shown in Figure 2. In the
un-assisted case, the MN learns that it has undergone handover when
it receives a new Router Advertisement message, and it simply sends a
combined Smooth Hand-over Initiate and BU message shown in Figure 2.
When the New-Router receives a Smooth Handover Initiate (SHIN)
destination option (as described in section 3), it identifies the
suboptions within the SHIN and constructs a new message for the
Previous-Router which requests the context handover. This message,
called the Smooth Handover Request (SHREQ) message, MAY use appropriate
security protection and is described in section 4. The New-Router then
decapsulates the Binding Update packet and transmits it to the intended
recipient.
When the Previous-Router receives the SHREQ message (see section 4),
it MUST check to see whether it has a security association with the New
Router. If so, the Previous Router MUST check for the presence and
validity of an IPv6 Authentication Option [2]. Then the Previous Router
MUST check for the presence and validity of the SHREQ Authentication
Suboption data supplied by the mobile node to make sure that the
handover has been authorized by the mobile node. This verification is
done as part of processing the destination option which includes the
sub-option supplied by the mobile node to the Previous-Router. The
Previous-Router then formulates a Smooth Handover Reply (SHREP) message
and begins to insert appropriate structures into the message for the
context transfer. It is important that context for the mobile node
be not destroyed at the Previous-Router without authorization. After
gathering all the requested state for the smooth handover, and sending
it to the New-Router in the SHREP message, the Previous-Router has to
keep the context data for the mobile node intact for CONTEXT_SAVE_TIME
in order to allow recovery in case a SHREP message is lost and not
received by the router sending the SHREQ message.
3. Smooth Handover Initiate (SHIN) Destination Option
The Smooth Handover Initiate destination option is an envelope for
containing suboptions, prefixed by some fields that are generally
expected to be useful for all suboptions.
IP fields (in encapsulating header):
Source address
The New CoA of the MN
Koodli, Perkins Expires 13 January 2001 [Page 5]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Header (NH = DestOpts) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH = IPv6 | Hdr Ext Len | Op-Type=SHIN | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128-bit Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128-bit Previous Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| Feature Data for Nrtr only
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| Feature Data for Nrtr + Prtr
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SOType=AuthPrtr| Sub-Option Len| Reserved | Replay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Authentication Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| Feature Data for Prtr only
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Header (NH = DestOpts) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH = NONE | Binding Update to HA/Regional Mobility Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Smooth Handover Initiate Destination Option Format
Destination Address
The global IP address of the
New-Router
Option Type Smooth Handover Initiate (SHIN)
Option Length Variable
Reserved Reserved for future use. Must be set to zero
by the MN.
Replay A value used to make sure that each use of the
Smooth Handover Initiate destination option is
uniquely identifiable.
Koodli, Perkins Expires 13 January 2001 [Page 6]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
Authentication Data
An unforgeable value calculated as discussed
below.
Suboptions Feature suboptions included as selected by the
mobile node, in the order specified.
IP fields (in encapsulated header)
Source address
The New CoA of the MN
Destination Address
The global IP address of the mobility
agent to which the mobile node wished
the Binding Update to be delivered.
In order to make sure that context cannot be lost at the previous
router in response to a erroneous action or malicious not initiated by
the mobile node, authentication is required for the handover request.
The Authentication Data (Auth) is calculated as follows:
Auth = HMAC (Key, input_data) mod 2^32
where HMAC (Key, Data) is defined (see RFC 2104 [3] for details) roughly
as follows:
HMAC (Key, Data) = MD5 (Key, MD5 (Key || Data))
and MD5 is defined as given in RFC 1321 [6]. The input_data is defined
as follows:
input_data = HO_features || Replay || Previous_Care-of_Address
where HO_features includes all the sub-option data from the MN to the
Previous-Router.
If a mobile node uses the same features and Previous_Care-of_Address
more than 255 times, then the mobile node SHOULD establish a new
security association with the Previous-Router (i.e., the mobile node's
default router at the Previous Care-of Address).
When the mobile node requests smooth handover features, it also
implicitly requests that the Previous Router establish a binding cache
entry for the mobile node at the new Care-of Address given in the SHREQ
message. This binding cache entry is used to tunnel incoming packets
to the New Router, as specified in [1]. By default, this binding cache
has Lifetime equal to be HO_BINDING_LIFE. At the end of the binding
lifetime, in addition to deleting the binding cache entry giving the
mobile node's new Care-of Address, the Previous Router SHOULD tear down
all existing connection context associated with the mobile node. A
specific feature MAY request a different value for specific feature
context lifetime.
Koodli, Perkins Expires 13 January 2001 [Page 7]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
4. Smooth Handover Request Message (SHREQ)
The Smooth Handover Request (SHREQ) message, illustrated in figure 4,
is sent from the New-Router to the Previous-Router to request that some
feature context associated with the mobile node at the Previous-Router
be sent to the New-Router as part of a smooth handover. The destination
option contains sub-options prefixed by the New and Previous Care-of
Addresses of the MN. The New-Router MUST copy the sub-options supplied
by the MN (in the SHIN message) exclusively for the Previous-Router
verbatim starting from the sub- option type AuthPrtr.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Header (NH = DestOpts) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH = NONE | Hdr Ext Len | Op-Type=SHREQ | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128-bit New Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128-bit Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options feature data for Prtr only from MN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options feature data for Nrtr and Prtr from MN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SOType=AuthPrtr| Sub-Option Len| Reserved | Replay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Authentication Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options feature data for Prtr only from Nrtr
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Smooth Handover Request Message Format
IP fields:
Source address The IP address of the New-Router
Destination Address The IP address of the Previous-Router
Option Type Smooth Handover Request (SHREQ)
Option Length Variable
Koodli, Perkins Expires 13 January 2001 [Page 8]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
Reserved Reserved for future use, set to zero by the MN.
Replay A value used to make sure that each use of the
Smooth Handover Initiate destination option is
uniquely identifiable.
Authentication Data
An unforgeable value calculated as discussed
above.
Suboptions Feature suboptions included as selected by the
mobile node and the New- Router, in the order
specified.
If a router transmits a SHREQ message, and does not receive a SHREP
message within SHREQ_REXMIT_TIME, the router SHOULD retransmit the SHREQ
message. This retransmission should be attempted until SHREQ_RETRIES is
exceeded.
5. Smooth Handover Reply (SHREP) Message
The Smooth Handover Reply (SHREP) message, illustrated in figure 5,
is sent from the Previous-Router to the New-Router to furnish feature
context data associated with the mobile node as part of a smooth
handover.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Header (NH = DestOpts) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH = NONE | Hdr Ext Len | Op-Type=SHREP | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128-bit New Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128-bit Previous Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options for Nrtr only
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options for Nrtr and MN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options for MN only
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Smooth Handover Reply Message Format
Koodli, Perkins Expires 13 January 2001 [Page 9]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
IP fields
Source address The global IP address of the
Previous-Router.
Destination Address The global IP address of the
New-Router.
Option Type Smooth Handover Reply (SHREP)
Option Length Variable
Suboptions
Feature suboptions data appropriate for
each sub-option present in the SHREQ
message in the order specified.
6. Smooth Handover Acknowledgement (SHACK) Message
The Smooth Handover Acknowledgement (SHACK) message, illustrated in
figure 6, MAY be sent from the New-Router to the mobile node in some
cases, to inform the mobile node about the status of its smooth handover
request. The acknowledgment may contain multiple separate status
reports for each relevant feature that was requested. However, unless a
failure has occurred, or else unless required by a specific feature, the
SHACK message is optional. The mobile node MUST be prepared to process
a SHACK message even when no error has occurred.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Header (NH = DestOpts) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NH = NONE | Hdr Ext Len | Op-Type=SHACK | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options response from Nrtr and Prtr
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options response from Prtr only
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Smooth Handover Reply Message Format
Koodli, Perkins Expires 13 January 2001 [Page 10]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
7. NCMA Hand-over
In this type of hand-over, the Previous-Router proactively pushes
state information to the New-Router. This could improve performance
when the MN sends SHIN message as before, since the state would already
be available at the New-Router.
For this purpose, the Previous Router uses the SHREP message,
with all suboptions inserted just as for the MCNA case. In order
for this operation to be secure the Previous Router MUST have a
security association with the New Router, and it MUST include an IPv6
Authentication Header in the unsolicited SHREP message. Otherwise, the
SHREP message is just as described in section 5, except that the New
Care-of Address is set to zero.
When the New Router receives a SHREP, it MUST check for the presence
and validity of an IPv6 Authentication Header using the security
association it has with the Previous Router. It will be able to
characterize the message as an unsolicited SHREP, because the New
Care-of Address will be zero. When the New Router receives a valid
unsolicited SHREP message, it MUST buffer the message for at least
GRAT_SHREP_TIME, or until it receives the corresponding SHIN message
from the mobile node whichever event occurs first.
When the mobile node sends a SHIN to a New Router that has received
an unsolicited SHREP from the Previous Router, the New Router can
immediately complete all necessary context transfers for the smooth
handover.
If the New Router receives an unsolicited SHREP message for a smooth
handover which has already been initiated by a Mobile Node, it SHOULD
silently discard the unsolicited SHREP. The New Router will most likely
already have sent a SHREQ message to the Previous Router requesting the
context transfer which was indicated in the unsolicited SHREP.
Koodli, Perkins Expires 13 January 2001 [Page 11]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
8. Configurable Parameters
Every Mobile IP agent supporting the extensions defined in this
document SHOULD be able to configure each parameter in the following
table. Each table entry contains the name of the parameter, the default
value, and the section of the document in which the parameter first
appears.
Parameter Name Default Value
------------------- -------------
SHREQ_RETRIES 3
SHREQ_REXMIT_TIME 1 seconds
CONTEXT_SAVE_TIME 2 * SHREQ_REXMIT_TIME
HO_BINDING_LIFE 5 seconds
9. Security Considerations
According to this specification, the New-Router transmits the
encapsulated Binding Update immediately upon receipt from the mobile
node. This typically enables a higher grade of service for the
generally honest user at the cost of only a tiny and short-lived
additional vulnerability to malicious use.
Since authentication data is supplied by the mobile node along with
its smooth handover requests, there is substantially no danger of loss
of handover context due to malicious attacks. However, if the mobile
node fails to change its security association with the Previous-Router
(as specified in section 3), an attacker could keep track of all 256
available replay protection values and cause a future disconnection the
next time the mobile node acquires the same care-of address at the same
Previous-Router.
The Previous-Router and the New-Router MAY use authentication for the
SHREQ and SHREP messages depending on their security association.
10. Acknowledgements
The authors wish to thank Robert Chalmers, Hannu Flinck, Govind
Krishnamurthi, Jari Malinen and Manish Tiwari for discussion and review
of this document.
Koodli, Perkins Expires 13 January 2001 [Page 12]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
References
[1] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in
progress).
draft-ietf-mobileip-ipv6-12.txt, April 2000.
[2] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.
[3] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for
Message Authentication. Request for Comments (Informational)
2104, Internet Engineering Task Force, February 1997.
[4] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
[5] C. E. Perkins and D. Johnson. Route Optimization in Mobile IP
(work in progress).
draft-ietf-mobileip-optim-09.txt, February 2000.
[6] R. Rivest. The MD5 Message-Digest Algorithm. Request for
Comments (Informational) 1321, Internet Engineering Task Force,
April 1992.
Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Motorola
6000 Connection Drive 1501 West Shure Drive
M/S M8-540
Irving, Texas 75039 Arlington Heights, IL 60004
USA USA
Phone: +1 972-894-6709 Phone: +1 847-632-3148
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com
Questions about this memo can also be directed to the authors:
Koodli, Perkins Expires 13 January 2001 [Page 13]
Internet Draft Smooth Handovers with Mobile IPv6 13 July 2000
Rajeev Koodli Charles E. Perkins
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Phone: +1-650 625-2359 Phone: +1-650 625-2986
EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502 Fax: +1 650 625-2502
Koodli, Perkins Expires 13 January 2001 [Page 14]