NETLMM Working Group                                    G. Giaretta, Ed.
Internet-Draft                                                  Qualcomm
Intended status: Informational                          October 24,                         November 15, 2008
Expires: April 27, May 19, 2009

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

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 April 27, May 19, 2009.

Abstract

   The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6
   (MIPv6) protocols interact with each other need special
   considerations.  An analysis of all the scenarios that involve this
   interaction is necessary are both deployed in order to provide guidelines to PMIPv6
   protocol design a network require some
   analysis and applicability. considerations.  This document describes all identified
   possible scenarios, which require an interaction between PMIPv6 and
   MIPv6 and discusses all issues related to these scenarios.  Solutions
   and reccomendations to enable these scenarios are also described.

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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview of the scenarios and related issues . . . . . . . . .  4
     3.1.  Issues related to scenario A . . . . . . . . . . . . . . .  9
     3.2.  Issues related to scenario B . . . . . . . . . . . . . . .  9
     3.3.  Issues related to scenario C . . . . . . . . . . . . . . . 10
   4.  Analysis of possible solutions . . . . . . . . . . . . . . . . 13 12
     4.1.  Solutions related to scenario A  . . . . . . . . . . . . . 13 12
     4.2.  Solutoins  Solutions related to scenario B  . . . . . . . . . . . . . 14
     4.3.  Solutions related to scenario C  . . . . . . . . . . . . . 14
       4.3.1.  Mobility from a PMIPv6 domain to a non-PMIPv6
               domain . . . . . . . . . . . . . . . . . . . . . . . . 15
       4.3.2.  Mobility from a non-PMIPv6 domain to a PMIPv6
               domain . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   6.  Additional Authors . . . . . . . . . . . . . . . . . . . . . . 18 17
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 19 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 20

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 [RFC5213] has been designated as the network-based localized mobility
   management protocol.

   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 network based protocol developed
   in IETF; it is therefore worth investigating
   standardized by IETF.  In many deployment scenarios this protocol
   will be deployed together with MIPv6 [RFC3775], for example with
   PMIPv6 as local mobility protocol and MIPv6 as global mobility
   protocol.  While the details usage of a hierarchical mobility scheme where Proxy Mobile IPv6 is used for local mobility and Mobile IPv6 is used for protocol should not
   have implications of how global mobility.

   The second reason mobility is that Proxy Mobile IPv6 has been chosen by managed, since PMIPv6 is
   partially based on MIPv6 signaling and data structure, some
   considerations are needed to understand how the
   NETLMM WG mainly for reusability grounds protocols interact
   and a MIPv6 home agent how the different scenarios can be extended to handle PMIPv6. enabled.

   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 use Mobile IPv6; or the mobility of a node is managed in
   turn by a host-based and a network-based mechanism.  This needs also
   to be analyzed as a possible deployment scenario.

   This document provides a taxonomy of all scenarios that require
   direct interaction between MIPv6 and PMIPv6.  Moreover, this document
   presents and identifies all known issues pertained to these scenarios
   and discusses possible means and mechanisms that may be required are recommended to
   enable them.

2.  Terminology

   General mobility terminology can be found in [RFC3753].  The
   following acronyms are used in this document:

      MN-HoA: the home address of a mobile node in a Proxy Mobile IPv6
      domain.

      MN-HNP: the IPv6 prefix that is always present in the Router
      Advertisements that the mobile node receives when it is attached
      to any of the access links in that Proxy Mobile IPv6 domain.  MN-
      HoA always belongs to this prefix.

      MIPv6-HoA: the Home Address the MN includes in MIPv6 binding
      update messages.  Based on the scenario, MIPv6-HoA and MN-HoA may
      be the same or different.

      MIPv6-CoA: the Care-of Address the MN includes in MIPv6 binding
      update messages.  Based on the scenario, MIPv6-HoA and MN-HoA may
      be the same or different.

3.  Overview of the scenarios and related issues

   Several scenarios can be identified where Mobile IPv6 and Proxy
   Mobile IPv6 are used deployed in the same network.  This document does not
   only focus on scenarios where the two protocols are used by the same
   mobile node to manage local and global mobility, but it investigates
   also more complex scenarios where the protocols are more tightly integrated
   or where there is a co-existence of nodes which do or do not
   implement Mobile IPv6.

   The following scenarios were are identified:

   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 address managed by PMIPv6 (i.e. the MN-
      HoA based on PMIPv6 terminology) is registered as Care-of Address
      by the MN at the HA.  This means that the HA has a binding cache
      entry for MIPv6-HoA that points to the MN-HoA.

      The following figure illustrates this scenario.

                           +----+
                           | HA |  MIPv6-HoA -> MN-HoA
                           +----+
                             /\
                            /  \
             +-------------/----\--------------+
            (             /      \              ) Global Mobile IPv6
            (            /        \             ) Domain
             +----------/----------\-----------+
                       /            \
                    +----+         +----+
    MN-HoA -> MAG1  |LMA1|         |LMA2|
                    +----+         +----+
                     //\\             \\
               +----//--\\---+   +-----\\------+
              (    //    \\   ) (       \\      ) Local Mobility Network
              (   //      \\  ) (        \\     ) PMIPv6 domain
               +-//--------\\+   +--------\\---+
                //          \\             \\
               //            \\             \\
              //              \\             \\
           +----+           +----+         +----+
           |MAG1|           |MAG2|         |MAG3|
           +----+           +----+         +----+
             |                |              |
            [MN]

                                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 may be a common
      mobility anchor that acts as Mobile IPv6 Home Agent and Proxy
      Mobile IPv6 LMA, depending on the type of the node. node as depicted in
      the figure.  However, the LMA and HA can be also separated and
      this has no impacts to the mobility of the nodes.

                                  +--------+
                                  | 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).  This implies that the
      home link of the MN is actually a PMIPv6 domain.  In this case the
      MIPv6-HoA is equal to the MN-HoA (i.e. the address managed by
      PMIPv6).

              MIPv6-HoA == MN-HoA -> MAG1
                    +------+
                    |HA/LMA|-----------------------+
                    +------+                       |
                      //\\                         |
             +-------//--\\--------+               |
            (       //    \\ PMIPv6 )              |
            (      //      \\ domain)       +--------------+
             +----//--------\\-----+       (   Non-PMIPv6   )
                 //          \\            (   domain       )
                //            \\            +--------------+
               //              \\                  |
            +----+           +----+              +----+
            |MAG1|           |MAG2|              | AR |
            +----+           +----+              +----+
              |                |                   |
             [MN]

                           Figure 3 - Scenario C

      In the above figure the non-PMIPv6 domain can actually be also a
      different PMIPv6 domain that handles a different MN_HoA.  The
      following figure illustrates this sub-case: the MIPv6-HoA is equal
      to the MN_HoA; however when the MN hands over to MAG3 it gets a
      different IP address (managed by LMA2 using PMIPv6) and registers
      it as a MIPv6 CoA.

             MIPv6-HoA == MN-HoA -> MAG_1
                     +-------+
                     |HA/LMA1|-----------------------+
                     +-------+                       |
                       //\\                       +----+
              +-------//--\\--------+             |LMA2|
             (       //    \\  home  )            +----+
             (      //      \\ PMIPv6)       +------||------+
             (     //        \\domain)      (       ||visited)
              +---//----------\\----+       (       ||PMIPv6 )
                 //            \\           (       ||domain )
                //              \\           +------||------+
             +----+           +----+              +----+
             |MAG1|           |MAG2|              |MAG3|
             +----+           +----+              +----+
               |                |                   |
              [MN]

                               (a)

              MIPv6-HoA -> MN_CoA
                     +-------+
                     |HA/LMA1|-----------------------+
                     +-------+                       |
                       //\\                       +----+
              +-------//--\\--------+             |LMA2|  MN_CoA -> MAG3
             (       //    \\  home  )            +----+
             (      //      \\ PMIPv6)       +------||------+
             (     //        \\domain)      (       ||visited)
              +---//----------\\----+       (       ||PMIPv6 )
                 //            \\           (       ||domain )
                //              \\           +------||------+
             +----+           +----+              +----+
             |MAG1|           |MAG2|              |MAG3|
             +----+           +----+              +----+
               |                |                   |
                                                   [MN]

                                (b)

         Figure 4 - Scenario C with visited PMIPv6 domain

   Note that some of the scenarios can be combined.  For instance,
   scenario B can be combined with scenario A or scenario C.

   The following sections describe some possible issues for each
   scenario.  Note that the issues are described based on current
   specification and does not assume any optimized solution for any
   scenario.  The specifications considered as a baseline for the
   analysis are the following: [RFC3775], [RFC4877] and [RFC5213].  For
   example, the collocation of HA and LMA are considered as the
   combination of HA according [RFC3775] and LMA according to [RFC5213],
   e.g. no combined binding caches are considered.  The analysis of the
   collocated HA and LMA would show what is the preferred behaviour for
   this entity.  The behaviour and respective recommendations are
   described in Section 4.3.

3.1.  Issues related to scenario A

   This scenarios is very similar to other hierarchical mobility
   schemes, including a HMIPv6-MIPv6 scheme.  This is the scenario
   referenced in [RFC4830].  No issues have been identified in this
   scenario.  Note that a race condition where the MN registers the CoA
   at the HA before the CoA is actually bound to the MAG at the LMA is
   not possible.  The reason is that per PMIPv6 specification the MAG
   does not forward any packets sent by the MN until the PMIPv6 tunnel
   is up, regardless the mechanism used for address allocation.

   Section 4.1 describes one message flow in case PMIPv6 is used as a
   local mobility protocol and MIPv6 is used as a global mobility
   protocol.

3.2.  Issues related to scenario B

   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 or be configured to manage their own mobility. mobility
   to achieve better performance, e.g. for inter-technology handovers.
   Obviously, nodes that do not implement MIPv6 must rely on the network
   to manage their mobility: therefore Proxy MIPv6 is used for those
   nodes.

   Based on the current PMIPv6 solution described in [RFC5213], 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 network prefix
   (and any other information needed to emulate the home link) is
   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, the network must offer MIPv6 service to them.

   In such case the MAG should not emulate the home link.  Instead of
   advertising the HNP, the MAG should advertise the topologically
   correct local IP prefix, i.e. the prefix belonging to the MAG, so
   that the MN detects an IP movement, configures a new CoA and sends a
   MIPv6 Binding Update based on [RFC3775].

3.3.  Issues related to scenario C

   Some issues

   This section highlights some considerations that are present in this scenario: applicable to
   scenario C and need to be evaluated when selecting the technical
   approach to be chosen.

   1.  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 described in
          [RFC4877], the identifier of the MN is known by the Home Agent
          after the IKEv2 exchange, but this is not used in the MIPv6
          signaling, nor as a lookup key for the binding cache.  On the
          other hand, as specified in [RFC5213], a Proxy Binding Update
          contains the Home Prefix of the MN, the MN-ID and does 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.  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 these considerations, there
          is an "unused" (proxy)  Therefore PMIPv6 and MIPv6 will
          always create two different binding cache entry entries in the Binding
          Cache of the LMA/HA.  Note that the assumption in this section
          is that the binding caches of the HA/
          LMA and which implies that the HA are different and there is not any combined binding cache.  The need of such
          a combined binding cache will be discussed in Section 4.3.

       *  When the MN returns LMA are logically separated.
          How to handle the MIPv6 home link that is also a
          PMIPv6 domain, it de-registers to remove presence of the two binding cache
          entry it had created.  However in [RFC3775], de-registration
          is recommended (but not mandatory).  This implies that entries
          for the same MN
          receives a Router Advertisement with the home prefix, may
          start 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.  In case the de-registration BU is
          not sent, the PBU sent by the MAG will not update the Binding
          Cache entry related to the HoA, but 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, described 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. Section 4.3.

   2.  MIPv6 de-registration Binding Update deletes PMIPv6 binding cache
       entry

       *  When the mobile node moves from a MIPv6 foreign network to the
          PMIPv6 home domain, the MAG registers the mobile node at the
          LMA by sending a Proxy Binding Update.  Subsequently, the LMA
          updates the mobile node's binding cache entry with the MAG
          address and the MAG emulates the mobile node's home link.
          Upon detection of the home link, the mobile node will send a
          de-registration Binding Update to its home agent.  According  It is
          necessary to RFC3775, the home agent would delete the binding cache
          entry after accepting make sure that the de-registration Binding Update,
          i.e., it would delete of the proxy binding cache entry that was MIPv6
          BU does not change the PMIPv6 BCE just established created by the MAG.  Hence, packets arriving at the
          LMA and destined for the mobile node would not be forwarded to
          the mobile node anymore.

   3.  Race condition between Binding Update

   3.  Race condition between Binding Update and Proxy Binding Update
       messages (Sequence Numbers and Timestamps)

       *  MIPv6 and PMIPv6 use different mechanisms for handling re-
          ordering of registration messages and they are sent by
          different entities.  Whereas Binding Update messages are
          ordered by a sequence numbers and sent by the mobile node,
          Proxy Binding Update messages are ordered by a timestamp
          option and sent by MAGs.

       *  Assuming MAGs.Assuming the mobile node's MAG sends a
          Proxy Binding Update message (for refreshing the mobile node's
          BCE or because the mobile node has just done a handover to
          this MAG) and shortly thereafter the mobile node moves out of
          the PMIP home domain, where it configures a new MIPv6-CoA and
          sends a Binding Update message to its home agent.  If now the
          Proxy Binding Update message from the MAG is delayed so that
          it reaches the LMA after the Binding Update, the binding cache
          entry at the LMA would wrongly point to the MAG.  Without
          further measures, it is not clear if packets are not forwarded to
          the mobile node unless a new
          Binding Update is sent by the mobile node.  This may result in
          a significant packet loss.  A similar situation can occur if or not and for this reason the mobile node sends a Binding Update messsage from outside behavior of the PMIP home domain
          HA/LMA needs to be clarified in case there are two BCEs, one
          PMIPv6 and shortly thereafter enters one MIPv6 BCE, for the PMIP
          home domai same MN.

   4.  Use of wrong home agent or LMA after handover

       *  This issues can arise if multiple LMAs are deployed in the
          PMIP home domain.  If the mobile node moves from a MIPv6
          foreign network to the PMIP home domain, the MAG must send the
          Proxy Binding Update to the particular LMA that is co-located
          with the home agent which maintains the active binding cache
          entry of the mobile node.  If a different LMA is assigned to
          the MAG, packets addressed to the mobile node's home address
          do MN will not reach be on the mobile node anymore. home link but will still
          have MIPv6 active and this may be not desirable in some
          deployments.

       *  Similarly, if the mobile node moves from the PMIP home domain
          to a MIPv6 foreign network, the mobile node must send the
          Binding Update to the particular home agent that is co-located
          with the LMA which maintains the active proxy binding cache
          entry of the mobile node.  If the mobile node selects a
          different home agent, packets addressed to the mobile node's
          home address do not reach the mobile node.

   5.  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, the MAG sends proxy binding updates
          on behalf of a mobile node to update the binding cache entry
          that corresponds to the mobile node's home address.  Since the
          MAG sends the binding updates, PMIPv6 requires security
          associations between each MAG and the LMA.

       *  As described in [RFC4832], in PMIPv6 the MAG compromise or
          impersonation is an issue.  RFC4832, section 2.2, describes
          how a compromised MAG can harm the functionality of LMA, e.g.
          manipulating LMA's routing table (or binging cache).

       *  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).  Based on this
          consideration, the threat described in [RFC4832] is worse as
          it affects also hosts that are using the LMA/HA as MIPv6 HA
          and are not using PMIPv6

4.  Analysis of possible solutions

4.1.  Solutions related to scenario A

   As mentioned in Section 3.1, there are no significant issues in this
   scenario.

   Figures 5 and 6 show a scenario where a MN is moving from one PMIPv6
   domain to another, based on the scenario of Figure 1.  In Figure 5,
   the MN moves from an old MAG to MAG2 in the same PMIPv6 domain: this
   movement triggers a PBU to LMA1 and the updating of the binding cache
   at the LMA1; there is no MIPv6 signaling as the CoA_1 registered at
   the HA is the Home Address for the PMIPv6 session.  In Figure 6, the
   MN moves from MAG2 in the LMA1 PMIPv6 domain to MAG3 in a different
   PMIPv6 domain: this triggers the PMIPv6 signaling and the creation of
   a binding at the LMA2.  On the other hand, the local address of the
   MN is changed, as the LMA hss changed, and therefore the MN sends a
   MIPv6 Binding Update to the HA with the new CoA_2.

    +----+            +------+            +------+       +----+
    | MN |            | MAG2 |            | LMA1 |       | HA |
    +----+            +------+            +------+       +----+
      |                  |                    |            |
      |                  |                    |   +-----------------+
      |                  |                    |   |  HoA -> CoA_1   |
      |                  |                    |   | binding present |
      |                  |                    |   +-----------------+
      |                  |                    |            |
      | CoA conf/confirm |  PBU(CoA_1,MAG_2)  |            |
      | <--------------->|  ----------------->|            |
      |                  |              +-----------------+|
      |                  |              | CoA_1 -> MAG_2  ||
      |                  |              | binding updated ||
      |                  |              +-----------------+|
      |                  |          PBA       |            |
      |                  |   <----------------|            |
      |                  |                    |            |

       Figure 5 - Local Mobility Message Flow

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

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

        Figure 6 - Global Mobility Message Flow

4.2.  Solutoins  Solutions related to scenario B

   The solution for this scenario may depend on the access network being
   able to determine that a particular mobile node wants to use Mobile
   IPv6.  This would require a solution at the system level for the
   access network and is out of scope of this document.  Solutions that
   do not depend on the access network are out of the scope of this
   document.

4.3.  Solutions related to scenario C

   As described in Section 3.3, in this scenario the mobile node relies
   on Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6
   domain.  The mobile node then uses Mobile IPv6 whenever it moves out
   of the PMIPv6 domain.

   This section provides an analysis of domain which basically implies that the solutions for MIPv6 home link
   is a PMIPv6 domain.

   Analyzing the issues described in Section 3.3.  The analysis 3.3, it is performed in two different
   subsections, depending if the MN moves from a PMIPv6 domain clear that most
   of them are applicable only to a non-
   PMIPv6 domain or vice versa.

   NOTE: The NETLMM WG the case where there is still discussing a common BCE
   for the best approach to deal
   with this scenario, both in IETF meetings PMIPv6 registration and the MIPv6 registration.  The issue on
   how the NETLMM WG
   mailing list.  Current discussions are about handling this scenario
   with two protocols identify the same vs. separate BCEs and on BCE is valid only in case we
   assume that a PMIPv6 message has any value for a MIPv6 BCE.  If the external behavior of
   two different BCEs are considered completely independent, then the
   HA.
   issues described in Section 3.3 are not valid.  For this reason, the analysis provided in this draft it
   is to be
   considered tentative and recommended that when the draft will be updated MIPv6 home link is implemented as soon a
   PMIPv6 domain, the HA/LMA implementation treats the two protocol as
   independent.

   More in details the
   NETLMM WG following principles should be followed by the
   HA/LMA implementation:

   o  PMIPv6 signaling does not overwrite any MIPv6 BCE.  In particular,
      when a PMIPv6 binding cache entry is created for a MN which has decided
      previously created a MIPv6 BCE, the MIPv6 BCE of the UE is not
      overwritten and a new PMIPv6 BCE is created.

   o  The downlink packets in the case where both the MIPv6 BCE and
      PMIPv6 BCE exist are processed as follows:

   o

      1.  1) The MIPv6 BCE is processed first.  If the destination
          address of the received downlink packet matches the the BCE of
          the HA, the packet is forwarded by encapsulating it with the
          care-of-address contained in the BCE.

      2.  2) If the destination address does not match the MIPv6 BCE,
          the BCE created by PMIPv6 is applied and the packet are
          encapsualted to the registered MAG.

   The following subsections provide a description of the procedures
   which will be followed by the MN and HA/LMA based on the way forward. above
   principles.  The analysis is performed in two different subsections,
   depending if the MN moves from a PMIPv6 domain to a non-PMIPv6 domain
   or vice versa.

4.3.1.  Mobility from a PMIPv6 domain to a non-PMIPv6 domain

   Let's assume the MN is attached to a PMIPv6 domain and there is a
   valid Proxy Binding Cache entry at the LMA.  Then the MN moves to a
   adifferent
   different access network and starts using MIPv6 (e.g. because PMIPv6
   is not supported).  The MN needs to bootstrap MIPv6 parameters and
   send a MIPv6 Binding Update in order to have service continuity.
   Therefore the following steps must be performed by the UE:

   o  HA/LMA address discovery: the MN needs to discover the IP address
      of the LMA which has a valid binding cache entry for its home
      network prefix.  This is described in Section 3.3 as issue 4.

   o  Security Association establishment: the MN needs to establish an
      IPsec Security Association with the HA/LMA as described in
      [RFC4877]

   o  HoA or home network prefix assignment: as part of the MIPv6
      bootstrapping procedure the HA assigns a MIPv6 HoA to the MN.
      This address must be the same the MN was using in the PMIPv6
      domain.

   Since all these steps must be performed by the MN before sending the
   Binding Update, they have an impact on the handover latency
   experienced by the MN.  For this reason it is recommended that the MN
   establishes the IPsec security association (and consequently is
   provided by the HA/LMA with a MIPv6-HoA) when it is still attached to
   the PMIPv6 domain.  This implies that the mobile node has Mobile IPv6
   stack active while in the PMIPv6 domain, but as long as it is
   attached to the same Proxy Mobile IPv6 domain, it will appear to the
   mobile node as if it is attached to the home link.

   In order to establish the security association with the HA/LMA, the
   MN needs to discover the IP address of the LMA/HA while in the PMIPv6
   domain.  This can be done either based on DNS or based on DHCPv6, as
   described in [RFC5026] and [boot-integrated].  The network should be
   configured so that the MN discovers or gets assigned the same HA/LMA
   that was serving as the LMA in the PMIPv6 domain.  Details of the
   exact procedure are out of scope of this document.

   When the MN establishes the security association, it pacquires acquires a home
   address based on [RFC5026].  However, based on PMIPv6 operations, the
   LMA knows only the Home Network Prefix used by the MN and does not
   know the MN-HoA.For this reason, the MN must be configured to propose
   MN-HoA as the home address in the IKEv2 INTERNAL_IP6_ADDRESS
   attribute during the IKEv2 exchange with the HA/LMA.  Alternatively
   the HA/LMA can be configured to provide the entire Home Network
   Prefix via the MIP6_HOME_LINK attribute to the MN as specified in
   [RFC5026]; based on this Home Network Prefix the MN can configure a
   home address.  Note that the security association must be bound to
   the MN-HoA used in the PMIPv6 domain as per [RFC4877].  Note that the
   home network prefix is shared between the LMA and HA and this implies
   that there is an interaction between the LMA and the HA in order to
   assign a common home netowkr prefix when triggered by PMIPv6 and
   MIPv6 signaling

   When the MN hands over to an access network which does not support
   Proxy Mobile IPv6, it sends a Binding Update to the HA/LMA.  The
   LMA/HA must match the HoA with the MN-ID and update the respective
   BCE accordingly.  This is because the proxy HA.  A MIPv6 BCE
   is associated to the
   MN-ID and MN-HNP and not to created irrespective of the MN-HoA.  Note that this implies a
   change in existing PMIPv6 BCE.  Packets matching
   the BU processing if compared MIPv6 BCE are sent to RFC 3775: the LMA/HA must
   match the HoA included CoA present in the BU with the MN-ID known based on IKEv2
   signalling and update the respective MIPv6 BCE.  The
   PMIPv6 BCE accordingly (clearing the P
   flag).

   More generally, when the LMA and will expire in case the HA are co-located, binding cache
   lookup for a mobile node must use MAG does not send a combination of the mobile node's
   identifier and the home address. refresh PBU.
   The Binding Update from the mobile
   node contains the home address of the mobile node, whereas the Proxy
   Binding Update from the MAG contains only the mobile node's
   identifier.  Therefore when transitioning between using Proxy Mobile
   IPv6 and Mobile IPv6, the Home Agent must ensure that the mobile
   node's binding cache entry must be looked up with both the home
   address and identifier of the mobile node.  This requires the Home
   Agent to acquire the mobile node identifier other than from the
   Binding Update message (for e.g., from the preceding IKEv2 exchange
   that set up security associations for sending the Binding Update) and
   to store it as part of the binding cache entry for the mobile node.
   Note that this requires that the MN-ID used by the mobile node during
   the IKEv2 set-up refresh PBU is the same of the MN-ID used sent by the MAG in PMIPv6
   signalling.  This solves the issue 1 described in Section 3.3.

   Note that in this scenario the same binding cache entry for case the
   mobile node MN is at times modified by the mobile node multihomed and other times
   modified by a MAG.  The home agent must ensure that only authorized
   MAGs in addition to the mobile node are allowed to modify the binding
   cache entry for
   one of the mobile node.  This interface is valid, even though not
   explicitly mentioned, also for still attached on the next subsection. MAG link.

4.3.2.  Mobility from a non-PMIPv6 domain to a PMIPv6 domain

   In this section it is assumed that the MN is in a non-PMIPv6 access
   network and it has bootstrapped MIPv6 operations based on [RFC5026];
   therefore there is valid binding cache for its MIPv6-HoA at the HA.
   Then the MN moves to a PMIPv6 domain which is configured to be the
   home link for the MIPv6-HoA the MN has been assigned.

   In order to provide session continuity, the MAG needs to send a PBU
   to the HA/LMA that was serving the MN.  The MAG needs to discover the
   HA/LMA; however the current version of [RFC5213] assumes that the LMA
   is assigned or discovered when the MN attaches to the MAG. the exact
   mechanism is not specified in [RFC5213].  A detailed description of
   the necessary procedure is out of the scope of this document.  Note
   that the MAG may also rely on static configuration or lower layer
   information provided by the MN in order to select the correct HA/LMA.

   The PBU sent by the MAG must update the MIPv6 BCE of the MN.  However
   this PBU contains the MN-HNP and not the MN-HoA.  For this reason, in
   order to ensure that the PMIPv6 addressing model is maintained when
   the MN moves back to the PMIPv6 domain, a HA which acts also as LMA
   must allocate a home network prefix to the MN, even though during the
   MIPv6 bootstrapping only a /128 Home Address is assigned.  It is
   implementation specific if this prefix is stored on the MIPv6 BCE
   when the MN is just using MIPv6.

   As the MN moves to its home link, it will send a de-registration
   binding update with zero lifetime to its home agent.  This is done
   approximately at to discover the same time
   HA/LMA; however the MAG current version of [RFC5213] assumes that the sends a Proxy Binding
   Update LMA
   is assigned or discovered when the MN attaches to the LMA functionality co-located with MAG. the home agent.
   Actually exact
   mechanism is not specified in [RFC5213].  A detailed description of
   the de-registration necessary procedure is out of the MN will be received scope of this document.  Note
   that the MAG may also rely on static configuration or lower layer
   information provided by the HA/LMA
   after MN in order to select the correct HA/LMA.

   The PBU from the MAG as, based on [RFC5213], sent by the MAG forwards
   pakets only when the creates a PMIPv6 tunnel BCE for the MN which is established.  The HA/LMA MUST
   NOT delete
   independent of the binding cache entry for MIPv6 BCE.  Traffic destined to the mobile node after
   receiving a de-registration BU if MIPv6-HoA is
   still forwarded to the CoA present in the binding cache there is a BCE
   with MIPv6 BCE.  When the P-flag set for MN
   wants to use the same MN.  This solves issue 2 described
   in Section 3.3.

   NOTE: A solution for race conditions between BU HoA directly from the home link, it sends a de-
   registration message and PBU messages
   (issue #3) at that point only the PMIPv6 BCE is TBD.
   present.

5.  Security Considerations

   Scenarios A and B described in Section 3 do not introduce any
   security considerations in addition to those described in [pmipv6-
   draft] or [RFC3775].

   In Scenario C described in Section 3.3, the home agent has to allow
   the authorized MAGs in a particular PMIPv6 domain to be able to
   modify the binding cache entry for a mobile node.  [RFC3775] requires
   that only the right mobile node is allowed to modify the binding
   cache entry for its home address.

   This document requires that the a home agent that also implements the
   PMIPv6 LMA functionality should allow both the mobile node and the
   authorized MAGs to modify the binding cache entry entries for the mobile
   node.  Note that the compromised MAG threat described in [RFC4832]
   applies also here; in this scenario
   the threat is worse as it affects also hosts that are using the
   LMA/HA as MIPv6 HA and are not using PMIPv6. here.

6.  Additional Authors

   Chowdhury, Kuntal - kchowdhury@starentnetworks.com

   Hesham Soliman - Hesham@elevatemobile.com

   Vijay Devarapalli - vijay.devarapalli@azairenet.com

   Sri Gundavelli - sgundave@cisco.com

   Kilian Weniger - Kilian.Weniger@eu.panasonic.com

   Genadi Velev - Genadi.Velev@eu.panasonic.com

   Ahmad Muhanna - amuhanna@nortel.com

   George Tsirtsis - tsirtsis@googlemail.com

   Suresh Krishnan - suresh.krishnan@ericsson.com

7.  Acknowledgements

   This document is a merge of three four different Internet Drafts:
   draft-weniger-netlmm-pmipv6-mipv6-issues-00,
   draft-devarapalli-netlmm-pmipv6-mipv6-01and
   draft-devarapalli-netlmm-pmipv6-mipv6-01,
   draft-tsirtsis-logically-separate-lmaha-01and
   draft-giaretta-netlmm-mip-interactions-00.  Thanks to the authors and
   editors of those drafts.

   The authors would also like ot thank Jonne Soininen and Vidya
   Narayanan, NETLMM WG chairs, for their support.

8.  References

8.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.

   [RFC4832]  Vogt, C. and J. Kempf, "Security Threats to Network-Based
              Localized Mobility Management (NETLMM)", April 2007.

   [RFC4877]  Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
              IKEv2 and the Revised IPsec Architecture", 2005.

   [RFC5026]  Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
              Bootstrapping in Split Scenario", RFC 5026, October 2007.

   [RFC5213]  Gundavelli, S., "Proxy Mobile IPv6", August 2008.

   [boot-integrated]
              Chowdhury, K., Ed., "MIP6-bootstrapping for the Integrated
              Scenario", 2007.

   [draft-tsirtsis]
              Tsirtsis, G., "Behavior of Collocated HA/LMA", April 2008,
              <http://www.ietf.org/internet-drafts/
              draft-tsirtsis-logically-separate-lmaha-01.txt>.

   [pmipv6-draft]
              Gundavelli, S., Ed., "Proxy Mobile IPv6", 2007, <http://
              www.ietf.org/internet-drafts/
              draft-ietf-netlmm-proxymip6-01.txt>.

8.2.  Informative References

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

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

   [RFC4831]  Kempf, J., "Goals for Network-Based Localized Mobility
              Management (NETLMM)", RFC 4831, April 2007.

Author's Address

   Gerardo Giaretta (editor)
   Qualcomm

   Email: gerardog@qualcomm.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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

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

Intellectual Property

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

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

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