Internet DRAFT - draft-chen-mipshop-fast-handovers-prep-binding

draft-chen-mipshop-fast-handovers-prep-binding



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]