MIPSHOP Working Group HF. CHEN Jian. Zhang Internet Draft HUAWEI Expires: Oct 18, 2006 April 17, 2006 Prep-Binding of Fast Handovers for Mobile IPv6 draft-chen-mipshop-fast-handovers-prep-binding-02.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 Oct 18, 2006. chen Expires Oct 18, 2006 [Page 1] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April 2006 Copyright Notice Copyright (C) The Internet Society (2006). 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. 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.....................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 MN move to NAR from PAR and before MN finish binding update, MN has to use PCoA as source IP address for communication with CN by reverse tunnel. This document discusses a solution which support the binding update when MN still in PAR network (Prep-Binding). Prep- Binding should send CNoA to CN. This solution support NCoA for source IP address at that time without tunnel. chen Expires October 17, 2006 [Page 2] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April 2006 The following documents have been reviewed while drafting this document: o Fast Handovers for Mobile IPv6[RFC4068] o Mobility Support in IPv6 [RFC3775] 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 generated 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 chen Expires October 17, 2006 [Page 3] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April 2006 Prep-Entry(PEntry) A special entry in binding cache of CN created by PBU(defined in section 3.2.) 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 borrowed from RFC4068 In section 3.1 of RFC4068, it described the transitional action of MN in TPoMN. MN could receive packets from NAR while 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. There are two problems with this solution. First is that one more IPv6 header need to be added in each packet from MN to CN. It should reduce the usable bandwidth of the network. Second is that the PAR chen Expires October 17, 2006 [Page 4] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April 2006 and the MN MUST support reverse tunnel. It will farther reduce the performance of transmission while a great many tunnels are generated. This document discuss an alternative solution in section 3.2 3.2. Solution of Prep-Binding Update 3.2.1. Mobile Node Operation MN sends PBU to CN after MN receives PrRtAdv from PAR and a NCoA generated. The CoA carried in PBU message is NCoA. If MN received PBA from CN, MN sends packets to CN using NCoA as source IP address in TPoMN. PAR didn't need a reverse tunnel which is required by the Fmipv6. Prep-Binding Update(PBU) It should use 1 reserved bit of BU message which defined in section 6.1.7 RFC3775. +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|P| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | chen Expires October 17, 2006 [Page 5] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+ Acknowledge (A) The Acknowledge (A) bit MUST be set in the PBU message by MN to request a Prep-Binding Acknowledgement to be returned by CN. Prep-Binding(P) The Prep-Binding Update(P) bit is set by MN to request CN to create a new special entry in their Binding Cache. It means this binding is a temporary Binding Update. The entry which 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 large number. Setting 3 or 4 for Prep-Lifetime is desirable to increase security. 3.2.2. Correspondent Node Operation CN should setup a Prep-Binding Entry after CN received PBU and get NCoA. Conceptual Data Structures in CN o The home address of the mobile node. o The care-of address for the mobile node. o A lifetime value o A flag indicating whether this Binding Cache entry is a home registration entry (applicable only on nodes which support home agent functionality). 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] chen Expires October 17, 2006 [Page 6] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April 2006 >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 CN send a Prep-Binding Acknowledgement with 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 same as RFC3775 chen Expires October 17, 2006 [Page 7] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April 2006 Lifetime: The Lifetime in PBU is the perp-lifetime in PEntry. The lifetime of this entry started to count when CN receive the first packet whose source IP address is the NCoA. 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 | | chen Expires October 17, 2006 [Page 8] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April 2006 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. o Step 1, MN sends PBU to CN after MN received PrRtAdv o Step 2, CN creates a special entry in Binding Cache and feedbacks PBA to MN. o Step 3, when MN moves to NAR. MN sends packet containing NCoA as source IP address. CN processes packet by PEntry. 3.3. Issues of Prep-Binding Update Several issues of Prep-Binding Update should be discussed about this document. 1. Process's integrality of Prep-Binding Update The DAD of home address and the Return Routability Procedure are not discussed in this document. But the draft-zhang-mipshop-proactive- cot-00.txt has discussed the issues of proactive Care-of Address Test 2. Assigned Addressing in RFC4068 The RFC4068 define that the MN MUST use the assigned address upon attaching to NAR If there is an assigned NCoA in the FBack message. When should MN send PBU and receive PBA should be discussed. PEntry in Binding Cache of CN should be wrong if PBU and PBA are sent before Hack message and assigned addressing including in Hack. 3. Home Agent Operation Does HA create PEntry? It is an issue. chen Expires October 17, 2006 [Page 9] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April 2006 4. Security Considerations Prep-Binding Update should increase discussion of security. It could be deceived attack if Prep-Binding Update has no 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 transmitting in access layer is low usually. Tunnel between MN and PAR should reduce the ability of transmitting further. This document suggests Prep-Binding Update to reduce the load of PAR. 7. Acknowledgments chen Expires October 17, 2006 [Page 10] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April 2006 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 October 17, 2006 [Page 11] Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April 2006 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 (2006). 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 October 17, 2006 [Page 12]