MIPSHOP Working Group HF. CHEN Jian. Zhang Internet Draft HUAWEI Expires: April 11, 2006 October 12, 2005 Prep-Binding of Fast Handovers for Mobile IPv6 draft-chen-mipshop-fast-handovers-prep-binding-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. 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 12, 20056. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Fast Handovers have been specified in Fast Handovers for Mobile IPv6 defined in RFC4068. This document discussed the issues which happen after MN move to NAR and before finishing bind update. chen Expires April 11, 2006 [Page 1] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 October 2005 Table of Contents 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.....................7 4. Security Considerations......................................9 5. IANA Considerations.........................................9 6. Conclusions.................................................9 7. Acknowledgments.............................................9 8. References.................................................10 8.1. Normative References...................................10 8.2. Informative References.................................10 Author's Addresses............................................10 Intellectual Property Statement................................10 Disclaimer of Validity........................................11 Copyright Statement...........................................11 Acknowledgment................................................11 1. Introduction The Fast Handovers for Mobile IPv6 document [RFC4068] defines the Fast Handovers mechanisms between PAR and NAR. After MN move to NAR from PAR and before MN finish bind update, MN has to use PCoA for source IP address to communication with CN. This document should discuss a solution which finished Prep-Binding when MN still in PAR network. Prep-Binding should send CNoA to CN. This solution support NCoA for source IP address at that time. The following documents relating directly have been reviewed while drafting this document: o Fast Handovers for Mobile IPv6[RFC4068] o Mobility Support in IPv6 [RFC3775] chen Expires April 12, 2006 [Page 2] Internet-Draft Perp-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 are used in this document. Prep-Binding Update(PBU) Special BU message which is sent by MN when MN exist a NCoA local in PAR 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 of MN after MN moves to NAR before MN finishes Binding Update Prep-Entry(PEntry) A special entry in binding cache of CN be created by PBU which is defined in section 3.2. chen Expires April 12, 2006 [Page 3] Internet-Draft Perp-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 The figure 1 is the same as the figure 1 in RFC4068 In section 3.1 of RFC4068, it described the transitional action of MN in TPoMN. MN could receive packets from NAR which PAR SHOULD forward packets in the tunnel to NAR. In the opposite direction, MN SHOULD transmit packets to PAR by reverse tunnel until it completes the Binding Update. The source IP address of MN SHOULD be PCoA and the packet SHOULD not be dropped in ingress filtering of NAR. There are two problems of this solution. First is that one more IPv6 header has to be added in each packet from MN to CN. It should reduce the usable bandwidth of the network. Second is that the PAR and the MN MUST support reverse tunnel. It must will be farther reduce the performance of transmit. This document discuss another possible solution in section 3.2 chen Expires April 12, 2006 [Page 4] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 October 2005 3.2. Solution of Prep-Binding Update 3.2.1. Mobile Node Operation MN sends PBU to CN after MN receiving PrRtAdv from PAR and NCoA existing. CoA in PBU is NCoA. If MN received PBA from CN, MN sends packets to CN containing NCoA as source IP address in TPoMN. PAR didn't need a reverse tunnel. NAR could configure URPF on ingress too. Prep-Binding Update(PBU) It should use 1 bit of reserved of BU message which defined in section 6.1.7 RFC3775. +-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Perp-Binding Acknowledgement returned upon receipt of the Prep-Binding Update. chen Expires April 12, 2006 [Page 5] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 October 2005 Prep-Binding(P) The Prep-Binding Update(P) bit is set by the sending mobile node to request that 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 works in TPoMN only. Because this entry works before formal Binding Update, the Prep-Lifetime which defined in section 3.2.2 in this packet should not be a big number. It suggests 3 or 4 for Prep-Lifetime to increase security. 3.2.2. Correspondent Node Operation CN should setup a Prep-Binding Entry—Penrey after CN received PBU and get 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 perp-lifetime of Prep-binding Update which 0 A formal Binding Cache Entry which process as same as defined in [RFC3775] >0: A PEntry should work in TPoMN. The number of Perp- Lifetime means that lifetime of this entry after MN sent packet with NCoA as source IP address in TPoMN. The lifetime of this entry started to account when CN receive the first packet which the source IP address is the NCoA in this entry. After start to account, the lifetime of entry is the time of the lifetime record chen Expires April 12, 2006 [Page 6] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 October 2005 CN send a Prep-Binding Acknowledgement which status is 2 to acknowledge receipt of a PBU after setup PEnrty. Prep-Binding Acknowledgement(PBA) Two new status should be modified in BA which defined in section 6.1.8 RFC3775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 perp-lifetime in PEntry. The lifetime of this entry started to account when CN receive the first packet which the source IP address is the NCoA in this entry chen Expires April 12, 2006 [Page 7] Internet-Draft Perp-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 The figure 3 describes the process of Prep-Binding Fast Handover. The lines marked as 1,2 and 3 are key point of the process. chen Expires April 12, 2006 [Page 8] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 October 2005 o Step 1, MN sent PBU to CN after MN received PrRtAdv o Step 2, CN created a special entry in Binding Cache and feedback PBA to MN. o Step 3, when MN move to NAR. MN send packet containing NCoA as source IP address but not reverse tunnel. CN process packet by PEntry. 4. Security Considerations Prep-Binding Update should be increase discuss of security. It could be deceived attack if Prep-Binding Update has not mechanism of the authentication and the security. 5. IANA Considerations There are no IANA considerations defined in this document. 6. Conclusions This document described a kind of technique that MN could use NCoA before Binding Update when MN moved to NAR's network. The NAR and PAR are the router in access layer of network. The router's ability of transmit in access layer is low usually. Tunnel between MN and PAR should reduce ability of transmit farther. This document suggests Prep-Binding Update to reduce the load of PAR. 7. Acknowledgments chen Expires April 12, 2006 [Page 9] Internet-Draft Perp-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 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 chen Expires April 12, 2006 [Page 10] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 October 2005 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 12, 2006 [Page 11]