Mip6 Working Group Henrik Petander Eranga Perera Internet Draft National ICT Australia Expires: April 2006 October 16, 2005 Improved Binding Management for Make Before Break Handoffs in Mobile IPv6 draft-petander-mip6-mbb-00.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. This document may only be posted in an Internet-Draft. 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 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Mobile IPv6 binding management has been designed for break-before- make handoffs, which can be performed by hosts equipped with a single Petander Expires April 16, 2006 [Page 1] Internet-Draft draft-petander-mip6-mbb-00.txt October 2005 interface. However, a Mobile Node may be equipped with multiple interfaces, allowing it to perform Make-Before-Break handoffs by connecting simultaneously to two overlapping access networks during the handoff. In theory these handoffs can be lossless, provided that there is sufficient overlap between the two networks. However, unless Mobile IPv6 bindings are managed carefully Mobile Node and Correspondent Node will have inconsistent binding state during the handoff, which will lead to packet loss. In this draft we propose changes to binding management for lossless make-before-break handoffs. The proposed changes do not affect the interoperability with Mobile IPv6 nodes not implementing these changes. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. We refer to Home Agent (HA) and Correspondent Node (CN) as Correspondent Node for brevity, and distinguish between them only when there is a difference in their or Mobile Node's behavior. 1. Introduction In a Break-Before-Make (BBM) handoff, Mobile Node (MN) loses connectivity with its old access network before connecting to a new one. In a Make-Before-Break (MBB) handoff MN is still connected to its old Access Router while performing a handoff using a new one. MBB handoffs can in theory be completely lossless, since MN can receive data to its Care-of Address (CoA) on the old access network while registering a new CoA with its HA and CNs via the new access network. Normally, only MNs equipped with multiple interfaces can perform MBB handoffs. For example, inter access technology handoffs can often be performed as MBB handoffs. A MN may also be equipped with multiple interfaces of the same type and can use them for lossless intra access technology handoffs as proposed in [3]. In this draft we propose an extension to Mobile IPv6 [2] signaling and binding management to enhance performance of MBB handoffs. We first describe the problem, and then look at possible solutions and finally we propose changes to Mobile IPv6 binding update list and binding cache management. 2. Problem of Inconsistent Binding State between MN and CN In MBB handoffs MN is able to receive and send data using its old CoA for the duration of the handoff to the new CoA. Completion of the Petander Expires April 16, 2006 [Page 2] Internet-Draft draft-petander-mip6-mbb-00.txt October 2005 handoff in Mobile IPv6 means either sending a Binding Update (BU) or receiving a Binding Acknowledgement (BA). In order for MN to be able to send and receive packets during the handoff, MN and CN need to have a synchronous state of the binding between the home address and the CoA of MN. The problem is that MN cannot know with certainty when the binding cache entry of CN is updated to the new CoA, only that it happens between sending of BU and receiving of BA. If MN changes its binding when sending BU (instead of waiting for BA), it will drop all packets CN sends using the old CoA, i.e. packets CN has sent before it received BU: MN compares the CoA in its binding update list with (new CoA) with the old CoA used as destination address in IPv6 header, and drops the packets due to the mismatch. This is not necessarily the case for route optimized MN - CN communication due to the more relaxed checks, but will cause MN to drop all packets tunneled by HA due to the more strict checks on the tunnel header. MN can avoid this by changing its binding update list entry for CN to use new CoA only when receiving BA. However, during the time period between CN receiving BU and MN receiving BA, MN is likely to send packets to CN using the old CoA. CN will drop these packets due to the mismatch with the CoA in its binding cache and the one in the packets. As long as a MN and a CN use unmodified Mobile IPv6 signaling and binding management, it is impossible for them to have a consistent state for the home address to CoA binding. 3. Options for ensuring consistency of incoming and outgoing states for Binding Update List and Binding Cache With unmodified Mobile IPv6 signaling there exist two possible solutions for ensuring consistent state of bindings in CN and MN. Both solutions require that either MN or CN accepts incoming packets with the old CoA for a certain period after updating its binding(s) to use the new CoA. MN can update its binding update list entry for outgoing packets to include the new CoA immediately after sending BU. This will ensure that if packets arrive in the correct order at HA, i.e. after the BU, they will match the binding state and be processed correctly. To enable MN to receive incoming packets which CN sends to old CoA before it receives BU, MN also needs to retain the binding update list state for old CoA for receiving tunneled and route optimized packets sent by CN. MN needs to retain the old state until it Petander Expires April 16, 2006 [Page 3] Internet-Draft draft-petander-mip6-mbb-00.txt October 2005 receives BA or possibly for longer to handle packets arriving out of order. This approach has the potential drawback of outgoing packets sent by MN being lost, if HA or CN does not receive or accept the BU immediately. An example of non-immediate binding cache update in HA is the case of MN moving from its home network to a foreign network and HA performing proxy DAD before updating its binding cache. However, MN knows when it is registering for the first time, so it can avoid this problem. To avoid loss of packets due to BUs lost in transit, MN can send two BUs through both the old and new interfaces. A second option is to retain the old binding cache entry in CN with old CoA of MN for a short period of time after receiving a BU from MN including a new CoA and sending a BA. This allows MN to wait for a BA from CN before it starts using the new CoA for outgoing communications. In this case MN would send its packets via its old access router using the old CoA for the duration of a RTT between MN and HA (and any other delays, such as proxy DAD). To ensure consistent state for the new CoA MN needs to request for a BA, so that it knows for sure when CN has processed and accepted the BU. The latter option is more reliable, but also results in a slower handoff for outgoing packets. In some cases the handoff may take longer than the simultaneous connectivity to the old and new network and MN would be better of by using the new CoA at the new access router as soon as possible. If CN accepts incoming packets with old CoA, MN can choose between using its old and new CoA for outgoing packets for the period of time between sending BU and receiving BA depending on the situation. 4. Changes to use and management of Binding Update List MN MAY keep its state for the Binding Update Entry with its old CoA after sending a Binding Update containing its new CoA to CN. MN SHOULD keep this entry until it can be safely deleted. In the case of BU to HA MN SHOULD remove its OLD_BUL_STATE_LIFETIME seconds after receiving a positive BA from HA. In the case of BU to CN, MN SHOULD remove it OLD_BUL_STATE_LIFETIME seconds after receiving a positive BA from CN or if MN did not request a BA from CN OLD_BUL_STATE_LIFETIME after sending the BU. MN SHOULD accept packets from CN using the old CoA during the lifetime of the entry. MN MAY also send packets to CN using the old CoA until it gets a BA from CN indicating success of BU. MN SHOULD set the acknowledgment flag in BU, if MN uses the old CoA to send packets to CN after sending BU. If old CoA can be used for sending Petander Expires April 16, 2006 [Page 4] Internet-Draft draft-petander-mip6-mbb-00.txt October 2005 packets between BU and BA, this use MUST be configurable, so that the default is to use the new CoA. 5. Changes to use and management of Binding Cache CN MAY keep its state for Binding Cache Entry with the old CoA of MN after accepting a Binding Update from MN for a period of OLD_BC_STATE_LIFETIME. During this time CN SHOULD accept packets from MN with the old CoA. CN MUST not use the old CoA for sending packets to MN. 6. Security Considerations An attacker on the previous link of MN could inject packets with the old CoA to CN or HA during the lifetime of the receiving state for old CoA, if MN disconnects from the old link before binding cache or binding update list entries for the old CoA are deleted. However, the short lifetime of the receiving state for old CoA limits the scope of any vulnerability created by the dual receiving state in MN and CN. 7. Protocol Constants OLD_BUL_STATE_LIFETIME - 2s OLD_BC_STATE_LIFETIME - 1s A lifetime of 1s for old BC entries guarantees that the entries do not accumulate, since 1s is the minimum BU interval. Petander Expires April 16, 2006 [Page 5] Internet-Draft draft-petander-mip6-mbb-00.txt October 2005 8. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and Arkko J., "Mobility Support in IPv6", RFC 3775, June 2004. 9. Informative References [3] Petander H., Perera E., Seneviratne A., "Multiple Interface Handoffs: A Practical Method for Access Technology Independent Make-Before-Break Handoffs", NICTA Technical Report, July 2005, http://nicta.com.au/uploads/documents/PA005092_NICTA1.pdf Author's Address Henrik Petander National ICT Australia Australian Technology Park Bay 15 Locomotive Workshop, Eveleigh NSW 1430 Australia Email: henrik.petander@nicta.com.au Eranga Perera National ICT Australia Australian Technology Park Bay 15 Locomotive Workshop, Eveleigh NSW 1430 Australia Email: eranga.perera@nicta.com.au Petander Expires April 16, 2006 [Page 6] Internet-Draft draft-petander-mip6-mbb-00.txt 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. Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. Petander Expires April 16, 2006 [Page 7]