draft-ietf-mipshop-hmipv6-04.txt   rfc4140.txt 
Network Working Group Hesham Soliman, Flarion Network Working Group H. Soliman
INTERNET-DRAFT Claude Catelluccia, INRIA Request for Comments: 4140 Flarion
Expires: June 2005 Karim El Malki, Ericsson Category: Experimental C. Castelluccia
Ludovic Bellier, INRIA INRIA
December, 2004 K. El Malki
Ericsson
Hierarchical Mobile IPv6 mobility management (HMIPv6) L. Bellier
<draft-ietf-mipshop-hmipv6-04.txt> INRIA
August 2005
Status of this memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, we accept the provisions of
Section 4 of RFC 3667 (BCP 78).
Internet-Drafts are working documents of the Internet Engineering Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
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 Status of This Memo
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 This memo defines an Experimental Protocol for the Internet
http://www.ietf.org/ietf/lid-abstracts.txt community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
This document is a submission of the IETF MIPSHOP WG. Comments should Copyright (C) The Internet Society (2005).
be directed to the MIPSHOP WG mailing list, mipshop@ietf.org.
Abstract Abstract
This document introduces extensions to Mobile IPv6 and IPv6 Neighbour This document introduces extensions to Mobile IPv6 and IPv6 Neighbour
Discovery to allow for local mobility handling. Hierarchical mobility Discovery to allow for local mobility handling. Hierarchical
management for Mobile IPv6 is designed to reduce the amount of mobility management for Mobile IPv6 is designed to reduce the amount
signalling between the Mobile Node, its Correspondent Nodes and its of signalling between the Mobile Node, its Correspondent Nodes, and
Home Agent. The Mobility Anchor Point described in this document can its Home Agent. The Mobility Anchor Point (MAP) described in this
also be used to improve the performance of Mobile IPv6 in terms of document can also be used to improve the performance of Mobile IPv6
handover speed. in terms of handover speed.
Table of Contents Table of Contents
1. Introduction.....................................................3 1. Introduction ....................................................3
2. Terminology......................................................4 2. Terminology .....................................................4
3. Overview of HMIPv6...............................................4 3. Overview of HMIPv6 ..............................................5
3.1. HMIPv6 Operation............................................5 3.1. HMIPv6 Operation ...........................................6
4. Mobile IPv6 extensions...........................................7 4. Mobile IPv6 Extensions ..........................................8
4.1. Local Binding Update........................................7 4.1. Local Binding Update .......................................8
5. Neighbour Discovery extension - The MAP option message format....8 5. Neighbour Discovery Extension: The MAP Option Message Format ....9
6. Protocol operation...............................................9 6. Protocol Operation .............................................10
6.1. Mobile node Operation.......................................9 6.1. Mobile Node Operation .....................................10
6.1.1. Sending packets to correspondent nodes................11 6.1.1. Sending Packets to Correspondent Nodes .............12
6.2. MAP Operations.............................................11 6.2. MAP Operations ............................................12
6.3. Home Agent Operations......................................12 6.3. Home Agent Operations .....................................13
6.4. Correspondent node Operations..............................12 6.4. Correspondent Node Operations .............................13
6.5. Local Mobility Management optimisation within a MAP domain.12 6.5. Local Mobility Management Optimisation within a
6.6. Location Privacy...........................................13 MAP Domain ................................................13
7. MAP discovery...................................................13 6.6. Location Privacy ..........................................14
7.1. Dynamic MAP Discovery......................................13 7. MAP Discovery ..................................................14
7.1.1. Router Operation for Dynamic MAP Discovery............14 7.1. Dynamic MAP Discovery .....................................14
7.1.2. MAP Operation for Dynamic MAP Discovery...............14 7.1.1. Router Operation for Dynamic MAP Discovery .........15
7.2. Mobile node Operation......................................15 7.1.2. MAP Operation for Dynamic MAP Discovery ............15
8. Updating previous MAPs..........................................15 7.2. Mobile Node Operation .....................................16
9. Notes on MAP selection by the mobile node.......................16 8. Updating Previous MAPs .........................................16
9.1. MAP selection in a distributed-MAP environment.............16 9. Notes on MAP Selection by the Mobile Node ......................17
9.2. MAP selection in a flat mobility management architecture...17 9.1. MAP Selection in a Distributed-MAP Environment ............17
10. Detection and recovery from MAP failures.......................18 9.2. MAP Selection in a Flat Mobility Management Architecture ..19
11. IANA Considerations............................................18 10. Detection and Recovery from MAP Failures ......................19
12. Security considerations........................................19 11. IANA Considerations ...........................................20
12.1. Mobile node-MAP security..................................19 12. Security Considerations .......................................20
12.2. Mobile node-correspondent node security...................20 12.1. Mobile Node-MAP Security ................................20
12.3. Mobile node-Home Agent security...........................21 12.2. Mobile Node-Correspondent Node Security .................22
13. Acknowledgments................................................21 12.3. Mobile Node-Home Agent Security .........................22
14. Authors' Addresses.............................................21 13. Acknowledgments ...............................................22
15. References.....................................................22 14. References ....................................................23
15.1. Normative references......................................22 14.1. Normative References ....................................23
15.2. Informative References....................................23 14.2. Informative References ..................................23
Appendix A - Fast Mobile IPv6 Handovers and HMIPv6.................24 Appendix A: Fast Mobile IPv6 Handovers and HMIPv6 .................24
1. Introduction 1. Introduction
This memo introduces the concept of a Hierarchical Mobile IPv6 This memo introduces the concept of a Hierarchical Mobile IPv6
network, utilising a new node called the Mobility Anchor Point (MAP). network, utilising a new node called the Mobility Anchor Point (MAP).
Mobile IPv6 [1] allows nodes to move within the Internet topology Mobile IPv6 [1] allows nodes to move within the Internet topology
while maintaining reachability and on-going connections between while maintaining reachability and on-going connections between
mobile and correspondent nodes. To do this a mobile node sends mobile and correspondent nodes. To do this a mobile node sends
Binding Updates (BUs) to its Home Agent (HA) and all Correspondent Binding Updates (BUs) to its Home Agent (HA) and all Correspondent
Nodes (CNs) it communicates with, every time it moves. Authenticating Nodes (CNs) it communicates with, every time it moves.
binding updates requires approximately 1.5 round trip times between Authenticating binding updates requires approximately 1.5 round-trip
the mobile node and each correspondent node (for the entire return times between the mobile node and each correspondent node (for the
routability procedure in a best case scenario, i.e. no packet entire return routability procedure in a best case scenario, i.e., no
losses). In addition, one round trip time is needed to update the packet loss). In addition, one round-trip time is needed to update
Home Agent, this can be done simultaneously while updating the Home Agent; this can be done simultaneously while updating
correspondent nodes. The re-use of the home cookie (i.e. eliminating correspondent nodes. The re-use of the home cookie (i.e.,
HOTI/HOT) will not reduce the number of round trip times needed to eliminating HOTI/HOT) will not reduce the number of round trip times
update correspondent nodes. These round trip delays will disrupt needed to update correspondent nodes. These round trip delays will
active connections every time a handoff to a new AR is performed. disrupt active connections every time a handoff to a new AR is
Eliminating this additional delay element from the time-critical performed. Eliminating this additional delay element from the time-
handover period will significantly improve the performance of Mobile critical handover period will significantly improve the performance
IPv6. Moreover, in the case of wireless links, such solution reduces of Mobile IPv6. Moreover, in the case of wireless links, such a
the number of messages sent over the air interface to all solution reduces the number of messages sent over the air interface
correspondent nodes and the Home Agent. A local anchor point will to all correspondent nodes and the Home Agent. A local anchor point
also allow Mobile IPv6 to benefit from reduced mobility signalling will also allow Mobile IPv6 to benefit from reduced mobility
with external networks. signalling with external networks.
For these reasons a new Mobile IPv6 node, called the Mobility Anchor 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 Point, is used and can be located at any level in a hierarchical
network of routers, including the Access Router (AR). Unlike Foreign network of routers, including the Access Router (AR). Unlike Foreign
Agents in IPv4, a MAP is not required on each subnet. The MAP will 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. limit the amount of Mobile IPv6 signalling outside the local domain.
The introduction of the MAP provides a solution to the issues The introduction of the MAP provides a solution to the issues
outlined earlier in the following way: outlined earlier in the following way:
- The mobile node sends Binding Updates to the local MAP rather than - The mobile node sends Binding Updates to the local MAP rather than
the HA (that is typically further away) and CNs the HA (which is typically further away) and CNs
- Only one Binding Update message needs to be transmitted by the MN - 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 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 location. This is independent of the number of CNs that the MN is
communicating with. communicating with.
A MAP is essentially a local Home Agent. The aim of introducing the A MAP is essentially a local Home Agent. The aim of introducing the
hierarchical mobility management model in Mobile IPv6 is to enhance hierarchical mobility management model in Mobile IPv6 is to enhance
the performance of Mobile IPv6 while minimising the impact on Mobile the performance of Mobile IPv6 while minimising the impact on Mobile
IPv6 or other IPv6 protocols. It also supports Fast Mobile IPv6 IPv6 or other IPv6 protocols. It also supports Fast Mobile IPv6
Handovers to help Mobile Nodes in achieving seamless mobility (see Handovers to help Mobile Nodes achieve seamless mobility (see
Appendix A). Furthermore, HMIPv6 allows mobile nodes to hide their Appendix A). Furthermore, HMIPv6 allows mobile nodes to hide their
location from correspondent nodes and Home Agents while using Mobile location from correspondent nodes and Home Agents while using Mobile
IPv6 route optimisation. IPv6 route optimisation.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [10]. document are to be interpreted as described in RFC 2119 [3].
In addition, new terms are defined below: In addition, new terms are defined below:
Access Router (AR) The Mobile Node's default router. The AR Access Router (AR) The AR is the Mobile Node's default router.
aggregates the outbound traffic of mobile The AR aggregates the outbound traffic of
nodes. mobile nodes.
Mobility Anchor Point A Mobility Anchor Point is a router located Mobility Anchor Point A Mobility Anchor Point is a router located
(MAP) in a network visited by the mobile node. (MAP) in a network visited by the mobile node. The
The MAP is used by the MN as a local HA. MAP is used by the MN as a local HA. One or
One or more MAPs can exist within a visited more MAPs can exist within a visited network.
network.
Regional Care-of An RCoA is an address obtained by the Regional Care-of An RCoA is an address obtained by the
Address (RCoA) mobile node from the visited network. An Address (RCoA) mobile node from the visited network. An RCoA
RCoA is an address on the MAP's subnet. It is an address on the MAP's subnet. It is
is auto-configured by the mobile node when auto-configured by the mobile node when
receiving the MAP option. receiving the MAP option.
HMIPv6-aware An HMIPv6-aware mobile node is a mobile HMIPv6-aware An HMIPv6-aware mobile node is a mobile
Mobile Node node that can receive and process the MAP Mobile Node node that can receive and process the MAP
option received from its default router. option received from its default router. An
An HMIPv6-aware Mobile Node must also be HMIPv6-aware Mobile Node must also be able to
able to send local binding updates send local binding updates (Binding Update
(Binding Update with the M flag set). with the M flag set).
On-link CoA (LCoA) The LCoA is the on-link CoA configured on On-link Care-of The LCoA is the on-link CoA configured on
a mobile node's interface based on the Address (LCoA) a mobile node's interface based on the prefix
prefix advertised by its default router. advertised by its default router. In [1],
In [1] this is simply referred to as the this is simply referred to as the Care-of-
Care-of-address. However, in this memo LCoA address. However, in this memo LCoA is used
is used to distinguish it from the RCoA. to distinguish it from the RCoA.
Local Binding Update The MN sends a Local Binding Update to the Local Binding Update The MN sends a Local Binding Update to the MAP
MAP in order to establish a binding in order to establish a binding between the
between the RCoA and LCoA. RCoA and LCoA.
3. Overview of HMIPv6 3. Overview of HMIPv6
This Hierarchical Mobile IPv6 scheme introduces a new function, the This Hierarchical Mobile IPv6 scheme introduces a new function, the
MAP, and minor extensions to the mobile node operation. The MAP, and minor extensions to the mobile node operation. The
correspondent node and Home Agent operation will not be affected. correspondent node and Home Agent operation will not be affected.
Just like Mobile IPv6, this solution is independent of the underlying Just like Mobile IPv6, this solution is independent of the underlying
access technology, allowing mobility within or between different access technology, allowing mobility within or between different
types of access networks. types of access networks.
skipping to change at page 5, line 20 skipping to change at page 5, line 26
Advertisements containing information on one or more local MAPs. The Advertisements containing information on one or more local MAPs. The
MN can bind its current location (on-link CoA) with an address on 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 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 packets on behalf of the mobile node it is serving and will
encapsulate and forward them directly to the mobile node's current encapsulate and forward them directly to the mobile node's current
address. If the mobile node changes its current address within a address. If the mobile node changes its current address within a
local MAP domain (LCoA), it only needs to register the new address local MAP domain (LCoA), it only needs to register the new address
with the MAP. Hence, only the Regional CoA (RCoA) needs to be with the MAP. Hence, only the Regional CoA (RCoA) needs to be
registered with correspondent nodes and the HA. The RCoA does not 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 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 definition). This makes the mobile node's mobility transparent to
correspondent nodes it is communicating with. the correspondent nodes it is communicating with.
A MAP domain's boundaries are defined by the Access Routers (ARs) A MAP domain's boundaries are defined by the Access Routers (ARs)
advertising the MAP information to the attached Mobile Nodes. advertising the MAP information to the attached Mobile Nodes. The
The detailed extensions to Mobile IPv6 and operations of the detailed extensions to Mobile IPv6 and operations of the different
different nodes will be explained later in this document. nodes will be explained later in this document.
It should be noted that the HMIPv6 concept is simply an extension to It should be noted that the HMIPv6 concept is simply an extension to
the Mobile IPv6 protocol. An HMIPv6-aware mobile node with an the Mobile IPv6 protocol. An HMIPv6-aware mobile node with an
implementation of Mobile IPv6 SHOULD choose to use the MAP when implementation of Mobile IPv6 SHOULD choose to use the MAP when
discovering such capability in a visited network. However, in some discovering such capability in a visited network. However, in some
cases the mobile node may prefer to simply use the standard Mobile cases the mobile node may prefer to simply use the standard Mobile
IPv6 implementation. For instance, the mobile node may be located in IPv6 implementation. For instance, the mobile node may be located in
a visited network within its home site. In this case, the HA is 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. 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 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 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. of the MN (e.g., same site) is outside the scope of this document.
3.1. HMIPv6 Operation 3.1. HMIPv6 Operation
The network architecture shown in Figure 1 illustrates an example of The network architecture shown in Figure 1 illustrates an example of
the use of the MAP in a visited network. the use of the MAP in a visited network.
In Figure 1, the MAP can help in providing seamless mobility for the 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 mobile node as it moves from Access Router 1 (AR1) to Access Router 2
(AR2), while communicating with the correspondent node. A multi-level (AR2), while communicating with the correspondent node. A multi-
hierarchy is not required for a higher handover performance. Hence, level hierarchy is not required for a higher handover performance.
it is sufficient to locate one or more MAPs (possibly covering the Hence, it is sufficient to locate one or more MAPs (possibly covering
same domain) at any position in the operator's network. the same domain) at any position in the operator's network.
+-------+ +-------+
| HA | | HA |
+-------+ +----+ +-------+ +----+
| | CN | | | CN |
| +----+ | +----+
| | | |
+-------+-----+ +-------+-----+
| |
|RCoA |RCoA
skipping to change at page 6, line 38 skipping to change at page 6, line 50
+----+ ------------> +----+ ------------>
Movement Movement
Figure 1: Hierarchical Mobile IPv6 domain Figure 1: Hierarchical Mobile IPv6 domain
Upon arrival in a visited network, the mobile node will discover the Upon arrival in a visited network, the mobile node will discover the
global address of the MAP. This address is stored in the Access global address of the MAP. This address is stored in the Access
Routers and communicated to the mobile node via Router Advertisements Routers and communicated to the mobile node via Router Advertisements
(RAs). A new option for RAs is defined later in this specification. (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 This is needed to inform mobile nodes about the presence of the MAP
(MAP discovery). The discovery phase will also inform the mobile node (MAP discovery). The discovery phase will also inform the mobile
of the distance of the MAP from the mobile node. For example, the MAP node of the distance of the MAP from the mobile node. For example,
function could be implemented as shown in Figure 1 and at the same the MAP function could be implemented as shown in Figure 1, and, at
time also in AR1 and AR2. In this case the mobile node can choose the the same time, also be implemented in AR1 and AR2. In this case the
first hop MAP or one further up in the hierarchy of routers. The mobile node can choose the first hop MAP or one further up in the
details on how to choose a MAP are provided in section 10. 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 The process of MAP discovery continues as the mobile node moves from
one subnet to the next. Every time the mobile node detects movement, 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 it will also detect whether it is still in the same MAP domain. The
router advertisement used to detect movement will also inform the router advertisement used to detect movement will also inform the
mobile node, through the MAP option, whether it is still in the same 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 MAP domain. As the mobile node roams within a MAP domain, it will
continue to receive the same MAP option included in router continue to receive the same MAP option included in router
advertisements from its AR. If a change in the advertised MAP's advertisements from its AR. If a change in the advertised MAP's
address is received, the mobile node MUST act on the change by address is received, the mobile node MUST act on the change by
sending Binding Updates to its HA and correspondent nodes. sending Binding Updates to its HA and correspondent nodes.
If the mobile node is not HMIPv6-aware then no MAP Discovery will be 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] performed, resulting in the mobile node using the Mobile IPv6 [1]
protocol for its mobility management. On the other hand, if the protocol for its mobility management. On the other hand, if the
mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6 mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6
implementation. If so, the mobile node will first need to register 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 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 address (LCoA). The Home address used in the BU is the RCoA. The
MUST store this information in its Binding Cache to be able to MAP MUST store this information in its Binding Cache to be able to
forward packets to their final destination when received from the forward packets to their final destination when received from the
different correspondent nodes or HAs. different correspondent nodes or HAs.
The mobile node will always need to know the original sender of any The mobile node will always need to know the original sender of any
received packets to determine if route optimisation is required. This received packets to determine if route optimisation is required.
information will be available to the mobile node since the MAP does This information will be available to the mobile node because the MAP
not modify the contents of the original packet. Normal processing of does not modify the contents of the original packet. Normal
the received packets (as described in [1]) will give the mobile node processing of the received packets (as described in [1]) will give
the necessary information. the mobile node the necessary information.
To use the network bandwidth in a more efficient manner, a mobile To use the network bandwidth in a more efficient manner, a mobile
node may decide to register with more than one MAP simultaneously and node may decide to register with more than one MAP simultaneously and
use each MAP address for a specific group of correspondent nodes. For to use each MAP address for a specific group of correspondent nodes.
example, in Fig 1, if the correspondent node happens to exist on the For example, in Fig 1, if the correspondent node happens to exist on
same link as the mobile node, it would be more efficient to use the the same link as the mobile node, it would be more efficient to use
first hop MAP (in this case assume it is AR1) for communication the first hop MAP (in this case assume it is AR1) for communication
between them. This will avoid sending all packets via the "highest" between them. This will avoid sending all packets via the "highest"
MAP in the hierarchy and hence result in a more efficient usage of 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 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 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 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 binding update sent to another MAP. The LCoA included in the binding
update MUST be the mobile node's address derived from the prefix update MUST be the mobile node's address derived from the prefix
advertised on its link. advertised on its link.
If a router advertisement is used for MAP discovery, as described in If a router advertisement is used for MAP discovery, as described in
this document, all ARs belonging to the MAP domain MUST advertise the this document, all ARs belonging to the MAP domain MUST advertise the
MAP's IP address. The same concept (of advertising the MAP's presence MAP's IP address. The same concept (advertising the MAP's presence
within its domain) should be used if other methods of MAP discovery within its domain) should be used if other methods of MAP discovery
are introduced in future. are introduced in future.
4. Mobile IPv6 extensions 4. Mobile IPv6 Extensions
This section outlines the extensions proposed to the binding update This section outlines the extensions proposed to the binding update
specified in [1]. specified in [1].
4.1. Local Binding Update 4.1. Local Binding Update
A new flag is added; the M flag that indicates MAP registration. When A new flag is added: the M flag, which indicates MAP registration.
a mobile node registers with the MAP, the M and A flags MUST be set When a mobile node registers with the MAP, the M and A flags MUST be
to distinguish this registration from a BU being sent to the HA or a set to distinguish this registration from a BU being sent to the HA
correspondent node. or a correspondent node.
0 1 2 3 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 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 # | | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M| Reserved | Lifetime | |A|H|L|K|M| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. .
. Mobility Options .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description of extensions to the binding update: Description of extensions to the binding update:
M If set to 1 it indicates a MAP registration. M If set to 1 it indicates a MAP registration.
It should be noted that this is an extension to the Binding update It should be noted that this is an extension to the Binding update
specified in [1]. specified in [1].
5. Neighbour Discovery extension - The MAP option message format 5. Neighbour Discovery Extension: The MAP Option Message Format
0 1 2 3 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 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 | | Type | Length | Dist | Pref |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime | | Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Global IP Address for MAP + + Global IP Address for MAP +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type IPv6 Neighbor Discovery option. TBA. Type IPv6 Neighbor Discovery option. 23.
Length 8-bit unsigned integer. The length of the Length 8-bit unsigned integer. The length of the option
option and MUST be set to 3. and MUST be set to 3.
Dist A 4 bit unsigned integer identifying the Dist A 4-bit unsigned integer identifying the Distance
Distance Between MAP and the receiver of the Between MAP and the receiver of the advertisement.
advertisement. Its default value SHOULD be set Its default value SHOULD be set to 1 if Dynamic
to 1 if Dynamic MAP discovery is used. The MAP discovery is used. The Distance MUST be set
Distance MUST be set to 1 if the MAP is on the to 1 if the MAP is on the same link as the mobile
same link as the mobile node. This field need node. This field need not be interpreted as the
not be interpreted as the number of hops number of hops between MAP and the mobile node.
between MAP and the mobile node. The only The only requirement is that the meaning of the
requirement is that the meaning of the Distance field is consistently interpreted within
Distance field is consistently interpreted one Domain. A Distance value of Zero MUST NOT be
within one Domain. A Distance value of Zero used.
MUST NOT be used.
Pref The preference of a MAP. A 4 bit unsigned Pref The preference of a MAP. A 4-bit unsigned
integer. A decimal value of 15 indicates the integer. A decimal value of 15 indicates the
highest availability. highest availability.
R When set to 1 it indicates that the mobile R When set to 1, it indicates that the mobile node
node MUST form an RCoA based on the prefix in MUST form an RCoA based on the prefix in the MAP
the MAP option. option.
Valid Lifetime The minimum value (in seconds) of both the Valid Lifetime The minimum value (in seconds) of both the
preferred and valid lifetimes of the prefix preferred and valid lifetimes of the prefix
assigned to the MAP's subnet. This value assigned to the MAP's subnet. This value
indicates the validity of the MAP's address indicates the validity of the MAP's address and
and consequently the time for which the RCoA consequently the time for which the RCoA is valid.
is valid.
Global Address One of the MAP's global addresses. Global Address One of the MAP's global addresses. The 64-bit
The 64-bit prefix extracted from this address prefix extracted from this address MUST be
MUST be configured in the MAP to be used for configured in the MAP to be used for RCoA
RCoA construction by the mobile node. construction by the mobile node.
Although not explicitly included in the MAP option, the prefix length 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 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 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 identifier to the prefix. Thus, it necessitates a static prefix
length for the MAP's subnet. length for the MAP's subnet.
6. Protocol operation 6. Protocol Operation
This section describes the HMIPv6 protocol. In HMIPv6, the mobile 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 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 (LCoA). This RCoA is formed in a stateless manner by combining the
mobile node's interface identifier and the subnet prefix received in mobile node's interface identifier and the subnet prefix received in
the MAP option. the MAP option.
As illustrated in this section, this protocol requires updating the As illustrated in this section, this protocol requires updating the
mobile nodes' implementation only. The HA and correspondent node are mobile nodes' implementation only. The HA and correspondent node are
unchanged. The MAP performs the function of a "local" HA that binds unchanged. The MAP performs the function of a "local" HA that binds
the mobile node's RCoA to an LCoA. the mobile node's RCoA to an LCoA.
6.1. Mobile node Operation 6.1. Mobile Node Operation
When a mobile node moves into a new MAP domain (i.e. its MAP
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 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. 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 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 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 flags set. The local BU is a BU defined in [1] and includes the
mobile node's RCoA in the Home Address Option. No alternate-CoA 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 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 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 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 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 node's RCoA on its link and return a Binding Acknowledgement to the
MN. This acknowledgement identifies the binding as successful or MN. This acknowledgement identifies the binding as successful or
contains the appropriate fault code. No new error codes need to be contains the appropriate fault code. No new error codes need to be
supported by the mobile node for this operation. The mobile node MUST supported by the mobile node for this operation. The mobile node
silently ignore binding acknowledgements that do not contain a MUST silently ignore binding acknowledgements that do not contain a
routing header type 2, which includes the mobile node's RCoA. routing header type 2, which includes the mobile node's RCoA.
Following a successful registration with the MAP, a bi-directional Following a successful registration with the MAP, a bi-directional
tunnel between the mobile node and the MAP is established. All tunnel between the mobile node and the MAP is established. All
packets sent by the mobile node are tunnelled to the MAP. The outer 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 header contains the mobile node's LCoA in the source address field
and the MAP's address in the destination address field. The inner and the MAP's address in the destination address field. The inner
header contains the mobile node's RCoA in the source address field header contains the mobile node's RCoA in the source address field
and the peer's address in the destination address field. Similarly, and the peer's address in the destination address field. Similarly,
all packets addressed to the mobile node's RCoA are intercepted by all packets addressed to the mobile node's RCoA are intercepted by
the MAP and tunnelled to the mobile node's LCoA. the MAP and tunnelled to the mobile node's LCoA.
This specification allows a mobile node to use more than one RCoA if 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 it received more than one MAP option. In this case, the mobile node
MUST perform the binding update procedure for each RCoA. In addition, MUST perform the binding update procedure for each RCoA. In
the mobile node MUST NOT use one RCoA (e.g. RCoA1) derived from a addition, the mobile node MUST NOT use one RCoA (e.g., RCoA1) derived
MAP's prefix (e.g. MAP1) as a care-of address in its binding update from a MAP's prefix (e.g., MAP1) as a care-of address in its binding
to another MAP (e.g. MAP2). This would force packets to be update to another MAP (e.g., MAP2). This would force packets to be
encapsulated several times (twice in this example) on their path to encapsulated several times (twice in this example) on their path to
the mobile node. This form of multi-level hierarchy will reduce the the mobile node. This form of multi-level hierarchy will reduce the
protocol's efficiency and performance. protocol's efficiency and performance.
After registering with the MAP, the mobile node MUST register its new 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, 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 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 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 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 similar BU (i.e., that specifies the binding between the Home Address
and the RCoA) to its current correspondent nodes. and the RCoA) to its current correspondent nodes.
The mobile node SHOULD wait for the binding acknowledgement from the The mobile node SHOULD wait for the binding acknowledgement from the
MAP before registering with its HA. It should be noted that when MAP before registering with its HA. It should be noted that when
binding the RCoA with the HA and correspondent nodes, the binding binding the RCoA with the HA and correspondent nodes, the binding
lifetime MUST NOT be larger than the mobile node's binding lifetime lifetime MUST NOT be larger than the mobile node's binding lifetime
with the MAP, which is received in the Binding Acknowledgement. with the MAP, which is received in the Binding Acknowledgement.
In order to speed up the handover between MAPs and reduce packet 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 loss, a mobile node SHOULD send a local BU to its previous MAP,
specifying its new LCoA. Packets in transit that reach the previous specifying its new LCoA. Packets in transit that reach the previous
MAP are then forwarded to the new LCoA. MAP are then forwarded to the new LCoA.
The MAP will receive packets addressed to the mobile node's RCoA The MAP will receive packets addressed to the mobile node's RCoA
(from the HA or correspondent nodes). Packets will be tunnelled from (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 MAP to the mobile node's LCoA. The mobile node will de-capsulate
the packets and process them in the normal manner. the packets and process them in the normal manner.
When the mobile node moves within the same MAP domain, it should only 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 register its new LCoA with its MAP. In this case, the RCoA remains
unchanged. unchanged.
Note that a mobile node may send a BU containing its LCoA (instead of 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 its RCoA) to correspondent nodes, which are connected to its same
link. Packets will then be routed directly without going through the link. Packets will then be routed directly without going through the
MAP. MAP.
6.1.1. Sending packets to correspondent nodes 6.1.1. Sending Packets to Correspondent Nodes
The mobile node can communicate with a correspondent node through the The mobile node can communicate with a correspondent node through the
HA, or in a route-optimised manner, as described in [1]. When HA, or in a route-optimised manner, as described in [1]. When
communicating through the HA, the message formats in [1] can be communicating through the HA, the message formats in [1] can be re-
re-used. used.
If the mobile node communicates directly with the correspondent node If the mobile node communicates directly with the correspondent node
(i.e. the CN has a binding cache entry for the mobile node), the (i.e., the CN has a binding cache entry for the mobile node), the
mobile node MUST use the same care-of address used to create a mobile node MUST use the same care-of address used to create a
binding cache entry in the correspondent node (RCoA) as a source binding cache entry in the correspondent node (RCoA) as a source
address. According to [1], the mobile node MUST also include a Home address. According to [1], the mobile node MUST also include a Home
Address option in outgoing packets. The Home address option MUST Address option in outgoing packets. The Home address option MUST
contain the mobile node's home address. contain the mobile node's home address.
6.2. MAP Operations 6.2. MAP Operations
The MAP acts like a HA; it intercepts all packets addressed to The MAP acts like a HA; it intercepts all packets addressed to
registered mobile nodes and tunnels them to the corresponding LCoA, registered mobile nodes and tunnels them to the corresponding LCoA,
which is stored in its binding cache. which is stored in its binding cache.
A MAP has no knowledge of the mobile node's Home address. The mobile 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 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 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 an RCoA (contained in the BU as a Home address). If successful, the
MAP MUST return a binding acknowledgement to the mobile node MAP MUST return a binding acknowledgement to the mobile node,
indicating a successful registration. This is identical to the HA indicating a successful registration. This is identical to the HA
operation in [1]. No new error codes are introduced for HMIPv6. The operation in [1]. No new error codes are introduced for HMIPv6. The
binding acknowledgement MUST include a routing header type 2 that binding acknowledgement MUST include a routing header type 2 that
contains the mobile node's RCoA. contains the mobile node's RCoA.
The MAP MUST be able to accept packets tunnelled from the mobile 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 node, with the mobile node being the tunnel entry point and the MAP
being the tunnel exit point. being the tunnel exit point.
The MAP acts as a HA for the RCoA. Packets addressed to the RCOA are The MAP acts as a HA for the RCoA. Packets addressed to the RCOA are
intercepted by the MAP, using proxy Neighbour Advertisement, intercepted by the MAP, using proxy Neighbour Advertisement, and then
encapsulated and routed to the mobile node's LCoA. This operation is encapsulated and routed to the mobile node's LCoA. This operation is
identical to that of the HA described in [1]. identical to that of the HA described in [1].
A MAP MAY be configured with the list of valid on-link prefixes that 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 mobile nodes can use to derive LCoAs. This is useful for network
operators to stop mobile nodes from continuing to use the MAP after operators to stop mobile nodes from continuing to use the MAP after
moving to a different administrative domain. If a mobile node sent a 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 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 on-link prefixes" list, the MAP could reject the binding update using
existing error code 129 (administratively prohibited). existing error code 129 (administratively prohibited).
6.3. Home Agent Operations 6.3. Home Agent Operations
The support of HMIPv6 is completely transparent to the HA's The support of HMIPv6 is completely transparent to the HA's
operation. Packets addressed to a mobile node's Home Address will be operation. Packets addressed to a mobile node's Home Address will be
forwarded by the HA to its RCoA as described in [1]. forwarded by the HA to its RCoA, as described in [1].
6.4. Correspondent node Operations 6.4. Correspondent Node Operations
HMIPv6 is completely transparent to correspondent nodes. HMIPv6 is completely transparent to correspondent nodes.
6.5. Local Mobility Management optimisation within a MAP domain 6.5. Local Mobility Management Optimisation within a MAP Domain
In [1], it is stated that for short-term communication, particularly In [1], it is stated that for short-term communication, particularly
communication that may easily be retried upon failure, the mobile communication that may easily be retried upon failure, the mobile
node MAY choose to directly use one of its care-of addresses as the 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 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 option in the packet. Such use of the CoA will reduce the overhead
sending each packet due to the absence of additional options. In of sending each packet due to the absence of additional options. In
addition, it will provide an optimal route between the mobile node addition, it will provide an optimal route between the mobile node
and correspondent node. and correspondent node.
In HMIPv6, a mobile node can use its RCoA as the source address In HMIPv6, a mobile node can use its RCoA as the source address
without using a Home Address option. In other words, the RCoA can be without using a Home Address option. In other words, the RCoA can be
used as a potential source address for upper layers. Using this used as a potential source address for upper layers. Using this
feature, the mobile node will be seen by the correspondent node as a feature, the mobile node will be seen by the correspondent node as a
fixed node while moving within a MAP domain. fixed node while moving within a MAP domain.
This usage of the RCoA does not have the cost of Mobile IPv6 (i.e. no This usage of the RCoA does not have the cost of Mobile IPv6 (i.e.,
bindings or home address options are sent over the Internet) but no bindings or home address options are sent over the Internet), but
still provides local mobility management to the mobile nodes. still provides local mobility management to the mobile nodes.
Although such use of RCoA does not provide global mobility (i.e. Although such use of RCoA does not provide global mobility (i.e.,
communication is broken when a mobile host moves to a new MAP), it communication is broken when a mobile host moves to a new MAP), it
would be useful for several applications (e.g. web browsing). The would be useful for several applications (e.g., web browsing). The
validity of the RCoA as a source address used by applications will 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. depend on the size of a MAP domain and the speed of the mobile node.
Furthermore, since the support for BU processing in correspondent Furthermore, because the support for BU processing in correspondent
nodes is not mandated in [1], this mechanism can provide a way of nodes is not mandated in [1], this mechanism can provide a way of
obtaining route optimisation without sending BUs to the correspondent obtaining route optimisation without sending BUs to the correspondent
nodes. nodes.
Enabling this mechanism can be done by presenting the RCoA as a Enabling this mechanism can be done by presenting the RCoA as a
temporary home address for the mobile node. This may require an temporary home address for the mobile node. This may require an
implementation to augment its source address selection algorithm with implementation to augment its source address selection algorithm with
the knowledge of the RCoA in order to use it for the appropriate the knowledge of the RCoA in order to use it for the appropriate
applications. applications.
6.6. Location Privacy 6.6. Location Privacy
In HMIPv6, a mobile node hides its LCoA from its corresponding nodes 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 and its home agent by using its RCoA in the source field of the
packets that it sends. As a result, the location tracking of a mobile packets that it sends. As a result, the location tracking of a
node by its corresponding nodes or its home agent is difficult since mobile node by its corresponding nodes or its home agent is difficult
they only know its RCoA and not its LCoA. because they only know its RCoA and not its LCoA.
7. MAP discovery 7. MAP Discovery
This section describes how a mobile node obtains the MAP address and This section describes how a mobile node obtains the MAP address and
subnet prefix and how ARs in a domain discover MAPs. Two different subnet prefix, and how ARs in a domain discover MAPs. Two different
methods for MAP discovery are defined below. methods for MAP discovery are defined below.
Dynamic MAP Discovery is based on propagating the MAP option in Dynamic MAP Discovery is based on propagating the MAP option in
Router Advertisements from the MAP to the mobile node through certain Router Advertisements from the MAP to the mobile node through certain
(configured) router interfaces within the routers in an operator's (configured) router interfaces within the routers in an operator's
network. This requires manual configuration of the MAP and the network. This requires manual configuration of the MAP and also that
routers receiving the MAP option to allow them to propagate the the routers receiving the MAP option allow them to propagate the
option on certain interfaces. To ensure a secure communication option on certain interfaces. To ensure a secure communication
between routers, router advertisements that are sent between routers between routers, router advertisements that are sent between routers
for Dynamic MAP discovery SHOULD be authenticated (e.g. using AH, for Dynamic MAP discovery SHOULD be authenticated (e.g., using AH,
ESP, or SEND). In the case where this authentication is not possible ESP, or SEND). In the case where this authentication is not possible
(e.g. third party routers exist between the MAP and ARs), a network (e.g., third party routers exist between the MAP and ARs), a network
operator may prefer to manually configure all the ARs to send the MAP operator may prefer to manually configure all the ARs to send the MAP
option as described in this document. option, as described in this document.
Manual configuration of the MAP option information in ARs and other Manual configuration of the MAP option information in ARs and other
MAPs in the same domain is the default mechanism. It should also be MAPs in the same domain is the default mechanism. It should also be
possible to configure ARs and MAPs to enable dynamic mechanisms for possible to configure ARs and MAPs to enable dynamic mechanisms for
MAP Discovery. MAP Discovery.
7.1. Dynamic MAP Discovery 7.1. Dynamic MAP Discovery
The process of MAP discovery can be performed in different ways. The process of MAP discovery can be performed in different ways.
Router advertisements are used for Dynamic MAP Discovery by Router advertisements are used for Dynamic MAP Discovery by
skipping to change at page 14, line 13 skipping to change at page 15, line 11
distance vector from the mobile node (which may not imply the real distance vector from the mobile node (which may not imply the real
distance in terms of the number of hops), the preference for this distance in terms of the number of hops), the preference for this
particular MAP, the MAP's global IP address and subnet prefix particular MAP, the MAP's global IP address and subnet prefix
7.1.1. Router Operation for Dynamic MAP Discovery 7.1.1. Router Operation for Dynamic MAP Discovery
The ARs within a MAP domain may be configured dynamically with the The ARs within a MAP domain may be configured dynamically with the
information related to the MAP options. ARs may obtain this information related to the MAP options. ARs may obtain this
information by listening for RAs with MAP options. Each MAP in the information by listening for RAs with MAP options. Each MAP in the
network needs to be configured with a default preference, the right network needs to be configured with a default preference, the right
interfaces to send this option on and the IP address to be sent. The interfaces to send this option on, and the IP address to be sent.
initial value of the "Distance" field MAY be set to a default value The initial value of the "Distance" field MAY be set to a default
of 1 and MUST NOT be set to zero. Routers in the MAP domain should be value of 1 and MUST NOT be set to zero. Routers in the MAP domain
configured to re-send the MAP option on certain interfaces. should be configured to re-send the MAP option on certain interfaces.
Upon reception of a router advertisement with the MAP option, the Upon reception of a router advertisement with the MAP option, the
receiving router MUST copy the option and re-send it after receiving router MUST copy the option and re-send it after
incrementing the Distance field by one. If the receiving router was incrementing the Distance field by one. If the receiving router was
also a MAP, it MUST send its own option together with the received also a MAP, it MUST send its own option, together with the received
option in the same advertisement. If a router receives more than one option, in the same advertisement. If a router receives more than
MAP option for the same MAP (i.e. the same IP address in the MAP one MAP option for the same MAP (i.e., the same IP address in the MAP
option), from two different interfaces, it MUST choose the option option), from two different interfaces, it MUST choose the option
with the smallest distance field. with the smallest distance field.
In this manner, information about one or more MAPs can be dynamically In this manner, information about one or more MAPs can be dynamically
passed to a mobile node. Furthermore, by performing the discovery passed to a mobile node. Furthermore, by performing the discovery
phase in this way, different MAP nodes are able to change their phase in this way, different MAP nodes are able to change their
preferences dynamically based on the local policies, node overload or preferences dynamically based on the local policies, node overload or
other load sharing protocols being used. other load-sharing protocols being used.
7.1.2. MAP Operation for Dynamic MAP Discovery 7.1.2. MAP Operation for Dynamic MAP Discovery
A MAP will be configured to send its option or relay MAP options A MAP will be configured to send its option or relay MAP options
belonging to other MAPs onto certain interfaces. The choice of belonging to other MAPs onto certain interfaces. The choice of
interfaces is done by the network administrator (i.e. manual interfaces is done by the network administrator (i.e., manual
configuration) and depends on the network topology. A default configuration) and depends on the network topology. A default
preference value of 10 may be assigned to each MAP. It should be preference value 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 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 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 value of zero means the MAP SHOULD NOT be chosen by new mobile nodes.
nodes. This value could be reached in cases of node overload or This value could be reached in cases of node overload or partial node
partial node failures. failures.
The MAP option is propagated towards ARs in its domain. Each router The MAP option is propagated towards ARs in its domain. Each router
along the path to an AR will increment the Distance field by one. If along the path to an AR will increment the Distance field by one. If
a router that is also a MAP receives advertisements from other MAPs, 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 it MUST add its own MAP option and propagate both options to the next
router or to the AR (if it has direct connectivity with the AR). router or to the AR (if it has direct connectivity with the AR).
7.2. Mobile node Operation 7.2. Mobile Node Operation
When an HMIPv6-aware mobile node receives a router advertisement, it When an HMIPv6-aware mobile node receives a router advertisement, it
should search for the MAP option. One or more options may be found should search for the MAP option. One or more options may be found
for different MAP IP addresses. for different MAP IP addresses.
A mobile node SHOULD register with the MAP having the highest A mobile node SHOULD register with the MAP having the highest
preference value. A MAP with a preference value of zero SHOULD NOT be preference value. A MAP with a preference value of zero SHOULD NOT
used for new local BUs (i.e. the mobile node can refresh existing 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 bindings but cannot create new ones). However, a mobile node MAY
choose to register with one MAP over another depending on the value choose to register with one MAP over another, depending on the value
received in the Distance field, provided that the preference value is received in the Distance field, provided that the preference value is
above zero. above zero.
A MAP option containing a valid lifetime value of zero means that 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 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 indicates a MAP failure. When this option is received, a mobile node
MUST choose another MAP and create new bindings. Any existing 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 bindings with this MAP can be assumed to be lost. If no other MAP is
available the mobile node MUST revert to using the Mobile IPv6 available, the mobile node MUST revert to using the Mobile IPv6
protocol as specified in [1]. protocol, as specified in [1].
If a multihomed mobile node has access to several ARs simultaneously If a multihomed mobile node has access to several ARs simultaneously
(on different interfaces), it SHOULD use an LCoA on the link defined (on different interfaces), it SHOULD use an LCoA on the link defined
by the AR that advertises its current MAP. by the AR that advertises its current MAP.
A mobile node MUST store the received option(s) to choose at least A mobile node MUST store the received option(s) in order to choose at
one MAP to register with. Storing the options is essential as they least one MAP to register with. Storing the options is essential, as
will be compared to other options received later for the purpose of they will be compared to other options received later for the purpose
the movement detection algorithm. of the movement detection algorithm.
If no MAP options are found in the router advertisement, the mobile If no MAP options are found in the router advertisement, the mobile
node MUST use the Mobile IPv6 protocol as specified in [1]. 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 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 Address when performing the MAP registration. RCoA is then bound to
the LCoA in the MAP's Binding Cache. the LCoA in the MAP's Binding Cache.
A mobile node MAY choose to register with more than one MAP 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, or use both the RCoA and its LCoA as care-of
simultaneously with different correspondent nodes. addresses simultaneously with different correspondent nodes.
8. Updating previous MAPs 8. Updating Previous MAPs
When a mobile node moves into a new MAP domain, the mobile node may 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 send a BU to the previous MAP requesting it to forward packets
addressed to the mobile node's new CoA. An administrator MAY restrict addressed to the mobile node's new CoA. An administrator MAY
the MAP from forwarding packets to LCoAs outside the MAP's domain. restrict the MAP from forwarding packets to LCoAs outside the MAP's
However, it is RECOMMENDED that MAPs be allowed to forward packets to domain. However, it is RECOMMENDED that MAPs be allowed to forward
LCoAs associated with some of the ARs in neighbouring MAP domains, packets to LCoAs associated with some of the ARs in neighbouring MAP
provided that they are located within the same administrative domain. domains, provided that they are located within the same
administrative domain.
For instance, a MAP could be configured to forward packets to LCoAs For instance, a MAP could be configured to forward packets to LCoAs
associated with ARs that are geographically adjacent to ARs on the associated with ARs that are geographically adjacent to ARs on the
boundary of its domain. This will allow for a smooth inter-MAP boundary of its domain. This will allow for a smooth inter-MAP
handover as it allows the mobile node to continue to receive packets handover as it allows the mobile node to continue to receive packets
while updating the new MAP, its HA and, potentially, correspondent while updating the new MAP, its HA and, potentially, correspondent
nodes. nodes.
9. Notes on MAP selection by the mobile node 9. Notes on MAP Selection by the Mobile Node
HMIPv6 provides a flexible mechanism for local mobility management HMIPv6 provides a flexible mechanism for local mobility management
within a visited network. As explained earlier a MAP can exist within a visited network. As explained earlier, a MAP can exist
anywhere in the operator's network (including the AR). Several MAPs anywhere in the operator's network (including the AR). Several MAPs
can be located within the same domain independently of each other. In can be located within the same domain independently of each other.
addition, overlapping MAP domains are also allowed and recommended. In addition, overlapping MAP domains are also allowed and
Both static and dynamic hierarchies are supported. recommended. Both static and dynamic hierarchies are supported.
When the mobile node receives a router advertisement including a MAP When the mobile node receives a router advertisement including a MAP
option, it should perform actions according to the following movement option, it should perform actions according to the following movement
detection mechanisms. In a Hierarchical Mobile IP network such as the detection mechanisms. In a Hierarchical Mobile IP network such as
one described in this draft, the mobile node should be: the one described in this document, the mobile node should be:
- "Eager" to perform new bindings - "Eager" to perform new bindings
- "Lazy" in releasing existing bindings - "Lazy" in releasing existing bindings
The above means that the mobile node should register with any "new" 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 MAP advertised by the AR (Eager). The method by which the mobile
determines whether the MAP is a "new" MAP is described in section node determines whether the MAP is a "new" MAP is described in
9.1. The mobile node should not release existing bindings until it no section 9.1. The mobile node should not release existing bindings
longer receives the MAP option (or receives it with a lifetime of until it no longer receives the MAP option (or receives it with a
zero) or the lifetime of its existing binding expires (Lazy). This lifetime of zero) or the lifetime of its existing binding expires
Eager-Lazy approach described above will assist in providing a (Lazy). This Eager-Lazy approach, described above, will assist in
fallback mechanism in case of the failure of one of the MAP routers, providing a fallback mechanism in case of the failure of one of the
as it would reduce the time it takes for a mobile node to inform its MAP routers, as it will reduce the time it takes for a mobile node to
correspondent nodes and HA about its new care-of address. inform its correspondent nodes and HA about its new care-of address.
9.1. MAP selection in a distributed-MAP environment 9.1. MAP Selection in a Distributed-MAP Environment
The mobile node needs to consider several factors to optimally select The mobile node needs to consider several factors to optimally select
one or more MAPs, where several MAPs are available in the same one or more MAPs, where several MAPs are available in the same
domain. domain.
There are no benefits foreseen in selecting more than one MAP and There are no benefits foreseen in selecting more than one MAP and
forcing packets to be sent from the higher MAP down through a forcing packets to be sent from the higher MAP down through a
hierarchy of MAPs. This approach may add forwarding delays and hierarchy of MAPs. This approach may add forwarding delays and
eliminate the robustness of IP routing between the highest MAP and eliminate the robustness of IP routing between the highest MAP and
the mobile node; it is therefore prohibited by this specification. the mobile node; therefore, it is prohibited by this specification.
Hence, allowing more than one MAP ("above" the AR) within a network Allowing more than one MAP ("above" the AR) within a network should
should not imply that the mobile node forces packets to be routed not imply that the mobile node forces packets to be routed down the
down the hierarchy of MAPs. However, placing more than one MAP hierarchy of MAPs. However, placing more than one MAP "above" the AR
"above" the AR can be used for redundancy and as an optimisation for can be used for redundancy and as an optimisation for the different
the different mobility scenarios experienced by mobile nodes. The mobility scenarios experienced by mobile nodes. The MAPs are used
MAPs are used independently from each other by the MN (e.g. each MAP independently of each other by the MN (e.g., each MAP is used for
is used for communication to a certain set of CNs). communication to a certain set of CNs).
In terms of the Distance-based selection in a network with several 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 MAPs, a mobile node may choose to register with the furthest MAP to
avoid frequent re-registrations. This is particularly important for avoid frequent re-registrations. This is particularly important for
fast mobile nodes that will perform frequent handoffs. In this fast mobile nodes that will perform frequent handoffs. In this
scenario, the choice of a more distant MAP would reduce the scenario, the choice of a more distant MAP would reduce the
probability of having to change a MAP and informing all correspondent probability of having to change a MAP and informing all correspondent
nodes and the HA. This specification does not provide an algorithm nodes and the HA. This specification does not provide an algorithm
for the distance-based MAP selection. However, such algorithm may be for the distance-based MAP selection. However, such an algorithm may
introduced in future extensions utilising information about the speed be introduced in future extensions utilising information about the
of mobility from lower layers. speed of mobility from lower layers.
In a scenario where several MAPs are discovered by the mobile node in In a scenario where several MAPs are discovered by the mobile node in
one domain, the mobile node may need some sophisticated algorithms to one domain, the mobile node may need some sophisticated algorithms to
be able to select the appropriate MAP. These algorithms would have be able to select the appropriate MAP. These algorithms would have
the mobile node speed as an input (for distance based selection) the mobile node speed as an input (for distance based selection)
combined with the preference field in the MAP option. However, this combined with the preference field in the MAP option. However, this
specification proposes that the mobile node uses the following specification proposes that the mobile node uses the following
algorithm as a default, where other optimised algorithms are not algorithm as a default, where other optimised algorithms are not
available. The following algorithm is simply based on selecting the available. The following algorithm is simply based on selecting the
MAP that is most distant, provided that its preference value did not MAP that is most distant, provided that its preference value did not
reach a value of zero. The mobile node operation is shown below: reach a value of zero. The mobile node operation is shown below:
1. Receive and parse all MAP options 1. Receive and parse all MAP options
2. Arrange MAPs in a descending order, starting with the furthest 2. Arrange MAPs in a descending order, starting with the furthest
away MAP (i.e. MAP option having largest Dist field) away MAP (i.e., MAP option having largest Dist field)
3. Select first MAP in list 3. Select first MAP in list
4. If either the Preference value or the valid lifetime fields are 4. If either the preference value or the valid lifetime fields are
set to zero, select the following MAP in the list. set to zero, select the following MAP in the list.
5. Repeat step (4) while new MAP options still exist until a MAP is 5. Repeat step (4) while new MAP options still exist, until a MAP is
found with preference value and valid lifetime different from found with a non-zero preference value and a non-zero valid
zero. lifetime.
Implementing the steps above would result in mobile nodes selecting Implementing the steps above would result in mobile nodes selecting,
by default the most distant or furthest available MAP by default. by default, the most distant or furthest available MAP. This will
This will continue to take place, until the preference value reduces continue until the preference value reduces to zero. Following this,
to zero. Following this, mobile nodes will start selecting another mobile nodes will start selecting another MAP.
MAP.
9.2. MAP selection in a flat mobility management architecture 9.2. MAP Selection in a Flat Mobility Management Architecture
Network operators may choose a flat architecture in some cases where Network operators may choose a flat architecture in some cases where
a Mobile IPv6 handover may be considered a rare event. In these a Mobile IPv6 handover may be considered a rare event. In these
scenarios operators may choose to include the MAP function in ARs 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 only. The inclusion of the MAP function in ARs can still be useful
reduce the time required to update all correspondent nodes and the 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 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 an anchor point when performing a handoff. This kind of dynamic
hierarchy (or anchoring) is only recommended for cases where inter-AR hierarchy (or anchoring) is only recommended for cases where inter-AR
movement is not frequent. u0movement is not frequent.
10. Detection and recovery from MAP failures 10. Detection and Recovery from MAP Failures
This specification introduces a MAP that can be seen as a local Home 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 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 point of failure. If a MAP fails, its binding cache content will be
lost, resulting in loss of communication between mobile and lost, resulting in loss of communication between mobile and
correspondent nodes. This situation may be avoided with the use of correspondent nodes. This situation may be avoided by using more
more than one MAP on the same link and utilising some form of context than one MAP on the same link and by utilising some form of context
transfer protocol between them. Alternatively, future versions of the transfer protocol between them. Alternatively, future versions of
Virtual Router Redundancy Protocol [12], or HA redundancy protocols the Virtual Router Redundancy Protocol [4] or HA redundancy protocols
may allow networks to recover from MAP failures. may allow networks to recover from MAP failures.
In cases where such protocols are not supported, the mobile node In cases where such protocols are not supported, the mobile node
would need to detect MAP failures. The mobile node can detect this would need to detect MAP failures. The mobile node can detect this
situation when it receives a router advertisement containing a MAP situation when it receives a router advertisement containing a MAP
option with a lifetime of zero. The mobile node should start the MAP option with a lifetime of zero. The mobile node should start the MAP
discovery process and attempt to register with another MAP. After it discovery process and attempt to register with another MAP. After it
has selected and registered with another MAP it will also need to has selected and registered with another MAP, it will also need to
inform correspondent nodes and the Home Agent if its RCoA has inform correspondent nodes and the Home Agent if its RCoA has
changed. Note that, in the presence of a protocol that transfers changed. Note that in the presence of a protocol that transfers
binding cache entries between MAPs for redundancy purposes, a new MAP 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 may be able to provide the same RCoA to the mobile node (e.g., if
MAPs advertise the same prefix in the MAP option. This would save the both MAPs advertise the same prefix in the MAP option). This would
mobile node from updating correspondent nodes and the Home Agent. save the mobile node from updating correspondent nodes and the Home
Agent.
Access routers can be triggered to advertise a MAP option with a Access routers can be triggered to advertise a MAP option with a
lifetime of zero (indicating MAP failure) in different ways: lifetime of zero (indicating MAP failure) in different ways:
- By manual intervention. - By manual intervention.
- In a dynamic manner. - In a dynamic manner.
ARs can perform Dynamic detection of MAP failure by sending ICMP Echo ARs can perform Dynamic detection of MAP failure by sending ICMP Echo
request messages to the MAP regularly (e.g. every ten seconds). If no request messages to the MAP regularly (e.g., every ten seconds). If
response is received an AR may try to aggressively send echo requests no response is received, an AR may try to aggressively send echo
to the MAP for a short period of time (e.g. once every 5 seconds for requests to the MAP for a short period of time (e.g., once every 5
15 seconds); if no reply is received, a MAP option may be sent with a seconds for 15 seconds); if no reply is received, a MAP option may be
valid lifetime value of zero. sent with a valid lifetime value of zero.
This specification does not mandate a particular recovery mechanism. This specification does not mandate a particular recovery mechanism.
However, any similar mechanism between the MAP and an AR SHOULD be However, any similar mechanism between the MAP and an AR SHOULD be
secure to allow for message authentication, integrity protection and secure to allow for message authentication, integrity protection, and
protection against replay attacks. protection against replay attacks.
11. IANA Considerations 11. IANA Considerations
Section 4 introduces a new flag (M )to the Binding Update specified Section 4 introduces a new flag (M )to the Binding Update specified
in RFC 3775. in RFC 3775.
Section 5 introduces a new IPv6 Neighbour Discovery Option called the Section 5 introduces a new IPv6 Neighbour Discovery Option called the
MAP Option. An Option Type value for the MAP Option must be assigned MAP Option. IANA has assigned the Option Type value 23 for the MAP
by IANA within the option numbering space for IPv6 Neighbour Option within the option numbering space for IPv6 Neighbour Discovery
Discovery messages. messages.
12. Security considerations 12. Security Considerations
This specification introduces a new concept to Mobile IPv6, namely, a This specification introduces a new concept to Mobile IPv6, namely, a
Mobility Anchor Point that acts as a local Home Agent. It is crucial 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 that the security relationship between the mobile node and the MAP is
of strong nature; it MUST involve mutual authentication, integrity strong; it MUST involve mutual authentication, integrity protection,
protection and protection against replay attacks. Confidentiality may and protection against replay attacks. Confidentiality may be needed
be needed for payload traffic but is not required for binding updates for payload traffic, but is not required for binding updates to the
to the MAP. The absence of any of these protections may lead to MAP. The absence of any of these protections may lead to malicious
malicious mobile nodes impersonating other legitimate ones, mobile nodes impersonating other legitimate ones or impersonating a
impersonating a MAP. Any of these attacks will undoubtedly cause MAP. Any of these attacks will undoubtedly cause undesirable impacts
undesirable impacts to the mobile node's communication with all to the mobile node's communication with all correspondent nodes
correspondent nodes having knowledge of the mobile node's RCoA. having knowledge of the mobile node's RCoA.
Three different relationships (related to securing binding updates) Three different relationships (related to securing binding updates)
need to be considered: need to be considered:
1) The mobile node - MAP 1) The mobile node - MAP
2) The mobile node - Home Agent 2) The mobile node - Home Agent
3) The mobile node - correspondent node 3) The mobile node - correspondent node
12.1. Mobile node-MAP security 12.1. Mobile Node-MAP Security
In order to allow a mobile node to use the MAP's forwarding service, In order to allow a mobile node to use the MAP's forwarding service,
initial authorization (specifically for the service, not for the initial authorisation (specifically for the service, not for the
RCoA) MAY be needed. Authorising a mobile node to use the MAP service RCoA) MAY be needed. Authorising a mobile node to use the MAP
can be done based on the identity of the mobile node exchanged during service can be done based on the identity of the mobile node
the SA negotiation process. The authorization may be granted based on exchanged during the SA negotiation process. The authorisation may
the mobile node's identity, or based on the identity of a Certificate be granted based on the mobile node's identity, or based on the
Authority (CA) that the MAP trusts. For instance, if the mobile node identity of a Certificate Authority (CA) that the MAP trusts. For
presents a certificate signed by a trusted entity (e.g. a CA that instance, if the mobile node presents a certificate signed by a
belongs to the same administrative domain, or another trusted roaming trusted entity (e.g., a CA that belongs to the same administrative
partner), it would be sufficient for the MAP to authorise the use of domain, or another trusted roaming partner), it would be sufficient
its service. Note that this level of authorisation is independent of for the MAP to authorise the use of its service. Note that this
authorising the use of a particular RCoA. Similarly, the mobile node level of authorisation is independent of authorising the use of a
would trust the MAP, if it presents a certificate signed by the same particular RCoA. Similarly, the mobile node would trust the MAP if
CA, or by another CA that the mobile node is configured to trust it presents a certificate signed by the same CA or by another CA that
(e.g. a roaming partner). the mobile node is configured to trust (e.g., a roaming partner).
HMIPv6 uses an additional registration between the mobile node and HMIPv6 uses an additional registration between the mobile node and
its current MAP. As explained in this document, when a mobile node 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 moves into a new domain (i.e., served by a new MAP), it obtains an
RCoA, a LCoA and registers the binding between these two addresses 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 with the new MAP. The MAP then verifies whether the RCoA has not
registered yet and if so it creates a binding cache entry with the been registered yet and, if so, it creates a binding cache entry with
RCoA and LCoA. Whenever the mobile node gets a new LCoA, it needs to the RCoA and LCoA. Whenever the mobile node gets a new LCoA, it
send a new BU that specifies the binding between RCoA and its new needs to send a new BU that specifies the binding between RCoA and
LCoA. This BU needs to be authenticated otherwise any host could send its new LCoA. This BU needs to be authenticated, otherwise any host
a BU for the mobile node's RCoA and hijack the mobile node's packets. could send a BU for the mobile node's RCoA and hijack the mobile
However since the RCoA is temporary and is not bound to a particular node's packets. However, because the RCoA is temporary and is not
node, a mobile node does not have to initially (before the first bound to a particular node, a mobile node does not have to initially
binding update) prove that it owns its RCoA (unlike the requirement (before the first binding update) prove that it owns its RCoA (unlike
on home addresses in Mobile IPv6) when it establishes a Security the requirement on home addresses in Mobile IPv6) when it establishes
Association with its MAP. A MAP only needs to ensure that a BU for a a Security Association with its MAP. A MAP only needs to ensure that
particular RCoA was issued by the same mobile node that established a BU for a particular RCoA was issued by the same mobile node that
the Security Association for that RCoA. established the Security Association for that RCoA.
The MAP does not need to have prior knowledge of the identity of the 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 nor its Home Address. As a result the SA between the
mobile node and the MAP can be established using any key mobile node and the MAP can be established using any key
establishment protocols such as IKE. A return routability test is not establishment protocols such as IKE. A return routability test is
necessary. not necessary.
The MAP needs to set the SA for the RCoA (not the LCoA). This can be 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 performed with IKE [2]. The mobile node uses its LCoA as the source
address but specifies that the RCoA should be used in the SA. This is address, but specifies that the RCoA should be used in the SA. This
achieved by using the RCoA as the identity in IKE Phase 2 is achieved by using the RCoA as the identity in IKE Phase 2
negotiation. This step is identical to the use of the home address in negotiation. This step is identical to the use of the home address
IKE phase 2. in IKE phase 2.
If a binding cache entry exists for a given RCoA, the MAP's IKE 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 policy check MUST point to the SA used to install the entry. If the
mobile node's credentials stored in the existing SA do not match the mobile node's credentials stored in the existing SA do not match the
ones provided in the current negotiation, the MAP MUST reject the new ones provided in the current negotiation, the MAP MUST reject the new
SA establishment request for such RCoA with an INVALID-ID-INFORMATION SA establishment request for such RCoA with an INVALID-ID-INFORMATION
notification [6]. This is to prevent two different mobile nodes from notification [2]. This is to prevent two different mobile nodes from
registering (intentionally or not) the same RCoA. Upon receiving this registering (intentionally or not) the same RCoA. Upon receiving
notification, the mobile node SHOULD generate a new RCoA and restart this notification, the mobile node SHOULD generate a new RCoA and
the IKE negotiation. Alternatively, a MAP may decide that if a restart the IKE negotiation. Alternatively, a MAP may decide that,
binding cache entry already exists for a particular RCoA, no new if a binding cache entry already exists for a particular RCoA, no new
security association should be established for such RCoA, security association should be established for such RCoA; this is
independently of the mobile node credentials. This stops the mobile independent of the mobile node credentials. This prevents the mobile
node from re-establishing a security association for the same RCoA. node from being able to re-establish a security association for the
This is not a major problem since both AH and ESP headers allow for 4 same RCoA (i.e., to change session keys). However, this is not a
billion packets to be sent (the size of the sequence number field) major problem because the SA will typically only be used to protect
using the same security association. signalling traffic when a MN moves, and not for the actual data
traffic sent to arbitrary nodes.
Binding updates between the MAP and the mobile node MUST be protected 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 with either AH or ESP in transport mode. When ESP is used, a non-
authentication algorithm MUST be used. null authentication algorithm MUST be used.
12.2. Mobile node-correspondent node security 12.2. Mobile Node-Correspondent Node Security
Mobile IPv6 [1] defines a return routability procedure that allows Mobile IPv6 [1] defines a return routability procedure that allows
mobile and correspondent nodes to authenticate binding updates and mobile and correspondent nodes to authenticate binding updates and
acknowledgements. This specification does not impact the return acknowledgements. This specification does not impact the return
routability test defined in [1]. However, it is important to note routability test defined in [1]. However, it is important to note
that mobile node implementers need to be careful when selecting the 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 of the HOTI and COTI messages, defined in [1]. The
source address used in HOTI messages MUST be the mobile node's home source address used in HOTI messages MUST be the mobile node's home
address. The packet containing the HOTI message is encapsulated address. The packet containing the HOTI message is encapsulated
twice. The inner encapsulating header contains the RCoA in the source twice. The inner encapsulating header contains the RCoA in the
address field and the home agent's address in the destination address source address field and the home agent's address in the destination
field. The outer encapsulating header contains the mobile node's LCoA address field. The outer encapsulating header contains the mobile
in the source address field and the MAP's address in the destination node's LCoA in the source address field and the MAP's address in the
field. destination field.
12.3. Mobile node-Home Agent security 12.3. Mobile Node-Home Agent Security
The security relationship between the mobile node and its Home Agent, The security relationship between the mobile node and its Home Agent,
as discussed in [1], is not impacted by this specification. as discussed in [1], is not impacted by this specification.
13. Acknowledgments 13. Acknowledgments
The authors would like to thank Conny Larsson (Ericsson) and Mattias The authors would like to thank Conny Larsson (Ericsson) and Mattias
Pettersson (Ericsson) for their valuable input to this draft. Pettersson (Ericsson) for their valuable input to this document. The
The authors would also like to thank the members of the French RNRT authors would also like to thank the members of the French RNRT
MobiSecV6 project (BULL, France Telecom and INRIA) for testing the MobiSecV6 project (BULL, France Telecom and INRIA) for testing the
first implementation and for their valuable feedback. The INRIA first implementation and for their valuable feedback. The INRIA
HMIPv6 project is partially funded by the French Government. HMIPv6 project is partially funded by the French Government.
In addition, the authors would like to thank the following members of In addition, the authors would like to thank the following members of
the working group in alphabetical order: Samita Chakrabarti (Sun), the working group in alphabetical order: Samita Chakrabarti (Sun),
Gregory Daley (Monash University), Francis Dupont (GET/Enst Gregory Daley (Monash University), Francis Dupont (GET/Enst
Bretagne), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave Bretagne), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave
Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf
(Docomo labs), Martti Kuparinen (Ericsson) Fergal Ladley, Gabriel (Docomo labs), Martti Kuparinen (Ericsson) Fergal Ladley, Gabriel
Montenegro (Sun), Nick "Sharkey" Moore (Monash University) Erik Montenegro (Sun), Nick "Sharkey" Moore (Monash University) Erik
Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (Monash Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (Monash
University), and Alper Yegin (Samsung) for their comments on the University), and Alper Yegin (Samsung) for their comments on the
draft. document.
14. 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
15. References
15.1. Normative references
[1] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in
IPv6", RFC 3775.
[2] S. Thomson and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462.
[3] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery
for IP version 6", RFC 2461.
[4] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6)
specification", RFC 2460.
[5] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE) ",
RFC 2409.
[6] S. Kent and R. Atkinson, "IP Authentication Header", RFC 2402.
[7] S. Kent and R. Atkinson, "IP Encapsulating Security Payload",
RFC 2406.
[8] S. Kent and R. Atkinson, "Security Architecture for the 14. References
Internet", RFC 2401.
[9] A. Conta and S. Deering, "Generic Packet Tunneling in IPv6 14.1. Normative References
Specification", RFC 2473.
[10] S. Bradner, "Keywords to use in RFCs to Indicate Requirement [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
Levels", RFC2119. IPv6", RFC 3775, June 2004.
15.2. Informative References [2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[11] K. El Malki (Editor), et. al, "Low latency Handoffs in Mobile [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-08, work in Levels", BCP 14, RFC 2119, March 1997.
progress.
[12] R. Koodli (Editor), et. al, "Fast Handovers for Mobile IPv6", 14.2. Informative References
draft-ietf-mipshop-fast-mipv6-01.txt, work in progress.
[13] K. El Malki and H. Soliman, "Simultaneous Bindings for Mobile [4] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July
IPv6 Fast Handoffs", draft-elmalki-mobileip-bicasting-v6-03, work 2005.
in progress.
[14] P. Ferguson and D. Senie, "Network Ingress Filtering: [5] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Defeating Denial of Service Attacks which employ IP Source Address Denial of Service Attacks which employ IP Source Address
Spoofing", RFC2267. Spoofing", BCP 38, RFC 2827, May 2000.
[15] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill and P. Nikander, [6] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-04, work Neighbor Discovery (SEND)", RFC 3971, March 2005.
in progress, February 2004.
Appendix A - Fast Mobile IPv6 Handovers and HMIPv6 Appendix A: Fast Mobile IPv6 Handovers and HMIPv6
Fast Handovers are required to ensure that the layer 3 (Mobile IP) Fast Handovers are required to ensure that the layer 3 (Mobile IP)
handover delay is minimised, thus also minimising and possibly handover delay is minimised, thus also minimising, and possibly
eliminating the period of service disruption which normally occurs eliminating, the period of service disruption which normally occurs
when a mobile node moves between two ARs. This period of service when a mobile node moves between two ARs. This period of service
disruption usually occurs due to the time required by the mobile node disruption usually occurs due to the time required by the mobile node
to update its HA using Binding Updates after it moves between ARs. to update its HA using Binding Updates after it moves between ARs.
During this time period the mobile node cannot resume or continue During this time period the mobile node cannot resume or continue
communications. The mechanism to achieve Fast Handovers with Mobile communications. The mechanism to achieve Fast Handovers with Mobile
IPv6 is described in [14] and is briefly summarised here. This IPv6 is described in [5] and is briefly summarised here. This
mechanism allows the anticipation of the layer 3 handover such that mechanism allows the anticipation of the layer 3 handover, such that
data traffic can be redirected to the mobile node's new location data traffic can be redirected to the mobile node's new location
before it moves there. before it moves there.
While the mobile node is connected to its previous Access Router 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 (PAR) and is about to move to a new Access Router (NAR), the Fast
Handovers in Mobile IPv6 requires in sequence: Handovers in Mobile IPv6 requires in sequence:
1) the mobile node to obtain a new care-of address at the NAR while 1) The mobile node to obtain a new care-of address at the NAR while
connected to the PAR connected to the PAR.
2) New CoA to be used at NAR case: the mobile node to send a F-BU 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 (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 binding cache with the mobile node's new CoA while still attached
to PAR to PAR.
3) The previous anchor point (i.e. PAR) to start forwarding packets
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 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). (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 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 (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 moved and attached to NAR, in order to update its binding cache
with the mobile node's new CoA. with the mobile node's new CoA.
The mobile node or PAR may initiate the Fast Handover procedure by The mobile node or PAR may initiate the Fast Handover procedure by
using wireless link-layer information or link-layer triggers which using wireless link-layer information or link-layer triggers that
inform that the mobile node will soon be handed off between two inform that the mobile node will soon be handed off between two
wireless access points respectively attached to PAR and NAR. If the wireless access points respectively attached to PAR and NAR. If the
"trigger" is received at the mobile node, the mobile node will "trigger" is received at the mobile node, the mobile node will
initiate the layer-3 handover process by sending a Proxy Router initiate the layer-3 handover process by sending a Proxy Router
Solicitation message to PAR. Instead if the "trigger" is received at Solicitation message to PAR. Instead, if the "trigger" is received
PAR then it will transmit a Proxy Router Advertisement to the at PAR, then it will transmit a Proxy Router Advertisement to the
appropriate mobile node, without the need for solicitations. The appropriate mobile node, without the need for solicitations. The
basic Fast Handover message exchanges are illustrated in Figure A.1. basic Fast Handover message exchanges are illustrated in Figure A.1.
+-----------+ 1a. HI +-----+ +-----------+ 1a. HI +-----+
| | ---------------->| NAR | | | ---------------->| NAR |
| PAR | 1b. HAck | | | PAR | 1b. HAck | |
+-----------+ <--------------- +-----+ +-----------+ <--------------- +-----+
^ | ^ ^ | ^
(2a. RtSolPr) | | 2b | (2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU) | | Pr | 3. Fast BU (F-BU)
| | RtAdv | 4. Fast BA (F-BACK) | | RtAdv | 4. Fast BA (F-BACK)
| v v | v v
+------------+ +------------+
| MN | | MN |
+------------+ - - - - - -> +------------+ - - - - - ->
Movement Movement
Figure A.1 - Fast Mobile IPv6 Handover Protocol Figure A.1: Fast Mobile IPv6 Handover Protocol
The mobile node obtains a new care-of address while connected to PAR The mobile node obtains a new care-of address while connected to PAR
by means of router advertisements containing information from the NAR by means of router advertisements containing information from the NAR
(Proxy Router Advertisement which may be sent due to a Proxy Router (Proxy Router Advertisement, which may be sent due to a Proxy Router
Solicitation). The PAR will validate the mobile node's new CoA by 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 sending a Handover Initiate (HI) message to the NAR. The new CoA
in the HI message is formed by appending the mobile node's current sent in the HI message is formed by appending the mobile node's
interface identifier to the NAR's prefix. Based on the response current interface identifier to the NAR's prefix. Based on the
generated in the Handover Acknowledge (HAck) message, the PAR will response generated in the Handover Acknowledge (HAck) message, the
either generate a tunnel to the mobile node's new CoA (if the address PAR will either generate a tunnel to the mobile node's new CoA (if
was valid) or generate a tunnel to the NAR's address (if the address the address was valid) or generate a tunnel to the NAR's address (if
was already in use on the new subnet). If the address was already in the address was already in use on the new subnet). If the address
use on the new subnet it is assumed that there will be no time to was already in use on the new subnet, it is assumed that there will
perform another attempt to configure the mobile node with a CoA on be no time to perform another attempt to configure the mobile node
the new link, so the NAR will generate a host route for the mobile with a CoA on the new link. Therefore, the NAR will generate a host
node using its old CoA. Note that message 1a may precede message 2b route for the mobile node using its old CoA. Note that message 1a
or occur at the same time. may precede message 2b or occur at the same time.
In [14], the ARs act as local Home Agents, which hold binding caches In [5], the ARs act as local Home Agents, which hold binding caches
for the mobile nodes and receive Binding Updates. This makes these for the mobile nodes and receive Binding Updates. This makes these
ARs function like the MAP specified in this document. Also, it is ARs function like the MAP specified in this document. Also, it is
quite possible that the ARs are not directly connected, but quite possible that the ARs are not directly connected, but
communicate through an aggregation router. Such an aggregation router communicate through an aggregation router. Therefore, such an
is therefore also an ideal position for the MAP functionality. These aggregation router is also an ideal position for the MAP
are two ways of integrating the HMIPv6 and Fast Handover mechanisms. functionality. These are two ways of integrating the HMIPv6 and Fast
The first involves placing MAPs in place of the ARs which is a Handover mechanisms. The first involves placing MAPs in place of the
natural step. The second scenario involves placing the MAP in an ARs, which is a natural step. The second scenario involves placing
aggregation router "above" the ARs. In this case, [14] specifies the MAP in an aggregation router "above" the ARs. In this case, [5]
forwarding of packets between PAR and NAR. This could be inefficient specifies forwarding of packets between PAR and NAR. This could be
in terms of delay, bandwidth efficiency since packets will traverse inefficient in terms of delay and bandwidth efficiency because
the MAP-PAR link twice and packets arriving out of order at the packets will traverse the MAP-PAR link twice and packets will arrive
mobile node. Using the MAP in the aggregation router would improve out of order at the mobile node. Using the MAP in the aggregation
the efficiency of Fast Handovers which could make use of the MAP to router would improve the efficiency of Fast Handovers, which could
redirect traffic, thus saving delay and bandwidth between the make use of the MAP to redirect traffic, thus saving delay and
aggregation router and the PAR. bandwidth between the aggregation router and the PAR.
+---------+ +---------+
| MAP | | MAP |
+-------------->| | +-------------->| |
| +---------+ | +---------+
| | ^ | | ^
| 1a. HI | | | 1a. HI | |
| | | | | |
| | | 1b. HAck | | | 1b. HAck
| v | | v |
skipping to change at page 26, line 29 skipping to change at page 26, line 32
(2a. RtSolPr) | | 2b | (2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU) from mobile node to | | Pr | 3. Fast BU (F-BU) from mobile node to
| | MAP | | MAP
| | RtAdv | 4. Fast BA (F-BACK) from MAP to | | RtAdv | 4. Fast BA (F-BACK) from MAP to
| | | mobile node | | | mobile node
| v v | v v
+------------+ +------------+
| MN | Movement | MN | Movement
+------------+ - - - - - -> +------------+ - - - - - ->
Figure A.2 Fast Mobile IPv6 Handover Protocol using HMIPv6 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 In Figure A.2, the HI/HAck messages now occur between the MAP and NAR
to check the validity of the newly requested care-of address and to in order to check the validity of the newly requested care-of address
establish a temporary tunnel should the new care-of address not be and to establish a temporary tunnel should the new care-of address
valid. Therefore the same functionality of the Fast Handover 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 procedure is kept, but the anchor point is moved from the PAR to the
MAP. MAP.
As in the previous Fast Handover procedure, in the network-determined 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 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 Proxy Router Advertisement to the mobile node with the MAP option.
the mobile-determined case this is preceded by a Proxy Router 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 Solicitation from the mobile node. The same layer-2 trigger at PAR
the network-determined case could be used to independently initiate in the network-determined case could be used to independently
Context Transfer (e.g. QoS) between PAR and NAR. In the mobile initiate Context Transfer (e.g., QoS) between PAR and NAR. In the
determined case the trigger at PAR could be replaced by the reception mobile-determined case, the trigger at PAR could be replaced by the
of a Proxy Router Solicitation or F-BU. Context Transfer is being reception of a Proxy Router Solicitation or F-BU. Context Transfer
worked on in the IETF Seamoby WG. is being worked on in the IETF Seamoby WG.
The combination of Fast Handover and HMIPv6 allows the anticipation The combination of Fast Handover and HMIPv6 allows the anticipation
of the layer 3 handoff such that data traffic can be efficiently of the layer 3 handoff, such that data traffic can be efficiently
redirected to the mobile node's new location before it moves there. redirected to the mobile node's new location before it moves there.
However it is not easy to determine the correct time to start However, it is not easy to determine the correct time to start
forwarding traffic from the MAP to the mobile node's new location, 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 which has an impact on how smooth the handoff will be. The same
issues arise in [14] with respect to when to start forwarding between issues arise in [5] with respect to when to start forwarding between
PAR and NAR. Packet loss will occur if this is performed too late or 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 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 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- the MAP updates its binding cache upon receiving the anticipated
BU, since it is not known when exactly the mobile node will perform F-BU, because it is not known exactly when the mobile node will
or complete the layer-2 handover to NAR relative to when the mobile perform or complete the layer-2 handover to NAR, relative to when the
node transmits the F-BU. Also, some measure is needed to support the mobile node transmits the F-BU. Also, some measure is needed to
case in which the mobile node's layer-2 handover unexpectedly fails support the case in which the mobile node's layer-2 handover
(after Fast Handover has been initiated) or when the mobile node unexpectedly fails (after Fast Handover has been initiated) or when
moves quickly back-and-forth between ARs (ping-pong). Simultaneous the mobile node moves quickly back-and-forth between ARs (ping-pong).
bindings [15] provides a solution to these issues. In [15] a new Simultaneous bindings [6] provide a solution to these issues. In
Simultaneous Bindings Flag is added to the Fast Binding Update (F-BU) [6], a new Simultaneous Bindings Flag is added to the Fast Binding
message and a new Simultaneous Bindings suboption is defined for Fast Update (F-BU) message and a new Simultaneous Bindings suboption is
Binding Acknowledgement (F-BAck) message. Using this enhanced defined for the Fast Binding Acknowledgement (F-BAck) message. Using
mechanism, upon layer-3 handover, traffic for the mobile node will be this enhanced mechanism, upon layer-3 handover, traffic for the
sent from the MAP to both PAR and NAR for a certain period thus mobile node will be sent from the MAP to both PAR and NAR for a
isolating the mobile node from layer-2 effects such as handover certain period, thus isolating the mobile node from layer-2 effects
timing, ping-pong or handover failure and providing the mobile node such as handover timing, ping-pong, or handover failure and providing
with uninterrupted layer-3 connectivity. the mobile node with uninterrupted layer-3 connectivity.
Intellectual Property Statement 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@elmalki.homeip.net
Ludovic Bellier
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
France
EMail: ludovic.bellier@inria.fr
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright Statement Acknowledgement
Copyright (C) The Internet Society (2004). 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.
Disclaimer of Validity
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 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.
This Internet-Draft expires June, 2005. Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 156 change blocks. 
554 lines changed or deleted 518 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/