Network Working Group E. Wu Internet-Draft G. Daley Expires: April 27, 2006 A. Sekercioglu Monash University CTIE S. Narayanan Panasonic October 24, 2005 Direct Signaling for Mobile IPv6 Return Routability Procedure draft-ewu-mobopts-directsig-01.txt 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 April 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 Wu, et al. Expires April 27, 2006 [Page 1] Internet-Draft Mobile IPv6 Direct Signaling October 2005 and correspondent node's home addresses. 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. Changes to Mobile Nodes . . . . . . . . . . . . . . . . . . . 8 5.1 Binding Update Format . . . . . . . . . . . . . . . . . . 8 6. Changes to Correspondent Nodes . . . . . . . . . . . . . . . . 9 6.1 Binding Acknowledgement Format . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Wu, et al. Expires April 27, 2006 [Page 2] Internet-Draft Mobile IPv6 Direct Signaling October 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 April 27, 2006 [Page 3] Internet-Draft Mobile IPv6 Direct Signaling October 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 packet loss. Wu, et al. Expires April 27, 2006 [Page 4] Internet-Draft Mobile IPv6 Direct Signaling October 2005 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 April 27, 2006 [Page 5] Internet-Draft Mobile IPv6 Direct Signaling October 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 April 27, 2006 [Page 6] Internet-Draft Mobile IPv6 Direct Signaling October 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 April 27, 2006 [Page 7] Internet-Draft Mobile IPv6 Direct Signaling October 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. Changes to Mobile Nodes In order to support direct signaling, both the CN and and MN function within a mobile node require modification. When acting as an MN, the Binding Update List needs to identify if the peer CN is capable of receiving signaling messages at CoAs, and be able to identify if the Binding Update or Return Routability operation is the first transmission, or occurs on a retransmission. 5.1 Binding Update Format In Figure 4 a modified binding update format is presented, which incorporates the new direct signaling request flag: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|D| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Binding Update Message (D) Direct signaling: This flag indicates that the MN is able to perform direct signaling. When requesting that a CN accept direct signaling the MN sends a BU to the CN's HoA indicating that it is capable of performing direct Wu, et al. Expires April 27, 2006 [Page 8] Internet-Draft Mobile IPv6 Direct Signaling October 2005 signaling (D=on). The MN also sets the 'A' flag, to force an Binding Acknowledgement to be sent. Recipients of the Direct Signaling flag acknowledge the BU with a BAck [1]. Those recipients capable (and willing) to receive binding signaling at their CoA respond with a specially modified Binding Ack, as described in the next section. All binding updates using the optimization, sent to the CoA MUST contain the Direct Signaling flag set. These packets MAY leave the BU's Ack flag unset. 6. Changes to Correspondent Nodes A correspondent node which is also mobile needs to be able to understand direct signaling Binding updates, which are addressed to its CoA. Existing Binding Cache principles segregate binding signaling directed to different addresses deliberately in order not to confuse bindings where multiple HoAs are in use. Therefore, binding signaling to a CoA of an existing Mobile IPv6 host would be placed in a logically separate binding cache to that directed to a HoA [1]. With direct signaling however, the CoAs are already advertised to remote HA, and it is easy to pre-determine if ambiguity may exist. Therefore it is possible to use a unified binding cache, where packets addressed to any of the CN's addresses are treated as the same BCE. 6.1 Binding Acknowledgement Format Received Binding Update packets containing the Direct Signaling flag set indicate that the sender is able to provide direct signaling. A receiver of this flag is required to send Binding Acknowledgement if the BU contained tha Ack Flag set. A CN which both understands the BU's Direct Signaling Flag, and wishes to receive signaling at its CoA sends back an Acknowledgement to the MN containing a responding Direct Signaling Ack Flag, if the CN is required to send a BAck. If the MN receives a response from the CN with the Direct Signaling Ack flag unset, it MUST NOT send a BU to the CN's CoA, but should send binding signaling messages to the CN's HoA. Wu, et al. Expires April 27, 2006 [Page 9] Internet-Draft Mobile IPv6 Direct Signaling October 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Binding Acknowledgement Message (D) Direct Signaling Ack: When set, allows the MN to sent a BU to either the CN's CoA or Home Address. CN's which are not configured for direct signaling will ignore the BU's Direct Signaling Flag, and will leave the Direct Signaling Ack flag unset. This ensures that the MN will fallback to the procedures defined in Mobile IPv6 [1]. 7. IANA Considerations If this draft is adopeted, it will be necessary to allocate the Direct Signaling Flag from Section 5.1, and the Direct Signaling Ack Flag from Section 6.1 for the respsective binding messages. 8. 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. 9. Normative References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Wu, et al. Expires April 27, 2006 [Page 10] Internet-Draft Mobile IPv6 Direct Signaling October 2005 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 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 April 27, 2006 [Page 11] Internet-Draft Mobile IPv6 Direct Signaling October 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 April 27, 2006 [Page 12]