Network Working Group H. Soliman
Internet-Draft Elevate Technologies
Intended status: Standards Track C. Castelluccia
Expires: January 15, 2009 INRIA
K. ElMalki
Athonet
L. Bellier
INRIA
July 14, 2008
Hierarchical Mobile IPv6 Mobility Management
draft-ietf-mipshop-4140bis-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Internet-Draft will expire on January 15, 2009.
Soliman, et al. Expires January 15, 2009 [Page 1]
Internet-Draft HMIPv6 July 2008
Abstract
This document introduces extensions to Mobile IPv6 and IPv6 Neighbour
Discovery to allow for local mobility handling. Hierarchical
mobility management for Mobile IPv6 is designed to reduce the amount
of signalling between the Mobile Node, its Correspondent Nodes, and
its Home Agent. The Mobility Anchor Point (MAP) described in this
document can also be used to improve the performance of Mobile IPv6
in terms of handover speed.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of HMIPv6 . . . . . . . . . . . . . . . . . . . . . . 7
3.1. HMIPv6 Operations . . . . . . . . . . . . . . . . . . . . 7
4. Mobile IPv6 Extension - Local Binding update . . . . . . . . . 10
5. Neighbour Discovery Extension: The MAP Option . . . . . . . . 11
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Mobile Node Operation . . . . . . . . . . . . . . . . . . 13
6.1.1. Sending Packets to Correspondent Nodes . . . . . . . . 14
6.2. MAP Operations . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Home Agent Operations . . . . . . . . . . . . . . . . . . 15
6.4. Correspondent Node Operations . . . . . . . . . . . . . . 16
6.5. Local Mobility Management Optimisation within a MAP
Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.6. Location Privacy . . . . . . . . . . . . . . . . . . . . . 16
7. MAP Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Mobile Node Operation . . . . . . . . . . . . . . . . . . 17
8. Updating Previous MAPs . . . . . . . . . . . . . . . . . . . . 18
9. Note On MAP Selection by the Mobile Node . . . . . . . . . . . 19
9.1. MAP Selection in Distributed MAP Environment . . . . . . . 19
9.2. MAP Selection in a Flat Mobility Architecture. . . . . . . 20
10. Detection and Recovery from MAP Failures . . . . . . . . . . . 22
11. Tunelling impacts on MTU . . . . . . . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12.1. Mobile Node - MAP Security . . . . . . . . . . . . . . . . 25
12.2. Mobile Node - Correspondent Node Security . . . . . . . . 27
12.3. Mobile Node - Home Agent Security . . . . . . . . . . . . 27
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
15.1. Normative References . . . . . . . . . . . . . . . . . . . 30
15.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Appendix A - Fast Mobile IPv6 Handoers and HMIPv6 . . 31
Appendix B. Appendix B - Changes from RFC 4140 . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Soliman, et al. Expires January 15, 2009 [Page 2]
Internet-Draft HMIPv6 July 2008
Intellectual Property and Copyright Statements . . . . . . . . . . 37
Soliman, et al. Expires January 15, 2009 [Page 3]
Internet-Draft HMIPv6 July 2008
1. Requirements notation
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 [RFC2119].
In addition, the following terms are introduced:
Access Router (AR)
The AR is the Mobile Node's default router. The AR aggregates the
outbound traffic of mobile nodes.
Mobility Anchor Point (MAP)
A Mobility Anchor Point is a router located 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 Address (RCoA)
An RCoA is an address obtained by the mobile node from the visited
network. An RCoA is an address on the MAP's subnet. It is auto-
configured by the mobile node when receiving the MAP option.
HMIPv6-Aware Mobile Node
An HMIPv6-aware mobile node is a mobile 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 local binding
updates (Binding Update with the M flag set).
On-Link Care-of Address
The LCoA is the on-link CoA configured on a mobile node's
interface based on the prefix advertised by its default router.
In [RFC3775], 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.
Soliman, et al. Expires January 15, 2009 [Page 4]
Internet-Draft HMIPv6 July 2008
2. Introduction
This specification introduces the concept of a Hierarchical Mobile
IPv6 network, utilising a new node called the Mobility Anchor Point
(MAP).
Mobile IPv6 [RFC3775] 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 loss). 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 a
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). 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:
o The mobile node sends Binding Updates to the local MAP rather than
the HA (which is typically further away) and CNs.
o 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. Furthermore, HMIPv6 allows mobile
nodes to hide their location from correspondent nodes and Home Agents
Soliman, et al. Expires January 15, 2009 [Page 5]
Internet-Draft HMIPv6 July 2008
while using Mobile IPv6 route optimisation. The security differences
between the MAP and the Home Agent are described in Section 12
It is pertinent to note that the use of the MAP does not rely on or
assume the presence of a permanent Home Agent. In other words, a
mobile node need not have a permanent Home address or Home Agent in
order to be HMIPv6-aware or use the features in this specification.
A MAP may be used by a mobile node in a nomadic manner to achieve
mobility management within a local domain. Section 6.5 describes
such scenario.
Soliman, et al. Expires January 15, 2009 [Page 6]
Internet-Draft HMIPv6 July 2008
3. Overview of HMIPv6
This Hierarchical Mobile IPv6 scheme introduces a new function, the
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 within or between different
types of access networks.
A mobile node entering a MAP domain will receive Router
Advertisements containing information about one or more local MAPs.
The MN can bind its current location (on-link CoA) with an address on
the 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
correspondent nodes it communicates 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.
3.1. HMIPv6 Operations
The network architecture shown in Figure 1 illustrates an example of
the use of the MAP in a visited network.
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
Soliman, et al. Expires January 15, 2009 [Page 7]
Internet-Draft HMIPv6 July 2008
(AR2), while communicating with the correspondent node. A multi-
level hierarchy is not required for a higher handover performance.
Hence, it is sufficient to locate one or more MAPs (possibly covering
the same domain) at any position in the operator's network.
+-------+
| HA |
+-------+ +----+
| | CN |
| +----+
| |
+-------+-----+
|
|RCoA
+-------+
| MAP |
+-------+
| |
| +--------+
| |
| |
+-----+ +-----+
| AR1 | | AR2 |
+-----+ +-----+
LCoA1 LCoA2
+----+
| MN |
+----+ ------------>
Movement
Figure 1: Figure 1: Hierarchical Mobile IPv6 domain
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 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 be implemented 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.
Soliman, et al. Expires January 15, 2009 [Page 8]
Internet-Draft HMIPv6 July 2008
The process of MAP discovery continues as the mobile node moves from
one subnet to the next. Every time the mobile node detects movement,
it will also detect whether it is still in the same MAP domain. The
router advertisement used to detect movement will also inform the
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
sending 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
[RFC3775] 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 because the MAP
does not modify the contents of the original packet. Normal
processing of the received packets (as described in [RFC3775]) 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
to 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 thus will result in more efficient usage of
network bandwidth. The mobile node can also use its current on-link
address (LCoA) as a CoA, as specified in [RFC3775]. 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.
Soliman, et al. Expires January 15, 2009 [Page 9]
Internet-Draft HMIPv6 July 2008
4. Mobile IPv6 Extension - Local Binding update
This section outlines the extensions proposed to the binding update
specified in [RFC3775].
A new flag is added: the M flag, which indicates MAP registration.
When a mobile node registers with the MAP, the M and A flags MUST be
set to distinguish this registration from 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Local Binding Update
M
If set to 1 it indicates a MAP registration.
Soliman, et al. Expires January 15, 2009 [Page 10]
Internet-Draft HMIPv6 July 2008
5. Neighbour Discovery Extension: The MAP Option
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The MAP option
Type
IPv6 Neighbor Discovery option. 23.
Length
8-bit unsigned integer. The length of the option and MUST be set
to 3.
Dist
A 4-bit unsigned integer identifying the Distance Between MAP and
the receiver of the advertisement. The Distance MUST be set to 1
if the MAP is on the same link as the mobile node. This field
need not be interpreted as the number of hops between MAP and the
mobile node. The only requirement is that the meaning of the
Distance field is consistently interpreted within one Domain. A
larger value in the dist field indicates that the MAP is further
away from the mobile node. That is, a MAP option with a dist
field of 5 indicates that this MAP is further away from the mobile
node than another option with a dist field value of 3. A Distance
value of Zero MUST NOT be used. If the MAP option is advertised
within an overlap between two different MAP domains then this
field MUST be consistently interpreted within the overlap area.
Pref
Soliman, et al. Expires January 15, 2009 [Page 11]
Internet-Draft HMIPv6 July 2008
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 MUST form an RCoA
based on the prefix in the MAP option.
Valid Lifetime
The minimum value (in seconds) of both the preferred and valid
lifetimes of the prefix assigned to the MAP's subnet. This value
indicates the validity of the MAP's address and consequently the
time for which the RCoA is valid.
Global Address
One of the MAP's global addresses. The 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 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. Thus, it necessitates a static prefix
length for the MAP's subnet.
Soliman, et al. Expires January 15, 2009 [Page 12]
Internet-Draft HMIPv6 July 2008
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 interface identifier and the subnet prefix received in
the MAP option.
As illustrated in this section, this protocol requires updating the
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 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
and an on-link CoA (LCoA). The RCoA is 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 [RFC3775] and includes
the 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 mobile node for this operation. The mobile node
MUST silently ignore binding acknowledgements that do not contain a
routing header type 2, which includes the mobile node's RCoA.
Following a successful registration with the MAP, a bi-directional
tunnel between the mobile node and the MAP is established. All
packets sent by the mobile node are tunnelled to the MAP. The outer
header contains the mobile node's LCoA in the source address field
and the MAP's address in the 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 the mobile node's RCoA are intercepted by
the MAP and tunnelled to the mobile node's LCoA.
This specification allows a mobile node to use more than one RCoA if
it received more than one MAP option. In this case, the mobile node
MAY 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
Soliman, et al. Expires January 15, 2009 [Page 13]
Internet-Draft HMIPv6 July 2008
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 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 and the RCoA is used as the care-of
address in the source address field. The mobile node may also send a
similar BU (i.e., that specifies the binding between the Home Address
and the RCoA) to its current correspondent nodes.
The mobile node SHOULD wait for the binding acknowledgement from the
MAP before registering the RCoA with other nodes (e.g. CN or HA, if
available). 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 binding lifetime with the MAP, which is
received in the Binding Acknowledgement.
In order to speed up the handover between MAPs and reduce packet
loss, a mobile node SHOULD send a local BU to its previous MAP,
specifying its new LCoA. Packets 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 remains
unchanged.
Note that a mobile node may send a BU containing its LCoA (instead of
its RCoA) to correspondent nodes. If these nodes are connected to
the same link, packets will then be routed directly without going
through the MAP.
6.1.1. Sending Packets to Correspondent Nodes
The mobile node can communicate with a correspondent node through the
HA, or in a route-optimised manner, as described in [RFC3775]. When
communicating through the HA, the message formats in [RFC3775] are
used.
If the mobile node communicates directly with the correspondent node
(i.e., the CN has a binding cache entry for the mobile node), the
Soliman, et al. Expires January 15, 2009 [Page 14]
Internet-Draft HMIPv6 July 2008
mobile node MUST use the same care-of address used to create a
binding cache entry in the correspondent node (RCoA) as a source
address. According to [RFC3775], the mobile node MUST also include a
Home Address option in outgoing packets. The Home address option
MUST contain the mobile node's home address.
6.2. MAP Operations
The MAP acts like an HA; it intercepts all packets addressed to
registered mobile nodes and tunnels them to the corresponding LCoA,
which is stored in its binding cache.
A MAP has no knowledge of the mobile node's Home address. The mobile
node will send a local BU to the MAP with the M and A flags set. The
aim of this BU is to inform the MAP that the mobile node has formed
an RCoA (contained in the BU as a Home address). If successful, the
MAP MUST return a binding acknowledgement to the mobile node,
indicating a successful registration. This is identical to the HA
operation in [RFC3775]. 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 MUST be able to accept packets tunnelled from the mobile
node, with the mobile node being the tunnel entry point and the MAP
being the tunnel exit point.
The MAP acts as a HA for the RCoA. Packets addressed to the RCOA are
intercepted by the MAP, using proxy Neighbour Advertisement, and then
encapsulated and routed to the mobile node's LCoA. This operation is
identical to that of the HA described in [RFC3775].
A MAP MAY be configured with the list of valid on-link prefixes that
mobile nodes can use to derive LCoAs. This is useful for network
operators that need to stop mobile nodes from continuing to use the
MAP after moving to a different administrative domain. If a mobile
node sent a binding update containing an LCoA that is not in the
MAP's "valid on-link prefixes" list, the MAP could reject the binding
update using existing error code 129 (administratively prohibited).
6.3. Home Agent Operations
The support of HMIPv6 is completely transparent to the HA's
operation. Packets addressed to a mobile node's Home Address will be
forwarded by the HA to its RCoA, as described in [RFC3775].
Soliman, et al. Expires January 15, 2009 [Page 15]
Internet-Draft HMIPv6 July 2008
6.4. Correspondent Node Operations
HMIPv6 is completely transparent to correspondent nodes.
6.5. Local Mobility Management Optimisation within a MAP Domain
In [RFC3775], it is stated that for short-term communication,
particularly communication that may easily be retried upon failure,
the mobile node MAY choose to directly use one of its care-of
addresses as the source of the packet, thus not requiring the use of
a Home Address option in the packet. Such use of the CoA will reduce
the overhead of sending each packet due to the absence of additional
options. In addition, it will provide an optimal route between the
mobile node and correspondent node.
HMIPv6-aware mobile nodes can use their RCoA as the source address
without using a Home Address option. In other words, the RCoA can be
used as a source address for upper layers. Using this feature, the
mobile node will be seen by the correspondent node as a fixed node
while moving within a MAP domain.
This usage of the RCoA does not have the cost of Mobile IPv6 (i.e.,
no bindings or home address options are sent over the Internet), but
still provides local mobility management to the mobile nodes with
near-optimal routing. Although such use of RCoA does not provide
global mobility (i.e., communication is broken when a mobile node
changes its RCoA), it would be useful for several applications (e.g.,
web browsing). The validity of the RCoA as a source address used by
applications will depend on the size of a MAP domain and the speed of
the mobile node. Furthermore, because the support for BU processing
in correspondent nodes is not mandated in [RFC3775], this mechanism
can provide a way of obtaining route optimisation without sending BUs
to the correspondent nodes.
Enabling this mechanism can be done by presenting the RCoA as a
temporary home address for the mobile node. This may require an
implementation to augment its source address selection algorithm with
the knowledge of the RCoA in order to use it for the 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 source field of the
packets that it sends. As a result, address-based location tracking
of a mobile node by its corresponding nodes or its home agent is more
difficult because they only know its RCoA and not its LCoA.
Soliman, et al. Expires January 15, 2009 [Page 16]
Internet-Draft HMIPv6 July 2008
7. MAP Discovery
This section describes how a mobile node obtains the MAP address and
subnet prefix, and how ARs in a domain discover MAPs.
This specification requires network administrators to manually
configure the MAP option information in ARs and other Future
mechanisms may be defined to allow MAPs to be discovered dynamically.
7.1. 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. 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).
However, a mobile node MAY 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 no other MAP is
available, the mobile node MUST NOT attempt to use HMIPv6.
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) in order 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 movement detection algorithm.
If the R flag is set, the mobile node MUST place its RCoA in place of
the Home Address in the binding update message. This causes the RCoA
to be bound to the LCoA in the MAP's Binding Cache.
A mobile node MAY choose to register with more than one MAP
simultaneously, or use both the RCoA and its LCoA as care-of
addresses simultaneously with different correspondent nodes.
Soliman, et al. Expires January 15, 2009 [Page 17]
Internet-Draft HMIPv6 July 2008
8. Updating Previous MAPs
When a mobile 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 new CoA. An administrator MAY
restrict the MAP from forwarding packets to LCoAs outside the 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.
Soliman, et al. Expires January 15, 2009 [Page 18]
Internet-Draft HMIPv6 July 2008
9. Note On MAP Selection by the Mobile Node
HMIPv6 provides a flexible mechanism for local mobility management
within a visited network. As explained earlier, a MAP can exist
anywhere in the operator's network (including the AR). Several MAPs
can be located within 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 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 document, the mobile node should be:
o "Eager" to perform new bindings.
o "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 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 will reduce the time it takes for a mobile node to
inform its correspondent nodes and HA about its new care-of address.
9.1. MAP Selection in Distributed MAP Environment
The 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; therefore, it is prohibited by this specification.
Allowing more than one MAP ("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" 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 of each other by the MN (e.g., each MAP is used for
communication to a certain set of CNs).
Soliman, et al. Expires January 15, 2009 [Page 19]
Internet-Draft HMIPv6 July 2008
In terms of the 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 more distant MAP would reduce the
probability of having to change a MAP and informing all correspondent
nodes and the HA.
In a scenario where several MAPs are discovered by the mobile node in
one domain, the mobile node may need 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 are not
available. The following algorithm is simply based on selecting the
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
MAP (i.e., MAP option having largest Dist field)
3. Select first MAP in list
4. If either the preference value or the valid lifetime fields are
set to zero, select the following MAP in the list.
5. Repeat step (4) while new MAP options still exist, until a MAP is
found with a non-zero preference value and a non-zero valid
lifetime.
Implementing the steps above would result in mobile nodes selecting,
by default, the most distant or furthest available MAP. This will
continue until the preference value reduces to zero. Following this,
mobile nodes will start selecting another MAP.
9.2. MAP Selection in a Flat Mobility 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
Soliman, et al. Expires January 15, 2009 [Page 20]
Internet-Draft HMIPv6 July 2008
movement is not frequent.
Soliman, et al. Expires January 15, 2009 [Page 21]
Internet-Draft HMIPv6 July 2008
10. Detection and Recovery from MAP Failures
This specification introduces a MAP that 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 by using more
than one MAP on the same link and by utilising a form of context
transfer protocol between them. However, MAP redundancy is outside
the scope of this document.
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 then start
the MAP discovery process and attempt to register with another MAP.
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
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:
o By manual intervention.
o In a dynamic manner.
One way of performing dynamic detection of MAP failure can be done by
probing the MAP regularly (e.g., every ten seconds). If no response
is received, an AR MAY try to aggressively probe 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. The exact mechanisms for probing MAPs is outside the
scope of this document. The above text simply shows one example of
detecting failures.
This specification does not mandate a particular recovery mechanism.
However, any mechanism between the MAP and an AR SHOULD be secure to
allow for message authentication, integrity protection, and
protection against replay attacks.
Note that the above suggestion for detecting MAP failure may not
detect MAP failures that might take place between probes, i.e. if a
Soliman, et al. Expires January 15, 2009 [Page 22]
Internet-Draft HMIPv6 July 2008
MAP reboots between probes.
Soliman, et al. Expires January 15, 2009 [Page 23]
Internet-Draft HMIPv6 July 2008
11. Tunelling impacts on MTU
This specification requires the mobile node to tunnel outgoing trafic
to the MAP. Similarly, the MAP tunnels inbound packets to the mobile
node. If the mobile node has a home agent elsewhere on the Internet,
this will result in double encapsulations of inbound and outbound
packets. This may have impacts on the mobile node's path MTU.
Hence, mobile nodes MUST consider the encapsulation of traffic
between the node and the MAP when calculating the available MTU for
upper layers.
Soliman, et al. Expires January 15, 2009 [Page 24]
Internet-Draft HMIPv6 July 2008
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
strong; it MUST involve mutual authentication, integrity protection,
and protection against replay attacks. Confidentiality may be needed
for payload traffic and can be achieved using ESP, 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 or impersonating a MAP. Any of these attacks will
undoubtedly cause undesirable impacts to the mobile node's
communication with all correspondent nodes having knowledge of the
mobile node's RCoA.
Three different relationships (related to securing binding updates)
need to be considered:
1. The mobile node - MAP
2. The mobile node - Home Agent
3. The mobile node - correspondent node
12.1. Mobile Node - MAP Security
In order to allow a mobile node to use the MAP's forwarding service,
initial authorisation (specifically for the service, not for the
RCoA) MAY be needed. Authorising a mobile node to use the MAP
service can be done based on the identity of the mobile node
exchanged during the SA negotiation process. The authorisation may
be granted based on the mobile node's identity, or based on the
identity of a Certificate Authority (CA) that the MAP trusts. For
instance, if the mobile node presents a certificate signed by a
trusted entity (e.g., a CA that belongs to the same administrative
domain, or another trusted roaming partner), it would be sufficient
for the MAP to authorise the use of its service. Note that this
level of authorisation is independent of authorising the use of a
particular RCoA. Similarly, the mobile node trusts the MAP if it
presents a certificate signed by the same CA or by another CA that
the mobile node is configured to trust (e.g., a roaming partner). It
is likely that some deployments would be satisfied with the use of
self signed certificates for either the mobile node or the MAP or
both. This guarantees that the mobile node and the MAP are
authenticated for address allocation and future binding updates
without the need for identity authentication. Hence, the use of
trusted third party certificates is not required by this
specification.
Soliman, et al. Expires January 15, 2009 [Page 25]
Internet-Draft HMIPv6 July 2008
It is important to note that in this specification, authentication
and authorisation are effectively the same thing. All the MAP needs
to authorise the mobile node to use resources (RCoA) is to
authenticate the mobile node and verify that it belongs to a trusted
group (based on its certificate).
IKEv2 MUST be supported by the mobile node and the MAP. IKEv2 allows
the use of EAP as a mechanism to bootstrap the security association
between the communicating peers. Hence, EAP can be used with IKEv2
to leverage the AAA infrastructure to bootstrap the SA between the
mobile node and the MAP. Such mechanism is useful in scenarios where
an administrator wishes to avoid the configuration and management of
certificates on mobile nodes. A MAP MAY support the use of EAP over
IKEv2.
If EAP is used with IKEv2, the EAP method runs between the mobile
node and a AAA server. Following a successful authentication, the
resulting keying material can be used to bootstrap IKEv2 between the
MAP and the mobile node. The specification of which EAP methods
should be used, or how keys are transported between the MAP and the
AAA server is outside the scope of this document.
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, an LCoA and registers the binding between these two addresses
with the new MAP. The MAP then verifies whether the RCoA has not
been registered yet and, if so, it creates a binding cache entry with
the RCoA and LCoA. Whenever the mobile node gets a new LCoA, it
needs to send a new BU that specifies the binding between RCoA and
its new LCoA. This 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, because the RCoA is temporary and is not
bound to a particular node, a mobile node does not have to initially
(before the first binding update) prove that it owns its RCoA (unlike
the requirement on home addresses in Mobile IPv6) when it establishes
a Security Association with its MAP. A MAP only needs to ensure that
a BU for a particular RCoA was issued by the same mobile node that
established the Security Association for that RCoA.
The MAP does not need to have prior knowledge of the identity of the
mobile node nor its Home Address. As a result the SA between the
mobile node and the MAP can be established using any key
establishment protocols such as IKEv2. 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 IKEv2 [RFC4306]. The mobile node uses its LCoA as the
Soliman, et al. Expires January 15, 2009 [Page 26]
Internet-Draft HMIPv6 July 2008
source address, but specifies that the RCoA should be used in the SA.
This is achieved by using the RCoA as the identity in the IKE child
SA negotiation. This step is identical to the use of the home
address in IKE child SA when negotiating with the home agent.
The IPsec PAD entries described in [RFC4877] for allocating dynamic
home addresses SHOULD be used by the MAP to allocate the RCoA for
mobile nodes. 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 authentication algorithm MUST be used.
The Security Policy Database (SPD) entries in both the home agent and
the mobile node are identical to those setup for the home agent and
mobile node, respectively, as outlined in [RFC4877]
12.2. Mobile Node - Correspondent Node Security
Mobile IPv6 [RFC3775] defines a return routability procedure that
allows mobile and correspondent nodes to authenticate binding updates
and acknowledgements. This specification does not impact the return
routability test defined in [RFC3775]. 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
[RFC3775]. The source address used in HOTI messages SHOULD be the
mobile node's home address unless the mobile node wishes to use the
RCoA for route optimisation. The packet containing the HOTI message
is encapsulated twice. The inner encapsulating header contains the
RCoA in the source address field and the home agent's address in the
destination address field. The outer encapsulating header contains
the mobile node's LCoA in the source address field and the MAP's
address in the destination field.
12.3. Mobile Node - Home Agent Security
The security relationship between the mobile node and its Home Agent,
as discussed in [RFC3775], is not impacted by this specification.
The relationship between the MAP and the mobile node is not impacted
by the presence of a home agent.
Soliman, et al. Expires January 15, 2009 [Page 27]
Internet-Draft HMIPv6 July 2008
13. IANA Considerations
There are no IANA considerations for this specification. The MAP
option was allocated for RFC 4140 and will continue to be used by
this specification.
Soliman, et al. Expires January 15, 2009 [Page 28]
Internet-Draft HMIPv6 July 2008
14. Acknowledgements
The authors would like to thank Conny Larsson (Ericsson) and Mattias
Pettersson (Ericsson) for their valuable input to this document. 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),
Gregory Daley, Francis Dupont (GET/Enst Bretagne), Gopal Dommety
(Cisco), Eva Gustaffson (Ericsson), Dave Johnson (Rice University),
Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti
Kuparinen (Ericsson) Fergal Ladley, Gabriel Montenegro (Microsoft),
Nick "Sharkey" Moore, Vidya Narayanan (Qualcomm), Erik Nordmark
(Sun), Basavaraj Patil (Nokia), Brett Pentland (NEC), Thomas Schmidt
and Alper Yegin (Samsung) for their comments on the document.
Soliman, et al. Expires January 15, 2009 [Page 29]
Internet-Draft HMIPv6 July 2008
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
15.2. Informative References
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
Soliman, et al. Expires January 15, 2009 [Page 30]
Internet-Draft HMIPv6 July 2008
Appendix A. Appendix A - Fast Mobile IPv6 Handoers 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 [RFC4068] 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 new location
before it moves there.
While the mobile node is connected to its previous Access Router
(PAR) and is about to move to a new Access Router (NAR), the Fast
Handovers in Mobile IPv6 requires in sequence:
1. The mobile node to obtain a new care-of address at the NAR while
connected to the PAR.
2. New CoA to be used at NAR case: the mobile node to send a F-BU
(Fast BU) to its previous anchor point (i.e., PAR) to update its
binding cache with the mobile node's new CoA while still attached
to PAR.
3. The previous anchor point (i.e., PAR) to start forwarding packets
destined for the mobile node to the mobile node's new CoA at NAR
(or old CoA tunnelled to NAR, if new CoA is not applicable).
4. Old CoA to be used at NAR case: the mobile node to send a F-BU
(Fast BU) to its previous anchor point (i.e., PAR), after it has
moved and attached to NAR, in order to update its binding cache
with the mobile node's new CoA.
The mobile node or PAR may initiate the Fast Handover procedure by
using wireless link-layer information or link-layer triggers that
inform that the mobile node will soon be handed off between two
wireless access points respectively attached to PAR and NAR. If the
"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 PAR. Instead, if the "trigger" is received
at 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, et al. Expires January 15, 2009 [Page 31]
Internet-Draft HMIPv6 July 2008
+-----------+ 1a. HI +-----+
| | ----------------| NAR |
| PAR | 1b. HAck | |
+-----------+ --------------- +-----+
^ | ^
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU)
| | RtAdv | 4. Fast BA (F-BACK)
| v v
+------------+
| MN |
+------------+ - - - - - ->
Movement
Figure 4: Figure A.1: FMIPv6 Protocol
The mobile node obtains a new care-of address while connected to PAR
by means of router advertisements containing information from the NAR
(Proxy Router Advertisement, which may be sent due to a Proxy Router
Solicitation). The PAR will validate the mobile node's new CoA by
sending a Handover Initiate (HI) message to the NAR. The new CoA
sent in the HI message is formed by appending the mobile node's
current interface identifier to the NAR's prefix. Based on the
response generated in the Handover Acknowledge (HAck) message, the
PAR will either generate a tunnel to the mobile node's new CoA (if
the address was valid) or generate a tunnel to the 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. Therefore, the 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 [RFC4068], 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. Therefore, such an
aggregation router is also an ideal position for the MAP
functionality. These are two ways of integrating the HMIPv6 and ast
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" the ARs. In this case,
[RFC4068] specifies forwarding of packets between PAR and NAR. This
could be inefficient in terms of delay and bandwidth efficiency
because packets will traverse the MAP-PAR link twice and packets will
arrive out of order at the mobile node. Using the MAP in the
Soliman, et al. Expires January 15, 2009 [Page 32]
Internet-Draft HMIPv6 July 2008
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 PAR.
+---------+
| MAP |
+-------------->| |
| +---------+
| | ^
| 1a. HI | |
| | |
| | | 1b. HAck
| v |
+---------+ | +---------+
| | | | NAR |
| PAR | | | |
+---------+ | +---------+
^ | |
|(2a. RtSolPr)
| | 2b | 3. Fast BU (F-BU) from mobile node to
| | Pr | MAP
| | RtAdv | 4. Fast BA (F-BACK) from MAP to
| | | mobile node
| v v
+------------+
| MN | Movement
+------------+ - - - - - ->
Figure 5: Figure A.2: FMIPv6 using HMIPv6
In Figure A.2, the HI/HAck messages now occur between the MAP and NAR
in order 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 PAR to the
MAP.
As in the previous Fast Handover procedure, in the network-determined
case the layer-2 "triggers" at the PAR will cause the 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 at PAR
in the network-determined case could be used to independently
initiate Context Transfer (e.g., QoS) between PAR and NAR. In the
mobile-determined case, the trigger at PAR could be replaced by the
reception of a Proxy Router Solicitation or F-BU. Context Transfer
Soliman, et al. Expires January 15, 2009 [Page 33]
Internet-Draft HMIPv6 July 2008
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
redirected to the mobile 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 new location,
which has an impact on how smooth the handoff will be. The same
issues arise in [RFC4068] with respect to when to start forwarding
between PAR and 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 PAR and attaches to NAR. Such packet loss is likely to
occur if the MAP updates its binding cache upon receiving the
anticipated F-BU, because it is not known exactly when the mobile
node will perform or complete the layer-2 handover to 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 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 provide a solution to these
issues. A new Simultaneous Bindings Flag is added to the Fast
Binding Update (F-BU) message and a new Simultaneous Bindings
suboption is defined for the 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 PAR and
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, et al. Expires January 15, 2009 [Page 34]
Internet-Draft HMIPv6 July 2008
Appendix B. Appendix B - Changes from RFC 4140
o Dynamic MAP Discovery was removed.
o Updated the security section to use IKEv2 instead of IKEv1
o The document clarified that HMIPv6 can be used without the need
for a home agent
o Several editorials throughout the document
RFC 4140 was implemented and interop tested by at least two different
organisations. A test suite including test cases for RFC 4140 was
also developed by Ericsson and run against both implementations. No
major issues were found. The scalability of Dynamic MAP discovery
defined in RFC 4140 was seen as inappripriate for large scale
deployments and prone to loops. It was removed from this
specification.
At this time there is no publicly known deployment of this
specification.
Soliman, et al. Expires January 15, 2009 [Page 35]
Internet-Draft HMIPv6 July 2008
Authors' Addresses
Hesham Soliman
Elevate Technologies
Email: hesham@elevatemobile.com
Claude Castelluccia
INRIA
Phone: +33 4 76 61 52 15
Email: claude.castelluccia@inria.fr
Karim ElMalki
Athonet
Email: karim@elmalki.homeip.net
Ludovic Bellier
INRIA
Email: ludovic.bellier@inria.fr
Soliman, et al. Expires January 15, 2009 [Page 36]
Internet-Draft HMIPv6 July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Soliman, et al. Expires January 15, 2009 [Page 37]
