Internet DRAFT - draft-ma-mext-ihmipv6

draft-ma-mext-ihmipv6



Network Working Group                                      Zhengming. Ma
Internet-Draft                                                 Lin. Wang
Intended status: Informational                    SUN YAT-SEN UNIVERSITY
Expires: May 17, 2012                                  November 14, 2011


    Improved Hierarchical Mobile IPv6 (IHMIPv6) Mobility Management
                    draft-ma-mext-ihmipv6-00.txt

Abstract

   In HMIPv6 (RFC5213), a mobile node has three IPv6 addresses: HoA,
   RCoA and LCoA.  Outside the domain of a MAP, RCoA is used for
   routing, while HoA is used for authentication.  Hence HA and CN
   should maintain the binding of RCoA and HoA.  Inside the domain of a
   MAP, RCoA is used for authentication, while LCoA is used for routing.
   Hence MAP should maintain the binding of RCoA and LCoA.  Since RCoA
   is used for authentication, it should be unique to a mobile node.
   Therefore, how many mobile nodes there are inside domain of a MAP,
   how many different RCoAs the MAP has to allocate to the mobile nodes.
   In this Internet Draft, an improved or alternative solution to HMIPv6
   is presented, where RCoA is no longer used for authentication inside
   the domains of a MAP.  RCoA is used only for routing outside the
   domain of a MAP, as LCoA does inside the domain of a MAP.  Inside the
   domain of a MAP, HoA is used for authentication, as it does outside
   the domain of a MAP.  Since RCoA is no longer used for
   authentication, only one RCoA will be enough for all mobile nodes
   inside the domain of a MAP.

   Remark: This Internet Draft is based on HMIPv6 (RFC5380).  Only those
   parts in HMIPv6 related to RCoA have been rewritten, while the other
   parts in HMIPv6 remain almost unchanged.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Ma & Wang                 Expires May 17, 2012                  [Page 1]

Internet-Draft                    IHMIP                    November 2011


   This Internet-Draft will expire on May 17, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



































Ma & Wang                 Expires May 17, 2012                  [Page 2]

Internet-Draft                    IHMIP                    November 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview of IHMIPv6  . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  IHMIPv6 Operations . . . . . . . . . . . . . . . . . . . .  7
   4.  Mobile IPv6 Extension - Local Binding Update . . . . . . . . .  9
   5.  Neighbor Discovery Extension: The MAP Option . . . . . . . . . 10
   6.  Overview of IHMIPv6  . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . 11
       6.1.1.  Sending Packets to Correspondent Nodes . . . . . . . . 13
     6.2.  MAP Operations . . . . . . . . . . . . . . . . . . . . . . 13
     6.3.  Home Agent Operations  . . . . . . . . . . . . . . . . . . 14
     6.4.  Correspondent Node Operations  . . . . . . . . . . . . . . 14
     6.5.  Local Mobility Management Optimization within a MAP
           Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  MAP Discovery  . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . 15
   8.  Updating Previous MAPs . . . . . . . . . . . . . . . . . . . . 15
   9.  Note on MAP Selection by the Mobile Node . . . . . . . . . . . 16
     9.1.  MAP Selection in Distributed MAP Environment . . . . . . . 16
     9.2.  MAP Selection in a Flat Mobility Architecture  . . . . . . 18
   10. Detection and Recovery from MAP Failures . . . . . . . . . . . 18
   11. Tunelling Impacts on MTU . . . . . . . . . . . . . . . . . . . 19
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
     12.1. Mobile Node - MAP Security . . . . . . . . . . . . . . . . 20
     12.2. Mobile Node - Correspondent Node Security  . . . . . . . . 21
     12.3. Mobile Node - Home Agent Security  . . . . . . . . . . . . 22
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22





















Ma & Wang                 Expires May 17, 2012                  [Page 3]

Internet-Draft                    IHMIP                    November 2011


1.  Introduction

   This specification introduces the concept of an improved hierarchical
   Mobile IPv6 network, utilizing a node called the Mobility Anchor
   Point (MAP).

   Mobile IPv6 [RFC3775] allows nodes to move within the Internet
   topology while maintaining reachability and ongoing connections
   between mobile and correspondent nodes.  To do this, a mobile node
   sends binding updates (BUs) to its home agent (HA) every time it
   moves.

   The mobile node may send data packets via its home agent immediately
   after sending the binding update, but the home agent will not be able
   to route traffic back to the mobile node before it receives the
   binding update.  This incurs at least half a round-trip delay before

   The mobile node may send data packets via its home agent immediately
   after sending the binding update, but the home agent will not be able
   to route traffic back to the mobile node before it receives the
   binding update.  This incurs at least half a round-trip delay before
   packets are again forwarded to the right place.  There is an
   additional delay for sending data packets if the mobile node chooses
   to wait for a binding acknowledgement (BA).  The round-trip times can
   be relatively long if the mobile node and its home agent are in
   different parts of the world.

   For the reasons given above, Hierarchical Mobile IPv6[RFC5380] comes
   up with two important entities- the mobility anchor point(MAP) and
   the access router(AR).  One MAP administers several ARs.  The mobile
   node (MN) gets two addresses while accessing the Internet through AR.
   One of the two addresses is the Regional CoA (RCoA), the other is the
   local CoA (LCoA).  MAP maintains the binding of RCoA and LCoA, and
   that the binding of HoA and RCoA is maintains by HA and CN.

   The source address of all the messages and packets sent by MN is
   RCoA, as well as the destination address of all the messages and
   packets replied by the correspondent node is RCoA.  Such messages and
   packets will be routed to MAP, which will check the binding of RCoA
   and LCoA in its binding cache and sends the messages and packets to
   MN through the tunnel between MAP and AR.  In the process of MN's
   moving, MAP updates its binding of RCoA and LCoA by means of
   receiving the local binding update message (LBU) from MN and replying
   the Local binding acknowledgement message (LBA) to MN if MN doesn't
   move out of the range covered by a MAP which means only LCoA has
   changed and RCoA has no change.  If MN moves out of a MAP domain's
   boundaries which means both LCoA and RCoA have changed, MN should
   update the binding of RCoA and LCoA in MAP's binding cache, and also



Ma & Wang                 Expires May 17, 2012                  [Page 4]

Internet-Draft                    IHMIP                    November 2011


   update the binding of HoA and RCoA in the binding cache of HA and CN.

   In fact, MN usually moves within a small domain, that is to say, it
   roams within a local MAP domain.  Here only LCoA has changed and RCoA
   has no change, thus HMIPv6 just needs to update the binding of RCoA
   and LCoA in MAP by the interaction of LBU and LBA without updating
   the binding caches in HA and CN.  In this way, it can reduce a lot of
   signaling interactions.

   However, HMIPv6 should distribute a different RCoA for each MN in a
   MAP domain, though the data packets which use RCoA as their
   destination addresses are routed to the same MAP.  In spite of
   infinite address space of IPv6, the address resource is limited as to
   a specified network.  Therefore, according to the HMIPv6, this
   document prompts a improved hierarchical mobile IPv6 communication
   method in which all MNs accessed to the same MAP domain use a public
   IPv6 address so that it can save the IP address resource effectively.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In addition, the following terms are introduced:

   Access Router (AR)

   The AR is the mobile node's default router.  The AR aggregates the
   outbound traffic of mobile nodes.

   Home address (HoA)

   A unicast routable address assigned to a mobile node.  This address
   is within the mobile node's home link.  A mobile node with an IPv6
   home agent is assigned an IPv6 home address.

   Mobility Anchor Point (MAP)

   A Mobility Anchor Point is a router located in a network visited by
   the mobile node.  The MAP doesn't give any treatment to the messages
   and packets from AR, but the MAP should get the HoA by analysising
   the messages or packets from the external.

   Regional Care-of Address (RCoA)

   An RCoA is an address allocated by the MAP to the mobile node.



Ma & Wang                 Expires May 17, 2012                  [Page 5]

Internet-Draft                    IHMIP                    November 2011


   HMIPv6-Aware Mobile Node

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

   On-Link Care-of Address

   The LCoA is the on-link CoA configured on a mobile node's interface
   based on the prefix advertised by its default router.  In [RFC3775],
   this is simply referred to as the care-of address.

   Local Binding Update

   The MN sends a local binding update to the MAP in order to establish
   a binding between the RCoA and LCoA.



3.  Overview of IHMIPv6

   This Improved Hierarchical Mobile IPv6 scheme continues to use the
   function, the MAP, and minor extensions to the mobile node operation.
   The correspondent node and home agent operations will not be
   affected.  This solution is independent of the underlying access
   technology, allowing mobility within or between different types of
   access networks.

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

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




Ma & Wang                 Expires May 17, 2012                  [Page 6]

Internet-Draft                    IHMIP                    November 2011


   It should be noted that the IHMIPv6 concept is also simply an
   extension to the Mobile IPv6 protocol.  An IHMIPv6-aware mobile node
   with an implementation of Mobile IPv6 SHOULD choose to use the MAP
   when discovering such capability in a visited network.  However, in
   some cases the mobile node may prefer to simply use the standard
   Mobile IPv6 implementation.  For instance, the mobile node may be
   located in a visited network within its home site.  In this case, the
   HA is located near the visited network and could be used instead of a
   MAP.

   In this scenario, the mobile node would only update the HA whenever
   it moves.  The method to determine whether the HA is in the vicinity
   of the MN (e.g., same site) is outside the scope of this document.


3.1.   IHMIPv6 Operations

   The network architecture shown in Figure 1 illustrates an example of
   the use of the MAP in a visited network.

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

























Ma & Wang                 Expires May 17, 2012                  [Page 7]

Internet-Draft                    IHMIP                    November 2011


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

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


             Figure 1:Improved Hierarchical Mobile IPv6 domain

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

   The process of MAP Discovery continues as the mobile node moves from
   one subnet to the next.  Every time the mobile node detects movement,
   it will also detect whether it is still in the same MAP domain.  The
   Router Advertisement used to detect movement will also inform the
   mobile node, through Neighbor Discovery [RFC4861] and the MAP option,
   whether it is still in the same MAP domain.  As the mobile node roams



Ma & Wang                 Expires May 17, 2012                  [Page 8]

Internet-Draft                    IHMIP                    November 2011


   within a MAP domain, it will continue to receive the same MAP option
   included in Router Advertisements from its AR.  If a change in the
   advertised MAP's address is received, the mobile node MUST act on the
   change by sending binding updates to its HA and correspondent nodes.

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

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

   To use the network bandwidth in a more efficient manner, a mobile
   node may decide to register with more than one MAP simultaneously and
   to use each MAP address for a specific group of correspondent nodes.

   For example, in Figure 1, if the correspondent node happens to exist
   on the same link as the mobile node, it would be more efficient to
   use the first hop MAP (in this case assume it is AR1) for
   communication between them.  This will avoid sending all packets via
   the "highest" MAP in the hierarchy and thus will result in more
   efficient usage of network bandwidth.  The mobile node can also use
   its current on-link address (LCoA) as a CoA, as specified in
   [RFC3775].  The LCoA included in the binding update MUST be the
   mobile node's address, derived from the prefix advertised on its
   link.


4.  Mobile IPv6 Extension - Local Binding Update

   This section outlines the extensions proposed to the binding update
   specified in [RFC3775].

   A new flag is added: the M flag, which indicates MAP registration.
   When a mobile node registers with the MAP, the M flag MUST be set to
   distinguish this registration from a BU being sent to the HA or a
   correspondent node.



Ma & Wang                 Expires May 17, 2012                  [Page 9]

Internet-Draft                    IHMIP                    November 2011


   0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Sequence #         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |H|L|K|M|      Reserved         |            Lifetime           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                       Figure 2:Local Binding Update

   M

   If set to 1, it indicates a MAP registration.


5.  Neighbor Discovery Extension: The MAP Option

   0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |  Dist |  Pref |R|  Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Valid Lifetime                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                  Global IP Address for MAP                    +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





                          Figure 3:The MAP option

   Type

   IPv6 Neighbour Discovery option.  Its value is 23.



Ma & Wang                 Expires May 17, 2012                 [Page 10]

Internet-Draft                    IHMIP                    November 2011


   Length

   8-bit unsigned integer.  The length of the option and MUST be set to
   3.

   Dist

   A 4-bit unsigned integer identifying the distance between MAP and the
   receiver of the advertisement, measure in the number of hops and
   starting from 1 if the MAP is on the same link as the mobile node.  A
   distance value of zero MUST NOT be used.

   Pref

   The preference field, used as an indicator of operator preference.  A
   4-bit unsigned integer.  A decimal value of 15 indicates the highest
   preference.  When comparing two potential MAPs, the mobile node
   SHOULD inspect this field as a tie-breaker for MAPs that have equal
   Dist values.

   Valid Lifetime

   The minimum value (in seconds) of both the valid lifetime of the
   prefix used to form the MAP's address.  This value indicates the
   validity of the MAP's address.

   Global Address

   One of the MAP's global addresses.


6.  Overview of IHMIPv6

   This section describes the IHMIPv6 protocol.  In HMIPv6, the mobile
   node has two addresses, an RCoA on the MAP's link and an on-link CoA
   (LCoA).  In IHMIPv6, the node has one address, an on-link CoA (LCoA),
   without using an RCoA on the MAP's link.  HMIPv6 protocol requires
   updating the mobile nodes' implementation only.  The HA and
   correspondent node are unchanged.  The MAP performs the function of a
   "local" HA that binds the mobile node's LCoA to an MAPA.

6.1.  Mobile Node Operation

   When a mobile node moves into a new MAP domain (i.e., its MAP
   changes), it needs to configure two addresses: an MAPA and an on-link
   CoA (LCoA).  After discovering the global address of the MAP to
   acquire an MAPA, the mobile node sends a local BU to the MAP with the
   M flags set.  The local BU is a BU defined in [RFC3775] and includes



Ma & Wang                 Expires May 17, 2012                 [Page 11]

Internet-Draft                    IHMIP                    November 2011


   the mobile node's HoA in the Home Address option.  The LCoA is used
   as the source address of the BU.  This BU will bind the mobile node's
   HoA to its LCoA.  The MAP (acting as an HA) will then return a
   binding acknowledgement to the MN.  This acknowledgement either
   identifies the binding as successful or contains the appropriate
   fault code.  No new error codes need to be supported by the mobile
   node for this operation.  The mobile node MUST silently ignore
   binding acknowledgements that do not contain a routing header type 2,
   which includes the mobile node's HoA.

   Following a successful registration with the MAP, a bi-directional
   tunnel between the mobile node and the MAP is established.  All
   packets sent by the mobile node are tunneled to the MAP.  The outer
   header contains the mobile node's LCoA in the source address field,
   and the MAP's address in the destination address field.  The inner
   header contains the mobile node's HoA in the source address field,
   and the peer's address in the destination address field.  Similarly,
   all packets addressed to the MAPA are intercepted by the MAP and
   tunnelled to the mobile node's LCoA according to the HoA in the
   payload of packets.

   This specification allows a mobile node to use more than one MAPA if
   it received more than one MAP option.  In this case, the mobile node
   MAY perform the binding update procedure for each MAPA.

   After registering with the MAP, the mobile node MUST register its new
   MAPA with its HA by sending a BU that specifies the binding (MAPA,
   home address), as in Mobile IPv6.  The mobile node's home address is
   used in the Home Address option and the MAPA is used as the care-of
   address in the source address field.  The mobile node may also send a
   similar BU (i.e., that specifies the binding between the home address
   and the MAPA) to its current correspondent nodes.

   The mobile node SHOULD wait for the binding acknowledgement from the
   MAP before registering the MAPA with other nodes (e.g., CN or HA, if
   available).  It should be noted that when binding the MAPA with the
   HA and correspondent nodes, the binding lifetime MUST NOT be larger
   than the mobile node's binding lifetime with the MAP, which is
   received in the binding acknowledgement.

   In order to speed up the handover between MAPs and reduce packet
   loss, a mobile node SHOULD send a local BU to its previous MAP,
   specifying its new LCoA.  Packets in transit that reach the previous
   MAP are then forwarded to the new LCoA.

   The MAP will receive packets addressed to MAPA.  Packets will be
   tunnelled from the MAP to the mobile node's LCoA.  The mobile node
   will de-capsulate the packets and process them in the normal manner.



Ma & Wang                 Expires May 17, 2012                 [Page 12]

Internet-Draft                    IHMIP                    November 2011


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

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

6.1.1.  Sending Packets to Correspondent Nodes

   The mobile node can communicate with a correspondent node through the
   HA, or in a route-optimized manner, as described in [RFC3775].  When
   communicating through the HA, the message formats in [RFC3775] are
   used.

   If the mobile node communicates directly with the correspondent
   node(i.e., the CN has a binding cache entry for the mobile node), the
   mobile node MUST use the same address used to create a binding cache
   entry in the correspondent node (MAPA) as a source address.
   According to [RFC3775], the mobile node MUST also include a Home
   Address option in outgoing packets.  The Home Address option MUST
   contain the mobile node's home address.

6.2.  MAP Operations

   In [RFC5380], it is stated that the MAP acts like an HA and it
   intercepts all packets addressed to registered mobile nodes and
   tunnels them to the corresponding LCoA, which is stored in its
   binding cache.

   Outside the MAP domain, the messages or packets can be sent to MN by
   HA or CN, as described in [RFC5380].  According to [RFC3775], all the
   messages should include the home address option which should contains
   the mobile node's home address.  The packets sent to MN by CN use HoA
   as the destination address or its routing header type 2 contains HoA
   in a route-optimized manner.  In IHMIPv6, there is a extension to the
   MAP which can analysis the HoA from the packets.

   MAP maintains the binding of HoA and LCoA, HA maintains the binding
   of HoA and MAPA.  CN should maintain the binding of HoA and MAPA in a
   route-optimized manner.

   MAP does nothing with the messages and packets from the tunnel
   between AR and MAP, with the mobile node being the tunnel entry point
   and the MAP being the tunnel exit point ,as described in [RFC5380].
   As to the packets and messages from CN or HA, firstly MAP analsises
   the HoA from the packets and messages, and then checks the binding of



Ma & Wang                 Expires May 17, 2012                 [Page 13]

Internet-Draft                    IHMIP                    November 2011


   HoA and LCoA for HoA in its binding cache, and sends the packets and
   messages to MN by the tunnel between MAP and AR.

6.3.  Home Agent Operations

   The support of IHMIPv6 is completely transparent to the HA's
   operation.  Packets addressed to a mobile node's home address will be
   forwarded by the HA to its MAP, as described in [RFC3775].

6.4.  Correspondent Node Operations

   IHMIPv6 is completely transparent to correspondent nodes.

6.5.  Local Mobility Management Optimization within a MAP Domain

   In the same MAP domain, all the mobile nodes use the same address,
   MAPA, other than use different RCoAs in [RFC5380].  The messages or
   packets using MAPA as the destination address will be routed to the
   MAP.  The routing function of RCoA will be instead by that of MAPA,
   as well as, the identity recognition function of RCoA will be instead
   by that of HoA.  RCoA is replaced by MAPA in the LBU and LBA messages
   defined in [RFC5380], while HoA is contained in the LBU and LBA
   messages.

   IHMIPv6-aware mobile nodes can use their MAPA as the source address
   and use a Home Address option.  In other words, the MAPA can be used
   as a source address for upper layers.  Using this feature, the mobile
   node will be seen by the correspondent node as a fixed node while
   moving within a MAP domain.

   This usage of the MAPA does not have the cost of Mobile IPv6 (i.e.,
   no bindings or Home Address options are sent over the Internet), but
   still provides local mobility management to the mobile nodes with
   near-optimal routing.  Although such use of MAPA does not provide
   global mobility (i.e., communication is broken when a mobile node
   changes its MAPA), it would be useful for several applications (e.g.,
   web browsing).  The validity of the MAPA as a source address used by
   applications will depend on the size of a MAP domain and the speed of
   the mobile node.  Furthermore, because the support for BU processing
   in correspondent nodes is not mandated in [RFC3775], this mechanism
   can provide a way of obtaining route optimization without sending BUs
   to the correspondent nodes.

   Enabling this mechanism can be done by presenting the MAPA as a
   temporary home address for the mobile node.  This may require an
   implementation to augment its source address selection algorithm with
   the knowledge of the MAPA in order to use it for the appropriate
   applications.



Ma & Wang                 Expires May 17, 2012                 [Page 14]

Internet-Draft                    IHMIP                    November 2011


7.  MAP Discovery

   This section describes how a mobile node obtains the MAP address and
   subnet prefix, and how ARs in a domain discover MAPs.

   This specification requires network administrators to manually
   configure the MAP option information in ARs; future mechanisms may be
   defined to allow MAPs to be discovered dynamically.

7.1.  Mobile Node Operation

   When an HMIPv6-aware mobile node receives a Router Advertisement, it
   should search for the MAP option.  One or more options may be found
   for different MAP IP addresses.  A mobile node SHOULD register with
   the MAP having the highest preference value.  A MAP with a preference
   value of zero SHOULD NOT be used for new local BUs (i.e., the mobile
   node can refresh existing bindings but cannot create new ones).
   However, a mobile node MAY choose to register with one MAP over
   another, depending on the value received in the distance field,
   provided that the preference value is above zero.

   A MAP option containing a valid lifetime value of zero means that
   this MAP MUST NOT be selected by the MN.  A valid lifetime of zero
   indicates a MAP failure.  When this option is received, a mobile node
   MUST choose another MAP and create new bindings.  Any existing
   bindings with this MAP can be assumed to be lost.  If no other MAP is
   available, the mobile node MUST NOT attempt to use IHMIPv6.

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

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

   A mobile node MAY choose to register with more than one MAP
   simultaneously, or use both the MAPA and its LCoA as care-of
   addresses simultaneously with different correspondent nodes.


8.  Updating Previous MAPs

   When a mobile node moves into a new MAP domain, the mobile node may
   send a BU to the previous MAP requesting it to forward packets
   addressed to the mobile node's new MAPA.  An administrator MAY
   restrict the MAP from forwarding packets to LCoAs outside the MAP's



Ma & Wang                 Expires May 17, 2012                 [Page 15]

Internet-Draft                    IHMIP                    November 2011


   domain.  However, it is RECOMMENDED that MAPs be allowed to forward
   packets to LCoAs associated with some of the ARs in neighbouring MAP
   domains, provided that they are located within the same
   administrative domain.

   For instance, a MAP could be configured to forward packets to LCoAs
   associated with ARs that are geographically adjacent to ARs on the
   boundary of its domain.  This will allow for a smooth inter-MAP
   handover as it allows the mobile node to continue to receive packets
   while updating the new MAP, its HA and, potentially, correspondent
   nodes.


9.  Note on MAP Selection by the Mobile Node

   IHMIPv6 provides a flexible mechanism for local mobility management
   within a visited network.  As explained earlier, a MAP can exist
   anywhere in the operator's network (including the AR).  Several MAPs
   can be located within the same domain independently of each other.

   In addition, overlapping MAP domains are also allowed and
   recommended.  Both static and dynamic hierarchies are supported.

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

   o "Eager" to perform new bindings.

   o "Lazy" in releasing existing bindings.

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

9.1.  MAP Selection in Distributed MAP Environment

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



Ma & Wang                 Expires May 17, 2012                 [Page 16]

Internet-Draft                    IHMIP                    November 2011


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

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

   In a scenario where several MAPs are discovered by the mobile node in
   one domain, the mobile node may need sophisticated algorithms to be
   able to select the appropriate MAP.  These algorithms would have the
   mobile node speed as an input (for distance-based selection) combined
   with the preference field in the MAP option.  However, this
   specification proposes that the mobile node use the following
   algorithm as a default, where other optimized algorithms are not
   available.  The following algorithm is simply based on selecting the
   MAP that is most distant, provided that its preference value did not
   reach a value of zero.  The mobile node operation is shown below:

   1.  Receive and parse all MAP options.

   2.  Arrange MAPs in a descending order, starting with the furthest
   MAP (i.e., MAP option having largest Dist field).

   3.  Select first MAP in list.

   4.  If either the preference value or the valid lifetime fields are
   set to zero, select the following MAP in the list.

   5.  Repeat step (4) while new MAP options still exist, until a MAP is
   found with a non-zero preference value and a non-zero valid lifetime.

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



Ma & Wang                 Expires May 17, 2012                 [Page 17]

Internet-Draft                    IHMIP                    November 2011


   mobile nodes will start selecting another MAP.

9.2.  MAP Selection in a Flat Mobility Architecture

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


10.  Detection and Recovery from MAP Failures

   This specification introduces a MAP that can be seen as a local home
   agent in a visited network.  A MAP, like a home agent, is a single
   point of failure.  If a MAP fails, its binding cache content will be
   lost, resulting in loss of communication between mobile and
   correspondent nodes.  This situation may be avoided by using more
   than one MAP on the same link and by utilising a form of context
   transfer protocol between them.  However, MAP redundancy is outside
   the scope of this document.

   In cases where such protocols are not supported, the mobile node
   would need to detect MAP failures.  The mobile node can detect this
   situation when it receives a Router Advertisement containing a MAP
   option with a lifetime of zero.  The mobile node should then start
   the MAP Discovery process and attempt to register with another MAP.
   After it has selected and registered with another MAP, it will also
   need to inform correspondent nodes and the home agent if its MAPA has
   changed.

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

   o By manual intervention.

   o In a dynamic manner.

   One way of performing dynamic detection of MAP failure can be done by
   probing the MAP regularly (e.g., every 10 seconds).  If no response
   is received, an AR MAY try to aggressively probe the MAP for a short
   period of time (e.g., once every 5 seconds for 15 seconds); if no
   reply is received, a MAP option may be sent with a valid lifetime
   value of zero.  The exact mechanisms for probing MAPs is outside the



Ma & Wang                 Expires May 17, 2012                 [Page 18]

Internet-Draft                    IHMIP                    November 2011


   scope of this document.  The above text simply shows one example of
   detecting failures.

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

   Note that the above suggestion for detecting MAP failure may not
   detect MAP failures that might take place between probes, i.e.,if a
   MAP reboots between probes.


11.  Tunelling Impacts on MTU

   This specification requires the mobile node to tunnel outgoing
   traffic to the MAP.  Similarly, the MAP tunnels inbound packets to
   the mobile node.  If the mobile node has a home agent elsewhere on
   the Internet, this will result in double encapsulations of inbound
   and outbound packets.  This may have impacts on the mobile node's
   path MTU.  Hence, mobile nodes MUST consider the encapsulation of
   traffic between the node and the MAP when calculating the available
   MTU for upper layers.


12.  Security Considerations

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

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

   1.  The mobile node - MAP

   2.  The mobile node - correspondent node



Ma & Wang                 Expires May 17, 2012                 [Page 19]

Internet-Draft                    IHMIP                    November 2011


   3.  The mobile node - home agent

12.1.  Mobile Node - MAP Security

   In order to allow a mobile node to use the MAP's forwarding service,
   initial authorisation (specifically for the service, not for the
   MAPA) MAY be needed.  Authorising a mobile node to use the MAP
   service can be done based on the identity of the mobile node
   exchanged during the security association (SA) negotiation process.
   The authorisation may be granted based on the mobile node's identity
   or based on the identity of a Certificate Authority (CA) that the MAP
   trusts.  For instance, if the mobile node presents a certificate
   signed by a trusted entity (e.g., a CA that belongs to the same
   administrative domain, or another trusted roaming partner), it would
   be sufficient for the MAP to authorise the use of its service.  Note
   that this level of authorisation is independent of authorising the
   use of a particular MAPA.  Similarly, the mobile node trusts the MAP
   if it presents a certificate signed by the same CA or by another CA
   that the mobile node is configured to trust (e.g., a roaming
   partner).  It is likely that some deployments would be satisfied with
   the use of self-signed certificates for either the mobile node or the
   MAP or both.  This guarantees that the mobile node and the MAP are
   authenticated for address allocation and future binding updates
   without the need for identity authentication.  Hence, the use of
   trusted third-party certificates is not required by this
   specification.

   It is important to note that in this specification, authentication
   and authorisation are effectively the same thing.  All the MAP needs
   in order to allocate the mobile node an MAPA is to authenticate the
   mobile node and verify that it belongs to a trusted group (based on
   its certificate).

   IKEv2 MUST be supported by the mobile node and the MAP.  IKEv2 allows
   the use of Extensible Authentication Protocol (EAP) as a mechanism to
   bootstrap the security association between the communicating peers.

   Hence, EAP can be used with IKEv2 to leverage the Authentication,
   Authorization, and Accounting (AAA) infrastructure to bootstrap the
   SA between the mobile node and the MAP.  Such a mechanism is useful
   in scenarios where an administrator wishes to avoid the configuration
   and management of certificates on mobile nodes.  A MAP MAY support
   the use of EAP over IKEv2.

   If EAP is used with IKEv2, the EAP method runs between the mobile
   node and a AAA server.  Following a successful authentication, the
   resulting keying material can be used to bootstrap IKEv2 between the
   MAP and the mobile node.  The specification of which EAP methods



Ma & Wang                 Expires May 17, 2012                 [Page 20]

Internet-Draft                    IHMIP                    November 2011


   should be used or how keys are transported between the MAP and the
   AAA server is outside the scope of this document.

   HMIPv6 uses an additional registration between the mobile node and
   its current MAP.  As explained in this document, when a mobile node
   moves into a new domain (i.e., served by a new MAP), it obtains an
   MAPA and an LCoA and registers the binding between these two
   addresses with the new MAP.  The MAP then verifies the BU and creates
   a binding cache entry with the MAPA and LCoA.  Whenever the mobile
   node gets a new LCoA, it needs to send a new BU that specifies the
   binding between its MAPA and its new LCoA.  This BU needs to be
   authenticated; otherwise, any host could send a BU for the mobile
   node's MAPA and hijack the mobile node's packets.

   The MAP does not need to have prior knowledge of the identity of the
   mobile node or its home address.  As a result, the SA between the
   mobile node and the MAP can be established using any key
   establishment protocols such as IKEv2.  A return routability test is
   not necessary.

   The MAP needs to set the SA for the MAPA (not the LCoA).  This can be
   performed with IKEv2 [RFC4306].  The mobile node uses its LCoA as the
   source address, but specifies that the MAPA should be used in the SA.

   This is achieved by using the MAPA as the identity in the IKE
   CHILD_SA negotiation.  This step is identical to the use of the home
   address in IKE CHILD_SA when negotiating with the home agent.

   The IPsec Peer Authorization Database (PAD) entries and configuration
   payloads described in [RFC4877] for allocating dynamic home addresses
   SHOULD be used by the MAP to allocate the RCoA for mobile nodes.

   Binding updates between the MAP and the mobile node MUST be protected
   with either Authentication Header (AH) or Encapsulating Security
   Payload (ESP) in transport mode.  When ESP is used, a non-null
   authentication algorithm MUST be used.

   The Security Policy Database (SPD) entries in both the home agent and
   the mobile node are identical to those set up for the home agent and
   mobile node, respectively, as outlined in [RFC4877].

12.2.  Mobile Node - Correspondent Node Security

   Mobile IPv6 [RFC3775] defines a return routability procedure that
   allows mobile and correspondent nodes to authenticate binding updates
   and acknowledgements.  This specification does not impact the return
   routability test defined in [RFC3775].  However, it is important to
   note that mobile node implementers need to be careful when selecting



Ma & Wang                 Expires May 17, 2012                 [Page 21]

Internet-Draft                    IHMIP                    November 2011


   the source address of the HoTI and CoTI messages, defined in
   [RFC3775].  The source address used in HoTI messages SHOULD be the
   mobile node's home address unless the mobile node wishes to use the
   RCoA for route optimisation.  The packet containing the HoTI message
   is encapsulated twice.  The inner encapsulating header contains the
   RCoA in the source address field and the home agent's address in the
   destination address field.  The outer encapsulating header contains
   the mobile node's LCoA in the source address field and the MAP's
   address in the destination field.

12.3.  Mobile Node - Home Agent Security

   The security relationship between the mobile node and its home agent,
   as discussed in [RFC3775], is not impacted by this specification.

   The relationship between the MAP and the mobile node is not impacted
   by the presence of a home agent.


13.  IANA Considerations

   Both the MAP option and M flag were allocated for RFC 4140 and will
   continue to be used by this specification.


Authors' Addresses

   Zhengming Ma
   SUN YAT-SEN UNIVERSITY
   GuangZhou, Higher Mega Center  510006
   China

   Email: issmzm@mail.sysu.edu.cn


   Lin Wang
   SUN YAT-SEN UNIVERSITY
   GuangZhou, Higher Mega Center  510006
   China

   Email: darling135603@163.com










Ma & Wang                 Expires May 17, 2012                 [Page 22]