Mobopts Research Group C. Ng Internet-Draft Panasonic Expires: August 20, 2008 K. Aso Matsushita Electric Industrial Co. Ltd. (Panasonic) February 17, 2008 On Mobile IPv6 Optimization and Multihoming draft-ng-mobopts-multihoming-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 August 20, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Ng & Aso Expires August 20, 2008 [Page 1] Internet-Draft MIPv6 Optimization and Multihoming February 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 . . . . . 7 2.3. Security Threats . . . . . . . . . . . . . . . . . . . . . 11 3. Multihomed Correspondent Node . . . . . . . . . . . . . . . . 12 3.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Approaches for Optimization . . . . . . . . . . . . . . . 12 3.3. Security Threats . . . . . . . . . . . . . . . . . . . . . 13 4. Multihomed Anchor Node . . . . . . . . . . . . . . . . . . . . 16 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Informative Reference . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Ng & Aso Expires August 20, 2008 [Page 2] Internet-Draft MIPv6 Optimization and Multihoming February 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 consider 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. [AUTHOR'S NOTE]: Due to time constraint, Section 4 on "Multihomed Anchor Node" will be added in future update of this draft. Ng & Aso Expires August 20, 2008 [Page 3] Internet-Draft MIPv6 Optimization and Multihoming February 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 August 20, 2008 [Page 4] Internet-Draft MIPv6 Optimization and Multihoming February 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 August 20, 2008 [Page 5] Internet-Draft MIPv6 Optimization and Multihoming February 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 Nouce Indices Option Home Nonce Index for HoA1 Care-of Nonce Index for CoA Nouce Indices Option Home Nonce Index for HoA2 Care-of Nonce Index for CoA Nouce 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. This would simplify the key management process of the mobile node if it uses multiple home addresses to communicate with a correspondent node (such as through Shim6). Ng & Aso Expires August 20, 2008 [Page 6] Internet-Draft MIPv6 Optimization and Multihoming February 2008 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, 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 Ng & Aso Expires August 20, 2008 [Page 7] Internet-Draft MIPv6 Optimization and Multihoming February 2008 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 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))) This would simplify the key management in the mobile node, since only one Kbm is needed. 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. Example of such scenario will be the case where the mobile node has higher downlink than uplink capacity in one of its interfaces (i.e. asynchronous, eg. some modes in UMTS, or Satellite Comms). Then, the mobile node would Ng & Aso Expires August 20, 2008 [Page 8] Internet-Draft MIPv6 Optimization and Multihoming February 2008 possibly configure (via application support or flow filtering) the interface to be receive only, while other interface that is more balanced in terms of uplink and downlink capacities (eg WiFi) for transmit only. 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 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. Ng & Aso Expires August 20, 2008 [Page 9] Internet-Draft MIPv6 Optimization and Multihoming February 2008 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 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. This obviously cannot be assumed with the current interent in place. It can only be used in an environment where both the correspondent node and the mobile node are in a controlled network, such as 3GPP networks. Ng & Aso Expires August 20, 2008 [Page 10] Internet-Draft MIPv6 Optimization and Multihoming February 2008 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 August 20, 2008 [Page 11] Internet-Draft MIPv6 Optimization and Multihoming February 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 August 20, 2008 [Page 12] Internet-Draft MIPv6 Optimization and Multihoming February 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. This, however, can be easily detected by MN, since CN2 must response with a binding error message. This error message would allow MN to know that CN2 does not actually have any binding of its home address and care-of address; thus, MN would initiate the return routability procedure with CN2. o the threats on the correspondent node This is generally the case where a malicious node initiate return Ng & Aso Expires August 20, 2008 [Page 13] Internet-Draft MIPv6 Optimization and Multihoming February 2008 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. As discussed above, there seems to be minimal threats in such optimizations. The mobile node can rely on binding error message to eliminate denial-of service attacks, and the correspondent node can be configured to not return its list of addresses to protect its privacy. However, since binding error message will only be sent in response to a packet sent by the mobile node, the mobile node may not be able to detect a wrong assumption of route optimization being established only after a few packets has been received from the correspondent node. This is the case when the communications between mobile node and correspondent node is such that the correspondent node is doing most of the transmission. In such cases, the mobile node could perform a simple echo and response test on the addresses using the route optimized path. 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 (else, MN will receive Binding Error 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. Ng & Aso Expires August 20, 2008 [Page 14] Internet-Draft MIPv6 Optimization and Multihoming February 2008 Mobile Node Correspondent Node ----------- --------------------- | Addr1 Addr2 Addr3 |----------- HoTI (via HA) ----------->| | | |<----------- HoT (via HA) ------------| | | |---------------- CoTI --------------->| | | |<--------------- CoT -----------------| | | |----------------- BU ---------------->| | | |<--- BAck (specify: Addr2, Addr3) ----| | | |------- ICMP Echo Req (with HAO) ------------>| | |------- ICMP Echo Res (with RH2) -------------| | |------- ICMP Echo Req (with HAO) -------------------->| |------- ICMP Echo Res (with RH2) ---------------------| Ng & Aso Expires August 20, 2008 [Page 15] Internet-Draft MIPv6 Optimization and Multihoming February 2008 4. Multihomed Anchor Node TBD 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 and the correspondent node are multihomed, leaving the case where the mobility anchor is multihomed as future work in subsequent versions. 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-02 (work in progress), July 2007. [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-04 (work in progress), November 2007. Ng & Aso Expires August 20, 2008 [Page 16] Internet-Draft MIPv6 Optimization and Multihoming February 2008 [8] Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-05 (work in progress), January 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-00 (work in progress), November 2007. [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. Appendix A. Change Log 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 August 20, 2008 [Page 17] Internet-Draft MIPv6 Optimization and Multihoming February 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 August 20, 2008 [Page 18] Internet-Draft MIPv6 Optimization and Multihoming February 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). Ng & Aso Expires August 20, 2008 [Page 19]