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]