NetLMM Working Group M. Jeyatharan Internet-Draft C. Ng Expires: March 4, 2008 J. Hirano Panasonic September 2007 Multiple Interfaced Mobile Nodes in NetLMM draft-jeyatharan-netlmm-multi-interface-ps-00 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 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Currently, Proxy Mobile IPv6 (PMIPv6) only supports mobile node (MN) with single interface roaming in the PMIPv6 domain. This memo explores possible issues that may surface when considering MN with multiple interfaces. Jeyatharan, et al. Expires March 4, 2008 [Page 1] Internet-Draft Multiple Interfaces in NetLMM September 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multiple Interfaces Support Model in PMIP . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 6 6.2. Informative Reference . . . . . . . . . . . . . . . . . . 7 Appendix A. Multihoming Issues in different PMIP Single LMA Scenarios . . . . . . . . . . . . . . . . . . . . . . 7 Appendix B. Multihoming Issues in Multiple LMA Scenario . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Jeyatharan, et al. Expires March 4, 2008 [Page 2] Internet-Draft Multiple Interfaces in NetLMM September 2007 1. Introduction Proxy Mobile IPv6 (PMIPv6) is a network based local mobility management protocol that provides local mobility support to IPv6 hosts and MIPv6 hosts. Details of protocol operation and related terminologies are given in [1]. Nevertheless, the PMIPv6 protocol as outlined in [1] was designed with single-interface mobile node in mind and thus lacks multihoming support functionality. In this memo we specifically look at host multihoming and defer roaming mobile router multihoming support in PMIPv6 for future analysis. Currently, in PMIPv6 domain as disclosed in [1], there is only a single PMIPv6 prefix (or more correctly per-MN unique prefix) that is advertised for each MN and thus the problem analysis in this memo will be mostly confined to host multihoming from the perspective of explicit multiple interfaces. If the PMIPv6 domain has multiple local mobility anchors (LMAs), and the MAGs are connected to multiple LMAs, then, multiple local home prefixes may be received by the MN and it may configure multiple addresses for the same interface. This memo briefly looks at multihoming issue where multiple prefixes are processed by a single interface of MN in Appendix B. 2. Multiple Interfaces Support Model in PMIP When a node with multiple interfaces is roaming in a PMIP domain, there are various benefits it can enjoy if the PMIP domain allows more than one interfaces to be used simultaneously. Such benefits have been described elsewhere, such as in [2], and are thus omitted in this document. It should be noted that some benefits could be enjoyed by the PMIP domain as well. For instance, when the LMA receives a packet destined for a multiple interfaced MN, the LMA may be able to choose among multiple routes to better utilize the network resources of the PMIP domain or to avoid congested region of the PMIP domain. There are two main ways multiple interfaces support can be provided by the PMIP domain. The first way is to offer the MN different home network prefixes for each of MN's interfaces. The second way is to offer the MN the same home network prefix. o Different Home Network Prefix for Each Interface In this case, each interface of the MN is allocated a unique Home Network Prefix. If the MN is a IPv6 host using SHIM6 (Site Multihoming by IPv6 Intermediation) [3] or SCTP (Stream Control Transport Protocol) [4] or MONAMI6 capable mobile node [5], then the MN can continue to enjoy multihoming benefits. However, the Jeyatharan, et al. Expires March 4, 2008 [Page 3] Internet-Draft Multiple Interfaces in NetLMM September 2007 LMA will not be able to route packets destined to one of the MN's address configured from one Home Network Prefix assigned to one interface to another of MN's interfaces, since the addresses configured on these interfaces are from different prefixes. To use this model, the MN may have to generate different NAI for different interfaces or MAGs may need to generate interface identifier based on some hint from the MN about attachment via a certain interface. This is necessary since different home network prefixes must be allocated to different interfaces. Thus, for practical purposes, this model can be treated as multiple MNs having one interface each. As such, we do not forsee any other issues supporting this model of operation. In addition, this model requires MN to have additional functionalities to enjoy the benefits of multihoming, and the LMA cannot choose among different paths to deliver a packet to a multi-interfaced MN. On top of that, this model also unnecessarily consume network resources (a MN having multiple unqiue prefixes). Hence the rest of this document will concentrate on the second model unless explicitly stated otherwise. o Same Home Network Prefix for All Interfaces In this case, each interface will receive the same Home Network Prefix. In this scenario, MN should accept packets received by any interface as long as the destination address matches the Home Network Prefix regardless of the actual address configured (or assigned) for that interface. This will allow the LMA to choose from all available routes when forwarding packets to the MN. There is no need for the MN to run separate multihoming enabling protocols (such as SHIM6, SCTP, MONAMI6 extension) to enjoy the benefits of multihoming. 3. Problem Statement We next explore into whether the current PMIP protocol is capable of supporting multiple interfaced MN. Figure 1 shows a multiple interfaced MN, which is simultaneously attached to a PMIPv6 network via both its interfaces. Jeyatharan, et al. Expires March 4, 2008 [Page 4] Internet-Draft Multiple Interfaces in NetLMM September 2007 +-------------+-----------+--------+ | Home Prefix | CoA | NAI | +-----+ +-------------+-----------+--------+ | LMA | | MN.Prefix | MAG1.Addr | MN.NAI | -> old +--+--+ | MN.Prefix | MAG2.Addr | MN.NAI | -> new | +-------------+-----------+--------+ | +--------------------------+ | | | Proxy Mobile IP Domain | | | +--------------------------+ | | MAG2 Address | | MAG1 Address (MN.If2 proxy CoA) | | (MN.If1 proxy CoA) +------+ +------+ | MAG2 | | MAG1 | +------+ +------+ \ / If2 \ / If1 +------+ | MN | +------+ Figure 1: Attaching multiple interfaces in legacy PMIP domain In Figure 1 it is assumed that the interface MN.If1 roams into the PMIP domain first and gets attached to MAG1. The binding cache entry (BCE) thus created is marked "old". When MN powers up the second interface MN.If2, MAG2 will send a new PBU to the LMA, requesting to bind the Home Network Prefix of MN to the proxy CoA of MAG2.Addr(see 2nd BCE marked "new"). As of the current operation of LMA as specified in [1], LMA will overwrite the "old" BCE with the "new" BCE. Now, let us look at the problem from the perspective of MN operation. When a MN in the above figure sees a prefix via interface 1, it will either use statefull or stateless address autoconfiguration methods to configure a global routable address for interface 1. When MN.If2 attaches to MAG2 and receives the same prefix as received via MN.If1, MN.If2 might end up configuring a "tentative address" that is the same as the fully configured address for MN.If1. Now, when MN does duplicate address detection (DAD) on the above said "tentative address", DAD may fail due to same address being configured in interface 1 and the MN may not configure a global routable address for MN.If2 until it finds other ways of obtaining a unique address for that interface 2. In such a circumstance, there will not be any reachability at all to MN because the LMA has route to MN.If2 while MN has no global reachability for MN.If2 and is only attached via MN.If1. However such total IP disconnectivity will Jeyatharan, et al. Expires March 4, 2008 [Page 5] Internet-Draft Multiple Interfaces in NetLMM September 2007 sustain only for a short while until MAG1 sends a binding re- registration message. Even after the binding re-registration, MN will only use one interface and multi-homing benefits cannot be enjoyed by MN. There could be an event where the MN configures different addresses for each of its interfaces. This can happen when stateless address autoconfiguartion yields different addresses to the interfaces. Thus, in this differentr address scenario, MN will have two home addresses in PMIP domain. In such a case, MN can attach to PMIP via both its interfaces. When MN does such simultaneous attachment via valid global routable address assigned to all its interfaces, there is only one BCE entry for MN at any one time, even though the MN has attached multiple interfaces to the PMIP domain. The problem is not simply the reduction of MN's multiple attachments into effectively a single attachment. Packets may be lost as a result. For instance, when MN sends a packet through the interface MN.If1, MAG1 will tunnel the packet to LMA. Since the LMA can no longer locate a valid entry where MAG1.Addr is the proxy CoA of MN's prefix, the LMA will discard the packet. More elaborate multihoming problem description in various scenarios of MN attachments will be discussed in Appendix A and Appendix B. 4. IANA Considerations This is an informational document and does not require any IANA action. 5. Security Considerations This document explores the problem of supporting mobile nodes with multiple interfaces connecting to a single PMIPv6 domain. No additional security threat is identified as of the writing of this memo that is specific to multiple interfaces support. 6. References 6.1. Normative Reference [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-05 (work in progress), September 2007. Jeyatharan, et al. Expires March 4, 2008 [Page 6] Internet-Draft Multiple Interfaces in NetLMM September 2007 6.2. Informative Reference [2] Ernst, T., "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6-multihoming-motivation-scenario-02 (work in progress), July 2007. [3] Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-08 (work in progress), April 2007. [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [5] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-03 (work in progress), July 2007. Appendix A. Multihoming Issues in different PMIP Single LMA Scenarios In this section a brief description of multihoming problem in different scenarios is discussed. Only scenarios which were not highlighted previously is discussed here. Furthermore, in this section it is assumed the MN an HA are Monami6 capable. +-----+ BCE at LMA/HA | HA/ | +---------+-------+-----+-----+ | LMA | |MN prefix| MN.CoA| NAI | BID | +-----+ +---------+-------+-----+-----+ | | prefix |MAG1add| NAI | - |->deleted +-----------+ | prefix |MAG2add| NAI | - |->deleted | Home | | HoA |HomeCoA| NAI | BID1|->valid | PMIPv6 | +---------+-------+-----+-----+ | domain |\ +-----------+ \ | \ +----+ +----+ MAG1 Address |MAG1| |MAG2| MAG2 Address (MN.If1 proxy CoA) +----+ +----+ (MN.If2 proxy CoA) \ / HoA \If1 If2/ Home CoA +--------+ | MN | +--------+ Figure 2: Using multiple interfaces in home PMIPv6 domain Jeyatharan, et al. Expires March 4, 2008 [Page 7] Internet-Draft Multiple Interfaces in NetLMM September 2007 When the MN boots up in its home PMIPv6 network with both its interfaces, it may either configure two home addresses (one for each interface), or a single home address associated with one interface (If1) and a care-of address for the other interface (If2). This care-of address can be configured from the local home prefix obtained from the PMIPv6 home domain. Such a configuration scenario is shown in Figure 2. It is assumed that the MN attaches to MAG1 with If1 before attaching If2 to MAG2. The first entry in LMA's binding cache as shown in Figure 2 created from the PBU sent by MAG1 would be overwritten by the second entry created from the PBU sent by MAG1. Since MN configures a care-of address from its home prefix (i.e. a Home CoA), it then proceeds to send CMIP binding update to HA. As before, the LMA/HA would wipe out the second entry, and create a third entry from the CMIP binding. Thus, multihoming benefits cannot be obtained. Further, LMA/HA may not have a route to Home CoA, since the bindings of MN's prefix are removed. Thus, the MN may be rendered unreachable by the use of multiple interfaces. +-----+ BCE at LMA/HA | HA/ | +---------+---------+-----+-----+ | LMA | |MN prefix| MN.CoA | NAI | BID | +-----+ +---------+---------+-----+-----+ | | prefix | MAGaddr | NAI | - |->deleted +----------------+ | HoA | CoA | NAI | BID1|->valid | Home PMIP | +---------+---------+-----+-----+ | domain | +----------------+ | +-----+ | MAG | MAG Address +-----+ (MN.If1 proxy CoA) | | +-----------+ | | foreign | | | domain | | +-----------+ | | HoA | If1 | +------+ If2 +-----+ | MN |-------------| AR | +------+ CoA +-----+ Figure 3: Simultaneously at home and at foreign Figure 3 shows another scenario where MN connects interface If2 to a foreign domain while interface If1 is at home. MAG will send PBU to Jeyatharan, et al. Expires March 4, 2008 [Page 8] Internet-Draft Multiple Interfaces in NetLMM September 2007 the LMA/HA, resulting in the first entry in LMA/HA's binding cache as shown in Figure 3. After the MN has configured a care-of address for If2, it will send a CMIP binding to LMA/HA. Since there is no way for the LMA/HA to know that this CMIP binding is coming from another interface, it will replace the first entry in its binding cache with the second entry. Thus, multihoming benefits are not available to MN. +------+ +----------------+ | HA |----| Internet | +------+ +----------------+ | BCE at HA | BCE at LMA +-----+-----+-----+ | +----------+---------+-----+ | HoA | CoA | BID | +-------+ | MNprefix | MN.CoA | NAI | +-----+-----+-----+ | LMA | +----------+---------+-----+ | HoA | CoA1| BID1| +-------+ | prefix | MAGAddr | NAI | | HoA | CoA2| BID2| | +----------+---------+-----+ +-----+-----+-----+ | +--------------+ | Foreign | | PMIP | | domain 1 | +--------------+ | +-----------+ +-----+ | Foreign | | MAG | MAG Address | domain 2 | +-----+ (MN.If1 Proxy CoA) +-----------+ | | If1 | CoA1 (from PMIP prefix) +----+ If2 +--------+ | AR |------------| MN | +----+ CoA2 +--------+ Figure 4: Attaching to two different foreign domains In Figure 4 MN is attached to a foreign PMIPv6 domain 1 via If1 and attached to a foreign domain 2 via If2. The binding cache at LMA of the foreign PMIPv6 domain is shown in Figure 4. After configuring addresses on both If1 and If2, the MN will send binding updates to its home agent HA. Being Monami6 capable, the MN will add BID options for each of its bindings. Thus the binding cache at HA will contains two entries, as shown in Figure 4. In this case, MN can enjoy multioming benefits. Jeyatharan, et al. Expires March 4, 2008 [Page 9] Internet-Draft Multiple Interfaces in NetLMM September 2007 Appendix B. Multihoming Issues in Multiple LMA Scenario If there are multiple LMAs in the same PMIPv6 network, then there is a possibility that a MN sees multiple prefixes being received at the same interface. In this section this scenario is briefly analyzed to see whether multihoming issue is present. Again, it is assumed that MN and HA have Monami6 functionality. +-----+------------+------+ +----+ | HoA | CoA | BID | | HA | +-----+------------+------+ +----+ | HoA |LMA1pref.CoA| BID1 | | | HoA |LMA2pref.coA| BID2 | +----------+--------+-----+ +------------+ +-----+------------+------+ | prefix | MN.CoA | NAI | | Internet | +----------+--------+-----+ +------------+ | LMA1pref | MAGAddr| NAI | / \ +----------+--------+-----+ / \ +------+ +------+ | LMA1 | | LMA2 | +------+ +------+ | | +----------+--------+-----+ +-----------------+ | prefix | MN.CoA | NAI | | foreign | +----------+--------+-----+ | PMIPv6 | | LMA1pref | MAGAddr| NAI | | domain | +----------+--------+-----+ +-----------------+ | +-----+ | MAG | +-----+ LMA1pref | LMA2pref +-----+ | MN | +-----+ Figure 5: PMIPv6 domain with multiple LMAs Figure 5 shows a scenario where MN is attached to a foreign PMIPv6 domain with multiple LMAs. Here, MN may receive two per-MN unique prefixes (LMA1pref and LMA2pref) and configure two care-of addresses using these prefixes. As MN is Monami6 capable, it will assign different BID for each of the care-of addresses when binding them to its home address at its home agent HA. The binding caches of the LMAs and the HA are shown in Figure 5. In this case, MN can enjoy multioming benefits. Jeyatharan, et al. Expires March 4, 2008 [Page 10] Internet-Draft Multiple Interfaces in NetLMM September 2007 Authors' Addresses Mohana Dahamayanthi Jeyatharan Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG Phone: +65 65505494 Email: mohana.jeyatharan@sg.panasonic.com Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG Phone: +65 65505420 Email: chanwah.ng@sg.panasonic.com Jun Hirano Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3 Hikarino-oka Yokosuka, Kanagawa 239-0847 JP Phone: +81 46 840 5123 Email: hirano.jun@jp.panasonic.com Jeyatharan, et al. Expires March 4, 2008 [Page 11] Internet-Draft Multiple Interfaces in NetLMM September 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). Jeyatharan, et al. Expires March 4, 2008 [Page 12]