NetLMM Working Group M. Jeyatharan Internet-Draft C. Ng Expires: July 4, 2008 J. Hirano Panasonic January 2008 Multiple Interfaced Mobile Nodes in NetLMM draft-jeyatharan-netlmm-multi-interface-ps-01 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 July 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The specific mechanism described in the current PMIPv6 draft to support multihoming is such that a different unique prefix is given to each interface of a Mobile Node that is attached to the PMIPv6 domain. However, multihoming can also be provided using single prefix for all interfaces of MN. This memo explores and highlights some issues associated with multihoming support in PMIPv6: using single prefix per MN method or multiple prefixes per MN method. Jeyatharan, et al. Expires July 4, 2008 [Page 1] Internet-Draft Multiple Interfaces in NetLMM January 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multiple Interfaces Support Models in PMIPv6 . . . . . . . . . 4 3. Multiple Interface Problem Analysis for Single Prefix Model . 6 3.1. Problem Analysis for Simultaneous Attachment . . . . . . . 6 3.2. Problem Analysis for Hand-off Scenarios . . . . . . . . . 9 3.3. Problem Analysis for Setting Filter Rule . . . . . . . . . 10 4. Multiple Interface Problem Analysis for Multi Prefix Model . . 11 4.1. Problem Analysis for Simultaneous Attachment . . . . . . . 11 4.2. Problem Analysis for Horizontal Hand-off . . . . . . . . . 12 4.3. Problem Analysis for Vertical Hand-off . . . . . . . . . . 13 5. Problem Analysis for Multiple Care-of address (MCoA) binding in PMIPv6 . . . . . . . . . . . . . . . . . . . . . . 14 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17 9.2. Informative Reference . . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Multihoming Issues in PMIPv6 Single LMA Roaming Scenario . . . . . . . . . . . . . . . . . . . . . . 19 Appendix C. Multihoming Issues in Multiple LMA Scenario . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Jeyatharan, et al. Expires July 4, 2008 [Page 2] Internet-Draft Multiple Interfaces in NetLMM January 2008 1. Introduction Proxy Mobile Internet Protocol Version Six (PMIPv6) is a network based mobility management protocol which provides mobility management to all type of nodes including multiple interfaced (MuIf) mobile nodes (MNs) that may or may not have client MIPv6 (CMIPv6) functionality. Details of protocol operation and related terminologies are given in [1]. The PMIPv6 draft [1] highlight multihoming support for MuIf MNs where a unique prefix is given per each interface of MN. The base draft adopted such a multiple prefix model to provide basic multihoming support and connectivity to an unmodified MN. "Unmodified" MN is generally understood as mobile nodes that do not have any software changes to attain network based mobility management. However, multihoming can also be provided using single prefix for all interfaces and one need not restrict to unique prefix per interface type of allocation. In this memo, the main focus is to analyze and highlight multiple interface related issues in single prefix model and multiple prefix model so that one can understand the problems and appropriate solutions can be seeked to tackle the problems. The analysis is broken into clusters where issues related to simultaneous attachment via all MN's interfaces, vertical hand-off (switching from one interface to another), horizontal hand-off and filter rule setting to attain the objective of preferred path selection by MN are looked into in detail. In addition to these, how to support multihoming for unmodified MN in a single prefix model and how multihoming can be supported when MN configures multiple care-of addresses for a certain interface is also explored. Many Standard Organizations (SDO) such as third generation partner ship project (3GPP), third generation partner ship project 2 (3GPP2) and Wimax Forum are very much interested in adapting PMIPv6 as a mobility management protocol. We have done some study on the 3GPP architecture and thus in this memo, wherever appropriate we are highlighting PMIPv6 multihoming problems pertaining towards the 3GPP architecture. Nevertheless, we would not exclude such problem analysis for other SDO architectures that will adapt the PMIPv6 protocol for multihoming purposes. In Appendix B and Appendix C, the multihoming problem analysis is focused on advanced scenarios such as roaming and a scenario that has multiple local mobility anchors (LMAs). Roaming scenarios in this memo refers to MN moving away from home domain into foreign domains. In such roaming scenarios, the need for further work is highlighted for MNs that have some mobility management functionality. It can be easily understood that such roaming scenarios is not applicable to IPv6 nodes that do not have any Client MIPv6 stack implemented. Jeyatharan, et al. Expires July 4, 2008 [Page 3] Internet-Draft Multiple Interfaces in NetLMM January 2008 2. Multiple Interfaces Support Models in PMIPv6 When a node with multiple interfaces is roaming in a PMIPv6 domain, there are various benefits it can enjoy if the PMIPv6 domain allows more than one interfaces to be used simultaneously. Such benefits have been described elsewhere, such as in [2], and are thus omitted from this document. It should be noted that some benefits could be enjoyed by the PMIPv6 domain as well. For instance, when the LMA receives a packet destined for a multiple interfaced MN, the LMA may be able to choose amongst the multiple routes to better utilize the network resources of the PMIPv6 domain or to avoid congested region of the PMIPv6 domain. There are two main ways multiple interfaces support can be provided by the PMIPv6 domain. The first way is to offer the MN different home network prefixes for each of MN's interfaces as described in [1]. The second way is to offer the MN the same home network prefix for all its interfaces. In this section, a brief analysis and principle of these models are given. Further analysis and associated problems with these multihoming models are given in later sections. o Different Home Network Prefix for Each Interface In this case, each interface of MN is allocated an unique Home Network Prefix. To ensure that each interface of MN gets an unique prefix, the LMA will use a MN interface identifier (ID) inserted in the Proxy Binding Update (PBU), a hand-off flag in PBU and its own binding cache entries to allocate such unique prefix per interface. This multiple prefix model is described in greater detail in [1]. If the interface ID (If-ID) in PBU is not available at the LMA binding cache, and if the hand-off flag is set to "1" (implying new connection request), the LMA will assign a new prefix for the interface. When the interface ID which is sent in the PBU is matched to an entry in LMA, then the LMA will treat it as horizontal hand-off (i.e. one interface disconnecting from a MAG and connecting via another MAG) and assign the same prefix for session continuity. For advanced hand-off scenarios such as vertical hand-off (i.e. one interface shutting down and transferring flows to a newly powered on interface), the LMA will use more information such as vertical hand-off flags inserted in the PBU, as well as disconnected interface's If-ID, to assign the same prefix of the disconnected interface to the new interface. Suffice to say, the prefix allocation logic is pretty complex at LMA for this multiple prefix model because correct prefixes needs to be assigned based on MN's state such as new connection, horizontal hand-off and vertical hand-off. Since unique prefix is assigned per interface of MN, for practical Jeyatharan, et al. Expires July 4, 2008 [Page 4] Internet-Draft Multiple Interfaces in NetLMM January 2008 purpose, this model can be treated as multiple MNs each having a single interface. Thus, in a general sense, LMA will not be able to perform path switching for packets addressed to a particular interface. For example, MN's IF1 is assigned a prefix (P1) and MN's IF2 is assigned another prefix (P2). When LMA receives a packet addressed to an address configured using P1, LMA would not route such packet via MN's IF2 path. If MN is an 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 such as a flow coming towards a MN address can be reached via one or more of MN interfaces. Unless some changes are done to PMIPv6 protocol, these external protocols such as SHIM6 or MONAMI6 may need to be used to achieve multihoming benefits. Another general issue with this model is that prefix resources are wasted and in some cases, a node may not get a prefix in PMIPv6 domain if the PMIPv6 domain is supporting numerous MNs with many active interfaces. 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. If single prefix is used for all interfaces, then all interfaces may configure same address and thus flows can be routed to MN via all available paths without introducing any changes to PMIPv6 network entities. However, even if same address is configured for all interfaces, to attain some advanced multihoming benefits such as setting flow preference, some changes to the PMIPv6 network has to be made. When PMIPv6 implements this single prefix model, there is no need for the MN to run separate multihoming enabling protocols (such as SHIM6, SCTP, MONAMI6) to enjoy some benefits of multihoming. All MN has to do is to configure each interface with an IP address from the same prefix. At the LMA, since prefix based routing is used rather than address based routing, any flow destine for MN can be routed to MN via any interface. However, we will explain further in next section that further work is required even in the case of single prefix model to achieve all the benefits of multihoming. The main advantage of this model is that complex prefix allocation mechanism at LMA can be avoided and prefix resources are not wasted. Jeyatharan, et al. Expires July 4, 2008 [Page 5] Internet-Draft Multiple Interfaces in NetLMM January 2008 3. Multiple Interface Problem Analysis for Single Prefix Model In this section, problem analysis for multihomed nodes when PMIPv6 uses a single prefix per MN model is presented. The assumption in the analysis regarding to which PMIPv6 entity is mapped to which entity in 3GPP architecture is based on details provided in documents such as [6] and [7]. 3.1. Problem Analysis for Simultaneous Attachment +-------------+-----------+--------+-------+ | Home Prefix | CoA | MN-ID | If-ID | +---------------+ +-------------+-----------+--------+-------+ |LMA/HA/(PDN-GW)| | MN.Prefix | MAG1.Addr | NAI |If1-ID | +---------------+ | MN.Prefix | MAG2.Addr | NAI |If2-ID | | +-------------+-----------+--------+-------+ | BCEs at LMA/HA +--------------------------+ | | | Proxy Mobile IP Domain | | | +--------------------------+ | | MAG2.Addr| | MAG1.Addr +--------------+ +-----------+ | 3G(SGW)/MAG2 | | ePDG/MAG1 | +--------------+ +-----------+ \ / If2 \ / If1 +------+ | MN | +------+ Figure 1: Attaching multiple interfaces to PMIPv6 that deploys single prefix model We first explore some fundamental issues if PMIPv6 uses single prefix per MN type of multihoming support. Figure 1 shows a multiple interfaced MN, which is simultaneously attached to a PMIPv6 network via both its interfaces. It is considered that MN.If1 (i.e. Interface 1 of MN) is a wireless local area network (WLAN) interface and MN.If2 is a third generation cellular (3G) interface. It is further assumed that PMIPv6 protocol is deployed in 3GPP network where MN.If1 is attached to the evolved packet data network gateway (ePDG) via a IPSec tunnel and MN.If2 is attached to Serving Gateway (SGW)/MAG2 which is its first hop router. It is considered that the ePDG/MAG1 is not the first hop router for MN.If1. In this scenario, the ePDG is assumed to have the Mobility Access Gateway (MAG) Jeyatharan, et al. Expires July 4, 2008 [Page 6] Internet-Draft Multiple Interfaces in NetLMM January 2008 functionality and it acts as a trusted gateway to 3GPP core network. More information on 3GPP architectural entities and their roles can be obtained from 3GPP technical specifications [6] and [7]. If such single prefix type of multihoming is supported, then there needs to be some parameter in the LMA/HA cache to differentiate the bindings from same MN. This parameter can be the interface ID (If-ID) or Binding Identifiers (BID) as described in [5]. It is important to appreciate that in the single prefix model, the interface IDs are merely used to differentiate the binding entries associated with multiple interfaces of MN. Interface IDs are not used in prefix assignment. In such single prefix model, the Network Access Identifier (NAI) will be used for prefix assignment because only a single prefix needs to be assigned to a multiple interface MN. In Figure 1 it is assumed that, MN.If1 roams into the PMIPv6 domain first and gets attached to MAG1. This corresponds to the first entry in the binding cache (BC). When MN powers up MN.If2, MAG2 will send a new Proxy Binding Update (PBU) to the LMA/HA, requesting to bind the Home Network Prefix of MN to the proxy care-of address (CoA) which is MAG2.Addr (see 2nd BCE). It is further assumed that the PBU has If-ID information in an option. Basically these interface IDs can be media access control (MAC) addresses or these can be interface identifiers that MN use to form global unicast address. If the latter type of interface identifiers are used, then it is extremely important that they are unique across MN interfaces. Thus, as advised in [1] the use of MAC addresses are preferred for interface IDs, due to their uniqueness per interface. These interface IDs (assuming MAC address) can be readily obtained by MAGs if they are first hop routers. Since MAG1 is an ePDG as in Figure 1, then, using simple MAC addresses may not work as the MAC address cannot be obtained from IPSec tunnel establishment signal. In such a problematic case of an ePDG being a MAG, proper mechanisms should be in place to get the correct If-ID. There can be a case where ePDG in Figure 1 does not know If-ID and generates a random If-ID. If this If-ID is same as MN's some other interface If-ID(ex. MN.If2 identifier), then this may overwrite an existing If-ID that is available at LMA/HA cache. Such overwriting at LMA/HA will cause a loss of a valid routing state. In such a scenario where MAG is an ePDG, one possible way is for MN to generate an If-ID and explicitly inform the ePDG during IPSec tunnel establishment. Alternatively, MN can simply inform ePDG its MAC address during tunnel establishment. Another way is for Authentication Authorization Accounting server (AAA) to generate If-IDs for initial attachments and assume that If- IDs can be transferred via context transfer for hand-off attachments. Yet another way is for the MAG/ePDG to query nearby routers for MN's If-IDs and then generate a unique interface ID. With so many Jeyatharan, et al. Expires July 4, 2008 [Page 7] Internet-Draft Multiple Interfaces in NetLMM January 2008 approaches, some further analysis needs to be performed to select the best possible method. We feel some MN involvement may be required to attain this objective because only the MN will know its unique interfaces and its identifiers in all scenarios. Furthermore, it is easier for the MN to provide the initial attachment information to the network rather than the network identifying this. Suppose we consider MN is an unmodified host in Figure 1 and performs such a simultaneous attachment, and if it is given same address as MN.If1 for MN.If2 via statefull address configuration method, then MN.If2 may not be able to configure a global address (perhaps a Duplicate Address Detection (DAD failure)) and that interface will not be used. In such a case, MN can only receive packets via MN.If1 and packets sent to MAG2 will be lost until MAG2 detects that MN.If2 is not attached and sends a deregistration PBU to LMA/HA. Thus, ideal multihoming is not obtained. On the other hand, if MN configures different addresses on its interfaces using stateless address configuration (assuming different interface identifier for each interface), then successful simultaneous attachment can be obtained. However, packets arriving at LMA/HA to address of MN.If1 may be sent via MAG2 and MAG2 will drop the packets because it does not have a neighbour cache entry mapping address of MN.If1 to the layer two (L2) address of MN.If2. Thus, it can be clearly seen that, although multihoming support is available at LMA/HA, when LMA/HA routes packets based on prefix, packets to one address to which a MAG does not have supporting neighbour cache entry will be lost. To solve the above mentioned problem for an unmodified host when it configures same address for both its interfaces may be difficult. We feel that some changes can be done at the network side to prevent activation of stateful mode of address configuration for unmodified host and thus avoid same address being configured for its interfaces. Another possible means is that the dynamic host configuration protocol (DHCP) signal can be intercepted by MAGs and MAG could insert some interface specific options to the DHCP message so that the DHCP server assigns different addresses. Or, as discussed in the NetLMM mailing list, the unmodified host can be configured with a single virtual interface at Layer 3 to mitigate this issue. To solve the issue of flow switch at LMA/HA due to LMA/HA implementing prefix based routing and MN configuring different addresses for its interfaces, further work may be required. One possible solution to this flow switch issue is that the LMA/HA cache can be address based rather than prefix based. But, in such a case, the PBU registration has to wait until the MN finishes address configuration which causes some delay in routing state establishment at LMA/HA. Jeyatharan, et al. Expires July 4, 2008 [Page 8] Internet-Draft Multiple Interfaces in NetLMM January 2008 3.2. Problem Analysis for Hand-off Scenarios Hand-offs are generally classified as horizontal hand-off and vertical hand-off. In a multiple interface scenario using the single prefix model, when one of the interface roams while the other interface is still attached, the problem is not very complex. The reason being the new MAG only needs to know the If-ID of the interface that is performing the horizontal hand-off to create the correct routing entry at LMA/HA. Again, the new MAG can get to know this If-ID by various means. New MAG can get to know this via context transfer from old MAG, from AAA, from the MN, or obtaining directly from MAC address. For horizontal hand-off case, we do not foresee any issue as long as there are appropriate mechanisms in the system for the new MAG to know the If-ID. For the vertical hand-off case (MN shutting down an interface and transferring flows to a newly powered on interface), the same prefix is given to the new interface (single prefix model). There need not be any specific mechanism as in multiple prefix model to get the same prefix via the newly powered on interface. Basically, if MN's interface 1 shuts down and there are flows addressed to MN.If1, then when MN.If2 powers on, these flows can be readily received at MAG2 after MAG2 has performed the PBU at LMA/HA. The important point here is that, MAG2 can readily send the PBU once it knows If2-ID. Unlike in the multiple prefix model, MAG2 need not get information about If1 at all. Thus, we predict that v.hand-off establishment delay will be less in the single prefix model. The only problem is that the address of MN.If2 may be different from address of MN.If1 and MAG2 may discard these packets coming to address of MN.If1. In such a case, appropriate mechanism should be in place. For example, the MN may need to inform MAG2 about address of MN.If1, so that MAG2 can transfer packets to MN.If2 without trading off on the quality of service for flows destined to address of MN.If1. Again, to solve the above mentioned issue, some terminal involvement may be required. Perhaps a link layer (L2) trigger from MN may be sufficient if MAG2 is directly attached to MN. This said L2 trigger could be such that MN informs the address of MN.If1 to MAG2. Alternatively, MN.If2 can configure the same address as MN.If1 to solve this issue. Again, we like to highlight that the appropriate solution to this issue needs to be explored. Jeyatharan, et al. Expires July 4, 2008 [Page 9] Internet-Draft Multiple Interfaces in NetLMM January 2008 3.3. Problem Analysis for Setting Filter Rule +---------------------+ | HA/LMA/Home PDN-GW | Flow1: MN.If1 CoA +---------------------+ Flow2: MN.If2 CoA | | +----------------------------+ | Foreign LMA/Foreign PDN-GW | +----------------------------+ | BCE at Foreign LMA +-----------------------+ +-------------+-----------+--------+-------+ | | |Home Prefix | CoA | MN-ID | If-ID | |Proxy MIPv6 Domain | +------------------------------------------+ | | |MN.LMA Prefix| MAG1.Addr | NAI |If1-ID | +-----------------------+ |MN.LMA Prefix| MAG2.Addr | NAI |If2-ID | | \ +------------------------------------------+ MAG2.Addr| \ MAG1.Addr +---------+ +-----------+ | 3G/MAG2 | | ePDG/MAG1 | +---------+ +-----------+ \ / If2 \ / If1 +------+ | MN | +------+ Figure 2: Single Prefix Flow Filter Issue In this section we assume that MN has multihoming capability and the LMAs have multihoming functionality. One of the advantages of multihoming is that flow preference can be set by MN at the correspondent node (CN) or at the home agent (HA). In Figure 2 we assume that MN has some functionality such that it can set filter rules. How to set filters at the above said entities is out of scope of this memo. Filter rules are generally set by using flow identifier options (FID) in binding update (BU) message and details of this mechanism can be found in [8]. In the single prefix multiple interface scenario, there is a specific problem that needs to be tackled when MN sets filter rules at home agent and is currently attached to a foreign domain. This is explained in detail below. In Figure 2, MN sets filter rules at HA which is the Packet Data Network Gateway (PDN-GW) in the 3GPP model. MN prefers flow1 to traverse the WLAN interface and flow2 to traverse the cellular/3G interface. Thus, MN sets filter rules accordingly at HA. However, due to foreign LMA/foreign PDN-GW implementing prefix based routing, flow1 can be routed wrongly and may arrive via the cellular MAG. Jeyatharan, et al. Expires July 4, 2008 [Page 10] Internet-Draft Multiple Interfaces in NetLMM January 2008 This is certainly an issue and adequate mechanisms needs to be in place to rectify this. When MN's flow preference is broken, MN may need to appropriately set the filter rules at the correct entity (foreign LMA). It is further assumed that in Figure 2, MN gets the foreign prefix (local breakout prefix in 3GPP jargon) in the foreign domain. Foreign prefix can be used for route optimization without trading off the advantage of network based mobility management PMIPv6 offers. If in another scenario, MN is directly connected to home PMIPv6 domain, then MN may need to set filter rules at HA. 4. Multiple Interface Problem Analysis for Multi Prefix Model In this section, problem analysis for multihomed nodes when PMIPv6 uses a multiple prefixes per MN model is presented. 4.1. Problem Analysis for Simultaneous Attachment +-------------+-----------+--------+-------+ | Home Prefix | CoA | MN-ID | If-ID | +---------------+ +-------------+-----------+--------+-------+ |LMA/HA/(PDN-GW)| | MN.P1 | MAG1.Addr | NAI |If1-ID | +---------------+ | MN.P2 | MAG2.Addr | NAI |If2-ID | | +-------------+-----------+--------+-------+ | BCEs at LMA/HA +--------------------------+ | | | Proxy MIPv6 Domain | | | +--------------------------+ | | MAG2.Addr | | MAG1.Addr +---------+ +-----------+ | 3G/MAG2 | | ePDG/MAG1 | +---------+ +-----------+ \ / If2(P2) \ / If1(P1) +------+ | MN | +------+ Figure 3: Attaching Multiple Interfaces to PMIPv6 that deploys Multiple Prefix Model In Figure 3, it is considered that MN can be an IPv6 host or CMIPv6 enabled host. MN has two interfaces and receives different prefixes via each of its interfaces. Basically, when MN.If1 attaches to PMIPv6 network, the first BC entry will be created. When MN.If2 Jeyatharan, et al. Expires July 4, 2008 [Page 11] Internet-Draft Multiple Interfaces in NetLMM January 2008 attaches to PMIPv6 network, the second BC entry is created. This multiple prefix model does not create any confusion to an unmodified IPv6 host that does simultaneous attachment and thus we will not highlight this point any further as it has been discussed extensively in the NetLMM mailing list. However, if MN is having flows with multiple CNs and a certain CN sends packets to address of MN configured from prefix P1 and another CN sends packets to address of MN configured from prefix P2, then multihoming benefits such as these said flows coming via all MN interfaces cannot be achieved. Thus, some further work is required in this area. For example, LMA/HA can identify using the NAI that both entries belong to the same MN. But the MAGs are not aware of MN other interface prefixes. Thus, if LMA/HA decides to send packets configured from P1 to MAG2, MAG2 will drop it. If a MAG has knowledge of MN's other interface(interfaces not attached to MAG) prefixes, then definitely, MN can enjoy some advanced multihoming benefits. 4.2. Problem Analysis for Horizontal Hand-off +-------------------------------------------+ | | | Proxy Mobile IPv6 Domain | | | +-------------------------------------------+ | | | | MAG1.Addr | MAG2.Addr | MAG3.Addr +---------+ +-----------+ +----------+ | 3G/MAG1 | | WLAN/MAG2 | | WLAN/MAG3| +---------+ +-----------+ +----------+ \ / -------/ If1(P1) \ /If2(P2) /If2(P2) +-------------+/Horizontal hand-off for If2 | MN | +-------------+ Figure 4: Horizontal handoff in Multiple Prefix Model In Figure 4, it is assumed that MN has two interfaces. MN here can be an IPv6 host or MIPv6 host. Initially, it is assumed that MN is connected to PMIPv6 network via If1 and If2 at MAG1 and MAG2 respectively. It is further assumed that MN.If1 is connected to 3G network and MN.If2 is connected to trusted WLAN network. In trusted WLAN network, the AR will have the MAG functionality and more information on trusted WLAN can be found in [6] and [7]. It is further considered that MN while still connected to 3G network via MN.If1, will perform a horizontal hand-off for MN.If2. Basically, MN.If2 will detach from MAG2 and attach at a new MAG3. In such a Jeyatharan, et al. Expires July 4, 2008 [Page 12] Internet-Draft Multiple Interfaces in NetLMM January 2008 scenario, the important thing is that the If-ID information in the PBU sent from MAG3 has to have If2-ID. As discussed previously, various mechanisms are available for MAG3 to obtain If-ID of MN.If2. In the scenario shown in Figure 4, there is no big problem of getting this interface ID because MAG3 is the directly connected access router of MN and the MN.If2 MAC address can be readily obtained (assuming MAC address is used as MN If-ID). The only danger in this scenario is that, if MAG3 does not have interface ID of If2 (for some reason) and it does not know the hand-off state of MN, then it may set the hand-off flag to "4" in the access technology option saying that the hand-off is unknown. In such a worst case scenario, the LMA may assign a new prefix for If2 and session continuity for prefix P2 flows will be disrupted. Thus, these kind of issues needs to be prevented if multiple prefix model is deployed. The main point we want to highlight here is that, if MAG3 does not know If2-ID, then getting this information quickly needs to be explored to prevent horizontal hand-off establishment delay. 4.3. Problem Analysis for Vertical Hand-off +-------------------------------------------+ | | | Proxy Mobile IPv6 Domain | | | +-------------------------------------------+ | | | | MAG1.Addr | MAG2.Addr | MAG3.Addr +---------+ +-----------+ +----------+ | 3G/MAG1 | | WLAN/MAG2 | | WLAN/MAG3| +---------+ +-----------+ +----------+ \ / -------/ If1(P1) \ /If2(P2) / If3(P2) +-------------+/Vertical hand-off for If2 | MN | +-------------+ Figure 5: Vertical handoff in Multi Prefix Model In Figure 5, it is assumed that MN has three interfaces, such as MN.If1, MN.If2 and MN.If3. It is further assumed that initially MN has MN.If1 and MN.If2 connected to the PMIPv6 network. Then, after some time, MN shuts down MN.If2 and attaches via MN.If3 -- i.e., MN performs a vertical hand-off for MN.If2. What is desired by vertical hand-off from MN's point of view is that MN requires flows for prefix P2 to be sent via MN.If3. To achieve this, the LMA should assign prefix P2 to MN.If3. For LMA to process such vertical hand-off request information and assign the desired prefix P2 in the above Jeyatharan, et al. Expires July 4, 2008 [Page 13] Internet-Draft Multiple Interfaces in NetLMM January 2008 scenario, the PBU sent by MAG3 MUST have If2-ID in addition to If3-ID. Moreover, as mentioned in [1], the hand-off flag in the access technology type option should specify that this is a vertical hand-off. Thus one can clearly see the complexity involved in getting the correct prefix for vertical hand-off in the multi prefix model. Let us consider another scenario where MN did not have MN.If1 but only had MN.If2 and MN.If3. When MN performs a vertical handoff from MN.If2 to MN.If3, If2-ID may not be required in the PBU. Once LMA sees the hand-off flag pointing to "2" (vertical hand-off), it will assign P2 to MN.If3. This is because LMA have no difficulty in identifying P2 cache since there are no other entries associated with MN. Thus, one can appreciate that the vertical hand-off complexity is high when MN has more than two interfaces. As highlighted previously, when MN does vertical hand-off in a complex scenario as shown in Figure 5, MAG3 needs If2-ID information in the PBU. The question is how such information can be obtained by MAG3. Suppose MAG3 is ePDG. Then, as mentioned previously, MN can supply the If2-ID to MAG3. Another option is that MAG3 can get it via context transfer from MAG2. If vertical hand-off is performed between heterogeneous access network types, context transfer via heterogeneous networks may take some time and other fast mechansims may need to taken into consideration to prevent vertical hand-off establishment delay. 5. Problem Analysis for Multiple Care-of address (MCoA) binding in PMIPv6 In this section multihoming is analyzed from the perspective of multiple care-of addresses configured for certain interface of MN. Furthermore, the analysis is performed in a system that uses single prefix multihoming model at LMA/HA. We would like to highlight that the problem highlighted in this section is applicable even if LMA/HA deploys the multiple prefix per MN model. Jeyatharan, et al. Expires July 4, 2008 [Page 14] Internet-Draft Multiple Interfaces in NetLMM January 2008 +-------------+-----------+--------+-------+-----+ | Prefix/Addr | CoA | MN-ID | If-ID | Flag| +-------------++-------------+-----------+--------+-------+-----+ |HA/LMA/PDN-GW|| MN.Prefix | MAG1.Addr | MN.NAI |If1-ID | - | | || MN.Prefix | MAG2.Addr | MN.NAI |If2-ID | - | +-------------+| MN.HoA | home2 | MN.NAI |BID1 | "H" | | | MN.HoA | CoA.AR | MN.NAI |BID2 | - | | +-------------+-----------+--------+-------+-----+ | BCEs at LMA/HA +--------------------------+ | | | Proxy Mobile IPv6 Domain | | | +--------------------------+ | | MAG1.Addr| |MAG2.Addr +---------+ +-----------+ | 3G/MAG1 | | ePDG/MAG2 | +---------+ +-----------+ | | If1 | +--------------------------+ | | Non-Trusted WLAN Access | | +--------------------------+ | | | +--------+ | | AP/AR | | +--------+ | | \ /If2 +-----------+ | MN | +-----------+ Figure 6: Multihomed MN processing multiple addresses when PMIPv6 is deployed in 3GPP Suppose PMIPv6 protocol is deployed in 3GPP, there are many prefixes a particular interface of MN can receive. It may want to configure different addresses from different prefixes for various reasons. In such a scenario shown in Figure 6, it is assumed that MN has multihoming support and can generate BIDs as in [5] and LMA/HA can support multihoming as well. Generally, when an interface of MN configures different addresses, MN may prefer to have reachability to all such configured addresses from the LMA/HA to obtain multihoming benefits. It is also assumed that this PMIPv6 domain is MN's home PMIPv6 domain and MN home address(MONAMI6/MIPv6 sense) is equal to MN.If1 address. Furthermore, it is assumed that MN has a single home address. In Figure 6, it is considered that MN.If1 is attached to 3G Jeyatharan, et al. Expires July 4, 2008 [Page 15] Internet-Draft Multiple Interfaces in NetLMM January 2008 MAG1. When MN attaches to PMIPv6 network, it is assumed that it connects first via MN.If1. When such a connection is successful, then the first entry in the BC will appear. The If1-ID can be directly obtained by MAG1. It is further considered that MN.If2 is connected to PMIPv6/3GPP network via a Non-Trusted WLAN access network. MN.If2 is directly attached to AR/AP. When MN.If2 makes a successful IPSec tunnel to ePDG, the second entry in the binding cache will be created. Again, the If2-ID needs to be different from If1-ID. Before establishing a tunnel to ePDG, MN.If2 will get a nomadic address in the Non-trusted WLAN access network and this nomadic address prefix will be directly associated with AR's prefix. However, MN may not know that MN.If2 is attached to PMIPv6 network. If MN knows that this is PMIPv6 network, then it may act differently. MN not knowing that this is PMIPv6 network, may configure another address from the home prefix (home2) for MN.If2 to get reachability or to set filter rules at LMA/HA. MN may want to register these addresses (nomadic address/on-link CoA, home2) at LMA/HA. When MN does Multiple CoA binding at LMA/HA for home2 and on-link CoA, then these CMIPv6 registrations are shown in the binding cache by the third and fourth entries respectively. When MN does CMIPv6 registrations, the BIDs generated must be different from the PMIPv6 registrations. If MN uses If2-ID value as BID1 or BID2, then one of the CMIPv6 binding may overwrite the second PMIPv6 binding. Thus, some MN involvement and some added multihoming feature is necessary at MN in this scenario to have the desired binding cache entries at LMA/HA. Moreover, one can clearly see that when multiple PMIPv6 and CMIPv6 registrations are taking place, there is a signaling storm in the system although MN has only two physical interfaces. Thus, further work is required to solve some issues that may arise in this scenario. 6. Conclusion In this memo, various issues that needs to be addressed when multihoming is supported in the PMIPv6 domain was analyzed. Issues were analyzed for single and multiple prefix models. From the analysis as highlighted in the draft, irrespective of the model used, some further work is required to solve issues in: simultaneous attachment, flow filtering, horizontal and vertical hand-offs and multiple care-of address processing by a single interface. Finally, we would like to conclude that multihoming can be provided by either models. However, how these models are going to be used to achieve advanced multihoming benefits needs further work. Whether network based solutions or some terminal involvement deemed necessary has to be analyzed for each of the problem scenario that was highlighted in the memo. Considering that the PMIPv6 protocol is designed with the Jeyatharan, et al. Expires July 4, 2008 [Page 16] Internet-Draft Multiple Interfaces in NetLMM January 2008 objective of reducing the signaling from MN, we suggest that solution space analysis for these problems should consider solutions where MN involvement is minimal. 7. IANA Considerations This is an informational document and does not require any IANA action. 8. Security Considerations This document explores the problem of supporting mobile nodes with multiple interfaces connecting to a PMIPv6 domain. No additional security threat is identified as of the writing of this memo that is specific to multiple interfaces support. 9. References 9.1. Normative Reference [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10 (work in progress), February 2008. 9.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] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work in progress), February 2008. [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., Ernst, T., Nagami, K., and V. Devarapalli, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-05 (work in progress), January 2008. [6] "3GPP system architecture evolution (SAE)", 3GPP TR 23.882, Jeyatharan, et al. Expires July 4, 2008 [Page 17] Internet-Draft Multiple Interfaces in NetLMM January 2008 January 2008. [7] "Technical Specification Group Services and System aspects", 3GPP TR 23.402, December 2007. [8] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-soliman-monami6-flow-binding-05 (work in progress), November 2007. Appendix A. Change Log o draft-jeyatharan-netlmm-multi-interface-ps-01: * Expanded the draft into problem analysis for two PMIPv6 multihoming models. * Expanded the draft with problem analysis focusing on 3GPP scenarios. * Modified the draft by cutting down on some appendix scenarios. * Modified the draft by generalizing the problem analysis for all types of nodes. * Included some similar multihoming problem scenario as highlighted by Vijay Devarapalli in his PMIPv6 multihoming draft. o draft-jeyatharan-netlmm-multi-interface-ps-00: * Initial version. Jeyatharan, et al. Expires July 4, 2008 [Page 18] Internet-Draft Multiple Interfaces in NetLMM January 2008 Appendix B. Multihoming Issues in PMIPv6 Single LMA Roaming Scenario +-----+ BCEs at LMA/HA for single prefix model | HA/ | +---------+---------+-------+----------+------+ | LMA | |MN prefix| MN.CoA | MN-ID | If-ID |Flag | +-----+ +---------+---------+-------+----------+------+ | | prefix | MAGaddr | NAI | If1-ID | | +----------------+ | HoA | CoA | NAI | BID2 |"H" | | Home PMIP | +---------+---------+-------+----------+------+ | domain | +----------------+ | +-----+ | MAG | MAG Address +-----+ | | +-----------+ | | foreign | | | domain | | +-----------+ | | HoA | If1 | +--------------+ If2 +-----+ | Monami6 MN |-------------| AR | +--------------+ CoA +-----+ Figure 7: Simultaneously at home and at foreign In this section some issues associated with MN when it roaming away from home domain is analyzed. In Figure 7, it is assumed that MN can be a MONAMI6 node. It is assumed that MN.If1 is attached to home domain, which is also a PMIPv6 domain. The entry created at LMA/HA due to MN.If1 attachment is shown by the first entry. If MN.If2 is attached to foreign domain, MN will configure a CoA for MN.If2 and will want to send a CMIPv6 binding to LMA/HA either using a "H" flag or will send a CMIPv6 binding using BID2 in the binding update. If such an action is performed by MONAMI6 MN, then the binding cache created is shown by the second entry. The important point here is that, if 'H" flag is used, then there is no problem because both MN interfaces reachability states are available at LMA/HA. However, if MONAMI6 nodes decides to put BID2, instead of "H" flag, and if BID2 sent in CMIPv6 BU is same as If1-ID, then there is a danger of overwriting the first PMIPv6 entry and thus loosing the simultaneous at home and away benefits. Furthermore, if MN is a MIPv6 node in Figure 7, then MN may not insert BID or "H" flag in CMIPv6 BU and this CMIPv6 BU will overwrite the first PMIPv6 PBU and multihoming benefits will be lost. Jeyatharan, et al. Expires July 4, 2008 [Page 19] Internet-Draft Multiple Interfaces in NetLMM January 2008 If multiple prefix model is active in the scenario shown in Figure 7, then such a roaming scenario does not pose any issue for a MIPv6 host that has two home addresses (one for each interface configured from 2 different home prefixes). This is because, the first entry in BCE will have P1 prefix (PMIPv6 entry) and the second entry will have a CMIPv6 entry tying MN HoA(configured from P2 prefix) to a care-of address configured in foreign domain. Thus, the caches from both interfaces are clearly separated by means of prefixes. In this multiple prefix roaming case, If-ID need not be attached in the CMIPv6 BU to separate the bindings. Thus, roaming is not a issue for an unmodified MIPv6 host. Appendix C. 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. Jeyatharan, et al. Expires July 4, 2008 [Page 20] Internet-Draft Multiple Interfaces in NetLMM January 2008 +-----+------------+------+ +----+ | HoA | CoA | BID | | HA | +-----+------------+------+ +----+ | HoA |LMA1pref.CoA| BID1 | | | HoA |LMA2pref.coA| BID2 | +----------+--------+-----+ +------------+ +-----+------------+------+ | prefix | MN.CoA |MN-ID| | Internet | BCEs at HA +----------+--------+-----+ +------------+ | LMA1pref | MAGAddr| NAI | / \ +----------+--------+-----+ / \ BCEs at LMA1 +------+ +------+ | LMA1 | | LMA2 | +------+ +------+ | | +----------+--------+-----+ +-----------------+ | prefix | MN.CoA |MN-ID| | foreign | +----------+--------+-----+ | PMIPv6 | | LMA2pref | MAGAddr| NAI | | domain | +----------+--------+-----+ +-----------------+ BCEs at LMA2 | +-----+ | MAG | +-----+ LMA1pref | LMA2pref +-----+ | MN | +-----+ Figure 8: PMIPv6 domain with multiple LMAs Figure 8 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 8. In this case, MN can enjoy multioming benefits. Jeyatharan, et al. Expires July 4, 2008 [Page 21] Internet-Draft Multiple Interfaces in NetLMM January 2008 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 July 4, 2008 [Page 22] Internet-Draft Multiple Interfaces in NetLMM January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 July 4, 2008 [Page 23]