WDIFF

draft-ietf-mipshop-hmipv6-00.txt --> draft-ietf-mipshop-hmipv6-01.txt

IETF Mobile IP MIPSHOP Working Group Hesham Soliman, Flarion
INTERNET-DRAFT Claude Castelluccia, INRIA
Karim El-Malki, El Malki, Ericsson
Ludovic Bellier, INRIA
June, 2003
February, 2004

Hierarchical Mobile IPv6 mobility management (HMIPv6)
<draft-ietf-mipshop-hmipv6-00.txt>
<draft-ietf-mipshop-hmipv6-01.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@SUNROOF.ENG.SUN.COM mailing list.
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 cite them other than as "work in
progress".

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/lid-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This document is a product of the MIPSHOP WG.

Abstract

This draft document introduces extensions to Mobile IPv6 and IPv6 Neighbour
Discovery to allow for local mobility handling. Hierarchical mobility
management for Mobile IPv6 reduces the amount of signalling between
the Mobile Node, its Correspondent Nodes and its Home Agent. The
Mobility Anchor Point described in this document can also be used to
improve the performance of Mobile IPv6 in terms of handoff handover speed.

Soliman, Castelluccia, El-Malki, Bellier [Page 1]

INTERNET-DRAFT HMIPv6 June,2002 February 2004

TABLE OF CONTENTS

1. Terminology............................................ 3 Terminology......................................................3

2. Introduction and motivation............................ 4 motivation......................................4

3. Overview of HMIPv6..................................... 5 HMIPv6...............................................5
3.1 HMIPv6 Operation.............................................5

4. Mobile IPv6 extensions ................................ 7 extensions...........................................7
4.1 Local Binding Update.........................................8

5. Neighbour Discovery extension “ - The MAP option ............ 9 message format....8

6. Protocol operations ................................... 10 operation...............................................9
6.1 Mobile Node Operation.............................. 11 node Operation.......................................10
6.1.1 Sending packets to correspondent nodes................11
6.2 MAP operation...................................... 13 Operations..............................................11
6.3 Home Agent operation............................... 14 Operations.......................................12
6.4 Correspondent Node operation....................... 14 node Operations...............................12
6.5 Local Mobility Management optimisation within a MAP domain................................. 14 domain..12
6.6 Location Privacy................................... 14 Privacy............................................13

7. MAP Discovery.......................................... 15 discovery...................................................13
7.1 Dynamic MAP Discovery............................. 15 Discovery.......................................14
7.1.2 Router Operation for Dynamic MAP Discovery............14
7.1.3 MAP Operation for Dynamic MAP Discovery...............14
7.2 Using Router Renumbering for MAP Discovery........ 16 discovery..................15
7.2.1 Extension to the Match Prefix Part of RR..............16
7.3 MN Operation...................................... 17 Mobile node Operation.......................................16

8. Updating previous Anchor Points......................... 19 MAPs..........................................17

9. Special optimisations for sending Binding Updates....... 19

10. Notes on MAP selection by the MN........................ 20

11. mobile node.......................17
9.1 MAP selection in a distributed-MAPs environment.............18
9.2 MAP selection in a flat mobility management architecture....19

10. Detection and recovery from MAP failures................ 21 failures.......................19

11. IANA Considerations............................................20

12. Security considerations................................. 22 considerations........................................20
12.1 Mobile node û MAP security.................................21
12.2 Mobile node û correspondent node security..................22
12.3 Mobile node û Home Agent security..........................22

13. Acknowledgements........................................ 24 Acknowledgements...............................................22

14. Notice Regarding Intellectual Property Rights........... 24 Rights..................22

15. References.............................................. 25

16. Authors' addresses...................................... 26

17. Appendix A: Future Mobile IPv6 and HMIPv6............... 27 References.....................................................23

Soliman, Castelluccia, El-Malki, El Malki, Bellier [Page 2]

INTERNET-DRAFT HMIPv6 June,2003 February 2004

16. Authors' Addresses.............................................24

17. Intellectual Property Statement................................24

18. Full Copyright Statement.......................................25

Appendix A û Fast Mobile IPv6 Handovers and HMIPv6.................26

1. Terminology

This memo uses the terminology described in [1]. In addition, new
terms are defined below:

Access Router (AR) The Mobile NodesË Node's default router. The AR
aggregates the outbound traffic of mobile
nodes.

Mobility Anchor Point A Mobility Anchor Point is a router located
(MAP) in a network visited by the mobile node.
The MAP is used by the MN as a local HA.
One or more MAPs can exist within a visited
network.

Regional Care-of An RCoA is an address obtained by the
Address (RCoA) mobile node from the visited network. An
RCoA is an address on the MAPËs MAPÆs subnet. It
is auto-configured by the mobile node when
receiving the MAP option.

HMIPv6-aware An HMIPv6-aware mobile node is a mobile
Mobile Node node that can receive and process the MAP
option received from its default router.
An HMIPv6-aware Mobile Node must also be
able to send a local binding updates
(Binding Update with the M flag set).

On-link CoA (LCoA) The LCoA is the on-link CoA configured on
an
a mobile nodeËs node's interface based on the
prefix advertised by its default router.
In [1] this is simply referred to as the
Care-of-address. However, in this memo LCoA
is used to distinguish it from the RCoA.

Local Binding Update The MN sends a Local Binding Update to the
MAP in order to establish a binding
between the RCoA and LCoA.

Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and

Soliman, Castelluccia, El Malki, Bellier [Page 3]

INTERNET-DRAFT HMIPv6 February 2004

"MAY" that appear in this document are to be interpreted as described
in [KEYWORDS].

Soliman, Castelluccia, El-Malki, Bellier [Page 3]

INTERNET-DRAFT HMIPv6 June,2003 [11].

2. Introduction and motivation

This draft introduces the concept of a Hierarchical Mobile IPv6
network, utilising a new node called the Mobility Anchor Point (MAP).

Mobile IPv6 [1] allows nodes to move within the Internet topology
while maintaining reachability and on-going connections between
mobile and correspondent nodes. To do this a mobile node sends
Binding Updates (BUs) to its Home Agent (HA) and all Correspondent
Nodes (CNs) it communicates with, every time it moves. Authenticating
binding updates requires approximately 1.5 round trip times between
the mobile node and each correspondent node (for the entire return
routability procedure in a best case scenario, i.e. no packet
losses). In addition, one round trip time is needed to update the
Home Agent, this can be done simultaneously while updating
correspondent nodes. The re-use of the home cookie (i.e. eliminating
HOTI/HOT) will not reduce the number of round trip times needed to
update correspondent nodes. These round trip delays will disrupt
active connections every time a handoff to a new AR is performed.
Eliminating this additional delay element from the time-critical
handover period will significantly improve the performance of Mobile
IPv6. Moreover, in the case of wireless links, such solution reduces
the number of messages sent over the air interface to all
correspondent nodes and the Home Agent. A local anchor point will
also allow Mobile IPv6 to benefit from reduced mobility signalling
with external networks.

For these reasons a new Mobile IPv6 node, called the Mobility Anchor
Point is used and can be located at any level in a hierarchical
network of routers, including the Access Router (AR). Unlike Foreign
Agents in IPv4, a MAP is not required on each subnet. The MAP will
limit the amount of Mobile IPv6 signalling outside the local domain.
The introduction of the MAP provides a solution to the issues
outlined earlier in the following way:

- The mobile node sends Binding Updates to the local MAP rather than
the HA that (that is typically further away away) and CNs

- Only one Binding Update message needs to be transmitted by the MN
before traffic from the HA and all CNs is re-routed to its new
location. This is independent of the number of CNs that the MN is
communicating with.

A MAP is essentially a local Home Agent. The aim of introducing the
hierarchical mobility management model in Mobile IPv6 is to enhance
the performance of Mobile IPv6 while minimising the impact on Mobile
IPv6 or other IPv6 protocols. It also supports Fast Mobile IPv6
Handovers to help Mobile Nodes in achieving seamless mobility (see

Soliman, Castelluccia, El Malki, Bellier [Page 4]

INTERNET-DRAFT HMIPv6 February 2004

Appendix A). Furthermore, HMIPv6 allows mobile nodes to hide their
location from correspondent nodes and Home Agents while using Mobile
IPv6 route optimisation.

Soliman, Castelluccia, El-Malki, Bellier [Page 4]

INTERNET-DRAFT HMIPv6 June,2003

3. Overview of HMIPv6

This Hierarchical Mobile IPv6 scheme introduces a new function, the
Mobility Anchor Point(MAP),
MAP, and minor extensions to the mobile node operation. The
correspondent node and Home Agent operation will not be affected.

Just like Mobile IPv6, this solution is independent of the underlying
access technology, allowing mobility (including fast mobility [12]) within or between different
types of access networks. Furthermore, a
smooth architectural migration can be achieved from Hierarchical
MIPv4 networks, since a dual operation of IPv4 and IPv6 Hierarchies
will be possible making use of the similarity in architecture.

A mobile node entering a MAP domain will receive Router
Advertisements containing information on one or more local MAPs. The
MN can bind its current location (on-link CoA) with an address on the
MAPËs
MAP's subnet (RCoA). Acting as a local HA, the MAP will receive all
packets on behalf of the mobile node it is serving and will
encapsulate and forward them directly to the mobile node's current
address. If the mobile node changes its current address within a
local MAP domain (LCoA), it only needs to register the new address
with the MAP. Hence, only the Regional CoA (RCoA) needs to be
registered with correspondent nodes and the HA. The RCoA does not
change as long as the MN moves within a MAP domain (see below for
definition). This makes the mobile node's mobility transparent to the
correspondent nodes it is communicating with.

A MAP domain's boundaries are defined by the Access Routers (ARs)
advertising the MAP information to the attached Mobile Nodes.
The detailed extensions to Mobile IPv6 and operations of the
different nodes will be explained later in this document.

It should be noted that the HMIPv6 concept is simply an extension to
the Mobile IPv6 protocol. An HMIPv6-aware mobile node with an
implementation of Mobile IPv6 SHOULD choose to use the MAP when
discovering such capability in a visited network. However, in some
cases the mobile node may prefer to simply use the standard Mobile
IPv6 implementation. For instance, the mobile node may be located in
a visited network within its home site. In this case, the HA is
located near the visited network and could be used instead of a MAP.
In this scenario, the mobile node would only update the HA whenever
it moves. The method to determine whether the HA is in the vicinity
of the MN (e.g. same site) is outside the scope of this document.

2.1

3.1 HMIPv6 Operation

The network architecture shown below illustrates an example of the
use of the MAP in a (visited) visited network.

Soliman, Castelluccia, El-Malki, El Malki, Bellier [Page 5]

INTERNET-DRAFT HMIPv6 June,2003 February 2004

+-------+
| HA |
+-------+
|
| +----+
| | CN |
| +----+
+-----+ |
|
| | +---+
|
+-------+-----+
|
|RCoA
+-------+
| MAP | RCoA
+-------+
| |
| +--------+
| |
| |
+-----+ +-----+
| AR1 | | AR2 |
+-----+ +-----+
LCoA1 LCoA2

+----+
| MN |
+----+ ------------>
Movement

Figure 1: Hierarchical Mobile IPv6 domain

In Figure 1, the MAP can help in providing seamless mobility for the
mobile node as it moves from Access Router 1 (AR1) to Access Router 2
(AR2), while communicating with the correspondent node. A multi-level
hierarchy is not required for a higher handover performance, hence, hence it
is sufficient to locate one or more MAPs (possibly covering the same
domain) at any position in the operatorËs operatorÆs network.

Upon arrival in a visited network, the mobile node will discover the
global address of the MAP. This address is stored in the Access
Routers and communicated to the mobile node via Router Advertisements
(RAs). A new option for RAs is proposed defined later in this specification.
This is needed to inform mobile nodes about the presence of the MAP
(MAP discovery). The discovery phase will also inform the mobile node
of the distance of the MAP from the mobile node. For example, the MAP
function could be implemented as shown in Figure 1 and at the same
time also in AR1 and AR2. In this case the mobile node can choose the
first hop MAP or one further up in the hierarchy of routers. The
details on how to choose a MAP are provided in section 10.

The process of MAP discovery continues as the mobile node moves from
one subnet to the next. As Every time the mobile node roams within a MAP domain,

Soliman, Castelluccia, El-Malki, Bellier [Page 6]

INTERNET-DRAFT HMIPv6 June,2003

ARs are configured to announce detects movement,
it will also detect whether it is still in the same MAP address or addresses. domain. The
router advertisement used to detect movement will also inform the

Soliman, Castelluccia, El Malki, Bellier [Page 6]

INTERNET-DRAFT HMIPv6 February 2004

mobile node, through the MAP option, whether it is still in the same
MAP domain. As the mobile node roams within a MAP domain, it will
continue to receive the same MAP option included in router
advertisements from its AR. If a change in the advertised MAP's
address is received, the mobile node MUST act on the change by performing movement detection and
sending
the necessary Binding Updates to its HA and correspondent nodes.

If the mobile node is not HMIPv6-aware then no MAP Discovery will be
performed, resulting in the mobile node using the Mobile IPv6 [1]
protocol for its mobility management. On the other hand, if the
mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6
implementation. If so, the mobile node will first need to register
with a MAP by sending it a BU containing its Home Address and on-link
address (LCoA). The Home address used in the BU is the RCoA. The MAP
MUST store this information in its Binding Cache to be able to
forward packets to their final destination when received from the
different correspondent nodes or HAs.

The mobile node will always need to know the original sender of any
received packets to determine if route optimisation is required. This
information will be available to the mobile node since the MAP does
not modify the contents of the original packet. Normal processing of
the received packets (as described in [1]) will give the mobile node
the necessary information.

To use the network bandwidth in a more efficient manner, a mobile
node may decide to register with more than one MAP simultaneously and
use each MAP address for a specific group of correspondent nodes. For
example, in Fig 1, if the correspondent node happens to exist on the
same link as the mobile node, it would be more efficient to use the
first hop MAP (in this case assume it is AR1) for communication
between them. This will avoid sending all packets via the "highest"
MAP in the hierarchy and hence result in a more efficient usage of
network bandwidth. The mobile node can also use its current on-link
address (LCoA) as a CoA as specified in [1]. Note that the mobile
node MUST NOT present an RCoA from a MAPÆs subnet as an LCoA in a
binding update sent to another MAP. The LCoA included in the binding
update MUST be the mobile nodeÆs address derived from the prefix
advertised on its link.

If a router advertisement is used for MAP discovery, as described in
this document, all ARs belonging to the MAP domain MUST advertise the
MAP's IP address. A Router Renumbering [5] extension is also proposed
as an alternative for MAP discovery by ARs and MAPs. The same concept
(of advertising the MAPËs MAPÆs presence within its domain) should be used
if other methods of MAP discovery are introduced in future.

4. Mobile IPv6 extensions

This section outlines the extensions proposed to the binding update
and binding acknowledgement specified in [1].

Soliman, Castelluccia, El Malki, Bellier [Page 7]

INTERNET-DRAFT HMIPv6 February 2004

4.1 Local Binding Update

A new flag is added: added; the M flag that indicates MAP registration. When
a mobile node registers with the MAP, the M and A flags MUST be set

Soliman, Castelluccia, El-Malki, Bellier [Page 7]

INTERNET-DRAFT HMIPv6 June,2003
to distinguish this registration from a Home Registration or a BU being sent to the HA or a
correspondent 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Description of extensions to the binding update:

M If set to 1 it indicates a MAP registration.

It should be noted that this Binding update uses the same Mobility
Header type specified in [1].

4.2 On-link Care-Of address Test option

In this section a new option, the On-link Care-Of address Test (OCOT)
option is being introduced. This option is included in the binding
acknowledgement message.

5. Neighbour Discovery extension - The inclusion of this option is OPTIONAL and
SHOULD be configurable in the MAP. However, this MAP option MUST be
supported by the mobile node and MAP. message 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 | Length | Dist | Pref |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence no Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

Type Option ICMPv6 option type. TBA.

Length 8-bit unsigned integer. The length of the

Soliman, Castelluccia, El Malki, Bellier [Page 8]

INTERNET-DRAFT HMIPv6 February 2004

option (including the type and length fields)
in units of 8 octets. This field MUST be set
to 1.

Reserved 16-bit field. MUST be set to zero by the
sender and ignored by the receiver.

Soliman, Castelluccia, El-Malki, Bellier [Page 8]

INTERNET-DRAFT HMIPv6 June,2003

Sequence no A 32-bit unsigned integer. This field is
arbitrarily set by the MAP when sending a
binding acknowledgement and incremented by 1
when sent from the mobile node to the MAP.

5. Neighbour Discovery extension - The MAP option message 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 | Length | Dist | Pref |R|I|P|V| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

Type ICMPv6 option type. TBA.

Length 8-bit unsigned integer. The length of the
option (including the type and length fields)
in units of 8 octets. The value 0 is invalid.
Nodes The value 0 is invalid.
Nodes MUST silently discard an ND packet that
contains an option with length zero.

Dist A 4 bit unsigned integer showing identifying the distance
from
Distance Between MAP and the receiver of the
advertisement. Its default value SHOULD be set
to one 1 if dynamic Dynamic MAP discovery is used. The
Distance MUST be set to one 1 if the MAP is on the
same link as
the asthe mobile node. This field need
not be interpreted as the number of hops away from
between MAP and the mobile node. The only
requirement is that the meaning of the
Distance field is consistently interpreted
within one Domain. A Distance value of Zero
MUST NOT be used.

Pref The preference of a MAP. A 4 bit unsigned
integer. A decimal value of 15 indicates the
highest availability.

R When set to 1 it indicates that the mobile
node

Soliman, Castelluccia, El-Malki, Bellier [Page 9]

INTERNET-DRAFT HMIPv6 June,2003 MUST form an RCoA based on the prefix in
the MAP option.

I When set indicates that the mobile node MAY
use its RCoA as source address of its outgoing
packets

P When set indicates that the mobile node MUST
use its RCoA as source address of its outgoing
packets

V When set indicates that reverse tunnelling of
outbound traffic, to the MAP, is required if
RCoA is used as a source address in outgoing
packets.

Valid Lifetime The minimum value (in seconds) of both the
preferred and valid lifetimes of the prefix
assigned to the MAPËs MAP's subnet. This value
indicates the validity of the MAPËs MAP's address
and consequently the time for which the RCoA
is valid.

Global Address One of the MAP's global addresses.
The /64 64-bit prefix extracted from this address
MUST be configured in the MAP to be used for
RCoA construction by the mobile node.

Although not explicitly included in the MAP option, the prefix length
of the MAPËs MAP's Global IP address MUST be 64. This prefix is the one
used by the mobile node to form an RCoA, by appending a 64-bit
identifier to the prefix. Hence the need for having a static prefix
length for the MAPËs MAP's subnet.

6. Protocol operation

This section describes the HMIPv6 protocol. In HMIPv6, the mobile
node has two addresses, an RCoA on the MAP's link and an on-link CoA
(LCoA). This RCoA is formed in a stateless manner by combining the
mobile nodeËs nodeÆs interface identifier and the subnet prefix received in
the MAP option.

Soliman, Castelluccia, El Malki, Bellier [Page 9]

INTERNET-DRAFT HMIPv6 February 2004

As illustrated in this section, this protocol requires updating the
Mobile NodesË
mobile nodes' implementation only. The HA and correspondent node are
unchanged. The MAP performs the function of a "local" HA that binds
the mobile nodeËs node's RCoA to an LCoA.

6.1 Mobile node Operation

When a mobile node moves into a new MAP domain (i.e. its MAP
changes), it needs to configure two CoAs: an RCoA on the MAP's link

Soliman, Castelluccia, El-Malki, Bellier [Page 10]

INTERNET-DRAFT HMIPv6 June,2003
and an on-link CoA (LCoA). These addresses are formed in a stateless
manner. After forming the RCoA based on the prefix received in the
MAP option, the mobile node sends a local BU to the MAP with the A
and M flags set. The local BU is a BU defined in [1] and includes the
MNËs
mobile node's RCoA in the Home Address Option. No alternate-CoA
option is needed in this message. The LCoA is used as the source
address of the BU. This BU will bind the mobile node's RCoA (similar
to a Home Address) to its LCoA. The MAP (acting as a HA) will then
perform DAD (when a new binding is being created) for the mobile
node's RCoA on its link and return a Binding Acknowledgement to the
MN. This acknowledgement identifies the binding as successful or
contains the appropriate fault code. No new error codes need to be
supported by the MN mobile node for this operation. The MN mobile node MUST
silently ignore binding acknowledgements that do not contain a
routing header type 2 which includes the mobile nodeËs node's RCoA.

The MAP MAY include an OCOT option in

Following a successful registration with the binding acknowledgement. If
this option is included, MAP, a bi-directional
tunnel between the mobile node MUST return and the binding
acknowledgement MAP is established. All
packets sent by the mobile node are tunnelled to the MAP with MAP. The outer
header contains the OCOT option included, after
incrementing mobile node's LCoA in the sequence number source address field
and the MAP's address in the OCOT option by 1. This option
is included destination address field. The inner
header contains the mobile node's RCoA in the source address field
and the peer's address in the destination address field. Similarly,
all packets addressed to allow the mobile node's RCoA are intercepted by
the MAP and tunnelled to ensure that the mobile node's LCoA.

This specification allows a mobile node is located on
the link that to use more than one RCoA if
it claims received more than one MAP option. In this case, the mobile node
MUST perform the binding update procedure for each RCoA. In addition,
the mobile node MUST NOT use one RCoA (e.g. RCoA1) derived from a
MAPÆs prefix (e.g. MAP1) as a care-of address in its binding update
to another MAP (e.g. MAP2). This would force packets to be
encapsulated several times (twice in this example) on their path to
the mobile node. This form of multi-level hierarchy will reduce the
protocol's efficiency and is not attempting a flooding
attack directed towards another node on another link. performance.

After registering with the MAP, the mobile node MUST register its new
RCoA with its HA by sending a BU that specifies the binding (RCoA,
Home Address) as in Mobile IPv6. The mobile node's Home Address is
used in the home address option is set to and the Home Address, RCoA is used as the care-of
address (RCoA) can be found in the source address field or the alternate-CoA option. field. The MN mobile node may also send a

Soliman, Castelluccia, El Malki, Bellier [Page 10]

INTERNET-DRAFT HMIPv6 February 2004

similar BU (i.e. that specifies the binding between the Home Address
and the RCoA) to its current correspondent nodes. If the I
flag is set in the MAP option, the mobile node MAY use its RCoA as a
source address for the BU. If the P flag is set in the MAP option,
the mobile node MUST use RCoA as a source address.

If the mobile node uses its RCoA as a source address, the alternate-
CoA option will not be required. If both the P and V flags are set,
the mobile node MUST use RCoA as a source address and tunnel all
outgoing packets to the MAP. The source address in the outer header
is the mobile nodeËs LCoA and the destination address is the MAPËs
address. This is done to allow for cases where a network
administrator wants mobile nodes to use RCoA as a source, while
keeping ingress filter configurations in the ARs unchanged.

The mobile node SHOULD wait for the binding acknowledgement from the
MAP before registering with its HA. It should be noted that when
binding the RCoA with the HA and correspondent nodes, the binding
lifetime MUST NOT be larger than the mobile nodeËs node's binding lifetime
with the MAP, which is received in the Binding Acknowledgement.

In order to speed up the handover between MAPs, MAPs and reduce packet
loss, a mobile node may send a local BU to its previous MAP
specifying its new LCoA. Packets

Soliman, Castelluccia, El-Malki, Bellier [Page 11]

INTERNET-DRAFT HMIPv6 June,2003 in transit that reach the previous
MAP are then forwarded to the new LCoA.

The MAP will receive packets addressed to the mobile node's RCoA
(from the HA or correspondent nodes). Packets will be tunnelled from
the MAP to the mobile node's LCoA. The mobile node will de-capsulate
the packets and process them in the normal manner.

When the mobile node moves within the same MAP domain, it should only
register its new LCoA with its MAP. In this case, the RCoA stays remains
unchanged.

Note that a mobile node may send a BU containing its LCoA (instead of
its RCoA) to correspondent nodes which are connected to its same
link. Packets will then be routed directly without going through the
MAP.

A network operator may prefer

6.1.1 Sending packets to hide the mobile nodeËs LCoA from correspondent nodes outside

The mobile node can communicate with a correspondent node through the MAP domain. To ensure this,
HA, or in a MAP option route-optimised manner, as described in [1]. When
communicating through the HA, the message formats in [1] can be
sent re-
used.

If the mobile node communicates directly with the P flag set. In this case, correspondent node
(i.e. the CN has a binding cache entry for the mobile node), the
mobile node MUST use its
RCoA as the source same care-of address of its BU (no alternate-CoA option is
needed) used to its HA and create a
binding cache entry in the correspondent nodes. It MUST also use its RCoA node (RCoA) as the a source address for its
address. According to [1], the mobile node MUST also include a Home
Address option in outgoing packets.

On The Home address option MUST
contain the other hand, a mobile node may prefer node's home address.

6.2 MAP Operations

The MAP acts like a HA; it intercepts all packets addressed to hide its location from
the correspondent
registered mobile nodes it communicates with and tunnels them to the HA. To achieve
this, corresponding LCoA,
which is stored in its binding cache.

A MAP has no knowledge of the mobile node's Home address. The mobile
node should ensure that it does not provide both its
identity and location will send a local BU to any of the correspondent nodes. Since MAP with the
implied identity M and A flags set. The

Soliman, Castelluccia, El Malki, Bellier [Page 11]

INTERNET-DRAFT HMIPv6 February 2004

aim of this BU is to inform the MAP that the mobile node is included has formed
an RCoA (contained in every route-
optimised packet (a the BU as a Home Address), address). If successful, the mobile node should ensure that
it does not provide its exact location
MAP MUST return a binding acknowledgement to the correspondent nodes and
HA. Hence, the mobile node should use its RCoA as
indicating a source address
for all its outgoing packets. successful registration. This can be done if is identical to the I or P flags
are set HA
operation in [1]. No new error codes are introduced for HMIPv6. The
binding acknowledgement MUST include a routing header type 2 that
contains the mobile node's RCoA.

The MAP option. Otherwise location privacy can not MUST be
provided in this manner.

If the V flag is set (in addition able to accept packets tunnelled from the P or I flags), mobile
node, with the mobile node MUST tunnel all outgoing packets to being the MAP. This is needed to
allow for location privacy while keeping ingress filter configuration
in tunnel entry point and the ARs unchanged.

6.1.1 Sending packets to correspondent nodes MAP
being the tunnel exit point.

The mobile node can communicate with MAP acts as a correspondent node through HA for the
HA, or in a route-optimised manner, as described in [1]. When
communicating through RCoA. Packets addressed to the HA, RCOA are
intercepted by the message formats in [1] can be re-
used. However, MAP, using proxy Neighbour Advertisement,
encapsulated and routed to the mobile node MUST select the source address in
outgoing packets based on the content node's LCoA. This operation is
identical to that of the P, I and V flags HA described in the [1].

A MAP option.

Soliman, Castelluccia, El-Malki, Bellier [Page 12]

INTERNET-DRAFT HMIPv6 June,2003

If the mobile node communicates directly MAY be configured with the correspondent node
(i.e. the CN has a binding cache entry for the list of valid on-link prefixes that
mobile node), the nodes can use to derive LCoAs. This is useful for network
operators to stop mobile node MUST nodes from continuing to use the same care-of address used MAP after
moving to create a
binding cache entry in the correspondent node (RCoA) as different administrative domain. If a source
address. According to [1], the mobile node MUST also include sent a Home
Address option
binding update containing an LCoA that is not in outgoing packets. The Home address option MUST
contain the mobile nodeËs home address.

Since RCoA is used as a source address for outgoing packets, MAP's ôvalid on-
link prefixesö list, the
mobile node must consider MAP could reject the content binding update using
existing error code 129 (administratively prohibited).

6.3 Home Agent Operations

The support of HMIPv6 is completely transparent to the P, I and V flags HA's
operation. Packets addressed to
decide whether packets should a mobile node's Home Address will be sent directly with
forwarded by the HA to its RCoA as a source,
or tunnel packets described in [1].

6.4 Correspondent node Operations

HMIPv6 is completely transparent to correspondent nodes.

6.5 Local Mobility Management optimisation within a MAP domain

In [1], it is stated that for short-term communication, particularly
communication that may easily be retried upon failure, the MAP. When tunnelling outgoing packets mobile
node MAY choose to the
MAP, directly use one of its care-of addresses as the
source address in the outer header is the mobile nodeËs LCoA
and of the destination address is packet, thus not requiring the MAPËs address.

6.2 MAP Operations

The MAP acts like use of a HA; it intercepts all packets addressed to
registered mobile nodes and tunnels them to Home Address
option in the corresponding LCoA.

A MAP has no knowledge packet. Such use of the mobile node's Home address. The mobile
node CoA will send a local BU to the MAP with reduce the M and A flags set. The
aim overhead of this BU is
sending each packet due to inform the MAP that absence of additional options. In
addition, it will provide an optimal route between the mobile node has formed
an
and correspondent node.

In HMIPv6, a mobile node can use its RCoA (contained in the BU as the source address
without using a Home address). If successful, Address option. In other words, the
MAP MUST return RCoA can be
used as a binding acknowledgement to potential source address for upper layers. Using this
feature, the mobile node
indicating a successful registration. This is identical to will be seen by the HA
operation in [1]. No new error codes are introduced for HMIPv6. The
binding acknowledgement MUST include correspondent node as a routing header type 2 that
contains the mobile nodeËs RCoA.

When sending
fixed node while moving within a binding acknowledgement to MAP domain.

Soliman, Castelluccia, El Malki, Bellier [Page 12]

INTERNET-DRAFT HMIPv6 February 2004

This usage of the mobile node, RCoA does not have the MAP
MAY include cost of Mobile IPv6 (i.e. no
bindings or home address options are sent over the OCOT option. This option is needed Internet) but
still provides local mobility management to confirm the mobile nodeËs location on the claimed link. If this option nodes.
Although such use of RCoA does not provide global mobility (i.e.
communication is
included, the MAP will expect the broken when a mobile node host moves to return the binding
acknowledgement message after incrementing the sequence number in a new MAP), it
would be useful for several applications (e.g. web browsing). The
validity of the
OCOT option RCoA for as a source address used by 1. Until the mobile node returns the binding
acknowledgement, applications
will depend on the size of a MAP MUST tentatively store the binding in its
binding cache. When the binding acknowledgement, containing domain and the
sequence number +1, is received from speed of the mobile node, the MAP MUST
confirm
node. Furthermore, since the binding cache entry and continue forwarding packets support for BU processing in
correspondent nodes is not mandated in [1], this mechanism can
provide a way of obtaining route optimisation without sending BUs to
the mobile nodeËs LCoA correspondent nodes.

Enabling this mechanism can be done by presenting the RCoA as a
temporary home address for the lifetime of mobile node. This may require an
implementation to augment its source address selection algorithm with
the binding.

The inclusion knowledge of the OCOT option RCoA in order to use it for the binding acknowledgement
SHOULD be configurable, but MUST be supported appropriate
applications.

6.6 Location Privacy

In HMIPv6, a mobile node hides its LCoA from its corresponding nodes
and its home agent by using its RCoA in the MAP.

The MAP MUST be able to accept packets tunnelled from source field of the mobile
node, with
packets that it sends. As a result, the location tracking of a mobile
node being the tunnel entry point by its corresponding nodes or its home agent is difficult since
they only know its RCoA and the not its LCoA.

7. MAP
being the tunnel exit point. discovery

This is required independently of the
settings of section describes how a mobile node obtains the P, I, or V flags.

Soliman, Castelluccia, El-Malki, Bellier [Page 13]

INTERNET-DRAFT HMIPv6 June,2003

The MAP acts as address and
subnet prefix and how ARs in a HA domain discover MAPs. Two different
methods for the RCoA. Packets addressed to the RCOA MAP discovery are
intercepted by defined below.

Dynamic MAP Discovery is based on propagating the MAP, using proxy Neighbour Advertisement,
encapsulated and routed MAP option in
Router Advertisements from the MAP to the mobile nodeËs LCoA. This operation is
identical to that of node through certain
(configured) router interfaces within the HA described routers in [1].

6.3 Home Agent Operations

The support an operator's
network. This requires manual configuration of HMIPv6 is completely transparent to the HAËs
operation. Packets addressed to a mobile nodeËs Home Address will be
forwarded by MAP and the HA
routers receiving the MAP option to its RCoA as described in [1].

6.4 Correspondent node Operations

HMIPv6 is completely transparent allow them to correspondent nodes.

6.5 Local Mobility Management optimisation within propagate the
option on certain interfaces. To ensure a MAP domain

In [1], it is stated that for short-term communication, particularly secure communication
between routers, router advertisements that may easily are sent between routers
for Dynamic MAP discovery SHOULD be retried upon failure, the mobile
node MAY choose to directly use one of its care-of addresses as the
source of authenticated (e.g. using AH,
ESP, or SEND). In the packet, thus case where this authentication is not requiring possible
(e.g. third party routers exist between the use of MAP and ARs), a Home Address
option in the packet. Such use of the CoA will reduce the overhead of
sending each packet due network
operator may prefer to manually configure all the absence of additional options. In
addition, it will provide an optimal route between the mobile node
and correspondent node.

In HMIPv6, if ARs to send the I MAP
option or P flags are set in use the router renumbering mechanism for MAP option, a mobile
node can use its RCoA discovery, as the source of its packets without using a
Home Address option. It may also use the RCoA
described in this document.

Another MAP discovery method is based on Router Renumbering [5] as source address
described in section 7.2. In this method, no manual configuration is
required for routers within the local BU to register the binding between its LCoA and RCoA with
the local MAP. As a result the mobile node domain. The MAP option is seen by the
correspondent node as sent
directly from a fixed central node while moving to all ARs within a MAP domain. This use of

Soliman, Castelluccia, El Malki, Bellier [Page 13]

INTERNET-DRAFT HMIPv6 February 2004

method is best suited to large networks where manually configuring
all routers in a the RCoA network can be useful as it does not have the cost
of Mobile IPv6 (i.e. no bindings or home address options are sent
over the Internet) but still provides some local mobility management
to a significantly tedious
operation. On the mobile nodes. Although, such use of RCoA does not provide
global mobility (i.e. communication is broken other hand, when a mobile host
moves to a new MAP), it would be useful for several applications using this method, any subsequent
changes in the MAP optionÆs parameters (e.g. web browsing) communicating with other nodes for some period preference) would
require manual intervention.

Manual configuration of
time depending on the size of a MAP domain option information in ARs and other
MAPs in the speed of the
mobile node. Furthermore, since same domain is the support default mechanism. It should also be
possible to configure ARs and MAPs to enable either dynamic or Router
Renumbering mechanisms for BU processing in
correspondent nodes is not mandated in [1], this mechanism MAP Discovery.

7.1 Dynamic MAP Discovery

The process of MAP discovery can
provide be performed in many different ways.
Router advertisements are used for Dynamic MAP Discovery by
introducing a way of obtaining route optimisation without sending BUs new option. The access router is required to send the correspondent nodes.

6.6 Location Privacy

In HMIPv6, a mobile node MAY choose to hide
MAP option in its LCoA router advertisements. This option includes the
distance vector from its
corresponding nodes and its home agent by using its RCoA in the
source field mobile node (which may not imply the real
distance in terms of the packets that it sends. As a result, number of hops), the location

Soliman, Castelluccia, El-Malki, Bellier [Page 14]

INTERNET-DRAFT HMIPv6 June,2003

tracking of a mobile node by its corresponding nodes or its home
agent is difficult since they only know its RCoA and not its LCoA.
The MN may achieve such location privacy as described in section 6.1.

7. MAP discovery

This section describes how a mobile node obtains preference for this
particular MAP, the MAP MAP's global IP address and the MAP's subnet prefix and how ARs in a domain discover MAPs. Two different
methods
prefix.

7.1.2 Router Operation for MAP discovery are defined below. Dynamic MAP Discovery is based on propagating

The ARs within a MAP domain may be configured dynamically with the
information related to the MAP option options. ARs may obtain this
information by listening for RAs with MAP options. Each MAP in
Router Advertisements from the MAP
network needs to be configured with a default preference, the mobile node through certain
(configured) router right
interfaces within to send this option on and the hierarchy of routers. This
would require manual configuration IP address to be sent. The
initial value of the MAP "Distance" field MAY be set to a default value
of 1 and the routers
receiving MUST NOT be set to zero. Routers in the MAP option to allow them domain should be
configured to propagate re-send the MAP option on certain interfaces. To ensure

Upon reception of a secure communication between routers, router advertisements that are sent between routers for Dynamic advertisement with the MAP
discovery SHOULD be authenticated by AH or ESP. In option, the case where
this authentication is not possible (e.g. third party routers between
receiving router MUST copy the MAP option and ARs), a network operator may prefer to manually configure
all the ARs to send re-send it after
incrementing the MAP option or use Distance field by one. If the receiving router renumbering
mechanism for MAP discovery, as shown in this document.

Another method based on Router Renumbering [5] is was
also described a MAP, it MUST send its own option together with the received
option in
section 7.2. In this method, no manual configuration is required for
routers within the domain. The same advertisement. If a router receives more than one
MAP option is sent directly from a
central node to all ARs within a for the same MAP domain. This method is best
suited to large networks where manually configuring all routers
within a hierarchy can be a significantly tedious operation. On (i.e. the
other hand, when using this method, any subsequent changes same IP address in the MAP
optionËs parameters (e.g. preference) would require manual
intervention.

Manual configuration of
option), from two different interfaces, it MUST choose the MAP option
with the smallest distance field.

In this manner, information in ARs and other about one or more MAPs in the same domain is the default mechanism. It should also can be
possible dynamically
passed to configure ARs and MAPs a mobile node. Furthermore, by performing the discovery
phase in this way, different MAP nodes are able to enable either dynamic change their
preferences dynamically based on the local policies, node overload or Router
Renumbering mechanisms for
other load sharing protocols being used.

7.1.3 MAP Discovery.

7.1 Operation for Dynamic MAP Discovery

The process of

A MAP discovery can will be performed in many different ways.
Router advertisements are used for dynamic MAP discovery by
introducing a new option. The access router is required configured to send the
MAP option in its router advertisements. This option includes the
distance vector from the mobile node which may not imply the real
distance in terms of the number of hops, the preference for this
particular MAP, the MAP's global IP address and the MAP's subnet
prefix. In addition, the option contains some flags showing the MAPËs
mode of operation and other information. or relay MAP options

Soliman, Castelluccia, El-Malki, El Malki, Bellier [Page 15] 14]

INTERNET-DRAFT HMIPv6 June,2003

7.1.2 Router Operation for Dynamic MAP Discovery

The ARs within a MAP domain may be configured dynamically with the
information related February 2004

belonging to the MAP options. ARs may obtain this
information other MAPs onto certain interfaces. The choice of
interfaces is done by listening for RAs with MAP options. Each MAP in the network needs to be configured with a default preference, the right
interfaces to send this option on administrator (i.e. manual
configuration) and depends on the IP address to be sent. The
initial network topology. A default
preference value of the "Distance" field MAY 10 may be set assigned to each MAP. It should be
noted that a default MAP can change its preference value at any time due to
various reasons (e.g. node overload or load sharing). A preference
value of one. Routers in zero means that the MAP domain should SHOULD NOT be configured to re-send the chosen by new mobile
nodes. This value could be reached in cases of node overload or
partial node failures.

The MAP option on certain interfaces

Upon reception of a is propagated towards ARs in its domain. Each router advertisement with
along the MAP option, path to an AR will increment the
receiving Distance field by one. If
a router MUST copy the option and re-send it after
incrementing the Distance field by one. If the receiving router was that is also a MAP, MAP receives advertisements from other MAPs,
it MUST send add its own option together with the received
option in the same advertisement. If a router receives more than one MAP option for the same MAP (i.e. and propagate both options to the same IP address in next
router or to the MAP
option), from two different interfaces, AR (if it MUST choose the option has direct connectivity with the smaller distance field.

In this manner, information about a AR).

7.2 Using Router Renumbering for MAP at a certain level discovery

The Router Renumbering (RR) mechanism described in [2] defines a
hierarchy set
of messages that can be dynamically passed used to renumber certain interfaces on a mobile node. Furthermore, by
performing the discovery phase in this way, different MAP nodes
router without manual configuration of such router. RR messages are
able
authenticated and protected against replay attacks. The same concept
can be used to change their preferences dynamically based on configure a router to propagate the local
policies, node overload or other load sharing protocols being used.

7.1.3 MAP Operation for Dynamic MAP Discovery

A MAP will be configured to send its option or relay MAP options
belonging to other MAPs onto on
certain interfaces. The choice of
interfaces A new PCO command, PROPAGATE, is done by defined below.
This command is part of the network administrator (i.e. manual
configuration) Prefix Code Operation (PCO) and depends on is
included in the network topology. A default
preference value Match Prefix part of 10 may be assigned to each MAP. It should be
noted that a MAP can change its preference value at any time due to
various reasons (e.g. node overload or load sharing). A preference
value of zero means that the MAP SHOULD NOT be chosen by new mobile
nodes. This value could be reached in cases of node overload or
partial node failures.

The MAP option is propagated down the hierarchy. Each router along
the path to the access router will increment the Distance field by
one. If a router that is also a MAP receives advertisements from
other MAPs, it MUST add its own MAP option and propagate both options
to the next level in the hierarchy.

7.2 Using Router Renumbering for MAP discovery

The Router Renumbering (RR) mechanism described in [2] defines a set
of messages that can be used to renumber certain interfaces on a
router without manual configuration of such router. RR messages are
authenticated and protected against replay attacks. The same concept

Soliman, Castelluccia, El-Malki, Bellier [Page 16]

INTERNET-DRAFT HMIPv6 June,2003

can be used to configure a router to propagate the MAP option on
certain interfaces. A new PCO command, PROPAGATE, is defined below.
This command is part of the Prefix Code Operation (PCO) and is
included in the Match Prefix part of the message. A PCO message sent the message. A PCO message sent
to a router with the PROPAGATE command MUST contain one or more MAP
options in the Use Prefix part of the message.

Upon reception of this message, a router will propagate the MAP
option on the designated interface. interface by including it in its router
advertisement. This mechanism can be used to configure ARs to
advertise one or more MAP options. This is best suited to large
networks or for cases where third party networks may exist between
the MAP and ARs. Furthermore, unlike the Dynamic MAP
discovery
Discovery mechanism described earlier, this method does not require
each router in the MAP domain to understand the MAP option.

Soliman, Castelluccia, El Malki, Bellier [Page 15]

INTERNET-DRAFT HMIPv6 February 2004

7.2.1 Extension to the Match Prefix Part of RR

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | OpLength | Ordinal | MatchLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinLen | MaxLen | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MatchPrefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Extended Fields:

OpCode An unsigned 8-bit field specifying the operation to be
performed when the associated MatchPrefix matches an
interface's prefix or address. Values are:

1 the ADD operation

2 the CHANGE operation

3 the SET-GLOBAL operation The new value is:

4 the PROPAGATE operation (new code).

Soliman, Castelluccia, El-Malki, Bellier [Page 17]

INTERNET-DRAFT HMIPv6 June,2003 operation.

7.3 Mobile node Operation

When an HMIPv6-aware mobile node receives a router advertisement, it
should search for the MAP option. One or more options may be found
for different MAP IP addresses or subnet prefixes. addresses.

A mobile node SHOULD register with the MAP having the highest
preference value. A MAP with a preference value of zero SHOULD NOT be
used for new local BUs (i.e. the mobile node can refresh existing
bindings but cannot create new ones). A mobile node MAY however
choose to register with one MAP over another depending on the value
received in the Distance field, provided that the preference value is
above zero.

A MAP option containing a valid lifetime value of zero means that
this MAP MUST NOT be selected by the MN. A valid lifetime of zero
indicates a MAP failure. When this option is received, a mobile node
MUST choose another MAP and create new bindings. Any existing
bindings with this MAP can be assumed to be lost. If a multihomed mobile node has no other MAP is
available the mobile node MUST revert to using the Mobile IPv6
protocol as specified in [1].

Soliman, Castelluccia, El Malki, Bellier [Page 16]

INTERNET-DRAFT HMIPv6 February 2004

If a multihomed mobile node has access to several ARs simultaneously
(on different interfaces), it SHOULD use an LCoA on the link defined
by the AR that advertises its current MAP.

A mobile node MUST store the received option(s) and to choose at least
one MAP to register with. Storing the options is essential as they
will be compared to other options received later for the purpose of
the move movement detection algorithm.

If no MAP options are found in the router advertisement, the mobile
node MUST use the Mobile IPv6 protocol as specified in [1].

If the R flag is set, the mobile node MUST use its RCoA as the Home
Address when performing the MAP registration. RCoA is then bound to
the LCoA in the MAPËs MAP's Binding Cache.

If the I flag is set the mobile node MAY choose to use RCoA as a
source address in its outgoing packets depending on whether location
privacy (with respect to the correspondent nodes and HA) is required
by the mobile node or user. This choice can be made by default
policies in the mobile node or configurable options by the user.

If the P flag is set, the mobile node MUST use RCoA as a source
address. This can be due to the network operatorËs requirements of
not exposing certain prefixes to the external Internet.

The V flag indicates that the mobile node MUST tunnel its outbound
traffic to the MAP if its RCoA is used as a source address in
outbound packets. This flag is only useful if the P or I flags are
set. The aim of this flag is to avoid any potential ingress filtering

Soliman, Castelluccia, El-Malki, Bellier [Page 18]

INTERNET-DRAFT HMIPv6 June,2003

problems in the ARs (in cases where the ingress filter cannot be
manually configured to allow an RCoA prefix).

A mobile node MAY choose to register with more than one MAP
simultaneously or use both MAP address the RCoA and its own address LCoA as CoAs care-of addresses
simultaneously with different correspondent nodes provided the
setting of the P and I flags allow such choices. nodes.

8. Updating previous Anchor Points MAPs

When a mobile host node moves into a new MAP domain, the mobile node may
send a BU to the previous MAP requesting it to forward packets
addressed to the mobile nodeËs node's new CoA. An administrator MAY restrict
the MAP from forwarded forwarding packets to LcoAs LCoAs outside the MAPËs MAP's domain.
However, it is RECOMMENDED that MAPs be allowed to forward packets to
LCoAs associated with some of the ARs in neighbouring MAP domains,
provided that they are located within the same administrative domain.
For instance, a MAP could be configured to forward packets to LCoAs
associated with ARs that are geographically adjacent to ARs on the
boundary of its domain. This will allow for a smooth inter-MAP
handover as it allows the mobile node to continue to receive packets
while updating the new MAP, its HA and, potentially, correspondent
nodes.

9. Special optimisations for sending Binding Updates

In some link layers where Notes on MAP selection by the MAC acquisition time (before sending
each frame) is significant, it maybe useful for mobile nodes to
encapsulate the IP packet including a BU sent to the HA inside the IP
packet including a BU sent to the MAP. The decision on whether this
optimisation should be used or not is left to the mobile node
implementation, depending on the type of underlying L2 used for
transmission.

It should be noted however, that the use of such encapsulation may
cause extra signalling in case the Home registration was rejected by
the HA or MAP (e.g. if DAD failed and the mobile node is required to
provide a new Home address or if the MAP rejected the BU, forcing the
mobile node to re-register with the HA). Furthermore, the mobile node
might receive a binding acknowledgement from the MAP that contains a
lower lifetime than that received from the Home Agent. Hence, mobile
nodes should be careful when utilising this optimisation.

Therefore by default the MN SHOULD only send a BU containing its RCoA
to the HA and correspondent nodes after having received a positive
local BU acknowledgement from the MAP. This may be changed if it is
proven that the change will not impact the protocol behaviour.

Soliman, Castelluccia, El-Malki, Bellier [Page 19]

INTERNET-DRAFT HMIPv6 June,2003

10. Notes on MAP selection by the mobile node

HMIPv6 provides node

HMIPv6 provides a flexible mechanism for local mobility management
within a visited network. As explained earlier a MAP can exist on any
level
anywhere in a hierarchy including the AR. operator's network (including the AR). Several MAPs
can be located within a hierarchy the same domain independently of each other. In
addition, overlapping MAP domains are also allowed and recommended.
Both static and dynamic hierarchies are supported.

When the mobile node receives a router Advertisement advertisement including a MAP
option, it should perform actions according to the following movement
detection mechanisms. In a Hierarchical Mobile IP network such as the
one described in this draft, the mobile node SHOULD should be:

- "Eager" to perform new bindings

Soliman, Castelluccia, El Malki, Bellier [Page 17]

INTERNET-DRAFT HMIPv6 February 2004

- "Lazy" in releasing existing bindings

The above means that the mobile node should register with any "new"
MAP advertised by the AR (Eager). The method by which the mobile node
determines whether the MAP is a "new" MAP is described in section 5.
9.1. The mobile node should not release existing bindings until it no
longer receives the MAP option (or receives it with a lifetime of
zero) or the lifetime of its existing binding expires (Lazy). This
Eager-Lazy approach described above will assist in providing a
fallback mechanism in case of the failure of one of the MAP routers,
as it would reduce the time it takes for a mobile node to inform its
correspondent nodes and HA about its new COA.

10.1 care-of address.

9.1 MAP selection in a distributed-MAPs distributed-MAP environment

The MN mobile node needs to consider several factors to optimally select
one or more MAPs, where several MAPs are available in the same
domain.

There are no benefits foreseen in selecting more than one MAP and
forcing packets to be sent from the higher MAP down through a
hierarchy of MAPs. This approach may add forwarding delays and
eliminate the robustness of IP routing between the highest MAP and
the mobile node. node; it is therefore prohibited by this specification.
Hence, allowing more than one MAP (Ÿabove÷ (ôaboveö the AR) within a network
should not imply that the mobile node forces packets to be routed
down the hierarchy of MAPs. However, placing more than one MAP Ÿabove÷
ôaboveö the AR can be used for redundancy and as an optimisation for
the different mobility scenarios experienced by mobile nodes. The
MAPs are used independently from each other by the MN (e.g. each MAP
is used for communication to a certain set of CNs).

In terms of the Distance based Distance-based selection in a network with several
MAPs, a mobile node may choose to register with the furthest MAP to
avoid frequent re-registrations. This is particularly important for
fast mobile nodes that will perform frequent handoffs. In this
scenario, the choice of a further more distant MAP would reduce the
probability of having to change a MAP and informing all correspondent
nodes and the

Soliman, Castelluccia, El-Malki, Bellier [Page 20]

INTERNET-DRAFT HMIPv6 June,2003 HA. This specification does not provide an algorithm
for the distance-based MAP selection. However, such algorithm may be
introduced in future extensions utilising information about the speed
of mobility from lower layers.

In a scenario where several MAPs are discovered by the mobile node in
one domain, the mobile node may need some sophisticated algorithms to
be able to select the appropriate MAP. These algorithms would have
the mobile node speed as an input (for distance based selection)
combined with the preference field in the MAP option. However, this
specification proposes that the mobile node uses the following
algorithm as a default, where other optimised algorithms may are not be
available. The following algorithm is simply based on selecting the
furthest possible MAP,

Soliman, Castelluccia, El Malki, Bellier [Page 18]

INTERNET-DRAFT HMIPv6 February 2004

MAP that is most distant, provided that its preference value did not
reach a value of zero. The mobile node operation is shown below:

1. Receive and parse all MAP options
2. Arrange MAPs in a descending order, starting with the furthest
away MAP (i.e. MAP option having largest Dist field)
3. Select first MAP in list
4. If the Preference value or the valid lifetime are set to zero,
select the following MAP in the list.
5. Repeat step (4) while new MAP options still exist.

Implementing the exist until a MAP is
found with preference value and valid lifetime different from
zero.

Implementing the steps above would result in mobile nodes selecting
by default the most distant or Ÿfurthest÷ furthest available MAP by default.
This will continue to take place, until the preference value reduces
to zero. Following this, mobile nodes will start selecting another
MAP.

10.2

9.2 MAP selection in a flat mobility management architecture

Network operators may choose a flat architecture in some cases where
a Mobile IPv6 handover may be considered a rare event. In these
scenarios operators may choose to include the MAP function in ARs
only. The inclusion of the MAP function in ARs can still be useful to
reduce the time required to update all correspondent nodes and the
HA. In this scenario, a mobile node may choose a MAP (in the AR) as
an anchor point when performing a handoff. This kind of dynamic
hierarchy (or anchoring) is only recommended for cases where inter-AR
movement is not frequent.

11.

10. Detection and recovery from MAP failures

This specification introduces a MAP which can be seen as a local Home
Agent in a visited network. A MAP, like a Home Agent, is a single
point of failure. If a MAP fails, its binding cache content will be
lost, resulting in loss of communication between mobile and
correspondent nodes. This situation may be avoided with the use of
more than one MAP on the same link and utilising some form of context
transfer protocol between them. Alternatively, future versions of the

Soliman, Castelluccia, El-Malki, Bellier [Page 21]

INTERNET-DRAFT HMIPv6 June,2003
Virtual Router Redundancy Protocol [10] [10], or HA redundancy protocols
may allow networks to recover from MAP failures.

In cases where such protocols are not supported, the mobile node
would need to detect MAP failures. The mobile node can detect this
situation when it receives a router advertisement containing a MAP
option with a lifetime of zero. The mobile node should start the MAP
discovery process and attempt to register with another MAP. It After it
has selected and registered with another MAP it will also need to
inform correspondent nodes and the Home Agent if its RCoA has
changed. Note that, in the presence of a protocol that transfers

Soliman, Castelluccia, El Malki, Bellier [Page 19]

INTERNET-DRAFT HMIPv6 February 2004

binding cache entries between MAPs for redundancy purposes, a new MAP
may be able to provide the same RCoA to the mobile node, e.g. if both
MAPs advertise the same prefix in the MAP option. This would save the
mobile node from updating correspondent nodes and the Home Agent.

Access routers can be triggered to advertise a MAP option with a
lifetime of zero (indicating MAP failure) in different ways:

- By manual intervention.
- In a dynamic manner.

ARs can perform Dynamic detection of MAP failure can be done by sending ICMP Echo
request messages to the MAP regularly (e.g. every ten seconds). If no
response is received an AR may try to aggressively send echo requests
to the MAP for a short period of time (e.g. once every 5 seconds for
15 seconds); if no reply is received, a MAP option may be sent with a
valid lifetime value of zero.

This specification does not mandate a particular recovery mechanism.
However, any similar mechanism between the MAP and an AR SHOULD be
secure to allow for message authentication, integrity protection and
protection against replay attacks.

11. IANA Considerations

Section 5 introduces a new IPv6 Neighbour Discovery Option called the
MAP Option. An Option Type value for the MAP Option must be assigned
by IANA within the option numbering space for IPv6 Neighbour
Discovery messages.

Section 7.2.1 introduces a new OpCode in the Match-Prefix part of
Prefix Code Operation (PCO) used in Router Renumbering for IPv6 [2].
A next available OpCode value of 4 is proposed for allocation by IETF
Consensus only according to [11] as specified in [2].

12. Security considerations

This specification introduces a new concept to Mobile IPv6, namely, a
Mobility Anchor Point that acts as a local Home Agent. It is crucial
that the security relationship between the mobile node and the MAP is
of strong nature; it MUST involve mutual authentication, integrity
protection and protection against replay attacks. Confidentiality may
be needed for payload traffic but is not required for binding updates
to the MAP. The absence of any of these protections may lead to
malicious mobile nodes impersonating other legitimate ones,
impersonating a MAP. Any of these attacks will undoubtedly cause
undesirable impacts to the mobile nodeËs node's communication with all
correspondent nodes having knowledge of the mobile nodeËs node's RCoA.

Three different relationships (related to securing binding updates)
need to be considered:

Soliman, Castelluccia, El Malki, Bellier [Page 20]

INTERNET-DRAFT HMIPv6 February 2004

1) The mobile node “ - MAP
2) The mobile node “ - Home Agent

Soliman, Castelluccia, El-Malki, Bellier [Page 22]

INTERNET-DRAFT HMIPv6 June,2003
3) The mobile node - correspondent node

12.1 Mobile node “ - MAP security

HMIPv6 uses an additional registration between the mobile node and
its current MAP. As explained in this document, when a mobile node
moves into a new domain (i.e. served by a new MAP), it obtains an
RCoA, a LCoA and registers the binding between this these two addresses
with the new MAP. The MAP then verifies whether the RCoA has not been
registered yet and if not so it creates a BCE binding cache entry with the
RCoA and LCoA. Whenever the mobile node gets a new LCoA, it needs to
send a new
binding update BU that specifies the binding between RCoA and its new
LCoA. This binding update BU needs to be authenticated otherwise any host could send
a BU for the mobile node's RCoA and hijack the mobile node's packets.
However since the RCoA is temporary and is not bound to a particular
node, a mobile node does not have to prove that it owns its RCoA (as
(unlike the requirement on home addresses in Mobile IPv6) when it
establishes a Security Association with its MAP. A MAP only needs to make sure
ensure that when it
receives a BU for a RCoA, this BU particular RCoA was issued by the same mobile
node that established the Security Association. Association for that RCoA.

The MAP does not need to know the identity of the mobile node nor its
Home Address. As a result the SA between the mobile node and the MAP
can be simply established using any key establishment protocols such as IKE.
A return routability test is not necessary.

The MAP needs to set the SA for the RCoA (not the LCoA). This can be
performed with IKE [6]. The mobile node uses its LCoA as source
address but specifies that the RCoA should be used in the SA. This is
achieved by using the RCoA as the client identity in IKE Phase 2
negotiation (Quick mode).
negotiation. This step is identical to the use of the home address in
IKE phase 2.

If a binding cache entry exists for a given RCoA, the MAP's IKE
policy check MUST point to the SA used to install the entry. If the
mobile node's credentials stored in the existing SA does do not match the new SA which
ones provided in the current negotiation, the MN is trying to
establish, then a MAP MUST reject the new
SA establishment request for such RCoA with an INVALID-ID-INFORMATION
notification [6]. This is to prevent two different mobile nodes from
registering (intentionally or not) the same RCoA. Upon receiving this
notification, the mobile node should SHOULD generate a new RCoA and restart
the IKE negotiation.

Binding updates between the Alternatively, a MAP and the mobile node MUST be protected
with either AH or ESP [ ] in transport mode. may decide that if a
binding cache entry already exists for a particular RCoA, no new
security association should be established for such RCoA,
independently of the mobile node credentials. This stops the mobile
node from re-establishing a security association for the same RCoA.
This is not a major problem since both AH and ESP headers allow for 4

Soliman, Castelluccia, El Malki, Bellier [Page 21]

INTERNET-DRAFT HMIPv6 February 2004

billion packets to be sent (the size of the sequence number field)
using the same security association.

Binding updates between the MAP and the mobile node MUST be protected
with either AH or ESP in transport mode. When ESP is used, a non-
null non-null
authentication algorithm must be used.

12.2 Mobile node “ û correspondent node security

Mobile IPv6 [1] defines a return routability procedure that allows
mobile and correspondent nodes to authenticate binding updates and
acknowledgements. This specification does not impact the return

Soliman, Castelluccia, El-Malki, Bellier [Page 23]

INTERNET-DRAFT HMIPv6 June,2003
routability test defined in [1]. However, it is important to note
that mobile node implementers need to be careful when selecting the
source address of the HOTI and COTI messages defined in [1]. The
source address used in HOTI messages MUST be the mobile nodeËs RCoA.
When sending this message, the mobile node need to be aware that node's home
address. The packet containing the HOTI message may need to be tunnelled to is encapsulated
twice. The inner encapsulating header contains the MAP, which will de-capsulate
it RCoA in the source
address field and send it to the Home Agent (the destination home agent's address in the
tunnelled HOTI message). destination address
field. The decision about whether such message
should be tunnelled to the MAP or not, depends on the contents of outer encapsulating header contains the
V, P and I flags included mobile node's LCoA
in the MAP option. If either the P or I
flag is set, source address field and the V flag is set, MAP's address in the mobile destination
field.

12.3 Mobile node must tunnel all
outgoing packets to the MAP. For the HOTI message, this would mean
that the message is tunnelled twice, once to the û Home Agent, then
tunnelled again to the MAP.

If either Agent security

The security relationship between the P or I flag is set, mobile node and the V flag is not set, the
mobile node does not need to tunnel these packets to the MAP. The
same conditions apply to the COTI message.

If neither the P or I flag is set in the MAP option, the mobile node
is not required to tunnel packets to the MAP. However, the HOTI and
COTI messages MUST be tunnelled through the MAP. This is needed to
avoid cases where ingress filtering in the AR is not configured to
support the use of RCoA as a source address. The MAP is required to
accept tunnelled packets from the mobile node independently of the
settings of the P, I and V flags.

12.3 Mobile node “ Home Agent security

The security relationship between the mobile node and its Home Agent its Home Agent
is not impacted by this specification. The tunnel end point for the
Home Agent is the mobile nodeËs RCOA. If either the P or I flag is
set, and the V flag is set, the mobile node must encapsulate packets
to the MAP. When applying this to the tunnel interface to the Home
Agent, it would mean that double encapsulation is necessary for both:
outgoing and incoming packets.

13. Acknowledgements

The authors would like to thank Conny Larsson (Ericsson) and Mattias
Pettersson (Ericsson) for their valuable input to this draft.
The authors would also like to thank the members of the French RNRT
MobiSecV6 project (BULL, France Telecom and INRIA) for testing the
first implementation and for their valuable feedback. The INRIA
HMIPv6 project is partially funded by the French Government.

In addition, the authors would like to thank the following members of
the working group in alphabetical order: Samita Chakrabarti (Sun),
Greg
Gregory Daley (Monash University), Francis Dupont (Ernst-Bretagne),
Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave Johnson (Rice
University), Annika Jonsson (Ericsson), James Kempf (Docomo labs),

Soliman, Castelluccia, El-Malki, Bellier [Page 24]

INTERNET-DRAFT HMIPv6 June,2003
Martti Kuparinen (Ericsson) Fergal Ladley, Nick æSharkeyÆ Moore
(Monash University) Erik Nordmark (Sun), Basavaraj Patil (Nokia) (Nokia),
Brett Pentland (Monash University), and Alper Yegin (Docomo labs) for
their comments on the draft.

14. Notice Regarding Intellectual Property Rights

see

See http://www.ietf.org/ietf/IPR/ERICSSON-hmipv6.txt

Soliman, Castelluccia, El Malki, Bellier [Page 22]

INTERNET-DRAFT HMIPv6 February 2004

15. References

Normative

[1] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-21.txt. draft-ietf-mobileip-ipv6-24.txt, work in progress.

[2] M. Crawford ŸRouter ôRouter Renumbering for IPv6÷. IPv6ö. RFC 2984.

[3] S. Thomson and T. Narten "IPv6 Stateless Address
Autoconfiguration". RFC 2462.

[4] T. Narten, E. Nordmark and W. Simpson Ÿ ô Neighbour Discovery for
IP version 6 Ÿ. ô. RFC 2461.

[5] S. Deering and B. Hinden, ŸInternet ôInternet Protocol version 6 (IPv6)
specification÷.
specificationö. RFC 2460

[6] D. Harkins and D. Carrel, ŸThe ôThe Internet Key Exchange (IKE)÷. (IKE)ö.
RFC 2409.

[7] S. Kent and R. Atkinson, ŸIP ôIP Authentication Header÷. Headerö. RFC 2402

[8] S. Kent and R. Atkinson, ŸIP ôIP Encapsulating Security Payload÷. Payloadö.
RFC 2406

[9] S. Kent and R. Atkinson, ŸSecurity ôSecurity Architecture for the
Internet÷.
Internetö. RFC 2401

[10] A. Conta and S. Deering, ŸGeneric ôGeneric Packet Tunneling in IPv6
Specification÷
Specificationö RFC 2473.

[11] S. Bradner, ŸKeywords ôKeywords to use in RFCs to Indicate Requirement
Levels÷.
Levelsö. RFC2119

Non-Normative

[10] S. Knight, et al, ŸVirtual ôVirtual Router Redundancy Protocol÷. Protocolö.
RFC 2338.

[11] K. ElMalki, El Malki, Editor, et al, "Low latency Handoffs in Mobile
IPv4". draft-ietf-mobileip-lowlatency-handoffs-v4-00. draft-ietf-mobileip-lowlatency-handoffs-v4-08. work
in progress.

Soliman, Castelluccia, El-Malki, Bellier [Page 25]

INTERNET-DRAFT HMIPv6 June,2003

[12] R. Koodli, Editor, et al,"Fast Handovers for Mobile IPv6",
draft-ietf-mobileip-fast-mipv6-05.txt.
draft-ietf-mipshop-fast-mipv6-01.txt. Work in progress.

[13] K. ElMalki El Malki and H. Soliman, ŸSimultaneous ôSimultaneous Bindings for Mobile
IPv6 Fast Handoffs÷. draft-elmalki-mobileip-bicasting-v6-03.
Work in progress.

[14] P. Ferguson and D. Senie, ŸNetwork Ingress Filtering: Defeating
Denial Mobile
IPv6 Fast Handoffsö. draft-elmalki-mobileip-bicasting-v6-03.
Work in progress.

Soliman, Castelluccia, El Malki, Bellier [Page 23]

INTERNET-DRAFT HMIPv6 February 2004

[14] P. Ferguson and D. Senie, ôNetwork Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofingö. RFC2267

[15] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-04
(work in progress), February 2004.

16. Authors' Addresses

Hesham Soliman
Flarion Technologies
email: h.soliman@flarion.com

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

Karim El Malki
Ericsson AB
LM Ericssons Vag. 8
126 25 Stockholm
Sweden
email: karim.el-malki@ericsson.com
phone: +46 8 7195803

Ludovic Bellier
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
France
email: ludovic.bellier@inria.fr
phone: +33 4 76 61 52 15

17. Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of

Soliman, Castelluccia, El Malki, Bellier [Page 24]

INTERNET-DRAFT HMIPv6 February 2004

claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

18. Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Service Attacks
developing Internet standards in which employ IP Source Address
Spoofing÷. RFC2267

16. Authors' Addresses case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The working group can limited permissions granted above are perpetual and will not be contacted via
revoked by the current chairs:

Basavaraj Patil Phil Roberts
Nokia Corporation Megisto Systems,Inc
6000 Connection Drive 20251 Century Blvd
Irving, TX 75039 Germantown, MD 20874
USA USA

Phone: +1 972-894-6709 Phone: +1 301-444-1700
EMail: Raj.Patil@nokia.com EMail: proberts@megisto.com
Fax : +1 972-894-5349 Fax: +1 301-515-3675

Questions about this memo can also be directed to:

Hesham Soliman
Flarion Technologies
E-mail: H.Soliman@flarion.com

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

Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vag. 8
126 25 Stockholm
SWEDEN

Phone: +46 8 7195803
Fax: +46 8 7190170 Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Soliman, Castelluccia, El-Malki, El Malki, Bellier [Page 26] 25]

INTERNET-DRAFT HMIPv6 June,2003

E-mail: Karim.El-Malki@era.ericsson.se

Ludovic Bellier
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
France

email: ludovic.bellier@inria.fr
phone: +33 4 76 61 52 15
fax: +33 4 76 61 52 52

17. February 2004

Appendix A “ û Fast Mobile IPv6 Handovers and HMIPv6

Fast Handovers are required to ensure that the layer 3 (Mobile IP)
handover delay is minimised, thus also minimising and possibly
eliminating the period of service disruption which normally occurs
when a mobile node moves between two ARs. This period of service
disruption usually occurs due to the time required by the mobile node
to update its HA using Binding Updates after it moves between ARs.
During this time period the mobile node cannot resume or continue
communications. The mechanism to achieve Fast Handovers with Mobile
IPv6 is described in [12] and is briefly summarised here. This
mechanism allows the anticipation of the layer 3 handover such that
data traffic can be redirected to the mobile nodeËs nodeÆs new location
before it moves there.

While the mobile node is connected to its old previous Access Router (oAR)
(PAR) and is about to move to a new Access Router (nAR), (NAR), the Fast
Handovers in Mobile IPv6 requires in sequence:

1) the mobile node to obtain a new care-of address at the nAR NAR while
connected to the oAR PAR
2) New CoA to be used at nAR NAR case: the mobile node to send a F-BU
(Fast BU) to its old previous anchor point (i.e. oAR) PAR) to update its
binding cache with the mobile nodeËs node's new CoA while still attached
to oAR PAR
3) The old previous anchor point (i.e. oAR) PAR) to start forwarding packets
destined for the mobile node to the mobile nodeËs node's new CoA at nAR NAR
(or old CoA tunnelled to nAR NAR if new CoA is not applicable).
4) Old CoA to be used at nAR NAR case: the mobile node to send a F-BU
(Fast BU) to its old previous anchor point (i.e. oAR), PAR), after it has
moved and attached to nAR, NAR, in order to update its binding cache
with the mobile nodeËs node's new CoA.

The mobile node or oAR PAR may initiate the Fast Handover procedure by
using wireless link-layer information or link-layer Ÿtriggers÷ triggers which
inform that the mobile node will soon be handed off between two
wireless access points respectively attached to oAR PAR and nAR. NAR. If the
Ÿtrigger÷
ôtriggerö is received at the mobile node, the mobile node will
initiate the layer-3 handover process by sending a Proxy Router
Solicitation message to oAR. PAR. Instead if the Ÿtrigger÷ ôtriggerö is received at

Soliman, Castelluccia, El-Malki, Bellier [Page 27]

INTERNET-DRAFT HMIPv6 June,2003

oAR
PAR then it will transmit a Proxy Router Advertisement to the
appropriate mobile node, without the need for solicitations. The
basic Fast Handover message exchanges are illustrated in Figure A.1.

Soliman, Castelluccia, El Malki, Bellier [Page 26]

INTERNET-DRAFT HMIPv6 February 2004

+-----------+ 1a. HI +-----+
| | ---------------->| nAR NAR |
| oAR PAR | 1b. HAck | |
+-----------+ <--------------- +-----+
^ | ^
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU)
| | RtAdv | 4. Fast BA (F-BACK)
| v v
+------------+
| MN |
+------------+ - - - - - ->
Movement

Figure A.1 “ û Fast Mobile IPv6 Handover Protocol

The mobile node obtains a new care-of address while connected to oAR PAR
by means of router advertisements containing information from the nAR NAR
(Proxy Router Advertisement which may be sent due to a Proxy Router
Solicitation). The oAR PAR will validate the mobile nodeËs nodeÆs new CoA by
sending a Handover Initiate (HI) message to the nAR. NAR. The new CoA sent
in the HI message is formed by appending the mobile nodeËs Ÿcurrent÷ node's current
interface identifier to the nARËs NAR's prefix. Based on the response
generated in the Handover Acknowledge (HAck) message, the oAR PAR will
either generate a tunnel to the mobile nodeËs node's new CoA (if the address
was valid) or generate a tunnel to the nARËs NAR's address (if the address
was already in use on the new subnet). If the address was already in
use on the new subnet it is assumed that there will be no time to
perform another attempt to configure the mobile node with a CoA on
the new link, so the nAR NAR will generate a host route for the mobile
node using its old CoA. Note that message 1a may precede message 2b
or occur at the same time.

In [12], the ARs act as local Home Agents which hold binding caches
for the mobile nodes and receive Binding Updates. This makes these
ARs function like the MAP specified in this document. Also, it is
quite possible that the ARs are not directly connected, but
communicate through an aggregation router. Such an aggregation router
is therefore also an ideal position for the MAP functionality. These
are two ways of integrating the HMIPv6 and Fast Handover mechanisms.
The first involves placing MAPs in place of the ARs which is a
natural step. The second scenario involves placing the MAP in an
aggregation router Ÿabove÷ ôaboveö the ARs. In this case, [12] specifies
forwarding of packets between oAR PAR and nAR. NAR. This could be inefficient
in terms of delay, bandwidth efficiency since packets will traverse
the MAP-oAR MAP-PAR link twice and packets arriving out of order at the

Soliman, Castelluccia, El-Malki, Bellier [Page 28]

INTERNET-DRAFT HMIPv6 June,2003
mobile node. Using the MAP in the aggregation router would improve
the efficiency of Fast Handovers which could make use of the MAP to
redirect traffic, thus saving delay and bandwidth between the
aggregation router and the oAR. PAR.

Soliman, Castelluccia, El Malki, Bellier [Page 27]

INTERNET-DRAFT HMIPv6 February 2004

+---------+
| MAP |
+-------------->| |
| +---------+
| | ^
| 1a. HI | |
| | |
| | | 1b. HAck
| v |
+---------+ | +---------+
| | | | nAR NAR |
| oAR PAR | | | |
+---------+ | +---------+
^ | |
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU) from mobile node to
| | MAP
| | RtAdv | 4. Fast BA (F-BACK) from MAP to
| | | mobile node
| v v
+------------+
| MN | Movement
+------------+ - - - - - ->

Figure A.2 “ û Fast Mobile IPv6 Handover Protocol using HMIPv6

In Figure A.2, the HI/HAck messages now occur between the MAP and nAR NAR
to check the validity of the newly requested care-of address and to
establish a temporary tunnel should the new care-of address not be
valid. Therefore the same functionality of the Fast Handover
procedure is kept but the anchor point is moved from the oAR PAR to the
MAP.

As in the previous Fast Handover procedure, in the network-determined
case the layer-2 Ÿtriggers÷ ôtriggersö at the oAR PAR will cause the oAR PAR to send a
Proxy Router Advertisement to the mobile node with the MAP option. In
the mobile-determined case this is preceded by a Proxy Router
Solicitation from the mobile node. The same layer-2 Ÿtrigger÷ trigger at oAR PAR in
the network-determined case could be used to independently initiate
Context Transfer (e.g. QoS) between oAR PAR and nAR. NAR. In the
mobile-determined mobile-
determined case the trigger at oAR PAR could be replaced by the reception
of a Proxy Router Solicitation or F-BU. Context Transfer is being
worked on in the IETF Seamoby WG.

The combination of Fast Handover and HMIPv6 allows the anticipation
of the layer 3 handoff such that data traffic can be efficiently

Soliman, Castelluccia, El-Malki, Bellier [Page 29]

INTERNET-DRAFT HMIPv6 June,2003
redirected to the mobile nodeËs node's new location before it moves there.
However it is not easy to determine the correct time to start
forwarding traffic from the MAP to the mobile nodeËs node's new location,
which has an impact on how smooth the handoff will be. The same

Soliman, Castelluccia, El Malki, Bellier [Page 28]

INTERNET-DRAFT HMIPv6 February 2004

issues arises arise in [12] with respect to when to start forwarding between oAR
PAR and nAR. NAR. Packet loss will occur if this is performed too late or
too early with respect to the time in which the mobile node detaches
from oAR PAR and attaches to nAR. NAR. Such packet loss is likely to occur if
the MAP updates its binding cache upon receiving the
Ÿanticipated÷ F-BU, anticipated F-
BU, since it is not known when exactly the mobile node will perform
or complete the layer-2 handover to nAR NAR relative to when the mobile
node transmits the F-BU. Also, some measure is needed to support the
case in which the mobile nodeËs node's layer-2 handover unexpectedly fails
(after Fast Handover has been initiated) or when the mobile node
moves quickly back-and-forth between ARs (ping-pong). Simultaneous
bindings [13] provides a solution to these issues. In [13] a new
Simultaneous Bindings Flag is added to the Fast Binding Update (F-BU)
message and a new Simultaneous Bindings suboption is defined for Fast
Binding Acknowledgement (F-BAck) message. Using this enhanced
mechanism, upon layer-3 handover, traffic for the mobile node will be
sent from the MAP to both oAR PAR and nAR NAR for a certain period thus
isolating the mobile node from layer-2 effects such as handover
timing, ping-pong or handover failure and providing the mobile node
with uninterrupted layer-3 connectivity.

Soliman, Castelluccia, El-Malki, El Malki, Bellier [Page 30] 29]

----