Internet DRAFT - draft-castelluccia-mobileip-hmipv6
draft-castelluccia-mobileip-hmipv6
Mobile IP Working Group Claude Castelluccia
Ludovic Bellier
Internet Draft INRIA, France
July 2000
Hierarchical Mobile IPv6
draft-castelluccia-mobileip-hmipv6-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
In Mobile IPv6 a mobile node registers with its home agent and its
correspondent hosts each time it changes care-of address.
This draft presents a Hierarchical Mobile IPv6 proposal that reduces
C. Castelluccia, L. Bellier Expired January 2001 [Page 1]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
the number of signaling messages sent by a mobile host to its home
agent and correspondent hosts and that reduces the signaling delay.
Our proposal relies on the deployment of Mobility Networks that
provide flexibility and scalability.
1. Introduction
This Internet Draft presents a Hierarchical Mobile IPv6 proposal. Our
proposal makes full use of new IPv6 functionalities such as a large
address space and the neighbor discovery mechanisms to propose a
mobility management solution that is flexible, scalable and robust. As
most of the existing hierarchical Mobile IP schemes we use anchor
points, that we call mobility servers (MS), to deploy two levels of
hierarchies ([2] describes how to deploy more than two levels of
hierarchy). Each domain contains one or several mobility servers. If
a mobile host moves into a new domain it gets two CoA, a global one
(GCoA) and a local one (LCoA). If it moves within a domain, it only
needs to change its LCoA, the GCoA remains the same. The mobile host
registers its GCoA with its home agent and correspondent hosts and the
binding (LCoA, GCoA) with the domain mobility server. Packets
addressed to the mobile host's GCoA are routed to the domain,
intercepted by the MS and encapsulated to the MH's current LCoA. In
contrast to existing schemes ([3], [4]), the GCoA is not the address
of the MS but an address belonging to the MS's subnet (that we call
Mobility network). As a result, the MS can be changed (for load
balancing or robustness purposes) dynamically without having to change
the GCoAs (i.e. without breaking ongoing communications) of the mobile
hosts currently roaming in the domain.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 3119.
Binding Update : BU
Border Router : BR
Correspondent Host : CH
Global Care-of Address : GCoA
Home Address : H@
Home Agent : HA
Local Care-of Address : LCoA
Mobile Host : MH
Mobility Server : MS
Mobility Network : MN
C. Castelluccia, L. Bellier Expired January 2001 [Page 2]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
3. Protocol Overview
Our proposal differentiates the intra-domain mobility from the inter-
domain mobility. As a result, a host communicating with a mobile host
is only aware of the MH's inter-domain mobility. The mobile host's
intra-domain mobility is completely hidden. In this draft, we define a
domain as the highest level of our hierarchical architecture. A domain
is actually an arbitrary structure. It can be an ISP network, a campus
network, a company network, a set of LANs or even a single LAN. A
domain is connected to the rest of the Internet via one or several
interconnection routers that we call Border Routers (BR).
Our proposal is based on the deployment of Mobility Networks. A
Mobility Network of a domain is a LAN that defines an address space
for the mobile hosts roaming within this domain. A Mobility Network
contains one or several Mobility Servers. A Mobility Server (MS) is a
router of the Mobility Network that maintains a binding per mobile
hosts currently visiting the domain. Note that there is no constraint
on the physical location of the Mobility Network. However for
efficiency reasons, it is preferable to connect it to the border
router of the network that it is serving. The mobility Network can
actually be any sub-network of the domain. It does not have to be
dedicated to mobile hosts but instead can support ordinary (fixed)
hosts.
Deploying a Mobility Server in a separate Mobility Network instead of
implementing it on the BR, as proposed in [4], has two main
advantages. First, it does not require any modification to the routers
and is therefore easier to deploy. Second, it is more scalable since
(1) it does not add additional processing constraints on the BR, (2)
several MSs could be deployed for scalability and/or robustness
motivations. However the MS can be implemented within the BR if this
is desirable. This would then be very similar to the scheme proposed
in [4].
Note that a domain may contain more than one Mobility Networks if
necessary. If a domain has several BRs, we suggest to deploy one
Mobility Network per BR. Each MN is then in charge of a particular
area of the domain.
3.1. Inter-domain mobility
When a mobile host enters into a new domain, it gets two CoAs: a Local
Care-of Address (LCoA), which is a CoA on the link it is attached to,
and a Global Care-of Address (GCoA), which is a CoA in the Mobility
Network of the domain (note that in Mobile IPv6 only the LCoA is
required.).
C. Castelluccia, L. Bellier Expired January 2001 [Page 3]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
The mobile host then sends few BUs. It sends:
- a BU that specifies the binding between its GCoA and its LCoA to
the domain MS.
- a BU that specifies the binding between its home address (H@) and
its GCoA to its HA and to its external CHs (i.e. CHs that are
outside the domain).
- a BU that specifies the binding between its home address (H@) and
its LCoA to its local CHs (i.e. CHs that are within the domain).
As a result,
- An external host that sends packets to the mobile host uses its
GCoA. Packets are then routed to the Mobility Network of the
visited domain, intercepted by the Mobility Server and forwarded
(tunneled) to the current LCoA of the MH.
- A local host that sends packets to the mobile host uses its LCoA.
Packets are then directly delivered to the mobile host.
3.2. Intra-domain mobility
When a mobile host moves within the domain, it gets a new LCoA on its
new point-of attachment. The GCoA does not change. The mobile host
then sends the following BUs:
- a BU that specifies the binding between its home address and its
new LCoA to its local CHs (i.e. CHs that are within the domain).
- a BU that specifies the binding between its GCoA and its new LCoA
to the domain Mobility Server.
Note that during intra-domain mobility, no BU is sent on the Internet.
Figures 1 and 2 illustrate the Inter-domain and Intra-domain mobility
operations.
Figure 3 illustrates packet delivery.
----- (H@,GCoA) ----
| CH1 |<+++++++++++++>| HA |
----- + ----
| + /
------------+------
| + |
| Internet + |
| + |
------------+------
/ + |
/ + |
------- -+--------------------------------
| | | + | domain 2
| domain 1| | + ---- |
| | | + | BR |---| ----
C. Castelluccia, L. Bellier Expired January 2001 [Page 4]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
| | | + ---- |---| MS |
| | | + | ----<++++++++++ (LCoA1,GCoA)
| | | + +
| | | +++++++++++++++++++++++++++++++
| | | + +
| | | ----- + (H@,LCoA1) ---- +
| | | | + | +
| | | -----v ----+
| | | | CH2 | | MH |
| * | | ----- ^---
----*-- --------------------------*--------
* *
**********************************
******> MH movement
++++++> BU
Figure 1 : Intra Domain Mobility
----- ----
| CH1 | | HA |
----- ----
| /
-------------------
| |
| Internet |
| |
-------------------
|
|
-----------------------------------------
| |
| ---- |
| | BR |---| ----
| ---- |---| MS |
| | ----
^
| +
+
| (H@,LCoA) ++++++
+
| ++++++++
| ------ ----- + + -----
| | | + + |
C. Castelluccia, L. Bellier Expired January 2001 [Page 5]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
| ---- -----v +---
| | MH | | CH2 | | MH |
| ---- ----- ^---
------*----------------------*--------
* *
**********************
******> MH movement
++++++> BU
Figure 2 : Inter Domain Mobility
----- ----
| CH1 |oooooooooo | HA |
----- o ----
| o /
------------o------
| o |
| Internet o |
| o |
--------------o----
---------------------o-------------------
| |oooooooo
| ---- |o
| | BR |---|ooo>----
| ---- |---| MS |
| |OOO ----
| O
| O
| ooooooooo O
| -----o o --O--
| | o o |O
| ----- v---v
| | CH2 | | MH |
| ----- ----
----------------------------------------
oooo> packets
OOOO> encapsulated packets
Figure 3 : Packets delivery
C. Castelluccia, L. Bellier Expired January 2001 [Page 6]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
4. Protocol Details
4.1 New Router Advertisement Options
In order to register, a mobile host needs the following
information:
- the Mobility Server address,
- the Mobility Network prefix length.
This information is advertised by a new option used in the Router
Advertisement messages of the IPv6 Neighbor Discovery. The format
of this option, called the Mobility Information Option, is defined
as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | length | na | plen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MS address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- type = the type of the option (TBD).
- length = the length of the option = 20 bytes.
- na = not used, set to 0.
- plen = prefix length of the Mobility Network.
- MS address = the address of the mobility server in charged of
this link.
Figure 4 : Router Advertisement Mobility Information Option
Format
A router must be able to store the MS address and its prefix length
to fill in an Mobility Information Option in its router
advertisements. This information can be configured manually in each
router or dynamically via a specific protocol. For more
flexibility, we have designed a new protocol between the MS and the
routers. The MS periodically sends information packets to the
routers. These packets are IPv6 packets with a destination option
header. We created a new option in this header, the Mobility
Information Option.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| htype | hlength | otype | olen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| na | plen |
C. Castelluccia, L. Bellier Expired January 2001 [Page 7]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MS address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- htype = header type = destination options header.
- hlength = length of the header, 5.
- otype = option type (TBD)
- olen = option length, 20 bytes.
- plen = prefix length of the Mobility Network.
- MS address = the address of the local mobility agent.
Figure 5 : Destination Option Header Mobility Information Option
Format
A router must be able to receive and to handle the Mobility
Information Option. If the MS address is the unspecified address
or if the prefix length is 0, the router must stop advertising the
MS.
4.2 Mobile Host Operation
4.2.1 Registration Request and Update
In our proposal, the registration phase differs during local
(intra-domain) and global (inter-domain) mobility.
Inter-domain Mobility :
When the mobile host moves into a new domain, the Mobile host
performs the following operations:
- it gets a new GCoA (it gets the Mobility Network prefix
address from the Mobility Information Option of the router
advertisement and concatenates it with its interface ID) in the
Mobility Network,
- it gets a new LCoA on the local link and performs a DaD
(Duplicate Address Duplication),
- it registers the (GCoA,LCoA) binding with the MS (the MS then
performs a DaD and rejects the registration if it fails) using
a Registration Request packet as defined in Figure 6,
- it registers the (H@,LCoA) binding with its local CHs using
MIP Binding Updates. Note that each time the MH moves between
two domains, it should read its correspondent nodes list, and
compare its current LCoA prefix with the CH address prefix. If
C. Castelluccia, L. Bellier Expired January 2001 [Page 8]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
they match, the correspondent node and the mobile host are in
the same domain. The MH should tag the correspondent node entry
with a local flag. This flag should be used by the binding
update function to build packet with the LCoA or with the GCoA.
- it registers the (H@,GCoA) binding with its HA using a MIP
Binding Update
- it registers the (H@,GCoA) binding with its external CHs using
MIP Binding Updates.
Intra-domain Mobility :
When the mobile host moves locally (i.e. within the domain)
- it gets a new LCoA on the link, using the Prefix Information
Option of the router advertisement, and performs a DaD
(duplicate address detection),
- if the DaD is successful, it registers the (GCoA,LCoA) binding
with the MS using a Registration Update packet as defined in
Figure 7.
- it registers the (H@,LCoA) binding with its local CHs.
The Mobility Servers must, as the Home Agent does in Mobile IPv6,
acknowledge the reception of the Bindings coming from the MH.
Consequently, the registration messages sent by the MHs to the MSs
must have the 'acknowledge' flag set to 1.
Note that if the registration with the MS fails (i.e. the MH does
not receive any acknowledgment or an acknowledgment with an error
status), the MH MUST immedially switch to regular Mobile IP6. It
must then registers its LCoA directly with its HA and CHs and
bypass the MS registration phase.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| otype | olen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flag | malen | seq number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ptype | plen | pad | pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| previous |
| mobility server |
| address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pad | pad | atype | alen |
C. Castelluccia, L. Bellier Expired January 2001 [Page 9]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| home address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- otype = option type (TBD)
- olen = the option length, 32 bytes
- flag = A flag, same as Mobile IPv6.
- malen = prefix length of the Mobility Network.
- seq number = we use the same mechanism that Mobile IPv6. The MS
stores the sequence number read in the Registration packet. If the
next Registration packet contains a lower or equal sequence number,
the Registration packet is discarded and an acknowledgment is sent
to the MH with the status OPT6_BNDA_BADSEQ. The very first
Registration packet (after the first movement) must contain a
sequence number field set to 1. Each time the MH sends a
Registration Request, Update or Refresh packet, it has to increment
the sequence number. When the mobile host roams between two
domains, it must not reset its sequence number to 0. It has to
continue to increment the number because this number will be used
in the handoff request packet and will be checked by the previous
MS.
- lifetime = the requested lifetime for the binding. The MS has to
start a timer for this mobile host. If the timer expires, the MS
must remove the mobile host entry from its cache. The MH should
send refresh packet to refresh the timer. We use a sub-option to
add the address of the previous MS in the registration packet.
- ptype = the sub-option type, we use 102.
- plen = the length of the sub-option, 18. A MH is always
identified by its home address. We add a Home Address option in our
destination option to carry the home address.
- atype = home address option type.
- alen = 16.
Figure 6 : Registration Request Packet Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| otype | olen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flag | malen | seq number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pad | pad | atype | alen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C. Castelluccia, L. Bellier Expired January 2001 [Page 10]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
| |
| |
| home address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- otype = option type (TBD)
- olen = the option length, 8 bytes
- flag = A flag, same as Mobile IPv6.
- malen = prefix length of the Mobility Network.
- seq number = we use the same mechanism of Mobile IPv6. The MS
stores the sequence number read in the update packet. If the next
update packet contains a lower or equal sequence number, the update
is discarded and an acknowledgment should be sent to the MH with
the status OPT6_BNDA_BADSEQ.
- lifetime = the requested lifetime for the binding. The MS has to
restart the timer for this mobile host. Note that this timer was
previously started by a mobile host registration packet. If the
timer expires, the MS must remove the mobile host entry from its
cache. The MH should send a Registration Update packet to refresh
the timer. A MH is alway identified by its home address. We add a
Home Address option in our destination option to carry the home
address.
- atype = home address option type.
- alen = 16.
Figure 7 : Registration Update Packet Format
4.2.2 Registration Refresh
A Mobile Host must periodically send to its MS a Registration
Refresh packet to refresh its binding. The format of the
Registration Refresh packet is identical to one presented in Figure
7, with a different option type value (TBD).
4.3 Mobility Server Operation
4.3.1. Mobility Server Discovery
The MS periodically sends Mobility Server Information Packet to all
routers of its area.
4.3.2. Registration Request
C. Castelluccia, L. Bellier Expired January 2001 [Page 11]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
The MS must register mobile hosts. When a MS receives a
Registration Request packet, it has to check this registration
(authentication and sequence number). If the registration is
successful, the MS must add a binding for this MH in its cache and
act as a proxy between the GCoA and the LCoA (like a home agent).
Note that the GCoA is not contained in the registration packet. The
MS has to reconstruct it from the Mobility Network Prefix address
and the MH's Interface ID (derived from the Home Address). It then
performs a DaD with the constructed GCoA on the Mobility Network.
The lifetime field contained in the Registration Request packet is
used to start a timer. If this timer expires, the MH entry is
removed from the cache, and the proxy is stopped.
If the registration is accepted, the MS must return an
acknowledgment (that has the same format than MIP acknowledgment
packets) to the MH with the status OK.
If the registration aborts or is refused (because the DaD failed
for example), the MS has to return an acknowledgment to the sender
with the corresponding error status.
Note that we use the same error status of Mobile IPv6 registration
process.
4.3.3. Registration Update
When a MH receives a Registration Update packet from a MH, it has
to check if the sender is already registered and if the sequence
number of the incoming packet is greater than the previous sequence
number. If the Registration Update packet is valid, the MS must
update the MH's LCoA entry with the update packet source IP
address, restart the MH lifetime timer
with the value contained in the lifetime field of the registration
update packet and send a acknowledgment back to the MH (same format
than MIP's Binding Acknowledgment packet). If the Registration
Update packet is discarded, the MS has to send an acknowledgment
with the corresponding error status to the sender.
4.3.4. Registration Refresh
When a MS receives a Registration Refresh packet, it has to check
if the sender is already registered and if the sequence number of
the incoming packet is greater than the previous sequence number.
If the Refresh packet is valid, the MS must restart the MH lifetime
timer with the value contained in the lifetime field of the
registration refresh
packet.
If the registration update packet is discarded, the MS has to send
an acknowledgment with the corresponding error status to the
C. Castelluccia, L. Bellier Expired January 2001 [Page 12]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
sender.
4.3.5 Packet Delivery
As shown in figure 3, the MS acts as a proxy between the GCoA and
the LCoA. We use the same mechanism of a home agent to manage this
proxy.
External correspondent nodes use the GCoA to send packets to the
MH. Those packets are intercepted by the MS, encapsulated and
routed to the MH position (LCoA) (Note that instead of
encapsulating and decapsulating packets, the mobility server can
merely change the source and destination IP addresses of the
encapsulating IP header).
Internal correspondent nodes use the LCoA. The packets are directly
routed to the MH position.
4.3.6. Smooth Handoff
A MS must be able to handle handoff.
When a mobile host moves into a new domain, the new MS should send
a Handoff Request Packet to the previous MS requesting to forward
packets addressed to the MH. The Handoff Request packet format is
displayed in Figure 8.
No retransmission mechanism is needed. If the Handoff Request
packet is lost, the MH might lose few packets during the handoff.
We assume that those packets can easily be retransmitted by the
transport protocol or by the application.
When a MS receives a Handoff Request, it has to check that the MH
is registered, that the handoff request packet is authenticated
correctly and that the sequence number is greater than the previous
number (note that the sequence number in the handoff request packet
is the same than the sequence number used by the MH in its last
Registration Request packet). If the handoff request is accepted,
the MS has to update its cache by updating the LCoA associate to
the MH with the MH's new GCoA (as a result the packets in transit
will be redirected from the previous MS to the new one and then
encapsulated to the MH's current LCoA). The lifetime timer of the
MH is restarted by using the lifetime value found in the handoff
request packet.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| otype | olen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flag | malen | seq number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime |
C. Castelluccia, L. Bellier Expired January 2001 [Page 13]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ptype | plen | pad | pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Global |
| CoA |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pad | pad | atype | alen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| home address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- otype = option type (TBD)
- olen = the option length, 32 bytes
- flag = A flag, same as Mobile IPv6.
- malen = prefix length of the Mobility Network.
- seq number = we use the same mechanism that Mobile IPv6. The MS
stores the sequence number read in the Registration Request packet.
If the next registration packet contains a lower or equal sequence
number, the registration is discarded and an acknowledgment is sent
to the MH with the status OPT6_BNDA_BADSEQ.
- lifetime = the requested lifetime for the binding. The MS has to
start a timer for this mobile host. If the timer expires, the MS
must remove the mobile host entry from its cache. The MH should
send refresh packet to refresh the timer. We use a sub-option to
add the address of the previous MS in the registration packet.
- ptype = the sub-option type, we use 103.
- plen = the length of the sub-option, 18. - GCoA = the new GCoA
of the MH A MH is always identified by its home address. We add a
Home Address option in our destination option to carry the home
address.
- atype = home address option type.
- alen = 16.
Figure 8 : Handoff Request Packet Format
4.4 Home Agent Operation
- see Mobile IPv6 [1]-
4.5 Correspondent Host Operation
-see Mobile IPv6 [1]-
C. Castelluccia, L. Bellier Expired January 2001 [Page 14]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
5. Security Consideration
5.1. Correspondent Node Consideration
Our solution does not introduce more security problems than Mobile
IPv6. The IPSec SA are created by using the home address of the mobile
hos.
5.2. Mobility Server Consideration
5.2.1. MS <-> MH
A mobile host has to register with its home agent and with the
local mobility server. All registration messages between the MH and
the MS have to be authenticated. This means that the mobile host
has to share an authentication key (private or public) with all
domains (i.e. the MS) it may visit. These keys can be pre-installed
manually or obtained via AAA servers.
5.2.2. MS <-> MS
After an inter-domain movement, the new MS may ask the previous MS
to redirect the packets addressed to the MH to it. This is
performed by the emission of a Handoff Request packet from the
current MS to the previous one (see Section 4.3.5). This operation
requires that the 2 MSs share an authentication key. This key can
be pre-intalled or obtained dynamically via some kind of AAA
servers for example.
6. Conclusion
This paper presents a solution that makes use of IPv6 new
functionalities, such as a large address space and the Neighbor
Discovery mechanism, to propose a mobility management scheme that is
hierarchical, flexible and scalable. We propose a hierarchical
architecture that separates local mobility (within a domain) from
global mobility (across domains). Local handoffs are managed locally
and transparently to a mobile node's correspondent hosts.
As most of proposed schemes ([3], [4]) we use anchor points to deploy
two levels of hierarchy ([2] describes how to deploy more than two
levels of hierarchy) in the networks and we assign to each mobile host
a Global Care-of Address that only needs to be changed when the mobile
host moves into a new domain. However in contrast to other schemes,
the GCoA that we assign to a MH is not the address of the anchor
point. As a result, the anchor point can be replaced (for load
balancing, scalability, robustness purposes) dynamically and
transparently to ongoing communications.
C. Castelluccia, L. Bellier Expired January 2001 [Page 15]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
Our proposal is built on top of and is fully compatible with the IETF
Mobile IPv6 protocol. It does not require installation everywhere to
be useful but instead can be deployed gradually.
7. Implementation Status
The implementation of Hierarchical Mobile IPv6 is done under
FreeBSD 3.3 and can be down-loaded from :
http://www.inrialpes.fr/planete/people/bellier/hmip.html
This implementation is in full conformance with the Mobile IPv6
Internet Draft 7. We have to adapt the implementation to be in full
conformance with the Mobile IPv6 Internet Draft 12.
References
[1] D. Johnson and C. Perkins. "Mobility support in IPv6",
draft-ietf-mobileip-ipv6-10.txt, February 2000.
[2] Castelluccia C., "An Hierarchical Mobile IPv6 Proposal", INRIA
TR-0226, November 1998. Available
at http://www.inrialpes.fr/Planete/people/ccastel/index.html
[3] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional
Tunnel Management",
draft-ietf-mobileip-reg-tunnel-02.txt (work in progress), March
2000.
[4] K. El Malki and H. Soliman, "Hierarchical Mobile IPv4/v6 and
Fast Handoffs",
draft-elmalki-soliman-hmipv4v6-00.txt, March 2000.
Authors' Addresses
Claude Castelluccia
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
France
email: claude.castelluccia@inria.fr
phone: +33 4 76 61 52 15
fax: +33 4 76 61 52 52
Ludovic Bellier
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
France
C. Castelluccia, L. Bellier Expired January 2001 [Page 16]
Internet Draft INRIA Hierarchical Mobile IPv6 July, 6 th 2000
email: ludovic.bellier@inria.fr
phone: +33 4 76 61 52 15
fax: +33 4 76 61 52 52
C. Castelluccia, L. Bellier Expired January 2001 [Page 17]
