MIPSHOP Working Group HF. CHEN Jian. Zhang Internet Draft HUAWEI Expires: April 23, 2006 October 24, 2005 Prep-Binding of Fast Handovers for Mobile IPv6 draft-chen-mipshop-fast-handovers-prep-binding-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 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Fast Handovers are specified in RFC4068, Fast Handovers for Mobile IPv6. This document discusses the issues which happen after the MN moves to the NAR but before it finishes the binding update. Table of Contents chen Expires April 23, 2006 [Page 1] Internet-Draft Prep-Binding of Fast Handovers for Mobile IPv6 October 2005 1. Introduction................................................2 2. Terminology.................................................3 3. Prep-Binding Update.........................................4 3.1. Problem statement.......................................4 3.2. Solution of Prep-Binding Update.........................5 3.2.1. Mobile Node Operation..............................5 3.2.2. Correspondent Node Operation.......................6 3.2.3. Process of Prep-Binding Update.....................8 3.3. Issues of Prep-Binding Update...........................9 4. Security Considerations.....................................10 5. IANA Considerations........................................10 6. Conclusions................................................10 7. Acknowledgments............................................10 8. References.................................................11 8.1. Normative References...................................11 8.2. Informative References.................................11 Author's Addresses............................................11 Intellectual Property Statement................................12 Disclaimer of Validity........................................12 Copyright Statement...........................................12 Acknowledgment................................................12 1. Introduction The Fast Handovers for Mobile IPv6 document [RFC4068] defines the Fast Handovers mechanisms between PAR and NAR. After the MN moves to the NAR from PAR but before MN finishes the binding update, the MN has to use the PCoA for the source IP address to communicate with the CN. This document describes a solution that completes Prep-Binding when the MN is still in the PAR network. Prep-Binding should send the NCoA to the CN. This solution supports using the NCoA for the source IP address at that time. The following related documents have been reviewed while drafting this document: o Fast Handovers for Mobile IPv6[RFC4068] o Mobility Support in IPv6 [RFC3775] chen Expires April 23, 2006 [Page 2] Internet-Draft Prep-Binding of Fast Handovers for Mobile IPv6 October 2005 2. Terminology 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]. The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed. This document borrows all of the terminology from RFC4068. The following terminology and abbreviations also are used in this document. Prep-Binding Update (PBU) Special BU message which is sent by a MN when the MN uses the NCoA before the Binding Update is complete. Prep-Binding Acknowledgement (PBA) The Prep-Binding Acknowledgement is used to acknowledge receipt of a Prep-Binding Update. Transitional Period of MN (TPoMN) The period after a MN moves to the NAR before the MN finishes the Binding Update. Prep-Entry (PEntry) A special entry in the binding cache of a CN which is created after a PBU is received as described in section 3.2. chen Expires April 23, 2006 [Page 3] Internet-Draft Prep-Binding of Fast Handovers for Mobile IPv6 October 2005 3. Prep-Binding Update 3.1. Problem statement v +------------+ +-+ | Previous | < | | ---------- | Access | ------ > ----\ +-+ | Router | < \ MN | (PAR) | \ | +------------+ +---------------+ | ^ IP | Correspondent | | | Network | Node | V | +---------------+ v / v +------------+ / +-+ | New | < / | | ---------- | Access | ------ > ----/ +-+ | Router | < MN | (NAR) | +------------+ Figure 1: Reference Scenario for Handover Figure 1 is the same as figure 1 in RFC 4068. In section 3.1 of RFC4068, it describes the transitional action of the MN during the TPoMN. The MN could receive packets from the NAR which the PAR SHOULD forward packets in a tunnel to the NAR. In the opposite direction, The MN SHOULD transmit packets to the PAR by reverse tunnel until it completes the Binding Update. The source IP address of the MN SHOULD be the PCoA and the packets SHOULD not be dropped in ingress filtering of NAR. There are two problems with this solution. First is that one more IPv6 header has to be added to each packet from the MN to the CN, which reduces the usable bandwidth of the network. Second is that the PAR and the MN MUST support reverse tunnel, which also reducea the performance. This document discuss another possible solution in section 3.2 chen Expires April 23, 2006 [Page 4] Internet-Draft Prep-Binding of Fast Handovers for Mobile IPv6 October 2005 3.2. Solution of Prep-Binding Update 3.2.1. Mobile Node Operation The MN sends the PBU to the CN after the MN receives a PrRtAdv from the PAR and the NCoA is determined. The CoA in the PBU is the NCoA. If the MN receives the PBA from the CN, the MN sends packets to the CN containing the NCoA as the source IP address in the TPoMN. The PAR does not need a reverse tunnel. The NAR could configure the URPF on ingress too. Prep-Binding Update(PBU) It should use 1 bit of the reserved field of the BU message which is defined in section 6.1.7 of RFC 3775. +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|P| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+ Acknowledge (A) The Acknowledge (A) bit MUST be set by the sending mobile node to request a Prep-Binding Acknowledgement returned upon receipt of the chen Expires April 23, 2006 [Page 5] Internet-Draft Prep-Binding of Fast Handovers for Mobile IPv6 October 2005 Prep-Binding Update. Prep-Binding(P) The Prep-Binding Update(P) bit is set by the sending mobile node to request that the CN create a new special entry in their Binding Cache. It means this binding is a temporary Binding Update. The entry created by this kind of Binding Update is valid during the TPoMN only. Because this entry works before the formal Binding Update, the Prep- Lifetime which is defined in section 3.2.2 in this entry should be a small number like 3 or 4 3.2.2. Correspondent Node Operation The CN should set up a Prep-Binding Entry after the CN receives a PBU and gets the NCoA. Conceptual Data Structures in CN o The home address of the mobile node for which this is the Binding Cache entry. o The care-of address for the mobile node indicated by the home address field in this Binding Cache entry. o A lifetime value o A flag indicating whether or not this Binding Cache entry is a home registration entry. o The maximum value of the Sequence Number field received in previous Binding Updates for this home address. o Usage information for this Binding Cache entry. o A prep-lifetime value of Prep-binding Update 0 A formal Binding Cache Entry which is handled the same as defined in [RFC3775] >0: A PEntry should work in the TPoMN. The value of the Prep-Lifetime is the lifetime of this entry after the MN sent the packet with the NCoA as the source IP address in the TPoMN. The lifetime of this entry starts when the CN receives the first packet chen Expires April 23, 2006 [Page 6] Internet-Draft Prep-Binding of Fast Handovers for Mobile IPv6 October 2005 whose the source IP address is the NCoA in this entry. Once started, the lifetime of entry is amount of time indicated by the value. The CN sends a Prep-Binding Acknowledgement which status is 2 to acknowledge receipt of a PBU after setup PEnrty. Prep-Binding Acknowledgement(PBA) Two new status values should be added to the BA which is defined in section 6.1.8 of RFC 3775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Status 0 Binding Update accepted 1 Accepted but prefix discovery necessary 2 Prep-Binding Update accepted 140 Prep-Binding Update refused ... the other status defined as same as RFC3775 Lifetime: The Lifetime in PBU is the prep-lifetime in PEntry. The lifetime of this entry starts when the CN receives the first packet whose the source IP address is the NCoA in this entry. chen Expires April 23, 2006 [Page 7] Internet-Draft Prep-Binding of Fast Handovers for Mobile IPv6 October 2005 3.2.3. Process of Prep-Binding Update CN/HA MN PAR NAR | |------RtSolPr------>| | | |<-----PrRtAdv-------| | 1 | <------PBU-------| | | 2 | -------PBA------>| | | | |------FBU---------->|------HI------>| | | |<-----HAck-----| | | <--FBack---|--FBack---> | | disconnect forward | | | packets==========>| | connect | | | |--------- FNA --------------------->| | forward packets | | 3 PEentry<=============by NCoA | | | |<====================== deliver packets |<-process of BU-> | | | | | | | formal forward packets | | entry<==============by NCoA | | | | | | figure 3:Prep-Binding Fast Handover chen Expires April 23, 2006 [Page 8] Internet-Draft Prep-Binding of Fast Handovers for Mobile IPv6 October 2005 Figure 3 shows the process of Prep-Binding Fast Handover. The lines marked as 1,2 and 3 are key points of the process. o Step 1, The MN sends the PBU message to the CN after the MN received PrRtAdv message o Step 2, the CN creates a special entry in the Binding Cache and sends the PBA acknowledgment to the MN. o Step 3, when the MN moves to the NAR. The MN sends packets containing NCoA as the source IP address but does not reverse tunnel. The CN processes the packets using PEntry. 3.3. Issues of Prep-Binding Update Several issues of Prep-Binding Update should be discussed further. 1. Process's integrality of Prep-Binding Update The DAD of the CoA address and the Return Routability Procedure have not been discussed clearly in this document. 2. Assigned Addressing in RFC 4068 RFC 4068 states that the MN MUST use the assigned address upon attaching to the NAR if there is an assigned NCoA in the FBack message. The time when the MN sends the PBU and receives the PBA should be discussed further. The PEntry in Binding Cache of the CN should be wrong if the PBU and PBA messages are sent before the HAck message and the assigned addresses are included in the HAck message. A proposed solution is that a reverse tunnel from the MN to the PAR which is described in [RFC4068] for the PBU and PBA messages are sent before the HAck message and the assigned addresses are included in the HAck message. 3. Home Agent Operation Does the HA create an PEntry? It is an open issue. chen Expires April 23, 2006 [Page 9] Internet-Draft Prep-Binding of Fast Handovers for Mobile IPv6 October 2005 4. Security Considerations The Prep-Binding Update solution requires security analysis. For instance, without proper mechanisms for authentication and security, the Prep-Binding update would be susceptible to deceptive attacks. 5. IANA Considerations There are no IANA considerations defined in this document. 6. Conclusions This document describes a solution where the MN uses the NCoA before the Binding Update is complete when the MN moved to the NAR's network. The NAR and PAR are routers in access layer of network where the router capacity and performance is relatively low, and the tunnel between the MN and the PAR will also degrade performance. This document suggests using the Prep-Binding Update to reduce the load of the PAR and to improve overall performance during fast handovers. 7. Acknowledgments chen Expires April 23, 2006 [Page 10] Internet-Draft Prep-Binding of Fast Handovers for Mobile IPv6 October 2005 8. References 8.1. Normative References [RFC4068] R. Koodli, Ed. "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [RFC3775] D. Johnson. and C. Perkins and J. Arkko, " Mobility Support in IPv6", RFC 3755, June 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 8.2. Informative References [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-1583. Author's Addresses Hongfei Chen HUAWEI Hua Wei Bld.,No.3 Xinxi Rd., Shang-Di Information Industry Base Hai-Dian District Beijing P.R.China Phone: +86 010 82882540 Email: chenhongfei@huawei.com Jian Zhang HUAWEI Hua Wei Bld.,No.3 Xinxi Rd., Shang-Di Information Industry Base Hai-Dian District Beijing P.R.China Phone: +86 010 82882233 Email: hwzhj@huawei.com chen Expires April 23, 2006 [Page 11] Internet-Draft Prep-Binding of Fast Handovers for Mobile IPv6 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. chen Expires April 23, 2006 [Page 12]