Network Working Group J-C. Lee Internet-Draft D. Kaspar Intended status: Standards Track ETRI Expires: August 30, 2007 February 26, 2007 The Problem Statements for NEMO in NetLMM domains (draft-lee-netlmm-nemo-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 August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Lee & Kaspar Expires August 30, 2007 [Page 1] Internet-Draft ps for nemo in netlmm February 2007 Abstract The NetLMM protocol provides local mobility to the mobile node without requiring any modification of mobile node. The NetLMM domain provides this service by maintaining forwarding state for the mobile node's prefix. In case that the mobile node is a mobile router in the home network the NetLMM domain may not have the forwarding state for the mobile network prefix, so it can't forward packets from nodes within the mobile network, that is to say, existing NetLMM protocols do not consider mobile routers enough. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. The Granularity of Mobility Management . . . . . . . . . . 6 4.2. The Requirements for NetLMM protocol . . . . . . . . . . . 6 4.3. NetLMM protocol . . . . . . . . . . . . . . . . . . . . . 6 5. Problem Statement for NEMO in NetLMM domain . . . . . . . . . 7 6. Packet Forwarding Scenario for NEMO in NetLMM domain . . . . . 8 6.1. Mobile Router is "at home" . . . . . . . . . . . . . . . . 8 6.2. Mobile Router is "away" . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Lee & Kaspar Expires August 30, 2007 [Page 2] Internet-Draft ps for nemo in netlmm February 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 August 30, 2007 [Page 3] Internet-Draft ps for nemo in netlmm February 2007 2. Introduction The NetLMM (Network-based Localized Mobility Management) protocol provides local mobility to the mobile nodes without requiring any involvement of a mobile node stack. From the perspective of the mobile node, the entire NetLMM domain appears as a single link, the network ensures the mobile node believes it is always on its home link. So the mobile node in a NetLMM domain may operate as if it were still in the same subnet while it is moving in the NetLMM domain. The NetLMM protocol has two principal functional entities, which are called MAG (Mobile Access Gateway) and LMA (Local Mobility Anchor). The LMA maintains a collection of routes for individual mobile nodes while the mobile nodes moves around in the NetLMM domain. The route information that the LMA keeps is, however, only for the packets based on the subnet prefix allocated to the mobile node itself. So if a mobile router (MR) implementing the NEMO protocol [RFC3963] joins the NetLMM domain as a home network and moves around among MAGs in the NetLMM domain, the MAG may not know how to handle the packets from nodes attached to the mobile router. Lee & Kaspar Expires August 30, 2007 [Page 4] Internet-Draft ps for nemo in netlmm February 2007 3. Terminology Localized Mobility Management Protocol Same as defined in [netlmm-ps]. NetLMM protocol This term does not mean "NetLMM design team protocol" but assumes a network-based localized mobility management protocol that supports the NetLMM functional architecture described in [netlmm-goals]. So this term includes "netlmm dt protocol" and "proxy MIPv6 protocol". NetLMM domain This term is defined in [netlmm-dt-protocol] but the meaning of "the NetLMM protocol" follows the term "NetLMM protocol" previously defined. Lee & Kaspar Expires August 30, 2007 [Page 5] Internet-Draft ps for nemo in netlmm February 2007 4. Assumptions In general, the localized/global mobility management scheme follows the assumptions below, which this draft is based on. 4.1. The Granularity of Mobility Management Mobility management is broken down into localized mobility management and global mobility management. Local mobility involves movements across some administratively and geographically contiguous set of subnets. The mobile node that implements a global mobility protocol moves across broader administrative, geographical, and topological domains and these domains could be localized mobility management domain or not. 4.2. The Requirements for NetLMM protocol o The NetLMM protocol should be able to support unmodified mobile nodes (goal #7 of [netlmm-goals]). In this goal the mobile node can be a normal host or a node that has some kind of global mobility protocol. o Localized mobility management is independent of global mobility management (goal #10 of [netlmm-goals]). This goal says that the implementation and deployment of the localized mobility management protocol should not restrict, or be restricted by, the choice of global mobility management protocol. This means that the mobile node which has a global mobility protocol can move freely across NetLMM domains or any ordinary subnet; and from the mobile node's point of view both appear as the same, that is to say, single subnet. In other words, the mobile node does not know and does not need to know whether the domain that it just entered is a NetLMM domain or not 4.3. NetLMM protocol Currently there are two NetLMM protocol candidates; the design team protocol and the proxy mobile IPv6 protocol [netlmm-pmipv6]. This draft considers both of them. Lee & Kaspar Expires August 30, 2007 [Page 6] Internet-Draft ps for nemo in netlmm February 2007 5. Problem Statement for NEMO in NetLMM domain [netlmm-goals] describes the goals (or requirements) for NetLMM. Section 3.7 "Support for Unmodified Mobile Nodes (Goal #7)" of [netlmm-goals] 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 some kind of global mobility protocol. Since the entire NetLMM domain appears as a single link to the mobile node, the mobile node that has a global mobility protocol will not trigger the global mobility protocol while moving into (or inside of) the NetLMM 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 that implements NEMO protocol there may be problems in forwarding packets from the nodes attached to the mobile router. The NetLMM protocol has two principal functional entities, which are called MAG (Mobile Access Gateway) and LMA (Local Mobility Anchor). The LMA maintains a collection of routes for individual mobile nodes and it will be used while the mobile node moves around in the NetLMM domain. The route information that the LMA keeps is, however, only for the packets based on the subnet prefix allocated to the mobile node itself. Thus, if a mobile router joins the NetLMM domain as a home network and moves around among MAGs that belong to the NetLMM domain a MAG may not know how to handle the packets from nodes attached to the mobile router because there is no way to inform the MAG and LMA of the mobile network prefix. If the mobile router boots up in a normal access network and then moves into a NetLMM domain this problem does not occur because in the foreign network the mobile router will make a tunnel to the home agent and forward all packets from its mobile network through this tunnel to the home agent. In this case the source address of packet is the CoA of the mobile router and the MAG that the mobile router is attached to can handle this packet. So, This problem statement might have an impact on the NetLMM protocol specification itself. Lee & Kaspar Expires August 30, 2007 [Page 7] Internet-Draft ps for nemo in netlmm February 2007 6. Packet Forwarding Scenario for NEMO in NetLMM domain We consider two scenarios in that a mobile router joins NetLMM domain. 6.1. Mobile Router is "at home" The MR will obtain a prefix by attaching to the NetLMM domain. But all the nodes within the mobile network attached to the MR will keep their prefix. Because the MR is "at home", it will not encapsulate packets from attached nodes, but forward them to a MAG. The MAG only knows the prefix of the MR, but not the prefix of any attached node. This situation might cause the combination of NEMO and NetLMM to fail. 6.2. Mobile Router is "away" The MR will also receive a prefix during NetLMM domain attachment. But the NEMO protocol which is implemented at the MR will encapsulate packets from nodes attached to the MR. Therefore, the mobile network will appear to the MAG as if it is a single node. It is assumed that in this case, no problems will occur. Lee & Kaspar Expires August 30, 2007 [Page 8] Internet-Draft ps for nemo in netlmm February 2007 7. IANA Considerations There is no IANA consideration in this document. Lee & Kaspar Expires August 30, 2007 [Page 9] Internet-Draft ps for nemo in netlmm February 2007 8. Security Considerations The security consideration is not studied for this issue yet. Lee & Kaspar Expires August 30, 2007 [Page 10] Internet-Draft ps for nemo in netlmm February 2007 9. References 9.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. 9.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 August 30, 2007 [Page 11] Internet-Draft ps for nemo in netlmm February 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 August 30, 2007 [Page 12] Internet-Draft ps for nemo in netlmm February 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 August 30, 2007 [Page 13]