One document matched: draft-devarapalli-netlmm-pmipv6-mipv6-00.txt

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


             Proxy Mobile IPv6 and Mobile IPv6 interworking
              draft-devarapalli-netlmm-pmipv6-mipv6-00.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 12, 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 12, 2007                [Page 1]

Internet-Draft        PIPv6 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.  Requiring Global Mobility at home (MIPv6-CoA == MN-HoA) . . 3
     3.2.  Avoiding Global Mobility at home (MIPv6-HoA == MN-HoA)  . . 4
     3.3.  Supporting both MIPv6 and PMIPv6 hosts in the same
           domain  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8































Devarapalli, et al.     Expires October 12, 2007                [Page 2]

Internet-Draft        PIPv6 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


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.  Requiring Global Mobility at home (MIPv6-CoA == MN-HoA)

   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.

   When at home or away, where network-based mobility is enabled, the
   mobile node will use the locally obtained IPv6address (MIPv6-CoA) on
   the attached link and establish global mobility management for its
   home address (MIPv6-HoA), using host-based mobility signaling.




Devarapalli, et al.     Expires October 12, 2007                [Page 3]

Internet-Draft        PIPv6 and MIPv6 interworking            April 2007


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

3.2.  Avoiding Global Mobility at home (MIPv6-HoA == MN-HoA)

   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 12, 2007                [Page 4]

Internet-Draft        PIPv6 and MIPv6 interworking            April 2007


   Note that in the 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 corresponded
   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.

   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.

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
   allow both the mobile node and the authorized MAGs to modify the



Devarapalli, et al.     Expires October 12, 2007                [Page 5]

Internet-Draft        PIPv6 and MIPv6 interworking            April 2007


   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 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-sgundave-mip6-proxymip6-02 (work in progress), March 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 12, 2007                [Page 6]

Internet-Draft        PIPv6 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 12, 2007                [Page 7]

Internet-Draft        PIPv6 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 12, 2007                [Page 8]