Mobile IP Working Group Rajeev Koodli
INTERNET DRAFT Charles E. Perkins
2 March 2001 Communication Systems Laboratory
Nokia Research Center
Jonathan Trostle
Cisco Systems
Fast Handovers in Mobile IPv6
draft-koodli-mobileip-fastv6-02.txt
Status of This Memo
This document is a submission by 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.
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.
Abstract
When a mobile node moves to a new point of attachment in the
Internet, relying on router advertisements may be insufficient to
insure adequate performance of time-critical applications running on
the mobile node. In many cases, other indications are available to
trigger handover of the mobile node to a new point of attachment,
at a new access router. The mobile node and the access router may
then be able to take steps, in addition to those specified for Mobile
IPv6, to reduce the time during which the mobile node is effectively
disconnected from the Internet. This specification provides security
extensions to the solution proposed in the earlier version of this
Koodli, Perkins, Trostle Expires 2 September 2001 [Page i]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
document for fast handovers. These security extensions are based on
a light-weight version of the Kerberos Authentication Service.
Koodli, Perkins, Trostle Expires 2 September 2001 [Page ii]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
Contents
Status of This Memo i
Abstract i
1. Fast Handover Definition 2
2. Proposal 3
3. Security Extensions 6
4. New Access Router Processing 8
5. ICMP Handover Redirect Message Format 8
5.1. Light-weight Kerberos Authentication sub option . . . . . 10
6. ICMP Handover Message Format 10
6.1. ICMP Handover Authentication Suboption Format . . . . . . 12
6.1.1. Router Solicitation and Advertisement Options . . 13
7. ICMP Handover Error Format 14
8. Security Considerations 14
A. Link Failure 15
B. Alternative to ICMP Handover Message 15
Addresses 16
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 1]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
1. Fast Handover Definition
When a Mobile Node (MN) undergoes handover from one link to another,
it needs to obtain a new care-of address at the New Router as soon
as possible in order to be able to send and receive IP packets. See
Figure 1 for a reference diagram of handover assumed in the rest
of this document. The latency involved in forming a new CoA in
IPv6 comes mainly from Neighbor Discovery, which includes Router
Advertisement and possibly Router Solicitation, and Duplicate Address
Detection (DAD) when stateless auto-configuration is used. After
the mobile node forms a new CoA, it may be able send packets using
the new CoA, but it cannot receive packets at that address until
its mobility agent(s) and correspondent nodes are notified with
Binding Updates. The timeline for these operations is illustrated
in Figure 2. Thus, the delay involved in forming a new CoA must be
reduced so that the mobile node can resume IP packet transmission
quickly, and, the latency involved in forwarding packets to the
mobile node until it successfully informs its mobility agent(s) and
correspondent Node(s) must be reduced as well. We outline a proposal
to reduce these two latencies when handovers are network-controlled,
i.e., some network entity instructs the mobile node to undergo
handover from one access router to another. This network entity
is assumed to know the IP addresses and network prefixes of those
routers.
v +------------+
+-+ | Previous | <
| | ---------- | Router | ------ > ----\
+-+ | (Prtr) | < \
MN | | \
| +------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +------------+ /
+-+ | New | < /
| | ---------- | Router | ------ > ----/
+-+ | (Nrtr) | <
MN | |
+------------+
Figure 1: Reference Scenario for Handover
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 2]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
X-------X-----X--------------X--------> Time
^ ^ ^ ^
| | | |
| | | |
Handover | | |
epoch start | | |
| | |
New | |
link | |
formation | |
| |
| |
ND(+DAD) |
MN forms new |
CoA and sends |
Binding Update |
|
|
Binding Update
received. MN can receive
packets at new CoA
Figure 2: Handover Milestones and Latencies
2. Proposal
Our proposal has the following key components. First, the Previous
Router informs the mobile node to undergo handover, using a new form
of the Neighbor Discovery Redirect message. In this message, the
Previous Router supplies the required information for the mobile
node to form a new CoA as well as obtain the New Router's link-local
and link-layer addresses. Second, subsequent to delivering the
Redirect message, the Previous Router sends a message to the New
Router supplying the mobile node's new CoA and requesting it to act
as a ND Proxy for that address. This message, which could also
include the mobile node's previous CoA, sets up a forwarding path
from the Previous Router to the mobile node's new CoA. Finally, after
establishing the link connectivity, the mobile node sends a message
to the New Router which has the effect of resolving any potential
address conflicts and validating the mobile node's entry in the
New Router's ND cache. This message includes Binding Update as an
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 3]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
encapsulation, so that if the ND cache entry can be validated, the
Binding Update can be sent right away.
In addition to reducing the latencies mentioned earlier (using basic
IPv6 and Mobile IPv6 extensions), the above operations involve
sending minimal number of messages over an air interface, which could
be an important consideration in bandwidth-constrained links.
When the handovers are triggered by the network, with possible
assistance from the mobile node regarding the decision to undergo
handover, the Previous Router determines the network prefix of the
New Router to which the mobile node will get attached to next.
The Previous Router has to obtain one or more network prefix(es),
e.g_from a network entity that controls the handover. Subsequently,
the Previous Router sends a Handover Redirect message (which is
a modified ICMP Redirect) to the mobile node, containing the new
access router's IPv6 address as well as its link-layer IP address
and (implicitly) its link-local address. This typically allows the
mobile node to determine its new CoA while still being attached to
the Previous Router. Optionally, the previous access router MAY
supply a specific care-of address for the mobile node to use when it
establishes its new link to the new access router. The mobile node
should use this new CoA after establishing link connectivity at the
New Router. The Handover Redirect message is specified in section 5.
X-------X-----X--X------------------> Time
^ ^ ^ ^
| | | |
| | | MN ready to
Handover | | send and receive
start epoch | | packets
| |
New |
link |
formation |
|
|
ND(+DAD)
Figure 3: Optimized Handover Delays
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 4]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
After transmitting the Handover Redirect message to the mobile node,
the Previous Router sends a ICMP Handover message (see section 6 to
the New Router, containing the mobile node's new CoA. The New Router
verifies if the new CoA is already in use by simply verifying if an
entry exists in its ND cache entry. If an entry exists, it does
nothing (See below). If an entry does not exist, the New Router
begins to act as a Proxy so that it can respond to any potential
DAD conflicts on its link for the new CoA. This provides means for
avoiding potential DAD conflicts due to selecting an address while
not on-link. The behavior of the New Router as a Proxy is according
to the specifications in [3].
The above message from the Previous Router to the New Router MAY
include security keys (see section 6.1) that the latter could
use when the mobile node establishes connectivity with it. Such
a transfer however, assumes that there is appropriate trust
relationship between the two routers. The solution we propose
in this document is applicable even when there is no such trust
relationship. Furthermore, the message from the Previous Router to
the New Router may also include additional control information, such
as an indication to buffer packets sent to the new CoA, as well as
any other useful context information.
After receiving the Handover Redirect message and forming a new
CoA, the mobile node undergoes Layer 2 handover to establish a new
link to the New Router. Note that the mobile node already has the
New Router's link-local and link-layer addresses. It can thus
send IP packets (including a Binding Update) directly to the New
Router (to forward). However, since the ND cache entry at the New
Router must be verified to ensure a unique address and possibly
validated through authentication, the mobile node first sends a
message to the New Router containing its link-layer address and
an authentication header. This message also includes the Binding
Update as an encapsulated packet. If the New Router can successfully
validate the ND cache entry, then the Binding Update is delivered
right away. If not, an appropriate error message is sent back to the
mobile node, which then has to resort to forming a new CoA if the
address is already in use.
The above message has the effect of propagating the mobile node's
link-layer address (and the security credentials) to the New
Router with the assumption that the IP address is valid. Thus, it
effectively reduces handover latency by the amount of time necessary
for two messaging round-trips -- once, for DAD, and and again for
Neighbor Solicitation and Neighbor Advertisement to determine New
Router's link-layer address. Besides saving handover time, the
handover message also serves to eliminate the bandwidth overhead
which would otherwise be consumed as the mobile node and new access
router perform DAD and Neighbor Discovery messages.
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 5]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
Note that since the Previous Router already has an association from
the previous CoA to the new CoA, the packets could be arriving at the
New Router almost as soon as a new link is established for the mobile
node. Some of these packets that arrive earlier than the mobile
node's establishment of IP connectivity at the New Router could be
lost without appropriate support for buffering.
3. Security Extensions
The main security issues are the security of binding updates and AAA
for network access. Binding updates (BU's) are authenticated with
IPSEC as described in [1]. Network access AAA (or just AAA) will
require authentication and key establishment between the Mobile Node
and the New Router. The New Router will also require authenticated
authorization attributes for the MN. The proposal in this draft for
AAA is based on the requirement that the New Router will not allow
the MN's data packets to flow (although packets destined to the MN
may be buffered) before the MN successfully authenticates itself.
With respect to AAA security, mechanisms that require public key
operations on the MN during fast handover are currently considerably
compute intensive. Kerberos [5] is a possibility, but it would be
better to complete authentication and key establishment in a single
round trip over the air interface, regardless of trust relationships
and realm boundaries. We propose to use a lightweight version of
Kerberos [4]. The primary benefit is that AAA can be accomplished
within a single round trip over the air interface, regardless of the
trust relationship between the New Router and the Previous Router.
Crossrealm lightweight ticket granting tickets (TGT's) also allow AAA
to occur without round trips back to the MN user's home domain, and
without requiring that the same AAA keys be used on both the Previous
Router and the New Router. Diameter TLV's and other authorization
attributes can be carried in lightweight tickets. The session key
inside the lightweight Kerberos ticket is shared by both the New
Router and the MN; it can be used to create data integrity and data
confidentiality keys.
Security attributes are transported in the following messages: A
new suboption with the principal name and realm is added to the
Handover Redirect message. A new message is added which is the MN's
response to the Previous Router Handover Redirect message: the
Handover Redirect Ack message. It contains the lwkerb-ap-req PDU
which contains a lightweight Kerberos ticket. The Previous Router
will transport the lwkerb-ap-req in the ICMP Handover message to the
New Router. The New Router will (with possible assistance from a
KDC) process the lwkerb-ap-req and authenticate the MN user. The
New Router may need to contact the KDC, depending on which of the
following three cases applies:
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 6]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
1. Prtr and Nrtr share a long term key (which encrypts the
lightweight ticket), so Nrtr doesn't have to contact the KDC
when it receives the lwkerb-ap-req. It will immediately decrypt
the ticket and process the lwkerb-ap-req without any network
exchanges with other servers.
2. The lwkerb-ap-req contains a ticket encrypted in the key of the
local KDC so Nrtr only has to contact a KDC in its own domain.
So this should take less time than having to contact a KDC in the
user's domain.
3. The lwkerb-ap-req contains a ticket encrypted in the key of the
user's KDC. Although Nrtr will contact a KDC in its own domain,
that KDC will have to contact a KDC in the user's domain (or an
intermediate proxy which then contacts the user domain KDC).
A new message, Authenticated-MN (Nrtr to MN), is used to send the
lwkerb-ap-rep PDU from the New Router to the MN (see Figure 4).
3
Prtr ----- Nrtr
\ /
1,2 \ / 4,5
\ /
MN
1. Handover Redirect (from Prtr to MN) with principal name, realm
2. Handover Redirect Ack (from MN to Prtr) with lwkerb-ap-req
3. ICMP Handover Message (from Prtr to Nrtr) with lwkerb-ap-req
4. Autheticated-MN (from Nrtr to MN) with lwkerb-ap-rep
5. Message from MN to Nrtr, e.g., a SHIN message that also
includes BU from the MN to Home Agent.
(it is possible to switch the order of 4 and 5).
Figure 4: Message flow with security extensions
The MN may also send a router solicitation message with a new
suboption asking for a list of adjacent realms to be sent back in the
router advertisement. The list of adjacent realms can be used by
the MN to precache crossrealm lightweight TGT's targeted at adjacent
realms (as a background task). This performance optimization allows
subsequent authentications for adjacent realms to skip exchanges with
the remote user's KDC. Instead, a local KDC will be used.
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 7]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
4. New Access Router Processing
When the new access router receives the ICMP Handover message,
it SHOULD first check for the existence and validity of an AH
header, with authentication data computed according to the security
association between the previous access router and the new access
router.
If the handover message does not have the `M' bit set, the new
access router SHOULD compute the layer-2 address of the mobile node
by masking off the bits corresponding to the given Mobile Node
Care-of Address field. This will allow the new access router to send
messages to the mobile node at its new care-of address without having
to perform Neighbor Solicitation.
If the new access router receives a handover message containing a
new Care-of Address that is already in use by another node in its
Neighbor Cache, the new access router SHOULD return a ICMP Handover
Error message (see section 7) to the previous access router.
5. ICMP Handover Redirect Message Format
Routers send Handover Redirect packets to inform a mobile node of
a better access router. The redirect message SHOULD also contain
information enabling the mobile node to determine the layer-2 address
for the new access router, as well as its new care-of address for
attachment to the Internet at the new access router.
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 8]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Size |M|C|S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Router IPv6 Address (128 bits) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Access Router MAC Address (64 bits) (if present) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ New Care-of Address (128 bits) (if present) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Options ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD
Code 0
M If the `M' bit is set, the 64-bit Access Router MAC
Address field is present.
C If the `C' bit is set, the 128-bit New Care-of Address
field is present.
S If the `S' bit is set, light-weight kerberos
authentication sub option is present
If the `M' bit is not set, then the Access Router's MAC address
may be determined by applying the value in the Prefix Size to mask
off the routing prefix bits of the value in the Access Router IPv6
Address field.
If the `C' bit is not set, then the mobile node may determine its new
care-of address by applying the value in the Prefix Size to select
the routing prefix from the the address in the Access Router IPv6
Address field. This routing prefix may then be prepended to the
lower-order bits of the mobile node's current care-of address.
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 9]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
The mobile node determines the new router's link-local address by
replacing Prefix-Size bits by the well-known link-local address
prefix FE80:.
Whether or not the `C' bit is set, the mobile node MAY attempt to
acquire a new care-of address once connectivity is established at the
new access router, or else it MAY continue to use the care-of address
implicitly or explicitly formed as above. Such care-of address
acquisition follows the Mobile IPv6 specification [1].
5.1. Light-weight Kerberos Authentication sub option
The following sub option is used when the `S' bit is set to provide
Kerberos Principal Name and Realms.
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 | Kerberos Principal Name ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kerberos Principal Realm ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Message type. To be assigned.
Length 8-bit unsigned integer. The length in bytes of the
option (including the type and length fields).
Principal Name Kerberos Principal Name
Principal Realm Kerberos Principal Realm
6. ICMP Handover Message Format
An access router sends an ICMP Handover message to inform a new
access router that it will soon be the default (edge) router for a
mobile node. The handover message contains enough information so
that the new access router can create the appropriate entry in its
Neighbor Cache for the prospective mobile node.
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 10]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Size |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Mobile Node's New Care-of Address (128 bits) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Mobile Node MAC Address (64 bits) (if present) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Type TBD
Code 0
M If the `M' bit is set, the 64-bit Mobile Node MAC Address
field is present.
If the `M' bit is not set, then the mobile node's MAC address may be
determined by using the routing prefix to mask off the leading bits
of the mobile node's care-of address.
Available suboptions include a Mobile Node Authentication suboption,
which we define below based on light-weight kerberos mechanism.
Other suboptions may be defined to handle necessary context
transfers.
The previous router needs to determine the correct address for
inclusion as the Mobile Node's New Care-of Address field. This can
be done by consulting its local tables to determine the correct
routing prefix for the new access router's service area. Determining
the assocation between neighboring access routers, and their prefixes
which are to be used for creating new care-of addresses, is carried
out by techniques beyond the scope of this specification. It
should be noted, however, that manual configuration is a realistic
possibility at the time the access routers are installed.
When the new access router receives a ICMP Handover message that
does not contain the Mobile Node MAC Address field, the new access
router determines the mobile node's layer-2 address by masking off
the leading bits according to the appropriate prefix size for that
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 11]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
subnet. The routing prefix is naturally known to the new access
router, since it is the default router for that subnet.
6.1. ICMP Handover Authentication Suboption Format
In this section, we define a light-weight Kerberos Authentication sub
option. Its format is shown in Figure 5. This sub option is used
to transport lwkerb-ap-req and lwkerb-ap-rep messages in the ICMP
handover, Handover redirect ack, and Authenticated-MN 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 | Lightweight Kerberos Message /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Sub option for carrying light-weight Kerberos messages
Type Message type. To be assigned.
Length 8-bit unsigned integer. The length in bytes of the
option (including the type and length fields).
LKB Lightweight Kerberos protocol message as defined in [4].
The Handover Redirect ack message and the Authenticated-MN message
have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Options /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD
Code 0
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 12]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
Length length of total message in bytes
Options Lightweight Kerberos Message Option (see above) or other
options.
6.1.1. Router Solicitation and Advertisement Options
The following router solicitation message suboption is used to
request that the access router return a list of adjacent realms
in its router advertisement. The access router may also return a
Kerberos message suboption with a reverse ticket.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Message type. To be assigned.
Length 8-bit unsigned integer. The length in bytes of the
option (including the type and length fields).
The following router advertisement message suboption is used to
return a list of adjacent realms in the router advertisement:
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 | Realm 1... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Realm 2... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... Realm n... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Message type. To be assigned.
Length 8-bit unsigned integer. The length in bytes of the
option (including the type and length fields).
Realm i The realm name of the ith geographically adjacent
Kerberos realm.
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 13]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
7. ICMP Handover Error Format
A prospective new access router sends the ICMP Handover Error message
to inform the previous access router that the handover is likely to
fail, and that the mobile node should not expect to consider the
sending access router as its new default router. The Handover Error
message contains enough information so that the previous access
router can determine which Handover Message caused the error.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Mobile Node's New Care-of Address (128 bits) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The previous access router uses its cached handover information to
determine which of its visiting mobile nodes is indicated by the
value given in the Mobile Node's New Care-of Address field.
8. Security Considerations
Any handover message has to be made secure against malicious nodes
wishing to fraudulently redirect traffic away from the mobile node.
Messages from the mobile node have to be authenticated so that an
access router does not erroneously redirect traffic to a malicious
interloper.
Messages, if any, to the previous access router have to be
authenticated so that the previous access router does not erroneously
redirect traffic away from the mobile node.
Messages to the new access router SHOULD be authenticated to enable
detection of malicious attempts to cause the new access router to
wastefully reserve resources for a mobile node that is unlikely to
arrive.
The security extensions presented in this document can be used to
meet the security requirements described in this section.
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 14]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
References
[1] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in
progress).
draft-ietf-mobileip-ipv6-13.txt, October 2000.
[2] Rajeev Koodli and Charles E. Perkins. A Framework for
Smooth Handovers with Mobile IPv6 (work in progress).
Internet Draft, Internet Engineering Task Force.
draft-koodli-mobileip-smoothv6-02.txt, November 2000.
[3] 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.
A. Link Failure
In some radio networks, it is possible that the mobile node is not
able to establish the link with the New Router after deciding to
undergo new link establishment. In such a case, the mobile node may
revert back to the Previous Router resulting in a ``link reversal''.
When this happens, the mobile node has to send a message requesting
to disable forwarding to the new CoA that is no longer valid. When
this happens, the Previous Router may determine, through the Handover
Error message, that it has to stop forwarding packets to the MN's
new CoA. It may then determine if the mobile node is present on its
link and resume forwarding packets as appropriate. Alternatively,
the mobile node itself may send a message requesting to disable
forwarding to the new CoA that is no longer valid.
Note that since a Binding Update has not been delivered yet, packets
will still be arriving at the Previous Router, and by disabling
forwarding to the new CoA, those packets can be delivered again at
the mobile node's current location.
B. Alternative to ICMP Handover Message
The Previous Router MAY use an unsolicited SHREP message defined
in [2] to supply the mobile node's new CoA and security information
to the New Router. The mobile node MAY use a SHIN message defined
in the same document when it sends a message to propagate its
link-layer address to the New Router. The Previous Router MAY use
the unsolicited SHREP message to also supply any control information
(such as an indication to buffer packets) as well as any useful
context information (such as header compression state variables).
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 15]
Internet Draft Fast Handovers in Mobile IPv6 2 March 2001
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:
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:Jo+1-650n625-2359athan TrostlPhone:e +1-650 625-2986
EMail:Cirajeev.koodli@nokia.comsco EMail:Sycharliep@iprg.nokia.comstem
Fax:17+10650W625-2502. Tasman DriveFax: +1 650 625-2502
San Jose, CA 95134
USA
Phone: +1-408-527-6201
EMail: jtrostle@cisco.com
Koodli, Perkins, Trostle Expires 2 September 2001 [Page 16]