[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-netlmm-mip-interactions

NETLMM Working Group                                          H. Soliman
Internet-Draft                                      Elevate Technologies
Intended status: Informational                          G. Giaretta, Ed.
Expires: October 26, 2007                                 April 24, 2007


  Interactions between PMIPv6 and MIPv6: scenarios and related issues
               draft-giaretta-netlmm-mip-interactions-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on October 26, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   There has been a lot of discussion and analysis of how Mobile IPv6
   and Proxy Mobile IPv6 can interact. A deeper analysis on the possible
   scenarios and related issues is necessary in order to provide
   guidelines to PMIPv6 protocol specification.  With this purpose in
   mind, this document describes all scenarios of possible interactions
   between Mobile IPv6 and Proxy Mobile IPv6 and discusses a list of
   issues related to the each scenario.




Soliman & Giaretta      Expires October 26, 2007                [Page 1]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


Requirements Language

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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview of the scenarios  . . . . . . . . . . . . . . . . . .  4
   4.  Scenarios and related issues . . . . . . . . . . . . . . . . .  7
     4.1.  Scenario A - Hierarchical Mobility . . . . . . . . . . . .  7
     4.2.  Scenario B - Two types of nodes in the network . . . . . . 11
     4.3.  Scenario C - Movements between PMIPv6-enable and non
           PMIPv6-enabled access networks . . . . . . . . . . . . . . 13
   5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23

























Soliman & Giaretta      Expires October 26, 2007                [Page 2]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


1.  Introduction

   The NETLMM WG is chartered to standardize a network-based protocol
   for localized mobility management.  The goals that must be fulfilled
   by the protocol design are listed in rfc4831.  Proxy Mobile IPv6 has
   been designated as the network-based localized mobility management
   protocol that will be standardized by IETF.

   There are two main reasons why the interactions between Proxy Mobile
   IPv6 and Mobile IPv6 need to be studied.  The first reason is that
   Mobile IPv6 is the main global mobility management protocol developed
   in IETF; it is therefore natural to investigate the details of a
   hierarchical mobility scheme where Proxy Mobile IPv6 is used for
   local mobility and Mobile IPv6 is used for global mobility.

   The second reason is that Mobile IPv6 has been chosen by the NETLMM
   WG mainly for reusability grounds: during the protocol selection
   decision, it has been stated that Mobile IPv6 HA implementation can
   be somehow re-used (with minimal modifications) to act as Proxy
   Mobile IPv6 Local Mobility Anchor.

   Moreover, based on these considerations, some SDOs are investigating
   complex scenarios where the mobility of some nodes are handled using
   Proxy Mobile IPv6, while other nodes manage their own movements using
   Mobile IPv6; or the mobility of a node is managed in turn by a host-
   based and a network-based mechanism.

   The main purpose of this document is to provide a taxonomy of the
   scenarios where Mobile IPv6 and Proxy Mobile IPv6 can be used
   together.  Moreover the document will also identify the issues that
   may be present in those scenarios, identifying the requirements that
   Proxy Mobile IPv6 and/or Mobile IPv6 must fulfill in order to enable
   them.

   In this document we make the assumption that a node using Mobile IPv6
   is compliant with the Mobile IPv6 base specification [RFC3775]
   [RFC3776] (i.e. extensions defined [RFC4283] [RFC4285] in are not
   used).

   Note that some issues identified in this document may be solved by
   existing internet drafts that provide PMIPv6 solutions.  However,
   these issues are listed anyhow as the intent of this document is to
   list the issues that some scenarios may present without going into
   the details of the solution space.

   This document is organized as follows: Section 3 gives an overview of
   the scenarios, Section 4 describes in details the scenarios and list
   the issues that must be solved in order to enable those scenarios and



Soliman & Giaretta      Expires October 26, 2007                [Page 3]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


   Section 5 provides some final considerations and some suggestions on
   the next steps in NETLMM WG.


2.  Terminology

   General mobility terminology can be found in [RFC3753].  Other terms
   used in this document are defined as follows:

   o  Local Mobility Anchor (LMA)

         Local Mobility Anchor is the home agent for the mobile node in
         the Proxy Mobile IPv6 domain.  It is the topological anchor
         point for the mobile node's home prefix and is the entity that
         manages the mobile node's reachability state.

   o  Mobile Access Gateway (MAG)

         Mobile Access Gateway (MAG) is the proxy mobility agent in the
         network which manages the mobility related signaling for a
         mobile node that is attached to its access link.  It is the
         entity responsible for tracking the mobile node's attachment to
         the link and for signaling the mobile node's local mobility
         anchor.

   o  Proxy Mobile IPv6 Domain (PMIPv6-Domain)

         It is a localized mobility management domain where the mobility
         management of a mobile node is handled using Proxy Mobile IPv6
         protocol as defined in this specification.

   o  Proxy Binding Update (PBU)

         A PMIPv6 Binding Update sent by the MAG to the LMA as specified
         in draft-ietf-netlmm-proxymip6-00.


3.  Overview of the scenarios

   Several scenarios can be identified where Mobile IPv6 and Proxy
   Mobile IPv6 are used.  This document will not focus only on scenarios
   where the two protocols are used by the same mobile node to manage
   local and global mobility, but it will also investigate also more
   complex scenarios where the protocols are used beyond their original
   scope or where some nodes implement Mobile IPv6 and others do not
   implement it.

   The following scenarios were identified:



Soliman & Giaretta      Expires October 26, 2007                [Page 4]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


   o  Scenario A - in this scenario Proxy Mobile IPv6 is used as a
      network based local mobility management protocol whereas Mobile
      IPv6 is used as a global mobility management protocol.  This
      interaction is very similar to the HMIPv6-MIPv6 interaction;
      Mobile IPv6 is used to manage mobility among different access
      networks, while the mobility within the access network is handled
      by Proxy Mobile IPv6.

      The following figure illustrates this scenario.

                                    +----+
                                    | HA |
                                    +----+

            Access Net #1                            Access Net #2
          (PMIPv6 Domain #1)                       (PMIPv6 Domain #2)
          ________________                        ________________
         /                \                      /                \
        /     +------+     \                    /     +------+     \
       /      | LMA1 |      \                  /      | LMA2 |      \
       \      +------+      /                  \      +------+      /
        \                  /                    \                  /
         \________________/                      \________________/

                      +----+
                      | MN |  ----------------->
                      +----+       movement

                                 Figure 1 - Scenario A


   o  Scenario B - in this scenario some mobile nodes use Mobile IPv6 to
      manage their movements while others rely on a network-based
      mobility solution provided by the network.  There is a common
      mobility anchor that acts as Mobile IPv6 Home Agent and Proxy
      Mobile IPv6 LMA, depending on the type of the node.















Soliman & Giaretta      Expires October 26, 2007                [Page 5]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


                                  +--------+
                                  | HA/LMA |
                                  +--------+

             +------+                              +------+
             | MAG1 |                              | MAG2 |
             +------+                              +------+

                        +-----------+
                        | IPv6 host |   ----------------->
                        +-----------+       movement
                     +----------+
                     | MIPv6 MN |  ----------------->
                     +----------+       movement

                                 Figure 2 - Scenario B


   o  Scenario C - in this scenario the mobile node is moving across
      different access networks, some of them supporting Proxy Mobile
      IPv6 and some others not supporting it.  Therefore the mobile node
      is roaming from an access network where the mobility is managed
      through a network-based solution to an access network where a
      host-based management (i.e.  Mobile IPv6) is needed.  This
      scenario may have different sub-scenarios depending on the
      relations between the Mobile IPv6 home network and the Proxy
      Mobile IPv6 domain.  The following figure illustrates an example
      of this scenario, where the MN is moving from an access network
      where PMIPv6 is supported (i.e.  MAG functionality is supported)
      to a network where PMIPv6 is not supported (i.e.  MAG
      functionality is not supported by the AR): more details are
      described in section Section 4.

                              +--------+
                              | HA/LMA |
                              +--------+

             +-----+                              +----+
             | MAG |                              | AR |
             +-----+                              +----+

                     +----------+
                     | MIPv6 MN |  ----------------->
                     +----------+       movement

                           Figure 3 - Scenario C





Soliman & Giaretta      Expires October 26, 2007                [Page 6]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


4.  Scenarios and related issues

   In this section a more comprehensive description of the identified
   scenarios is presented.  Moreover, for each scenarios the possible
   issues are identified.  Note that, as mentioned before, some of these
   issues may be already solved in any of the PMIPv6 related internet
   drafts; however, the intent of this document is just to highlight the
   possible issues related to the identified scenarios, without going
   into solution space (at least for now), in order to get a complete
   picture of the possible interactions between PMIPv6 and MIPv6 and to
   understand which functionalities are needed from a protocol
   perspective.

4.1.  Scenario A - Hierarchical Mobility

   As described in Section 3, in this scenario PMIPv6 is used as a local
   mobility management protocol, while Mobile IPv6 is used to manage
   global mobility.  This means that the address handled by PMIPv6
   operations is the Care-of Address from a Mobile IPv6 perspective.

   Figure 4 shows the details of this scenario.  In figure (a) the
   mobile node has a Home Address and a Care-of Address (CoA_1) and is
   registered at the HA based on [RFC3775]; therefore there is a MIPv6
   tunnel between the HA and the MN.  Since the MN is attached at MAG1,
   there is a PMIPv6 tunnel between the LMA1 and the MAG1: the address
   managed by this tunnel is the CoA_1 of the MN.

                          +----+
                          | HA |   HoA -> CoA_1
                          +----+

        CoA_1 -> MAG_1       |
           +------+          .            +------+
           | LMA1 |          |            | LMA2 |
           +------+          .            +------+
                             |
                             |
    +------+      +------+   .
    | MAG1 |      | MAG2 |   |
    +------+      +------+   .
      ^                      |
      |                      |
      v                      .
    +----+                   |
    | MN |                   .
    +----+                   |
    HoA & CoA_1              .
                             |



Soliman & Giaretta      Expires October 26, 2007                [Page 7]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


                             .
    PMIPv6 Domain #1         |        PMIPv6 Domain #2

                            (a)



                          +----+
                          | HA |   HoA -> CoA_1
                          +----+

        CoA_1 -> MAG_2       |
           +------+          .            +------+
           | LMA1 |          |            | LMA2 |
           +------+          .            +------+
                             |
                             |
    +------+      +------+   .
    | MAG1 |      | MAG2 |   |
    +------+      +------+   .
                     ^       |
                     |       |
                     v       .
                  +----+     |
                  | MN |     .
                  +----+     |
                 HoA & CoA_1 .
                             |
                             .
    PMIPv6 Domain #1         |        PMIPv6 Domain #2

                            (b)

            Figure 4 - Local Mobility with PMIPv6


   Figure 4 (b) shows the MN attached at MAG2.  After the MN has moved
   to MAG2 link, based on PMIPv6 protocol operations, MAG2 sends a Proxy
   Binding Update to the LMA1 containing its own address and the address
   of the MN (i.e.  CoA_1).  The result of this registration is that the
   PMIPv6 tunnel is switched from MAG1 to MAG2 and therefore a tunnel
   between LMA1 and MAG2 is created.  Note that the MN has experienced a
   movement within the PMIPv6 Domain #1: this movement has not triggered
   any Mobile IPv6 operations, since the MN does not need to change its
   CoA_1 based on PMIPv6 operations.






Soliman & Giaretta      Expires October 26, 2007                [Page 8]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


   Figure 5 shows a global mobility scenario: the MN is moving across
   different PMIPv6 domains: in the new link, belonging to PMIPv6 domain
   #2, the MN configures a new CoA (i.e.  CoA_2) and sends a MIPv6
   Binding Update to the HA, updating its binding cache entry.  On the
   other hand, MAG3 sends a Proxy Binding Update to LMA2, creating a new
   PMIPv6 binding cache entry related to CoA_2.


                          +----+
                          | HA |   HoA -> CoA_2
                          +----+

                             |         CoA_2 -> MAG_3
           +------+          .            +------+
           | LMA1 |          |            | LMA2 |
           +------+          .            +------+
                             |
                             |
    +------+      +------+   .   +------+
    | MAG1 |      | MAG2 |   |   | MAG3 |
    +------+      +------+   .   +------+
                             |      ^
                             |      |
                             .      v
                             |    +----+
                             .    | MN |
                             |    +----+
                             .  HoA & CoA_2
                             |
                             .
    PMIPv6 Domain #1         |        PMIPv6 Domain #2


        Figure 5 - Global Mobility with Mobile IPv6


   This scenarios and the related sub-scenarios are very similar to any
   other hierarchical mobility scheme, including a HMIPv6-MIPv6 scheme.
   However, there are two main differences between the case when the
   local mobility is handled via a network-based scheme:

   o  if a host-based protocol is used, such as HMIPv6 [RFC4140], smooth
      transition can be achieved when handing off between two different
      LMM domains as the MN may keep the binding at the old MAP, while
      creating a binding with the new MAP and configuring a new Regional
      CoA.  In particular, the overlapping domains allow the MN to
      configure more than on RCoA and manage the tunnels between them,
      based on the mobility pattern and the MN's requirements.  This is



Soliman & Giaretta      Expires October 26, 2007                [Page 9]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


      surely more difficult if PMIPv6 is used, since when the MN gets a
      new address, it will swtch using that one (i.e. the usage of
      mutiple addresses in PMIPv6 seems more difficult than in a host-
      based mobility solution such as HMIPv6).

   o  if a host-based protocol is used for local mobility, race
      conditions cannot occur since the MN sends the MIPv6 Binding
      Update only when the Regional Care-of Address has been confirmed
      by the local anchor (e.g.  MAP).  This should occur also in the
      case the local mobility is handled by the network: the CoA should
      be confirmed to the MN only after a correct binding at the local
      anchor (i.e.  LMA) is created.  However, since the address
      allocation to the MN is not fully in the scope of PMIPv6 (i.e.
      MN-AR interface is system-specific), it may occur that the MN
      registers the CoA at the HA before the CoA is actually bound to
      the location of the MN (i.e.  MAG).  This seems only an issue in
      principle and it should occur very rarely, though.

   The following figures describe the details of the message flows for
   local and global mobility in this hierarchical scheme.

    +----+            +------+            +------+       +----+
    | MN |            | MAG2 |            | LMA1 |       | HA |
    +----+            +------+            +------+       +----+

                                                 +-----------------+
                                                 |  HoA -> CoA_1   |
                                                 | binding present |
                                                 +-----------------+

       CoA config/confirm   PBU(CoA_1,MAG_2)
       <---------------->  ------------------>
                                      +-----------------+
                                      | CoA_1 -> MAG_2  |
                                      | binding updated |
                                      +-----------------+
                                  PBA
                           <------------------

       Figure 6 - Local Mobility Message Flow (see Figure 4b)











Soliman & Giaretta      Expires October 26, 2007               [Page 10]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


    +----+            +------+            +------+       +----+
    | MN |            | MAG3 |            | LMA2 |       | HA |
    +----+            +------+            +------+       +----+

           CoA config        PBU(CoA_2,MAG_3)
       <---------------->  ------------------>
                                      +-----------------+
                                      | CoA_2 -> MAG_3  |
                                      | binding created |
                                      +-----------------+
                                  PBA
                           <------------------

                       BU (HoA, CoA_2)
       ---------------------------------------------------->

                                                 +-----------------+
                                                 |  HoA -> CoA_1   |
                                                 | binding updated |
                                                 +-----------------+
                           BA
       <----------------------------------------------------

        Figure 7 - Global Mobility Message Flow (see Figure 5)


   Based on the message flows of Figure 6 and Figure 7 and on the
   analysis presented above, there is not any issue in this scenario.
   The only possible issue is the race condition mentioned earlier but
   we have already stated that such an event should not occur if the
   entry in the LMA is created before the local address is confirmed to
   the MN.

4.2.  Scenario B - Two types of nodes in the network

   In this scenario there are two types of nodes in the access network:
   some nodes support Mobile IPv6 while some others do not.  The
   rationale behind such a scenario is that the nodes implementing
   Mobile IPv6 may prefer to manage their own mobility leveraging a
   host-based paradigm, in order for example to exploit some advantages
   of Mobile IPv6 protocol (e.g. route optimization support,
   confidentiality support for data packets between MN and HA).
   Obviously, nodes that do not implement MIPv6 must rely on the network
   to manage their mobility: therefore Proxy MIPv6 is used for those
   nodes.

   The issues with this scenario are related to the design of the MN-AR
   interface, that is out of scope of current NETLMM WG charter (even



Soliman & Giaretta      Expires October 26, 2007               [Page 11]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


   though there is an Informational RFC on this topic among the
   milestones).  However, it is worth discussing the possible issues
   introduced by this scenario in order to understand whether they can
   be solved at system level or have any impact on the choices in the
   PMIPv6 protocol design.

   Based on the current PMIPv6 solution described in
   draft-ietf-netlmm-proxymip6-00, in any link of the PMIPv6 domain the
   MAG emulates the mobile node's home link, advertising the home link
   prefix to the MN in a unicast Router Advertisement message.  This
   ensures that the IP address of the MN is still considered valid by
   the MN itself.  The home link prefix information (and any other
   information needed to emulate the home link) are included in the
   mobile node's profile that is obtained by the MAG via context
   transfer or via a policy store.

   However, in case there are nodes that implement Mobile IPv6 and want
   to use this protocol to manage their movements, the MAG should not
   emulate the home link.  Instead, a prefix specific of the access link
   should be advertised so that the MN detects an IP movement,
   configures a new CoA and sends a MIPv6 Binding Update based on
   [RFC3775].

   Therefore the MAG should somehow know that a MN is using MIPv6 in
   order to send the correct Router Advertisement.  A possible solution
   could be that this information is stored in the mobile node's
   profile; however, this approach is affected by some issues:

   o  Mobile IPv6 support on the terminal may not be an information that
      is available in the mobile node profile.  This is because MIPv6
      may be an additional software on a terminal, that can be installed
      or activated at any time.  Moreover,
      draft-ietf-netlmm-proxymip6-00 does not give enough information on
      what is the mobile node's profile and how is created (e.g. whether
      it is linked to the user's profile, whether it is created at the
      attach and how it is maintained).

   o  this approach implies that the access network must have a new
      functionality, since the Access Router must check the mobile
      node's profile even if the MN is using Mobile IPv6.  This does not
      follow the Mobile IPv6 assumption that the access network does not
      have any role in the procedures related to the change of the IP
      address.  Moreover, if context transfer is used to make the MAG
      aware of the mobile node's profile, a context transfer may be
      needed also for Mobile IPv6 nodes, but it is unclear how this
      context transfer should be triggered and performed.

   Solutions at the system level may be possible: for example, in the



Soliman & Giaretta      Expires October 26, 2007               [Page 12]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


   attach procedure to cellular networks, the mobile node usually
   exchanges a lot of information with the network about its
   capabilities and the support of Mobile IPv6 may be one of this
   information.  However, even in this case, the issues mentioned above
   apply.

   Based on the considerations in this section, there is therefore a
   clear need to define some mechanisms in order to manage the co-
   existence of nodes that use Mobile IPv6 and nodes that rely on Proxy
   Mobile IPv6.

4.3.  Scenario C - Movements between PMIPv6-enable and non PMIPv6-
      enabled access networks

   In this scenario the MN moves from one access network that supports
   Proxy MIPv6 to an access network that does not support PMIPv6.
   Therefore the mobility of the MN may be handled using Proxy MIPv6 in
   some access network, but must be also managed by Mobile IPv6 if the
   MN attaches to an access network that does not have any PMIPv6
   functionality.

   Two different sub-cases can be identified in this scenario:

   o  PMIPv6 is used to handle local mobility and the MN is moving from
      an access network that supports PMIPv6 to an access network that
      does not support PMIPv6, but the LMA is not co-located with the
      HA.  This means that Proxy Mobile IPv6 handles the Care-of Address
      of the MN, and that Mobile IPv6 is always used by the MN, either
      the MN is in an access network that supports Mobile IPv6 or it is
      in an access network with no PMIPv6 support.  This scenario is, as
      shown in the following figure, very similar to Scenario A and
      therefore does not imply any specific issue.



















Soliman & Giaretta      Expires October 26, 2007               [Page 13]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


                          +----+
                          | HA |   HoA -> CoA_1
                          +----+

    CoA_1 (prefix) -> MAG_2  |
           +------+          .
           | LMA1 |          |
           +------+          .
                             |
                             |
    +------+      +------+   .     +----+
    | MAG1 |      | MAG2 |   |     | AR |
    +------+      +------+   .     +----+
                     ^       |
                     |       |
                     v       .
                  +----+     |
                  | MN |     .
                  +----+     |
                 HoA & CoA_1 .
                             .
       PMIPv6 Domain         |

                            (a)



























Soliman & Giaretta      Expires October 26, 2007               [Page 14]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


                          +----+
                          | HA |   HoA -> CoA_2
                          +----+

                             |
           +------+          .
           | LMA1 |          |
           +------+          .
                             |
                             |
    +------+      +------+   .     +----+
    | MAG1 |      | MAG2 |   |     | AR |
    +------+      +------+   .     +----+
                             |        ^
                             |        |
                             .        v
                             |      +----+
                             .      | MN |
                             |      +----+
                             .     HoA & CoA_2
                             |
                             .
       PMIPv6 Domain         |

                            (b)

   Figure 8 - Mobility between a PMIPv6 domain and a non-PMIPv6 domain


   o  the home subnet is a PMIPv6 domain and the MN moves from its home
      subnet to a different link.  This is the scenario where the LMA is
      managing the same address managed by the HA; note that in this
      case PMIPv6 manages the Mobile IPv6 HoA.  The following figure
      illustrates this scenario.

















Soliman & Giaretta      Expires October 26, 2007               [Page 15]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


                +--------+
                | HA/LMA |   HoA (Home Prefix) -> MAG_1
                +--------+

                    |
      +------+      .     +----+
      | MAG1 |      |     | AR |
      +------+      .     +----+
          ^         |
          |         |
          v         .
        +----+      |
        | MN |      .
        +----+      |
         HoA        .
                    |
    PMIPv6 Domain
     (emulated
      home link)
                   (a)



                +--------+
                | HA/LMA |   HoA -> CoA_1
                +--------+

                    |
      +------+      .     +----+
      | MAG1 |      |     | AR |
      +------+      .     +----+
                    |       ^
                    |       |
                    .       v
                    |      +----+
                    .      | MN |
                    |      +----+
                    .   HoA & CoA_1
                    |
    PMIPv6 Domain
     (emulated
      home link)
                   (b)

   Figure 9 - Mobility between a PMIPv6 domain and a non-PMIPv6 domain


   The scenario described in Figure 8 (a and b) is very similar to the



Soliman & Giaretta      Expires October 26, 2007               [Page 16]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


   scenario A. This is because PMIPv6 is used to manage the CoA and has
   no visibility of the HoA.  Note that this applies also if LMA and HA
   are co-located in the same box, as long as PMIPv6 is used only to
   manage the Care-of Address mobility.  For this reason, in the rest of
   this sub-section we will concentrate on the scenario in Figure 9a and
   9b.

   In Figure 9a, the mobility of the MN is managed by the network
   through Proxy Mobile IPv6: the node acting as LMA has a proxy binding
   cache entry with the tuple (Home Prefix, MAG_1, MN_ID).  The Mobile
   Node is "at home" from a Mobile IPv6 perspective and therefore uses
   directly its Home Address for new and existing communications.  In
   case the MN moves within the PMIPv6 domain, PMIPv6 is triggered, a
   new MAG registers the home prefix of the MN at the LMA and the MN's
   home prefix is advertised to the MN so that the HoA can still be
   considered valid.  Note that this implies that the PMIPv6 domain
   coincides with the home network from a MIPv6 perspective: while the
   MN is roaming in the PMIPv6 domain, the MN can use the Home Address
   to exchange packets without any need of tunneling.  Downlink packets
   are tunneled to the MAG, but tunnel over the wireless link is avoided
   in this way.

   In Figure 9b, the MN has moved to an access network that does not
   have any support for Proxy Mobile IPv6.  In this case the MN receives
   a Router Advertisement message containing a different IPv6 prefix
   than its home prefix and therefore it detects a movement at the IP-
   layer level.  Based on that, the MN configures a new CoA and sends a
   Binding Update to the HA (i.e. the LMA) with the couple (HoA, CoA).

   Several possible issues are present in this scenario (direction of
   movement from the PMIPv6 domain to the non-PMIPv6 access network):

   o  HoA management and lookup key in the binding cache

      *  in MIPv6 [RFC3775] the lookup key in the Binding Cache is the
         Home Address of the MN.  In particular, based on the base
         specification [RFC3775], the MN does not include any
         identifier, such as the MN-ID [RFC4283], in the Binding Update
         message other than its Home Address.

      *  as specified in draft-netlmm-pmip6 [], a Proxy Binding Update
         contains the Home Prefix of the MN, the MN-ID and may not
         include the Home Address of the MN (since it may not be known
         by the MAG and consequently by the HA/LMA).  The lookup key in
         the binding cache of the LMA is either the home prefix or the
         MN-ID.





Soliman & Giaretta      Expires October 26, 2007               [Page 17]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


      *  this implies that lookup keys for MIPv6 and PMIPv6
         registrations are different.  Because of that, when the MN
         moves from its home network (i.e. from the PMIPv6 domain) to
         the foreign link, the Binding Update sent by the MN is not
         identified by the HA as an update of the Proxy Binding Cache
         Entry containing the home prefix of the MN, but a new binding
         cache entry is created.

      *  based on above bullets, there is an "unused" (proxy) binding
         cache entry in the Binding Cache of the LMA/HA.  Note that, if
         HA runs a longest-prefix-matching algorithm in order to tunnel
         downlink packets to the MN, packets destined to the HoA are
         anyway delivered correctly.

   o  Sequence Numbers and Timestamps

      *  in MIPv6 Sequence Numbers are used for message identification
         and replay protection.  In the latest PMIPv6 draft [],
         timestamps are used instead since the new MAG may not know the
         Sequence Number used in the last PBU.

      *  this implies that there are two different mechanisms for packet
         identification and replay protection; in the case of Figure 9b,
         the HA will receive a Binding Update from the MN that will
         modify a proxy binding cache entry that is identified by the
         timestamp.

      *  a specification of how the HA/LMA behaves in this case and how
         it processes BUs/PBUs with different identification mechanisms
         seem needed.

   o  Threat of compromised MAG

      *  in MIPv6 base specification [RFC3775] there is a strong binding
         between the Home Address registered by the MN and the Security
         Association used to modify the corresponding binding cache
         entry.

      *  in PMIPv6 specification different Security Associations are
         used to update the same entry related to a MN since a per-MAG
         Security Association model is adopted.

      *  in this mixed scenario, both host-based and network-based
         security associations are used to update the same binding cache
         entry at the HA/LMA (but see the first bullet of this list, as
         the entry may not be the same).





Soliman & Giaretta      Expires October 26, 2007               [Page 18]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


      *  based on this consideration, a compromised MAG can send a bogus
         Proxy BU to the HA/LMA even when the Mobile Node is not in the
         PMIPv6 domain, since the MAG is in the MIPv6 "home" domain.
         This introduces third part traffic stealing and reflection
         attacks, effectively bypassing MIPv6 security.  Those two
         attacks are not acceptable on the Internet and are avoided in
         MIPv6.

      *  note that the same issue applies in a simple PMIPv6 scenario;
         however, in the mixed scenario described in Figure 8, this is
         not possible, since the MAG is managing only the CoA of the MN
         and not the HoA.  Therefore, if PMIPv6 is used to handle the
         HoA mobility, the security of Mobile IPv6 is lowered to the
         PMIPv6 security.  This is not true if PMIPv6 is used together
         with MIPv6 but only to handle the CoA.

   In case the MN is returning home (i.e.moving into the PMIPv6 domain),
   several other considerations apply:

   o  HoA management and lookup key in the binding cache

      *  in MIPv6 [RFC3775], de-registration is recommended (but not
         mandatory).  This implies that the MN receives a Router
         Advertisement with the home prefix, starts using its HoA
         directly, without tunneling uplink packets but may not send a
         Binding Update to remove the binding cache entry related to the
         HoA.

      *  based on the same considerations made in the previous case, the
         PBU sent by the MAG will not update the Binding Cache entry
         related to the HoA, but more probably will create a new proxy
         binding cache entry including the home prefix of the MN, the
         MN-ID and the MAG address.

      *  this implies that, in case the MN does not send a de-
         registration binding update when returning home, the downlink
         packets may still be tunneled to the CoA and not to the MAG.

   o  Race condition in the registration from MAG and de-registration of
      the MN

      *  even though the MN sends a de-registration Binding Update, for
         example including a MN-ID in order that PBUs and BUs update the
         same binding cache entry (note however that this is not
         possible based on [RFC3775]), a race condition may happen if
         the de-registration BU sent from the MN is received by the HA
         after the PBU sent by the MAG.  In this case the BU from the MN
         will delete the entry created/updated by the MAG and therefore



Soliman & Giaretta      Expires October 26, 2007               [Page 19]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


         downlink packets will not be correctly routed to the MN.

   o  Sequence Numbers and Timestamps

      *  the same considerations done for the handover from the PMIPv6
         domain to the non-PMIPv6 access network applies also in this
         direction.

   As a general issue, this scenario contradicts with the scope of
   PMIPV6.  The NETLMM WG is chartered to produce a protocol to handle
   network-based local mobility management.  In the context of MIPv6,
   the main distinction between a local mobility management protocol and
   a global one is that former manages the changes in a CoA within a
   local domain and the latter manages the changes in the CoA globally.
   While the protocol itself may allow both types of mobility management
   with minimal change, there is a significant difference in terms of
   the security requirements, stability of an address and the relevant
   policies associated with such identifier.  A change in the context of
   the protocol would result in subtle violations of these issues, which
   can introduce significant security issues that do not exist in MIPv6.


5.  Conclusion

   The analysis provided in this document shows that PMIPv6 can be used
   for local mobility management when MIPv6 is used to handle global
   mobility.  No significant issues have been identified for such a
   scenario.  Note that this is the main scenario the NETLMM WG was
   chartered for rfc4830.

   Some issues have been identified in the two other scenarios
   considered.  Concerning scenario B (contemporary co-existence of
   MIPv6 and non-MIPv6 nodes), a method to allow MIPv6 nodes to use
   host-based mobility is needed: this implies that within a PMIPv6
   domain the MAG must be able to emulate the home network for some
   nodes and advertise link-specific prefixes for other nodes.

   Concerning scenario C, several issues have been identified, related
   to possible race conditions, the way the binding cache entries are
   identified at the HA and security threats.  It seems that the
   implementation of this scenario requires some additional capabilities
   from the MN, that cannot implement only MIPv6 base specification
   [RFC3775].


6.  IANA Considerations

   This document makes no request of IANA.



Soliman & Giaretta      Expires October 26, 2007               [Page 20]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


7.  Security Considerations

   The co-existence between PMIPv6 and MIPv6 is possible in some
   scenarios.  Essentially, such co-existence is seamless when PMIPv6 is
   restricted to the mobility management of the CoA.  However, the use
   of PMIPv6 for managing the home address introduces a number of
   security issues.

   Mobile IPv6 assumes a particular trust relationship between the MN
   and the HoA.  For instance, a MN does not do a CoA test when
   registering its home address.  The assumption here is that the HoA
   can trace a MN if it's reported as "misbehaving" (e.g. if it floods
   other nodes by registering a fake CoA).  The same assumption is not
   necessarily true for every local HA/MAP/LMA that a mobile node
   happens to be associated with.  Therefore, if an LMA is passed the
   MN's HoA to emulate a home link for a roaming node, there is a subtle
   violation of the security assumptions.

   A more significant violation of security policy can occur if a MAG is
   compromised while managing the mobility of the home address.  A
   compromised MAG can launch off-path attacks to steal or redirect the
   mobile node's traffic.  This situation is not possible in MIPv6
   unless an attacker can break the IPsec SA between the MN and the HA,
   which is an unlikely scenario.

   Hence, changing the end points for the signalling, while almost
   seamless to the actual protocol, can cause significant unintended
   consequences.  For this reason, and others, it is strongly
   recommended that PMIPv6 is only used to manage a local address and
   limit any potential attacks to the scope of the local domain.


8.  Acknowledgements

   The authors would like to thank Vidya Narayanan, Patrick Stupar and
   Stefano Faccin for their valuable comments.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.




Soliman & Giaretta      Expires October 26, 2007               [Page 21]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


   [RFC3776]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
              Protect Mobile IPv6 Signaling Between Mobile Nodes and
              Home Agents", RFC 3776, June 2004.

9.2.  Informative References

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

   [RFC4140]  Soliman, H., Castelluccia, C., El Malki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 Mobility Management
              (HMIPv6)", RFC 4140, August 2005.

   [RFC4283]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
              Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
              (MIPv6)", RFC 4283, November 2005.

   [RFC4285]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
              Chowdhury, "Authentication Protocol for Mobile IPv6",
              RFC 4285, January 2006.


Authors' Addresses

   Hesham Soliman
   Elevate Technologies

   Email: Hesham@elevatemobile.com



   Gerardo Giaretta (editor)

   Email: gerardo.giaretta@gmail.com











Soliman & Giaretta      Expires October 26, 2007               [Page 22]

Internet-Draft          PMIPv6-MIPv6 Interactions             April 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Soliman & Giaretta      Expires October 26, 2007               [Page 23]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/