Network Working Group S. Jeong Internet-Draft ETRI Intended status: Informational Y-H. Han Expires: March 1, 2007 KUT M-K. Shin ETRI P. Savola CSC/FUNET August 28, 2006 Problem Statement for Dual Stack Moving Internet (DSMI) draft-jeong-netlmm-dual-stack-moving-ps-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 March 1, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Jeong, et al. Expires March 1, 2007 [Page 1] Internet-Draft Dual Stack Moving Problem August 2006 Abstract This draft discusses the handover problem of dual stack mobile nodes when the mobile nodes roam over IPv4 and IPv6 NETLMM domains. Current NETLMM architecture supports IPv6 only. However, as the NETLMM architecture being more widely used, it will be likely to introduce the NETLMM architecture to IPv4 networks. In this environment, a dual stack mobile node may move to both IPv6 and IPv4 NETLMM domains. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Handover Scenario for Dual Stack Mobile Nodes . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Jeong, et al. Expires March 1, 2007 [Page 2] Internet-Draft Dual Stack Moving Problem August 2006 1. Introduction The Internet is now evolving towards a commercial carrier-grade IP network with appropriate QoS and security. Mobility management is one of the important factors in realizing such a mature IP network. Many proposals on IP mobility management for the Internet have considered the use of end-to-end principles. However, it is well known that mobility for IP nodes can be more efficiently supported if mobility management is handled by network elements. The IETF NETLMM WG has launched standardization of network-based mobility management in a localized domain. According to [I-D.ietf-netlmm-nohost-ps], problems of the existing host-based solutions for localized mobility management are summarized as follow: 1) change of host stack software, 2) lack of supporting both IPv4 and IPv6, and 3) additional security associations between network nodes and mobile nodes. Network-based localized mobility management could be one of the prominent ways to support IP mobility to mobile nodes, because it requires no software on the mobile node. In [I-D.ietf-netlmm-nohost-req], 12 goals for localized mobility management are described. Among them, following goal is not achieved yet. o Support for IPv4 and IPv6 (Goal #9) During the transition period from IPv4 to IPv6, it will be likely to exist heterogeneous localized domains supporting different IP stacks. That is, it is expected that some localized domains deploy IPv4-only, while other domains supports IPv6-only. In this environment, a dual stack mobile node may move to both IPv6 NETLMM domains and IPv4 NETLMM domains. Therefore, a new mobility management protocol is required to maintain IP connectivity during a dual stack mobile node's handover between IPv6 NETLMM domains and IPv4 NETLMM domains. Jeong, et al. Expires March 1, 2007 [Page 3] Internet-Draft Dual Stack Moving Problem August 2006 2. Terminology Terminology in this document follows that in [RFC3753] and [I-D.ietf-netlmm-nohost-ps], with the addition of some new and revised terminology given here: o Mobility Anchor Point (MAP) : A node in the network which manages a mapping between mobile node's permanent address and the local temporary address. Jeong, et al. Expires March 1, 2007 [Page 4] Internet-Draft Dual Stack Moving Problem August 2006 3. Problem Statement Current network-based localized mobility management architecture proposed by NETLMM WG supports IPv6 only. However, as the NETLMM architecture being more widely used, it will be likely to introduce the NETLMM architecture to IPv4 networks. In this environment, a dual stack mobile node may move to not only IPv6 NETLMM domains but also IPv4 NETLMM domains. When the dual stack mobile node handovers between IPv6 NETLMM and IPv4 NETLMM domains, it will be difficult to maintain IP connectivity. Especially, maintaining IPv6 connectivity in IPv4 NETLMM domains or IPv4 connectivity in IPv6 NETLMM domains is not supported. Therefore, this suggests to design a mobility management solution for federated NETLMM domains. Current mobility management protocols (e.g., Mobile IP) may be applied to the mobility management between heterogeneous NETLMM domains. However, the mobile host-side stack requirement would hinders the wide deployment of those mobility management protocols. Also, location privacy problem may occur when the mobile node moves to other NETLMM domains. The change in temporary local address as the mobile node moves exposes the mobile node's topological location to correspondents and potentially to eavesdroppers [I-D.ietf-netlmm-nohost-ps]. Therefore, it is needed to develop a mobility management protocol that supports mobile node's roaming over IPv6 and IPv4 NETLMM domains with single IP address and does not require additional host-side software update. 3.1. Handover Scenario for Dual Stack Mobile Nodes The mobile node's movement scenario for federated NETLMM domains is shown in Fig. 1. In the following handover scenario, we assume that both the mobile nodes and the MAPs are IPv4 and IPv6-capable and that the proposed protocol solution of NETLMM WG is used within a NETLMM domain. We also assume that the MAPs are always reachable through a globally unique IPv4 or IPv6 address. In the handover scenario, the dual stack mobile node moves between an IPv6-only NETLMM domain and IPv4-only NETLMM domain. Jeong, et al. Expires March 1, 2007 [Page 5] Internet-Draft Dual Stack Moving Problem August 2006 /-----------\ / Internet \ \ / \-----+-----/ | +-------------+-------------+ | | +-------+ +-------+ | MAP | | MAP | +---+---+ +-------+ | | /------+------\ /------+------\ / NETLMM \ / NETLMM \ \ domain (v4) / \ domain(v6) / \-------------/ \-------------/ | | | | +--+--+ +--+--+ +--+--+ +--+--+ | AR1 | | AR2 | | AR3 | | AR4 | +-----+ +-----+ +-----+ +-----+ / \ / \ / \ / \ / \ / \ / \ / \ +----+ +----+ | MN | <--> | MN | +----+ +----+ movement Figure 1: Handover between NETLMM domains supporting different IP versions In the scenario, the mobile node moves between the IPv6-only NETLMM domain and IPv4-only NETLMM domain, but the mobile node might be communicating with an IPv4-only application as well as an IPv6 application. Thus, we consider the following two cases of applications for CN. o case 1 : CN (Use of IPv4-only applications) o case 2 : CN (Use of IPv6 applications) Jeong, et al. Expires March 1, 2007 [Page 6] Internet-Draft Dual Stack Moving Problem August 2006 4. IANA Considerations There is no IANA consideration in this document. Jeong, et al. Expires March 1, 2007 [Page 7] Internet-Draft Dual Stack Moving Problem August 2006 5. Security Considerations Although NETLMM protocol solution supports mobility without any extra signaling between a mobile node and network, it still requires mobility signaling for the handover between NETLMM domains. Thus, it is required to have extra security association between a MAP and a mobile node when handover between NETLMM domains occurs. Also, removing mobile node's involvement in mobility management limits the possibility of DoS attacks on network infrastructural elements [I-D.ietf-netlmm-nohost-req]. IPSec can be applied to guarantee the signaling messages exchanged by network entities. Jeong, et al. Expires March 1, 2007 [Page 8] Internet-Draft Dual Stack Moving Problem August 2006 6. References [I-D.ietf-netlmm-nohost-ps] Kempf, J., "Problem Statement for Network-based Localized Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work in progress), June 2006. [I-D.ietf-netlmm-nohost-req] Kempf, J., "Goals for Network-based Localized Mobility Management (NETLMM)", draft-ietf-netlmm-nohost-req-04 (work in progress), August 2006. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. Jeong, et al. Expires March 1, 2007 [Page 9] Internet-Draft Dual Stack Moving Problem August 2006 Authors' Addresses Sangjin Jeong ETRI 161 Gajeong-dong, Yusung-gu Daejeon, 305-350 Korea Phone: +82 42 860 1877 Email: sjjeong@gmail.com Youn-Hee Han KUT Gajeon-Ri 307 Byeongcheon-Myeon Cheonan-Si Chungnam Province, 330-708 Korea Email: yhhan@kut.ac.kr Myung-Ki Shin ETRI 161 Gajeong-dong, Yusung-gu Daejeon, 305-350 Korea Phone: +82 42 860 4847 Email: myungki.shin@gmail.com Pekka Savola CSC/FUNET Espoo Finland Email: psavola@funet.fi Jeong, et al. Expires March 1, 2007 [Page 10] Internet-Draft Dual Stack Moving Problem August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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). Jeong, et al. Expires March 1, 2007 [Page 11]