Network Working Group S. Jeong Internet-Draft ETRI Intended status: Informational Y-H. Han Expires: August 5, 2007 KUT M-K. Shin H-J. Kim ETRI Feb 2007 Goals and Requirements for IPv4 Support in PMIPv6 draft-jeong-netlmm-ipv4-support-req-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 August 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The IETF NetLMM WG is developing standards of network-based mobility management in a localized domain. PMIPv6 architecture enables mobile nodes to roam without host-side mobility management protocol stack. Current PMIPv6 protocols mainly consider IPv6 and dual stack mobile Jeong, et al. Expires August 5, 2007 [Page 1] Internet-Draft PMIPv6 IPv4 Support Requirements-Goals Feb 2007 nodes. It also states deployment scenario of PMIPv6 in IPv6 infrastructure. However, localized mobility management in IPv4 network is also problematic. Also, there still exist a lot of IPv4 MNs and these IPv4 MNs may visit PMIPv6 domain. This document discusses a few scenarios of IPv4 support in PMIPv6 domain and describes goals and requirements for IPv4 support in PMIPv6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Possible Scenarios of IPv4 Support in PMIPv6 . . . . . . . 3 2. Goals of IPv4 support in PMIPv6 . . . . . . . . . . . . . . . . 4 3. Requirements of IPv4 support in PMIPv6 . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Jeong, et al. Expires August 5, 2007 [Page 2] Internet-Draft PMIPv6 IPv4 Support Requirements-Goals Feb 2007 1. Introduction The IETF NetLMM WG is developing standards of network-based mobility management in a localized domain. [I-D.ietf-netlmm-nohost-ps] summarizes the problems of the conventional host-based mobility management solutions as follows: 1) change of host-side software, 2) lack of simultaneously supporting both IPv4 and IPv6, and 3) additional security associations between network nodes and mobile nodes. Network-based localized mobility management is expected to be one of the prominent ways in order to provide IP mobility to mobile nodes, because it does not require additional software on the mobile node. In [I-D.ietf-netlmm-nohost-req], 11 goals for localized mobility management are described. Among them, following goal is not yet actively discussed in the mailing list. - Support for IPv4 and IPv6 (Goal #8): This goal describes considerations for deploying NetLMM architecture to not only IPv4 infrastructure, but also IPv6 infrastructure. Current network-based localized mobility management solutions proposed by NetLMM WG are designed with IPv6 infrastructure and IPv6 (or dual stack) mobile nodes in mind [I-D.singh-netlmm-protocol] [I-D.sgundave-mip6-proxymip6]. However, localized mobility management in IPv4 infrastructure is also problematic and as the NetLMM architecture being more widely used, it will be likely to introduce the NetLMM architecture to IPv4 networks. Also, there still exist a lot of IPv4 MNs and these IPv4 MNs may visit PMIPv6 domain. Further, dual stack or IPv4 MN in the PMIPv6 domain could communicate with IPv4 CNs. 1.1. Possible Scenarios of IPv4 Support in PMIPv6 IPv4 MN support - When an IPv4 MN moves from IPv4 network to a PMIPv6 domain, the PMIPv6 domain is required to detect an attachment of IPv4 MN and to maintain the MN's connectivity with IPv4 CNs. IPv4 infrastructure support - The dual stacked PMIPv6 components may be deployed a network where both IPv4 and IPv6 infrastructure coexist or where the network infrastructure still support IPv4 but it is expected that the network will be migrated to IPv6 soon. In this scenario, PMIPv6 signaling messages will be transported through IPv4 encapsulation. IPv4 CN support - The PMIPv6 components are reachable through a Jeong, et al. Expires August 5, 2007 [Page 3] Internet-Draft PMIPv6 IPv4 Support Requirements-Goals Feb 2007 globally unique IPv4 address so that IPv4 or dual stack MNs in the PMIPv6 domain can communicate with IPv4 CNs. 2. Goals of IPv4 support in PMIPv6 o Current PMIPv6 protocols mainly consider IPv6 or dual stack MNs. However, there still exist many IPv4 MNs. When an IPv4 MNs visits a PMIPv6 domain, the PMIPv6 domain should detect the IPv4 MN's attachment and should enable the IPv4 MN to communicate with IPv4 CNs. o IPv6 offers many improvements over IPv4 and MIPv6 also improves MIPv4. Although transition from IPv4 to IPv6 occurs in slow phase, the transition would happen eventually. During the transition period from IPv4 to IPv6, IPv4 and IPv6 infrastructure may coexist in a network. In such environment, dual stacked PMIPv6 components are likely to be deployed in order to support network-based localized mobility in the network where the large part of the network infrastructure is supporting IPv4. Therefore, in order to deploy PMIPv6 in such network, it is needed to consider deploying PMIPv6 in the IPv4 network infrastructure. The PMIPv6 signaling will be carried in IPv4 data tunnel. o When dual stack or IPv4 MN is attached to a PMIPv6 domain, the MN may communicate with both IPv6 and IPv4 CNs while the MN is in a PMIPv6 supporting domain (IPv6 or IPv4 infrastructure). Thus, the PMIPv6 domain should support data tunneling in order to carry IPv4 traffic to the MN. 3. Requirements of IPv4 support in PMIPv6 o If a MN wants to communicate with both IPv4 and IPv6 CN, the MN should be dual stacked. o When an IPv4 MN moves into a PMIPv6 domain, PMIPv6 components should detect the MN's attachment. PMIPv6 components should be dual stacked in order to detect the attachment of IPv4 and/or dual stack MN. o A dual stack or IPv4 MN has IPv4 address, if the MN communicates with IPv4 CNs. If the MN does not have IPv4 address yet, PMIPv6 domain should support allocation of IP address. Jeong, et al. Expires August 5, 2007 [Page 4] Internet-Draft PMIPv6 IPv4 Support Requirements-Goals Feb 2007 o The LMA in a PMIPv6 domain is reachable through globally unique IPv4 address, if the PMIPv6 domain support a IPv4 (or dual stack) MN to communicate with IPv4 CNs. o It should be possible for an access router in PMIPv6 domain to register MN's IPv4 address with the LMA using PMIPv6 signaling messages. o When PMIPv6 is deployed in the IPv6 infrastructure, PMIPv6 components should support IPv4-in-IPv6 data tunneling in order to transport IPv4 traffic over IPv6 infrastructure. When PMIPv6 is deployed in the IPv4 infrastructure, PMIPv6 components should support IPv6-in-IPv4 data tunneling in order to deliver IPv6 traffic over IPv4 infrastructure. o When an IPv6 network where PMIPv6 is deployed supports IPv4 MNs, PMIPv6 components should maintain two routing tables IPv4 and IPv6, respectively. When an IPv4 network where PMIPv6 is deployed supports dual stack MN that communicates with IPv6 CNs, PMIPv6 components should maintain both IPv4 and IPv6 routing tables. 4. IANA Considerations No action is required by IANA for this document. 5. Security Considerations The attachment of an IPv4 MN to a PMIPv6 domain with IPv6 infrastructure or a dual stack MN to a PMIPv6 domain with IPv4 infrastructure may introduce security threats in the PMIPv6 domain. Thus, access routers are required to perform authentication of MN before registering the MN to the LMA. 6. Informative References [I-D.ietf-netlmm-nohost-ps] Kempf, J., "Problem Statement for Network-based Localized Mobility Management", draft-ietf-netlmm-nohost-ps-05 (work in progress), September 2006. [I-D.ietf-netlmm-nohost-req] Kempf, J., "Goals for Network-based Localized Mobility Management (NETLMM)", draft-ietf-netlmm-nohost-req-05 (work in progress), October 2006. Jeong, et al. Expires August 5, 2007 [Page 5] Internet-Draft PMIPv6 IPv4 Support Requirements-Goals Feb 2007 [I-D.sgundave-mip6-proxymip6] Gundavelli, S., "Proxy Mobile IPv6", draft-sgundave-mip6-proxymip6-01 (work in progress), January 2007. [I-D.singh-netlmm-protocol] Bedekar, A., "A Protocol for Network-based Localized Mobility Management", draft-singh-netlmm-protocol-01 (work in progress), February 2007. Authors' Addresses Sangjin Jeong ETRI 161 Gajeong-dong, Yuseong-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, Yuseong-gu Daejeon, 305-350 Korea Phone: +82-42-860-4847 Email: myungki.shin@gmail.com Jeong, et al. Expires August 5, 2007 [Page 6] Internet-Draft PMIPv6 IPv4 Support Requirements-Goals Feb 2007 Hyoung-Jun Kim ETRI 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 Korea Phone: +82-42-860-6576 Email: khj@etri.re.kr Jeong, et al. Expires August 5, 2007 [Page 7] Internet-Draft PMIPv6 IPv4 Support Requirements-Goals Feb 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). Jeong, et al. Expires August 5, 2007 [Page 8]