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

Versions: 00 01

NETLMM Working Group                                      V. Devarapalli
Internet-Draft                                           Azaire Networks
Intended status: Informational                             S. Gundavelli
Expires: October 27, 2007                                  Cisco Systems
                                                            K. Chowdhury
                                                        Starent Networks
                                                              A. Muhanna
                                                         Nortel Networks
                                                          April 25, 2007


             Proxy Mobile IPv6 and Mobile IPv6 interworking
              draft-devarapalli-netlmm-pmipv6-mipv6-01.txt

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 27, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Proxy Mobile IPv6 is a network-based local mobility management
   protocol developed in the IETF.  Mobile IPv6 is a host-based mobility
   management protocol that has no restrictions in terms of



Devarapalli, et al.     Expires October 27, 2007                [Page 1]

Internet-Draft        PMIPv6 and MIPv6 interworking           April 2007


   applicability in a domain.  This document captures some of the
   scenarios where Proxy Mobile IPv6 and Mobile IPv6 are used together.
   It also describes how the two protocols can work together.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Interworking Scenarios . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Hierarchical Mobility Using Proxy Mobile IPv6 and
           Mobile IPv6  . . . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Transitioning between Proxy Mobile IPv6 and Mobile IPv6  .  5
     3.3.  Supporting both MIPv6 and PMIPv6 hosts in the same
           domain . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8
   Intellectual Property and Copyright Statements . . . . . . . . . . 10






























Devarapalli, et al.     Expires October 27, 2007                [Page 2]

Internet-Draft        PMIPv6 and MIPv6 interworking           April 2007


1.  Introduction

   The NETLMM WG has been working on a network-based mobility management
   protocol, Proxy Mobile IPv6 [3].  Proxy Mobile IPv6 (PMIPv6) is based
   on Mobile IPv6 [2] in the sense that it re-uses many concepts from
   the Mobile IPv6 protocol (MIPv6).  Most of the Home Agent
   functionality as defined in Mobile IPv6 is re-used for Proxy Mobile
   IPv6.  There are many scenarios where Proxy Mobile IPv6 and Mobile
   IPv6 can be used to-gether.  For example, Proxy Mobile IPv6 could be
   used as the local mobility management protocol and Mobile IPv6 as the
   global mobility management protocol in a hierarchical manner.

   In this document we capture three scenarios where Proxy Mobile IPv6
   and Mobile IPv6 interworking needs to be considered.

   1.  Proxy Mobile IPv6 and Mobile IPv6 are used in a hierarchical
       manner
   2.  Transitioning between Proxy Mobile IPv6 and Mobile IPv6
   3.  Co-existence of PMIPv6 and MIPv6 hosts in the same network

   This document also addresses how Mobile IPv6 and Proxy Mobile IPv6
   can be used together for the three scenarios mentioned above.


2.  Terminology

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


3.  Interworking Scenarios

3.1.  Hierarchical Mobility Using Proxy Mobile IPv6 and Mobile IPv6

   In this model, PMIPv6 and MIPv6 are used in a hierarchical manner
   where PMIPv6 is used for local mobility and MIPv6 is used for global
   mobility.  The MN-HoA address assigned to the mobile node in the
   Proxy Mobile IPv6 domain is used as the care-of address for Mobile
   IPv6 registration.  If the mobile node moves and attaches to an
   access network that is not part of the proxy mobile IPv6 domain, it
   acquires a care-of address from the access network and performs a
   regular Mobile IPv6 registration with its home agent.  When the
   mobile node is outside the Proxy Mobile IPv6 domain, only Mobile IPv6
   is used.






Devarapalli, et al.     Expires October 27, 2007                [Page 3]

Internet-Draft        PMIPv6 and MIPv6 interworking           April 2007


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

       MN obtains Mobile IPv6 HoA from HA
       MN obtains PMIPv6 MN-HoA1 from LMA1 and PMIPv6 MN-HoA2 from LMA2

       Figure 1: Hierarchical Mobility using Mobile IPv6 and PMIPv6

   Using the above figure to illustrate the hierarchical use of Mobile
   IPv6 and Proxy Mobile IPv6, when the MN is attached to MAG1, it uses
   MN-HoA as CoA for Mobile IPv6 registration with the home agent.  If
   the MN moves and attaches to MAG2, it is still attached to the same
   PMIPv6 domain and its PMIPv6 MN-HoA remains the same.  Since there is
   no change in care-of address, the MN does not need to update its
   binding at the home agent.  If the MN moves and attached to MAG3, it
   is no longer in the same PMIPv6 domain.  The MN acquires a new PMIPv6
   MN-HoA2 from LMA2.  Since there is now a change in the care-of
   address, the MN updates its binding with the home agent with MN-HoA2
   as the care-of address.

   When the mobile node moves and attaches to a different MAG in the
   PMIPv6 domain, the mobile node and the Mobile IPv6 home agent are not
   aware of the movement.  PMIPv6 takes care of managing the mobility
   between different MAGs.  The mobile node's movement is restricted



Devarapalli, et al.     Expires October 27, 2007                [Page 4]

Internet-Draft        PMIPv6 and MIPv6 interworking           April 2007


   only to the LMA.  If the mobile node movement results in attaching to
   a different PMIPv6 domain, then the mobile node sees a change in its
   care-of address and sends a binding update to its home agent.

   There are other hierarchical scenarios possible using Proxy Mobile
   IPv6 and Mobile IPv6, but they are addressed in this document.

3.2.  Transitioning between Proxy Mobile IPv6 and Mobile IPv6

   In this mode, the mobile node uses Proxy Mobile IPv6 as long as it is
   in the Proxy Mobile IPv6 domain.  It has Mobile IPv6 stack active at
   the same time, but as long as it is attached to the same Proxy Mobile
   IPv6 domain, it will appear as if it is attached to the home link.
   If it attaches to an access network that is not part of the Proxy
   Mobile IPv6 domain, it acquires a care-of address from the access
   networks, treats the earlier home address in the Proxy Mobile IPv6
   domain as the Mobile IPv6 home address and performs a Mobile IPv6
   registration.  The Mobile IPv6 registration is performed with the
   same home agent that was earlier a local mobility anchor in the Proxy
   Mobile IPv6 domain.

   The home agent supporting the mobile node based on host-based
   mobility management scheme, is also configured to function as a local
   mobility anchor for supporting local mobility management.

   When the mobile node is in its mobile IPv6 home domain, it will be
   able to roam in that domain using its MN-HoA and with out having to
   participate in any mobility related signaling.  The domain is enabled
   for network-based mobility and the obtained home address in the proxy
   mobile IPv6 context (MN-HoA) is the same as its global home address
   (MIPv6-HoA).  The mobile is not required to initiate host-based
   mobility and avoiding any IPv6 tunneling over the air in the home
   domain.

   When the mobile moves away from its home domain and enters another
   domain where network-based mobility management is enabled, the mobile
   node obtains an address from the new PMIPv6 domain, and uses that
   address as the care-of address for Mobile IPv6 registration.  The
   earlier MN-HoA address is now treated as the MIPv6 home address
   (MIPv6-HoA).  This is similar to the scenario described in
   Section 3.1.

   If the mobile node moves in to a domain where network based mobility
   is not enabled, the mobile node will configure a local address and
   use the local address as the care-of address for Mobile IPv6
   registration.  The LMA entity for the mobile node now becomes the
   home agent for the mobile node.




Devarapalli, et al.     Expires October 27, 2007                [Page 5]

Internet-Draft        PMIPv6 and MIPv6 interworking           April 2007


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

       MN obtains Mobile IPv6 HoA from HA
       MIPv6 HoA = PMIPv6 MN-HoA

             Figure 2: Transitioning between MIPv6 and PMIPv6

   The above figure illustrates the scenario.  When the MN is attached
   to MAG1, it obtains a PMIPv6 MN-HoA which is the same as the Mobile
   IPv6 HoA.  So, when the MN is attached to MAG1, it appears to the MN
   that it is at home.  If the MN moves and attaches to MAG2, its PMIPv6
   MN-HoA remains the same and it is still attached to the home link.
   If the MN moves outside the PMIPv6 domain and attaches to an access
   router that has no Proxy Mobile IPv6 support, it just configures an
   address from the access network and uses that address as the care-of
   address for Mobile IPv6 registration.

   Note that in this scenario the same binding cache entry for the
   mobile node is at times modified by the mobile node 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 the mobile node.

   If the mobile node moves back to the PMIPv6 domain that corresponds
   to its home link, it will send a de-registration binding update with
   zero lifetime to its home agent.  But at the same, the MAG the mobile
   node is attached will send a proxy Binding Update to the LMA
   functionality co-located with the home agent.  In this case, the home
   agent MUST send a binding acknowledgement with success status to the
   mobile node to indicate that it is at home, but modify the binding
   cache entry to reflect the fact that it is now a binding cache entry
   created using PMIPv6.  The home agent MUST NOT delete the binding
   cache entry for the mobile node.



Devarapalli, et al.     Expires October 27, 2007                [Page 6]

Internet-Draft        PMIPv6 and MIPv6 interworking           April 2007


   The bootstrapping mechanisms used to discover the LMA, the Mobile
   IPv6 home agent and home address for the mobile node must be
   configured such that the LMA assigned for a particular mobile node
   can be used as a home agent and the address given to the mobile node
   when it is attached to the PMIPv6 domain can be used as the MIPv6
   home address when the mobile node is no longer attached to the PMIPv6
   domain.

   When the LMA and the HA are co-located, binding cache lookup for a
   mobile node must use a combination of the mobile node's identifier
   and the home address.  The Binding Update from the mobile node
   contains only 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 may require 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
   save it as part of the binding cache entry for the mobile node.

   Note that there is only one binding cache for the mobile node at any
   time, irrespective of whether the mobile node is using Proxy Mobile
   IPv6 or Mobile IPv6.

3.3.  Supporting both MIPv6 and PMIPv6 hosts in the same domain

   This scenario addresses a network where there is a combination of
   Mobile IPv6 hosts and IPv6 hosts that do not implement any mobility
   management software.  The same home agent that supports hosts that
   have the Mobile IPv6 mobile node functionality will also act as the
   PMIPv6 LMA for hosts that rely on network-based mobility management.
   Supporting this scenario is rather straight forward and is described
   in the based PMIPv6 specification [3].


4.  Security Considerations

   Scenarios 1 and 3 described in Section 3 do not introduce any
   security considerations in addition to those described in [3] or [2].

   In Scenario 2 described in Section 3.2, 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.  RFC 3775 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



Devarapalli, et al.     Expires October 27, 2007                [Page 7]

Internet-Draft        PMIPv6 and MIPv6 interworking           April 2007


   allow both the mobile node and the authorized MAGs to modify the
   binding cache entry for the mobile node.


5.  IANA Considerations

   This document requires no action from IANA.


6.  Acknowledgments

   The authors would like to thank Gerardo Giaretta and Vidya Narayanan
   for interesting discussions on this topic.


7.  Normative References

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

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

   [3]  Gundavelli, S., "Proxy Mobile IPv6",
        draft-ietf-netlmm-proxymip6-00 (work in progress), April 2007.


Authors' Addresses

   Vijay Devarapalli
   Azaire Networks
   3121 Jay Street
   Santa Clara, CA  95054
   USA

   Email: vijay.devarapalli@azairenet.com


   Sri Gundavelli
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com






Devarapalli, et al.     Expires October 27, 2007                [Page 8]

Internet-Draft        PMIPv6 and MIPv6 interworking           April 2007


   Kuntal Chowdhury
   Starent Networks
   30 International Place
   Tewksbury, MA
   USA

   Email: kchowdhury@starentnetworks.com


   Ahmad Muhanna
   Nortel Networks
   2221 Lakeside Blvd.
   Richardson, TX  75082
   USA

   Email: amuhanna@nortel.com



































Devarapalli, et al.     Expires October 27, 2007                [Page 9]

Internet-Draft        PMIPv6 and MIPv6 interworking           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).





Devarapalli, et al.     Expires October 27, 2007               [Page 10]


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