Mobopts Research Group C. Ng Internet-Draft K. Aso Intended status: Informational Panasonic Expires: January 9, 2009 July 8, 2008 On Mobile IPv6 Optimization and Multihoming draft-ng-mobopts-multihoming-02 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 January 9, 2009. Ng & Aso Expires January 9, 2009 [Page 1] Internet-Draft MIPv6 Optimization and Multihoming July 2008 Abstract This memo explores the possible areas of extensions to MIPv6 route optimization in the considerations of multihomed nodes. The intention is to raise awareness in the research community, leading to a possible extension to RFC 4651. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multihomed Mobile Node . . . . . . . . . . . . . . . . . . . . 4 2.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Approaches for Optimization . . . . . . . . . . . . . . . 4 2.2.1. Mobile Node with Multiple Home Addresses . . . . . . . 4 2.2.2. Mobile Node with Multiple Care-of Addresses . . . . . 6 2.3. Security Threats . . . . . . . . . . . . . . . . . . . . . 10 3. Multihomed Correspondent Node . . . . . . . . . . . . . . . . 11 3.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Approaches for Optimization . . . . . . . . . . . . . . . 11 3.3. Security Threats . . . . . . . . . . . . . . . . . . . . . 12 4. Multihomed Anchor Node . . . . . . . . . . . . . . . . . . . . 14 4.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Approaches for Optimization . . . . . . . . . . . . . . . 14 4.3. Security Threats . . . . . . . . . . . . . . . . . . . . . 15 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Informative Reference . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Ng & Aso Expires January 9, 2009 [Page 2] Internet-Draft MIPv6 Optimization and Multihoming July 2008 1. Introduction RFC 4651 [1] discussed and analyzed various techniques of optimizing the Route Optimization in Mobility Support in IPv6 (Mobile IPv6, or MIPv6) [2]. One area in which RFC 4651 had not considered, which was in fact mentioned as a future research area, is the consideration of multihomed nodes. As different access technologies continues to emerge, the likelihood of a node being multihomed increases. Additionally, a node can enjoy various benefits, such as more resilience to link failures or network congestions, as documented in various literature (e.g. see [3], [4], [5]). Thus, it could be expected that in future, a substantial portion of nodes involved in Mobile IPv6 signaling will be multihomed. Narayanan et. al provided a good analysis in the interaction of between various mobility and multihoming protocols in [6] from an architectural perspective. The present memo is not meant to duplicate the work there. Instead, it is our intention to analyze if there are opportunities for optimization when multihomed node is involved in Mobile IPv6 signaling. For this purpose, this memo first considers the case where the mobile node is multihomed in Section 2, and then the case where the correspondent node is multihomed in Section 3. Finally, the case where the anchor node (i.e. home agent, mobility anchor point, etc) is multihomed will be considered in Section 4. Ng & Aso Expires January 9, 2009 [Page 3] Internet-Draft MIPv6 Optimization and Multihoming July 2008 2. Multihomed Mobile Node The case where the mobile node is multihomed is covered in various literature, for example, see [5] [6], [7], [8], [9], [10]. As such, this analysis will only focus on those not covered by these literature. 2.1. Scenario There are two main possibilities of a multihomed mobile node. In the first case, the mobile node can have multiple home addresses. This is possibly a result of the home network being multihomed, or the mobile node itself is subscribed to multiple mobility service providers. In the second case, the mobile node can have multiple care-of addresses. This is likely due to the mobile node attaching multiple interfaces to different access routers, or due to an access router advertising multiple prefixes. The first case is largely similar to a multihomed IPv6 node, and is currently being studied by the IETF SHIM6 Working Group. As such, our analysis will be confined to those optimization that are possible with respect to the Mobile IPv6 signaling. Similarly, the second case of multiple care-of addresses was previously analyzed by the IETF Monami6 Working Group (currently, the WG is merged with other mobility related effort in the Mobility Extension Working Group). Thus, we will limit our analysis to optimizing the signaling used in Mobile IPv6 Route Optimization. 2.2. Approaches for Optimization 2.2.1. Mobile Node with Multiple Home Addresses o Including Multiple Home Addresses in Binding Update When a mobile node has multiple home addresses, it will need to send multiple binding updates to a correspondent node or home agent, one for each home address. One way to reduce the number of signaling messages is thus to allow a binding update message to contain multiple home addresses -- i.e. multiple home address options in the destination header. However, since the destination header would typically be processed before the mobility header, a cleaner way to do this might be to create new mobility option to carry the home address, and include multiple such options in the binding update message. Ng & Aso Expires January 9, 2009 [Page 4] Internet-Draft MIPv6 Optimization and Multihoming July 2008 o Re-using Care-of Keygen Tokens For route optimization signaling with a correspondent node, the mobile node need not perform separate return routability procedures for each of the home addresses. Instead, one pair of HoTI/HoT message exchange for each home address is sufficient. The care-of keygen tokens can be used independently with each home keygen token. Below illustrates the use of three home addresses with one care-of address. Mobile Node Correspondent Node | | |------- HoTI for HoA1 (tunneled via HA) ------->| |<---- HoT(HoK1) for HoA1 (tunneled via HA) -----| |------- HoTI for HoA2 (tunneled via HA) ------->| |<---- HoT(HoK2) for HoA1 (tunneled via HA) -----| |------- HoTI for HoA3 (tunneled via HA) ------->| |<---- HoT(HoK3) for HoA3 (tunneled via HA) -----| |-------------------- CoTI --------------------->| |<----------------- CoT(CoK) --------------------| |---------------- BU for HoA1 ------------------>| |---------------- BU for HoA2 ------------------>| |---------------- BU for HoA3 ------------------>| | | Here, HoK1, HoK2, HoK3 are the home keygen tokens for the home addresses HoA1, HoA2, HoA3 of the mobile node respectively, and CoK is the care-of keygen token for the care-of address CoA of the mobile node. o Binding Multiple Home Addresses in Correspondent Node If multiple home addresses is included in a single binding update message sent to the correspondent node, multiple home nonce indices must be specified as well. The main consideration next is whether multiple mobility management key (Kbm) should be generated, one for each home address; or a single unified Kbm should be used. Using multiple Kbm has the advantage of flexibility. The mobile node may later choose to update the bindings associated to a single home address without having to generate a new Kbm. Using a single Kbm would be the more natural choice if multiple home addresses are specified in a single binding update. This way, only one Authenticator value is needed. When multiple Kbm are used, multiple Authenticator values must be present in the binding update message. A binding update message Ng & Aso Expires January 9, 2009 [Page 5] Internet-Draft MIPv6 Optimization and Multihoming July 2008 would be something similar to the following: IPv6 Header Source = MN's CoA Destination = CN Destination Header Home Address Option = MN's HoA1 Home Address Option = MN's HoA2 Home Address Option = MN's HoA3 Mobility Header Message Type = Binding Update Nonce Indices Option Home Nonce Index for HoA1 Care-of Nonce Index for CoA Nonce Indices Option Home Nonce Index for HoA2 Care-of Nonce Index for CoA Nonce Indices Option Home Nonce Index for HoA3 Care-of Nonce Index for CoA Binding Authorization Data Authenticator value using keygen for HoA1 Binding Authorization Data Authenticator value using keygen for HoA2 Binding Authorization Data Authenticator value using keygen for HoA3 The reader would note that this looks like a simple aggregation of three binding updates into a single message. The complexity in processing such a binding update message may not be justified for the mere saving of bandwidth compared to the sending of three separate binding updates (one for each home address). The other alternative will be to use a single Kbm. In this case, the Kbm may be generated by: Kbm = SHA1 (HoK1 | HoK2 | HoK3 | CoK) Only one Authenticator value is needed in this case, although multiple Nonce Indices Options are still needed. 2.2.2. Mobile Node with Multiple Care-of Addresses Binding of multiple care-of addresses to a home agent is already being developed in [8], and its security consideration discussed in [7] and [11]. As such, they would not be duplicated here. Instead, Ng & Aso Expires January 9, 2009 [Page 6] Internet-Draft MIPv6 Optimization and Multihoming July 2008 we focus on the binding of multiple care-of addresses to a correspondent node, and some approaches to optimizing the signaling. o Binding Multiple Care-of Addresses at Correspondent Node When a mobile node wishes to bind multiple care-of addresses to its home address at a correspondent node, the current approach specified in [8] is to use a Binding Identifier (BID) to reference each care-of address binding. So, assuming a mobile node MN with three care-of addresses CoA1, CoA2, and CoA3, it will send one HoTI message and three CoTI messages (one for each care-of address) to the correspondent node CN. After collecting the keygen tokens, it will send three binding update messages, one for each care-of address, and each with a different BID value. This is illustrated below. Mobile Node Correspondent Node ---------------- ------------------ CoA1 CoA2 CoA3 | | | |------- HoTI (via HA) -------------->| | | |<------- HoT (via HA) ---------------| |------------------------ CoTI ------------------>| |<-------------------- CoT (CoK1) ----------------| | |------------------ CoTI ------------------>| | |<-------------- CoT (CoK2) ----------------| | | |------------ CoTI ------------------>| | | |<-------- CoT (CoK3) ----------------| |---------------- BU (BID=1, using Kbm1) -------->| | |---------- BU (BID=2, using Kbm2) -------->| | | |---- BU (BID=3, using Kbm3) -------->| As we can see from above, the mobile node will need to gather three care-of keygen tokens (CoK1, CoK2, CoK3) and combine each of them with the home keygen token (HoK) to form three mobility management keys (Kbm1, Kbm2, and Kbm3). Each of these keys is then used to protect the binding update message. The next logical step for optimization is to combine all the binding update messages into one message, or what is known a Bulk BU. This means that multiple care-of addresses are included in the Bulk BU message. As in Section 2.2.1, we could continue to use multiple Authenticator values or a single Authenticator value. Using multiple Authenticator values would mean using each of the three keys Kbm1, Kbm2 and Kbm3 to generate a cryptographic checksum of the Bulk BU. Using a single Authenticator value means that the care-of keygen tokens should be combined to form a single Ng & Aso Expires January 9, 2009 [Page 7] Internet-Draft MIPv6 Optimization and Multihoming July 2008 key, Kbm*, possibly given by: Kbm* = SHA1 (HoK | CoK1 | CoK2 | CoK3) With this, only one Authenticator value is needed, although multiple Nonce Indices Options is still required in the Binding Update message to contain all the care-of nonce indices. The Authenticator value given by First (96, HMAC_SHA1 (Kbm*, (care-of address | correspondent | BU))) could either remain the same and use the care-of address that appears as the source of the binding update in the calculation, or one could change the Authenticator value into the following to use all three care-of addresses: First (96, HMAC_SHA1 (Kbm*, (CoA1 | CoA2 | CoA3 | correspondent | BU))) o Optimizing based on Usage of Care-of Addresses Another approach to optimization would be to remove redundant signaling based on the usage of care-of addresses. Return routability procedure establishes the validity of a care-of address as a source address of a packet sent from the home address, and the reachability of the home address at the care-of address (when care-of address is used as destination). If, in a scenario, it is not necessary to establish both the validity and the reachability of a care-of address, then one could reduce the amount of signaling messages needed in the return routability procedure to establish only the needed characteristics of the care-of address. It is not possible to do so with only one care-of address, since a pair of packet exchange is required to prove anything. However, with multiple care-of addresses, such optimization becomes possible. In one example, a mobile node MN with multiple care-of addresses (CoA1 and CoA2) could assign different usage for each of its care-of addresses. For instance, CoA1 could be only used for transmitting data to the correspondent node CN, whereas CoA2 is only used for receiving data from CN. In this case, it is not necessary to establish the reachability of CoA1 as a destination address. Neither is it useful to establish the validity of CoA2 as a source address. An approach for optimization is thus to send a CoTI from CoA1 to CN. In this CoTI message, it is indicated that CoA1 is a transmit-only address and CoA2 is specified as a Ng & Aso Expires January 9, 2009 [Page 8] Internet-Draft MIPv6 Optimization and Multihoming July 2008 receive-only address. CN then generates the paired care-of keygen token, PCoK, using PCoK = First (64, HMAC_SHA1 (Kcn, (CoA1 | CoA2 | nonce | 3))) The last octet '3' is used to differentiate the PCoK from a normal CoK. This included in a CoT message that is sent to the receive- only care-of address CoA2. Finally, to complete the optimized return routability procedure (which could be aptly termed as "Paired Return Routability Procedure"), MN sends a binding update message to CN. The binding update message is sent from CoA1, and includes new option to indicate that the source address is a transmit-only address and specify that CoA2 is a receive-only address. The Authenticator value is given by First (96, HMAC_SHA1 (PKbm, (CoA1 | CoA2 | correspondent | BU))) where the paired mobility management key, PKbm, is given by PKbm = SHA1 ( HoK | PCoK ) If a binding acknowledgement is sent, it should be sent to the receive-only care-of address CoA2. The message sequence illustrates the paired return routability procedure. Mobile Node Correspondent Node ------------ ------------------ CoA1 CoA2 | |--------------- HoTI (via HA) -------------->| | |<--------- HoT (via HA) ---------------| |-------------- CoTI (pair=CoA2) ------------>| | |<---------- CoT (PCoK) ----------------| |--------------- BU (Pair=CoA2) ------------->| | |<------------- BAck -------------------| The CN must in this case record in its binding cache that CoA1 is only used to receive data from MN, and CoA2 is only used to transmit data to MN. o Optimizing based on Network Infrastructure The above pairing of care-of addresses can also be used within a controlled network infrastructure, such as those provided by cellular operators, or a network with Source Address Validation Ng & Aso Expires January 9, 2009 [Page 9] Internet-Draft MIPv6 Optimization and Multihoming July 2008 Architecture (SAVA) in place. Characteristics of such a network infrastructure is that it guarantees the reachability of an address as a destination address if the validity of the address as a source address is proven, and vice versa. This can be achieved, for instance in a cellular operator controlled network with aggressive ingress filtering on all network components. With such a network infrastructure in place, it is no longer necessary for a correspondent node to use both the CoTI and CoT messages to establish the reachability of a care-of address as a destination address and validity of the care-of address as a source address. Since establishing one characteristic (eg. validity as source) implies the other (eg. reachability as destination), the CoTI and CoT messages can be used to test two care-of addresses. This optimization is similar to the pairing of two care-of addresses in the above discussion of Paired Return Routability Procedure. 2.3. Security Threats At first glance, it seems that the inclusion of multiple home addresses (see Section 2.2.1) and multiple care-of addresses (see Section 2.2.2) in a single binding update message would not expose the recipient to additional security threats other than those already existed in the original binding update mechanism of RFC 3775 (see [12]). Similarly, the use of the Pairing Return Routability Procedure does not seems to have additional security concerns compared with using multiple Return Routability procedures, if the assumptions behind its usage are valid (i.e. care-of addresses are used for transmitting or receiving only, or the underlying network infrastructure guarantees the reachability or validity given one is proven). This is because these optimizations utilize all components of the original return routability procedure -- they merely optimize by merging some messages into one. Of-course, it is only prudent for one to analyze the security threats more rigorously before actually adopting any of these optimizations. The author hereby invites interested researchers to do so, and discuss the security implications for inclusion in future version of this draft. Ng & Aso Expires January 9, 2009 [Page 10] Internet-Draft MIPv6 Optimization and Multihoming July 2008 3. Multihomed Correspondent Node 3.1. Scenario There are two main possibilities why a correspondent node can be multihomed. Firstly, the correspondent node can be on a multihomed site. Secondly, the correspondent node may be using multiple interfaces. In both cases, the correspondent node would configure multiple addresses, and may use more than one address when communicating with the mobile node. Such communications may take the form of: o Single Session: with the use of multihoming-capable protocols such as Stream Control Transmission Protocol (SCTP) [13], or Site Multihoming by Intermediation (Shim6) [14], the correspondent node and mobile node may be having only a single transport session, even though multiple addresses are used. o Multiple Sessions: the correspondent node may wish to perform load balancing between its multiple addresses such that, for instance, audio streams would use one address while video stream uses another address when having a video conference session with the mobile node. In both of the forms, the packet data unit (PDU) received by the IP layer of the mobile node from the upper layers will be addressed to multiple addresses belonging to the correspondent node. In the Single Session case, the SCTP or SHIM6 protocol layer will split the traffic stream into different PDUs to be sent to different addresses of the correspondent node. In the Multiple Sessions case, the applications will open different sessions addressed to different addresses of the correspondent node. Either way, the Mobile IP layer will not be aware of the fact that all these different addresses belong to the same physical node. When route optimization is attempted, the mobile node will initiate return routability procedure with each and every of the correspondent node's addresses, oblivious to the fact that only one set of return routability procedure is needed to bind its care-of address to its home address at the correspondent node. 3.2. Approaches for Optimization Approaches to eliminate such redundant signaling would involve making the Mobile IP layer of the mobile node aware that the addresses all belongs to the same correspondent node. In one approach, special application programming interface (API) is provided to allow upper layers to link a set of addresses as belonging to a single entity. This will allow SCTP, Shim6 or other multihoming protocols to inform Ng & Aso Expires January 9, 2009 [Page 11] Internet-Draft MIPv6 Optimization and Multihoming July 2008 the Mobile IP layer that route optimization is enabled with all the addresses in the linked set as long as return routability procedure is successfully conducted with one of the addresses in the linked set. The disadvantage of this approach is that it relies on upper layers to utilize the newly provided API. Old, unmaintained programs would not be able to do so, resulting in redundant signaling. Another approach is for the correspondent node to inform the mobile node of all its addresses upon receiving the first signaling message from the mobile node. This may be any one of the Home Test Init, Care-of Test Init or Binding Update messages. Upon responding with the Home Test, Care-of Test or Binding Acknowledgment messages, the correspondent node may include the list of addresses it owns, so that the mobile node would know that it need not repeat the return routability procedure with these addresses. 3.3. Security Threats There are security threats that needs to be analyzed for the second approach. Two aspects of the threat analysis should be covered: o the threats on the mobile node This is generally the case where a malicious correspondent node sends back a list of fake addresses. This would cause the mobile node to wrongly assume that route optimization with an address is established when it is in fact not. To illustrate how this can be used as an attack, consider a mobile node MN having communications with two correspondent nodes CN1 and CN2. Suppose that CN1 is malicious such that when MN attempts to perform route optimization with CN1, it informs MN that it also owns the address of CN2. This would trick MN into thinking that it has already established route optimization with CN2. Packets sent to CN2 from MN would thus be using the care-of address of MN as source and containing the home address destination option. However, since CN2 does not actually have a binding cache entry of the care-of address and home address of MN, these packets will be discarded, thus causing a denial-of service. o the threats on the correspondent node This is generally the case where a malicious node initiate return routability procedure with a correspondent node, tricking it to revealing the list of addresses it owns. This does not seems to be a serious threat at first glance, since if the correspondent node does not wish its list of addresses to be known, it can always be configured to not return the list of addresses. Ng & Aso Expires January 9, 2009 [Page 12] Internet-Draft MIPv6 Optimization and Multihoming July 2008 To eliminate the security threat to the mobile node, the mobile node would probably need to perform a test on the list of addresses it received. A simple echo and response test on the addresses using the route optimized path would suffice. For instance, consider a mobile node MN communicating with a correspondent node CN with three addresses, CN.Addr1, CN.Addr2, and CN.Addr3. Upon initiating route optimization with CN.Addr1, MN receives the list of addresses from CN that claims to own CN.Addr2 and CN.Addr3 as well. To test the validity of this claim, MN needs to send a, say, ICMP Echo Request message to each of CN.Addr2 and CN.Addr3. Each IMCP Echo Request message would assume route optimization is achieved, i.e. each message will use the care-of address of MN as the source address, and contain the home address of MN in the home address destination option. If the addresses CN.Addr2 and CN.Addr3 are valid, MN will receive ICMP Echo response message from each of these addresses. The ICMP Echo Response messages should also contain the care-of address of MN as the source address and have a type 2 routing header bearing the home address of MN. Such a test adds one more pair of message exchange per correspondent node address, but it is still better than the six messages required by return routability if the mobile node did not know that the addresses belong to the same node. It is possible to further optimize the number of signaling by adding an option in the ICMP Echo Request message sent to CN.Addr2, such that the ICMP Echo Response message will be sent via CN.Addr3. This way, we eliminate another pair of message exchange. The figure below illustrates this. Mobile Node Correspondent Node ----------- --------------------- | Addr1 Addr2 Addr3 |----------- HoTI (via HA) ----------->| | | |<----------- HoT (via HA) ------------| | | |---------------- CoTI --------------->| | | |<--------------- CoT -----------------| | | |----------------- BU ---------------->| | | |<--- BAck (specify: Addr2, Addr3) ----| | | |----------- ICMP Echo Req ------------------->| | |<-----------ICMP Echo Resp ---------------------------| One could of-course use binding update and binding acknowledgement messages to replace the ICMP Echo request and response messages. Ng & Aso Expires January 9, 2009 [Page 13] Internet-Draft MIPv6 Optimization and Multihoming July 2008 4. Multihomed Anchor Node 4.1. Scenario In this section, multihomed anchor points are considered. Anchor points include home agents in Mobile IPv6 and NEMO Basic Support, mobility anchor points (MAP) in Hierarchical Mobile IPv6 (HMIPv6) [15], and local mobility anchor (LMA) in Proxy Mobile IPv6 (PMIP) [16]. We would largely concentrate on the Mobile IPv6 or NEMO home agents at this point, although most of the discussions should be equally applicable to mobility anchor points and local mobility anchors as well. As home agents (and anchor points in generally) are routers by definition, they would usually have multiple interfaces (and thus multihomed). In this document, we are only interested in the case when a home agent has multiple global addresses configured on its egress interface(s) such that a mobile node that is away from the home link can contact the home agent via multiple paths. This scenario usually means that the home agent is connected to multiple egress routers, and each of the home agent's address would be reachable via one egress routers. Another possible scenario is when the home agent is managing separate home links, possibly configuring a different home agent address on the each home link. 4.2. Approaches for Optimization In the case where the home agent has different egress routes, one possible optimization is to let the mobile node knows the network characteristics of each egress path. This allows the mobile node to (1) select which egress path to use when tunneling packets to the home agent, and (2) request the home agent to use a particular egress route when forwarding packets to the correspondent node or mobile node. o Informing mobile node egress characteristics of home agent Information on the egress characteristics of the home agent can be transmitted to the mobile node by attaching them onto the Binding Acknowledgement message as new options, or be sent using existing protocol by running it over the bi-directional tunnel between the mobile node and the home agent. o Tunneling packets from mobile node to home agent With the information on the egress characteristics of the home agent, the mobile node can then select the appropriate path to reach the home agent when tunneling packets to the home agent for Ng & Aso Expires January 9, 2009 [Page 14] Internet-Draft MIPv6 Optimization and Multihoming July 2008 forwarding. This assumes that there are multiple globally routable unicast addresses of the home agent for the mobile node to choose from, and using one such home agent address implies the choosing one particular path to reach the home agent. o Forwarding packets to correspondent node Once the home agent received a packet to be forwarded to a correspondent node, the home agent will need to choose which of its available egress path it can use to forward the packet out. One way is to simply forward the packet out the same way as it was received -- since the mobile node chooses to tunnel this packet via a particular egress interface of the home agent, it makes sense to assume that the mobile node would want the packet to be forwarded to the correspondent node via the same egress interface. Another alternative is to allow the mobile node to explicitly specify which egress interface to use by using new options in the Destination Header of the tunnel packet. o Forwarding packets to mobile node When the home agent intercepted a packet to be forwarded to the mobile node, the home agent will need to choose which of its available egress path it can use to forward the packet out. The obvious approach to allow this is to use similar concept of the flow binding mechanism [17] currently being developed by the MExt Working Group, and allows each flow binding filter to specify which egress interface of the home agent to use for (in addition to which care-of address of the mobile node to use) for a given flow. In the case where the home agent is managing separate home links, a possible scenario is for a mobile node to subscribe to multiple home links managed by the same home agent. The mobile node may sees different home agent addresses on different home links and think they are separate entities. A small optimization here would be for the home agent to inform the mobile node that it owns the different home agent addresses. This way, the mobile node can specify multiple home addresses in a single binding update to the home agent (see Section Section 2.2.1). 4.3. Security Threats As signaling between the home agent and the mobile node is protected by security association, there are no third party security threats. A home agent may falsely claim to be multihomed -- but obviously, if a home agent has malicious intent or is compromised, it can do much more harm to the mobile node then claiming to own addresses it does Ng & Aso Expires January 9, 2009 [Page 15] Internet-Draft MIPv6 Optimization and Multihoming July 2008 not actually own. 5. Conclusion This memo explores the use of multihoming and mobility protocols simultaneously, and investigates specifically if there are further enhancements that can be done in such situations. We had analyzed the cases where the mobile node, the correspondent node, and the anchor point are multihomed, and discussed various possible optimizations in each case. 6. Informative Reference [1] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [4] Bagnulo, M. and J. Abley, "Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)", draft-ietf-shim6-applicability-03 (work in progress), July 2007. [5] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6-multihoming-motivation-scenario-03 (work in progress), May 2008. [6] Narayanan, V., Thaler, D., Bagnulo, M., and H. Soliman, "IP Mobility and Multi-homing Interactions and Architectural Considerations", draft-vidya-ip-mobility-multihoming-interactions-01 (work in progress), July 2007. [7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", draft-ietf-monami6-mipv6-analysis-05 (work in progress), May 2008. [8] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, Ng & Aso Expires January 9, 2009 [Page 16] Internet-Draft MIPv6 Optimization and Multihoming July 2008 "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008. [9] Ng, C. and T. Ernst, "Multiple Access Interfaces for Mobile Nodes and Networks", 12th IEEE International Conference on Networks, Vol 2, Pages 774-779, 2004. [10] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007. [11] Lim, B., Ng, C., and K. Aso, "Verification of Care-of Addresses in Multiple Bindings Registration", draft-lim-mext-multiple-coa-verify-01 (work in progress), February 2008. [12] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [13] 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. [14] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work in progress), February 2008. [15] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [16] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-18 (work in progress), May 2008. [17] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-ietf-mext-flow-binding-00 (work in progress), May 2008. Appendix A. Change Log o draft-ng-mobopts-multihoming-02: * Added Section for "Multihomed Anchor Points" Ng & Aso Expires January 9, 2009 [Page 17] Internet-Draft MIPv6 Optimization and Multihoming July 2008 o draft-ng-mobopts-multihoming-01: * Added Section for "Multihomed MN" * Re-organized "Multihomed CN" and added discussion on mitigating the security threats o draft-ng-mobopts-multihoming-00: * Initial version. Ng & Aso Expires January 9, 2009 [Page 18] Internet-Draft MIPv6 Optimization and Multihoming July 2008 Authors' Addresses 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 Keigo Aso Matsushita Electric Industrial Co. Ltd. (Panasonic) 5-3 Hikarino-oka Yokosuka, Kanagawa 239-0847 JP Phone: +81 46 840 5123 Email: asou.keigo@jp.panasonic.com Ng & Aso Expires January 9, 2009 [Page 19] Internet-Draft MIPv6 Optimization and Multihoming July 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. Ng & Aso Expires January 9, 2009 [Page 20]