Network Working Group E. Wu Internet-Draft G. Daley Expires: August 15, 2005 A. Sekercioglu Monash University CTIE S. Narayanan Panasonic February 14, 2005 Direct Signaling for Mobile IPv6 Return Routability Procedure draft-ewu-mobopts-directsig-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract In Mobile IPv6, mobile nodes must complete Return Routability Procedure and binding process before route optimization for data packet transmission is performed. This requires signaling exchange between the mobile and correspondent node. For the current specification, signaling is restricted to be routed to the mobile's and correspondent node's home addresses. Wu, et al. Expires August 15, 2005 [Page 1] Internet-Draft Mobile IPv6 Direct Signaling February 2005 This document describes a mechanism to enable mobile and correspondent nodes to send the signaling packets directly to their care-of addresses. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 MN to MN Signaling . . . . . . . . . . . . . . . . . . . . 3 2. MN-to-MN Communications via Indirect Signaling Route . . . . . 4 3. Direct MN-to-MN Signaling Route . . . . . . . . . . . . . . . 6 4. Recovery from Failure . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 10 Wu, et al. Expires August 15, 2005 [Page 2] Internet-Draft Mobile IPv6 Direct Signaling February 2005 1. Introduction Mobile IPv6 Route Optimization is a flexible mechanism which allows Mobile Nodes (MNs) to negotiate with their peer Correspondent Nodes (CNs) as to whether the peer sends data to its visited or its home location. Route Optimization in Mobile IPv6 requires some proof of ownership test before sending a Binding Update message, which changes the CN's knowledge of where the MN is, by providing a visited network Care-of-Address for packet delivery [1]. Below is a diagram showing the logical path taken by signaling messages used in binding signaling, and the basic authorization scheme for mobility: Return Routability. +----+ | HA | | MN | +----+ / | / | / | / | HoTI/HoT | / HoTI/HoT / | / | / | / | / | +----+ / +----+ | |/ | | | CN |-------------| MN | +----+ CoTI/CoT/BU +----+ Figure 1: Return Routability and Binding Update Signaling paths 1.1 MN to MN Signaling When two Mobile IPv6 Mobile Nodes each decide to perform route optimization to each other, the MNs can send data on the data path between each other's Care-of-Addresses on their visited networks. When they transmit binding signaling to each other though, they are not allowed to transmit mobility signaling messages to the peer's CoA, and must send messages to Home Addresses (HoAs) on the Home Wu, et al. Expires August 15, 2005 [Page 3] Internet-Draft Mobile IPv6 Direct Signaling February 2005 Network, without reference to the Binding Cache[1]. This is a result of an oversight in earlier Mobile IPv6 specifications, discovered through testing. Two mobile nodes would successfully update each other at the CoA with Return Routability and Binding messages, unless one wasn't able to complete mobility signaling before the other moved. In this case MNs would retry binding messages to the incorrect care-of-address. Subsequent versions of the Mobile IPv6 draft specifications removed this anomaly, making Binding Update, CoTI and HoTI messages get sent to Home Address messages in order to provide robust signaling [1]. This document describes a possible route optimization to the return routability procedure and binding process between two communicating nodes while attaching to foreign links. It describes the differences between signaling to Home Addresses, and signaling to care-of-addresses, and provides some motivation for sending signaling messages directly. It presents a robust and efficient method for solving the simultaneous movement issue, which prevented Mobile IPv6 sending directly to a mobile Correspondent Node's (CN's) Care of Address. 2. MN-to-MN Communications via Indirect Signaling Route Mobile Node to Mobile Node Signaling in Mobile IPv6 may not use the binding cache entry [1]. This means that when an MN moves and signals to its CN, the signaling messages traverse a longer path than the data messages. Additional cost of indirect signaling is associated with i) round trip delays for packets traveled to the Correspondent Node's home network ii) additional transmission delays for the use of additional IPv6 headers for packets sending via the home agent (i.e. tunneling). As can be seen in Figure 2, the additional duration is related to how far the CN is from its home network. All signaling messages are diverted to the Home Agent before traveling to the CN's location. Where there are time constraints or loss bounds for data traffic, this may affect the function of applications by increasing the service restoration time after movement. In some cases, binding signaling messages may arrive after data messages. For an address which is not already bound, this results in Wu, et al. Expires August 15, 2005 [Page 4] Internet-Draft Mobile IPv6 Direct Signaling February 2005 packet loss. Also, no signaling message ever tests the data path (between the CoAs) before application data traverses it. +----+ HoTI/HoT +----+ | HA |----------| HA | | CN | | MN | +----+\ +----+ | \ | | \ | | \ | | CoTI/CoT/BU | | \ | HoTI/HoT/CoTI/CoT/BU \ HoTI/HoT | \ | | \ | | \ | +----+ +----+ | | | | | CN | | MN | +----+ +----+ Figure 2: Indirect signaling route On the positive side, when signaling to the CN's home address, messages will only go missing due to movement in the interval between when the CN moves, and the time it takes to update its own Home Agent. The following equation defines delays for indirect signaling exchange, D: D = max( RTT MN-HAMN + RTT HAMN-HACN + RTT HACN-CN, RTT MN-HACN + RTTHACN-CN) + T MN-HACN + T HACN-CN where, RTT is the round trip time delay between two intermediate nodes A and B, expressed as "RTT A-B" T is the transmission (one way trip) delay from node A to node B, expressed as "T A-B" MN is the mobile node CN is the Correspondent Node Wu, et al. Expires August 15, 2005 [Page 5] Internet-Draft Mobile IPv6 Direct Signaling February 2005 HAMN is the Mobile Node's Home Agent HACN is the Correspondent Node's Home Agent 3. Direct MN-to-MN Signaling Route When Mobile Nodes use direct signaling, they consult their binding cache before transmitting mobility signaling to their peers. If the peer CN is mobile, the MN may attempt to send signaling directly to the CN's Care-of-Address. All operations which regard the MN's own Care-of-Address still operate as in Mobile IPv6, including the source address for CoTI and HoTI messages [1]. The signaling paths used for direct signaling are described in Figure 3. Binding Update messages, CoTI and HoTI messages are transmitted to the CN's CoA, and their responses from the CN are sent from the same addresses, transmitted back to the origin of the packet. It is notable that in order to provide interoperability with Mobile IPv6 Nodes, that mobility signaling does not take on any additional Routing Headers or Home Address options through adopting the direct signaling path. This means that the overheads for signaling messages are actually lower for successful signaling exchanges on the direct path, because they do not incur tunnel overheads. Wu, et al. Expires August 15, 2005 [Page 6] Internet-Draft Mobile IPv6 Direct Signaling February 2005 +----+ +----+ | HA | | HA | | CN | | MN | +----+ +----+ / | / | / | HoTI/HoT | / | / HoTI/HoT / | / | / | / | / | / | +----+/ +----+ | | | | | CN |-------------| MN | +----+ CoTI/CoT/BU +----+ Figure 3: Direct signaling route Therefore, the delay incurred by signaling exchange on the direct path is: Ddirect = max(RTT MN-HAMN + RTT HAMN-CN, RTT MN-CN) + T MN-CN) The largest delay component is likely to be the the home test return routability operation. Where this can be done off the critical path, the return routability and binding signaling delays becomes up to three messages on the route optimized data path between the MN and CN. When signaling directly to the CN's Care-of-Address, packets may be lost if the CN moves away from that visited network before binding signaling completes. Robustness mechanisms which handle this case are described in Section 4. 4. Recovery from Failure When signaling to the CN's Care-of-Address there is a chance that the CN will move before the BU is received. Where Binding signaling is being Acknowledged (or responded to with HoT or CoT), it is possible to determine if the CN received a particular message. If the MN receives an acknowledging message to its directly transmitted signaling message, it knows that binding signaling has completed, and that both the MN and CN have each other's CoA bindings correct. Wu, et al. Expires August 15, 2005 [Page 7] Internet-Draft Mobile IPv6 Direct Signaling February 2005 Where timeout occurs waiting for a response, it is possible that the peer CN may have moved, and the MN's own Binding Cache state is therefore suspect (even though the lack of response may be due to packet loss). In this case, the MN sends mobility signaling to the CN through its Home Address without reference to the binding cache entry's stored Care-of-Address. This allows robust fallback to Mobile IPv6's procedures, and avoids the failed retries which would occur otherwise on simultaneous movement. When binding cache entries are succeeding, the binding signaling occurs on the direct (fast) transmission path. 5. Security Considerations When a host signals directly to the MN, it is able to bypass the CN's home network, but not its own. Therefore each of the Return Routability tests provided by Mobile IPv6 is still valid, and the MNs each prove they are on the path to the Care-of and Home Addresses. Since the signaling path to a mobile CN for HoTI/Hot and CoTI/CoT are now less diverse with direct signaling, it may be slightly easier for attackers to intercept or spoof signaling to steal or redirect packets. In the worst case, this becomes the same as for a fixed CN. 6 References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Authors' Addresses Eric Wu Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4996 EMail: eric.wu@@eng.monash.edu.au Wu, et al. Expires August 15, 2005 [Page 8] Internet-Draft Mobile IPv6 Direct Signaling February 2005 Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4655 EMail: greg.daley@@eng.monash.edu.au Ahmet Sekercioglu Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 3503 EMail: ahmet.sekercioglu@@eng.monash.edu.au Sathya Narayanan Panasonic Digital Networking Lab 2 Research Way Princeton, NJ 08540 U.S.A. Phone: (609) 734 7599 EMail: sathya@@Research.Panasonic.COM Wu, et al. Expires August 15, 2005 [Page 9] Internet-Draft Mobile IPv6 Direct Signaling February 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wu, et al. Expires August 15, 2005 [Page 10]