Network Working Group J-C. Lee Internet-Draft D. Kaspar Intended status: Standards Track ETRI Expires: February 8, 2008 August 7, 2007 NEMO in PMIPv6 domain (draft-lee-netlmm-nemo-ps-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 February 8, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Lee & Kaspar Expires February 8, 2008 [Page 1] Internet-Draft NEMO in PMIPv6 August 2007 Abstract The PMIPv6 protocol provides local mobility to a mobile node without its involvement in mobility management. To provide session continuity without involvement of the mobile node, MAG and LMA maintain forwarding information for the mobile node's HNP. If the mobile node is a mobile router and the PMIPv6 domain is a home network of it, the MAG and LMA should also have forwarding state for MNP. This memo describes several NEMO related issues including this. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Local Mobility Management and Granularity of Mobility Management . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. The Requirements for NetLMM protocol . . . . . . . . . . . 5 3.3. A PMIPv6 domain as a Mobile Router's Home Network . . . . 5 4. Issues for NEMO in PMIPv6 domain . . . . . . . . . . . . . . . 6 4.1. MNP for mobile router . . . . . . . . . . . . . . . . . . 6 4.2. Ingress Filtering for MNP of Mobile Router . . . . . . . . 6 4.3. LMA as HA of Mobile Router . . . . . . . . . . . . . . . . 6 4.4. Dynamic Routing Protocol at LMA . . . . . . . . . . . . . 7 5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Using MNP option . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Lee & Kaspar Expires February 8, 2008 [Page 2] Internet-Draft NEMO in PMIPv6 August 2007 1. Requirements notation 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 [RFC2119]. Lee & Kaspar Expires February 8, 2008 [Page 3] Internet-Draft NEMO in PMIPv6 August 2007 2. Introduction The PMIPv6 protocol provides local mobility to a mobile node without requiring any involvement of a mobile node stack. From the perspective of the mobile node the entire PMIPv6 domain looks like a single link. This allows the mobile node in a PMIPv6 domain to operate as if it were still in home link while it roams in the PMIPv6 domain. The PMIPv6 protocol has two principal functional entities which maintain forwarding information for the mobile node. MAG (Mobile Access Gateway) and LMA (Local Mobility Anchor) are them. The MAG maintains data path for the mobile node, and the LMA maintains a collection of routes for individual mobile node while the mobile node roams in the PMIPv6 domain. Those forwarding information, however, is for the traffic for mobile node. It doesn't care about the traffic for LFN of the mobile router. If a mobile node is a mobile router, MAG and LMA of current PMIPv6 protocol could not handle the traffic for LFN of mobile router. The goal of this memo is to provide short descriptions for NEMO related issues like this. Lee & Kaspar Expires February 8, 2008 [Page 4] Internet-Draft NEMO in PMIPv6 August 2007 3. Assumptions 3.1. Local Mobility Management and Granularity of Mobility Management Mobility management can be broken down into localized mobility management and global mobility management. Localized mobility involves movements across some administratively and geographically contiguous set of subnets, whereas the mobile node that implements a global mobility protocol is able to move across broad administrative, geographical, and topological domains. The local subdomains of these domains could be domains implementing localized mobility management or not. 3.2. The Requirements for NetLMM protocol [netlmm-goals] includes following goals for NetLMM protocol. o The NetLMM protocol should be able to support unmodified mobile nodes (goal #7 of [netlmm-goals]). o Localized mobility management is independent of global mobility management (goal #10 of [netlmm-goals]). Considering these two goals for NetLMM protocol, we can say that a mobile node in PMIPv6 domain could be a host or router (mobile router), and even if a mobile node is a mobile router the PMIPv6 domain should support it without requiring any modification of it. 3.3. A PMIPv6 domain as a Mobile Router's Home Network This memo deals with a PMIPv6 domain which is a mobile router's home network. Lee & Kaspar Expires February 8, 2008 [Page 5] Internet-Draft NEMO in PMIPv6 August 2007 4. Issues for NEMO in PMIPv6 domain 4.1. MNP for mobile router [netlmm-goals] describes the goals (or requirements) for NetLMM. Section 3.7 "Support for Unmodified Mobile Nodes (Goal #7)" says that the NetLMM solution should be able to support any mobile node without requiring localized mobility management software on the mobile node. In this context, the mobile node can be an ordinary host or a node that has global mobility protocol. The entire PMIPv6 domain appears as a single link to the mobile node, so the mobile node that has a global mobility protocol will not trigger the global mobility protocol while roaming in the PMIPv6 domain. In this situation most of the mobile nodes that have a host- based global mobility protocol may work well, but if the mobile node is a mobile router there may be problems in forwarding packets from LFN. The PMIPv6 protocol has two principal functional entities which are called MAG (Mobile Access Gateway) and LMA (Local Mobility Anchor). The MAG maintains data path for the mobile node, and the LMA maintains a collection of routes for individual mobile node while the mobile node roams in the PMIPv6 domain. Those forwarding information, however, is for the traffic for mobile node. It doesn't care about the traffic for LFN of the mobile router. If a mobile node is a mobile router, MAG and LMA of current PMIPv6 protocol could not handle the traffic for LFN of mobile router. If the mobile router boots up in a normal home network and then moves into a PMIPv6 domain this problem would not occur, because the mobile router will make a tunnel to the home agent and forwards all packets from its mobile network via this tunnel to the home agent. In this case the source address of packets is the CoA of the mobile router and the MAG and LMA can handle these packets. 4.2. Ingress Filtering for MNP of Mobile Router If the MAG doesn't have any information about MNP, the packets from LFN might be filtered out at the MAG. 4.3. LMA as HA of Mobile Router In PMIPv6 domain LMA is usually HA for a mobile router, and MAG advertises RA message on behalf of LMA (HA). Therefore the RA message advertised by the MAG should not have 'H' bit because the HA Lee & Kaspar Expires February 8, 2008 [Page 6] Internet-Draft NEMO in PMIPv6 August 2007 and the mobile router are not on same link. 4.4. Dynamic Routing Protocol at LMA [RFC3963] describes that intra-domain routing protocol like RIPng can be used as an alternative way to set up forwarding state for MNP at the home agent. After bootstrapping of the mobile router, the mobile router and the home agent start to exchange routing updates messages periodically. Normally a request message is sent as multicast from the routing protocol's specific port, but the mobile router couldn't receive this message because the LMA and the mobile router are not in the same link (the mobile router is not the tunnel's end point). As part of normal routing protocol operation, the next hop information in routing entries is filled with the mobile router's link-local address with the outgoing interface set to the bi-directional tunnel, but link-local address can't be used because of same reason as before. Lee & Kaspar Expires February 8, 2008 [Page 7] Internet-Draft NEMO in PMIPv6 August 2007 5. Proposed Solution 5.1. Using MNP option If we can know MNP for the mobile router it could be registered on a profile server in advance. Once a mobile router enters PMIPv6 domain it performs access authentication. During this procedure a MAG can get MNP together with HNP for the mobile router, and then the MAG sends BU including MNP and HNP to the LMA. While the mobile router roams in the PMIPv6 domain, the MAG that the mobile router is attached to should always send BU containing HNP and MNP. Lee & Kaspar Expires February 8, 2008 [Page 8] Internet-Draft NEMO in PMIPv6 August 2007 6. IANA Considerations There is no IANA consideration in this document. Lee & Kaspar Expires February 8, 2008 [Page 9] Internet-Draft NEMO in PMIPv6 August 2007 7. Security Considerations The security consideration is not studied for this issue yet. Lee & Kaspar Expires February 8, 2008 [Page 10] Internet-Draft NEMO in PMIPv6 August 2007 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [netlmm-dt-protocol] Levkowetz, H., "The NetLMM Protocol", October 2006. [netlmm-goals] Kempf, J., "Goals for Network-based Localized Mobility Management", October 2006. [netlmm-pmipv6] Gundavelli, S., "Proxy Mobile IPv6", January 2007. [netlmm-ps] Kempf, J., "Problem Statement for Network-based Localized Mobility Management", September 2006. 8.2. Informative References [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. Lee & Kaspar Expires February 8, 2008 [Page 11] Internet-Draft NEMO in PMIPv6 August 2007 Authors' Addresses Joo-Chul Lee ETRI 161 Gajeong-dong Yuseong-gu Daejeon, 305-700 Korea Fax: +82 42 861 5404 Email: rune@etri.re.kr Dominik Kaspar ETRI 161 Gajeong-dong Yuseong-gu Daejeon, 305-700 Korea Fax: +82 42 861 5404 Email: dominik@etri.re.kr Lee & Kaspar Expires February 8, 2008 [Page 12] Internet-Draft NEMO in PMIPv6 August 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). Lee & Kaspar Expires February 8, 2008 [Page 13]