mipshop B. Xia Internet-Draft X. Qin Intended status: Informational Huawei Technologies. Expires: December 21, 2007 June 19, 2007 Flexible Fast Handover for Mobile IPv6 draft-qin-mipshop-flexible-fmip-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 December 21, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Fast Handovers for Mobile IPv6 protocol improves handover latency due to Mobile IPv6 procedures. Such improvement streamlines handover performance and benefit to both real-time application and non-real- time throughput-sensitive traffic. This document introduces an enhanced Fast Handovers for Mobile IPv6 protocol to support statful address configuration. Xia & Qin Expires December 21, 2007 [Page 1] Internet-Draft Flexible Fast Handover for Mobile IPv6 June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 3 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Router Solicitation for Proxy Advertisement (RtSolPr) . . 6 4.2. New Proxy Router Advertisement (PrRtAdv) . . . . . . . . . 7 4.3. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 7 4.4. Fast Router Advertisement (FRA) . . . . . . . . . . . . . 8 5. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Normative Reference . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Xia & Qin Expires December 21, 2007 [Page 2] Internet-Draft Flexible Fast Handover for Mobile IPv6 June 2007 1. Introduction Fast Handovers for Mobile IPv6 (FMIP) describes the protocol operations for a mobile node to send packets as soon as it detects a new subnet link, and how to deliver packets to a mobile node as soon as its attachment is detected by the new access router. These operations reduce handover latency due to the movement detection and new prefix discovery. This document describes a protocol to support stateful new CoA configuration in addition to stateless address configuration. 2. Terminology The terminology in this document follows the definitions in [fmip]. In addition, the following definition is used: Temporary Care of Address (TCoA) A tentative NCoA, the Next Access Router (NAR) assigns an IPv6 address from local address pool for the mobile node to use temporarily. Fast Router Advertisement (FRA) A Router Advertisement, NAR send a RA to inform the mobile node about DHCP server address and other parameters without any random delay preceding the sending of the RA. 3. Protocol Operations This protocol provides stateful address configuration. By means of this function, a network may manage address assignment for all mobile nodes on the basis of a consistent strategy. This way could eliminate the probability of address collision, thus, no Duplicate Address detection is required. The following protocol operation is based on FMIPv6 protocol, some details which are defined in FMIPv6 will not be repeated here if it is not necessary. In FMIPv6 protocol, two scenarios are introduced depending on whether an FBack is received on the previous link. Below, enhanced FMIPv6 protocol operations are still described in the two scenarios. Scenario 1 presents "Predictive" Fast Handover procedure as shown in Figure 1. Scenario 2 depicts "Reactive" Fast Handover procedure as shown in Figure 2. Xia & Qin Expires December 21, 2007 [Page 3] Internet-Draft Flexible Fast Handover for Mobile IPv6 June 2007 MN PAR NAR | | | |------RtSolPr------->| |(a) |<-----PrRtAdv--------| | | | | |------FBU----------->|--------HI--------->|(b) | |<------HAck(TCoA)---| | <--FBack(TCoA)---|--FBack---> |(c) | | | disconnect forward | | packets===============>| | | | connect | | | | | |--------- FNA --------------------------->|(d) |<------------------------------FRA--------|(e) | | | |<=================================== deliver packets | | |<---------------------DHCP exchanges----->|(f) | | | Figure 1: "Predictive" Fast Handover There are operations: (a)The MN sends an RtSolPr to its access router to resolve one or more Access Point Identifiers to subnet-specific information. In response, the access router (e.g., PAR in Figure 1) sends a PrRtAdv message containing one or more [AP-ID, AR-Info] tuples. The MN may set E flag in RtSolPr to inform PAR whether it supports the stateful address auto-configuration, the extension is defined in Section 4.1. In accordance with this flag, PAR could judge whether to use the extension designed for stateful address configuration in this document. PAR sets E flag in PrRtAdv to inform the MN of the address configuration type which the PAR supports, the message formats of which is defined in Section 4.2. (b)If stateful address configuration is required, the MN sends an FBU message within a link-local address as a NCoA when a link- specific handover event occurs. PAR should send an HI message to NAR to request address assignment with E flag set, and receive HAck with an assigned address as TCoA. This address is assigned from the local address pool by NAR. As HAck is received, PAR is authorized to bind PCoA to TCoA, so that arriving packets can be tunneled to the new location of the MN. PAR begins tunneling packets to TCoA. If stateless auto-configuration is required, protocol operations conform to FMIPv6. Xia & Qin Expires December 21, 2007 [Page 4] Internet-Draft Flexible Fast Handover for Mobile IPv6 June 2007 (c)PAR sends back FBack to the MN over PAR's link, if the MN receives it over PAR's link, the MN should use the assigned address. (d)The MN should send FNA immediately after attaching to NAR, so that arriving and buffered packets can be forwarded to the MN right away. (e) The purpose of the FRA is to inform the MN of IPv6 address of DHCP server and DUID. This FRA should be sent without any interval. This step will not introduce more delay. FRA is described in Section 4.4. (f) The MN could send DHCP request message to DHCP server with TCoA. DHCP server confirms this TCoA as the NCoA. MN PAR NAR | | | |------RtSolPr------->| |(a) |<-----PrRtAdv--------| | | | | disconnect | | | | | connect | | |------FNA(FBU)--------------------------->|(b) |<---------------------------FRA-----------|(c) |<---------------------DHCP exchanges----->|(d) | |<-----FBU-----------|(e) | |------FBack-------->| | forward | | packets===============>| |<=================================== deliver packets | | | Figure 2: "Reactive" Fast Handover There are operations: (a)The MN sends an RtSolPr to its access router to resolve one or more Access Point Identifiers to subnet-specific information. In response, the access router (e.g., PAR in Figure 1) sends a PrRtAdv message containing one or more [AP-ID, AR-Info] tuples. (b) If the MN has not sent the FBU or the MN has left the link after sending the FBU (which itself may be lost), the MN does not Xia & Qin Expires December 21, 2007 [Page 5] Internet-Draft Flexible Fast Handover for Mobile IPv6 June 2007 receive the FBack on the previous link. Without receiving an FBack in the latter case, the MN cannot ascertain whether PAR has successfully processed the FBU. In this case, the MN cannot obtain an assigned TCoA. Thereby, source address of FNA is a link-local address of the MN. Source address of FBU is also a link-local address. The FBU is encapsulated into the FNA as the same as FMIPv6. (c) The purpose of the FRA is to inform the MN of the TCoA, the DHCP server IPv6 address and DUID of the DHCP server. This FRA should be sent without any random delay. This step will not introduce more delay. (d) The MN could request the NCoA via DHCP messages exchange with DHCP server. (e) In order to forward datagrams from PAR to NAR, NAR may forward the FBU with NCoA to PAR to establish tunnels. PAR responses it with FBack. 4. Message Formats This section defines extension to messages which are defined in FMIPv6 in order to support this protocol. Only new formats are introduced. Other parts which are not changed conform to FMIPv6. 4.1. Router Solicitation for Proxy Advertisement (RtSolPr) Mobile Nodes send Router Solicitation for Proxy Advertisement in order to prompt routers for Proxy Router Advertisements. It also informs that whether the MN supports stateful address configuration function with 'E' flag. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype |E| Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 3: Router Solicitation for Proxy Advertisement (RtSolPr) Message E Flag Xia & Qin Expires December 21, 2007 [Page 6] Internet-Draft Flexible Fast Handover for Mobile IPv6 June 2007 Stateful address configuration flag. When set, this message informs the PAR that the MN supports stateful address auto- configuration. 4.2. New Proxy Router Advertisement (PrRtAdv) Access routers send Proxy Router Advertisement messages gratuitously if the handover is network-initiated or as a response to a RtSolPr message from an MN. Except that PrRtAdv provides the Link-Layer Address, IP address, and subnet prefixes of neighboring routers, It also informs that whether PAR supports stateful address configuration function with 'E' flag. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype |E| Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 4: New Proxy Router Advertisement (PrRtAdv) Message E flag Stateful address configuration flag. When set, this message informs the mobile node that PAR supports the extension designed for stateful address configuration. 4.3. Handover Initiate (HI) The Handover Initiate (HI) is an ICMPv6 message sent by an Access Router (typically PAR) to another Access Router (typically NAR) to initiate the process of a MN's handover. In this specification, HI requests stateful address assignment from local address pool of NAR. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype |S|U|E|Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Xia & Qin Expires December 21, 2007 [Page 7] Internet-Draft Flexible Fast Handover for Mobile IPv6 June 2007 Figure 5: Handover Initiate (HI) Message E flag Stateful address configuration flag. When set, this message asks NAR to assign and manage address stately. 4.4. Fast Router Advertisement (FRA) Fast Router Advertisement is an extended Router Advertisement message. This section only presents new options, other parts conform to Neighbor Discovery for IPv6 protocol [ND]. DHCP option is defined as below in Figure 6: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DHCP Server IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DUID length | | +-+-+-+-+-+-+-+-+ | | DHCP server DUID | | +-+-+-+-+-+-+-+-+-+-+... Figure 6: DHCP Option Format Option Type To be assigned by IANA. Length The length of the option. Reserved These bits are reserved. DHCP Server IPv6 Address The IPv6 address of DHCP server. Xia & Qin Expires December 21, 2007 [Page 8] Internet-Draft Flexible Fast Handover for Mobile IPv6 June 2007 DUID Length The length of DUID. DHCP Server DUID DHCP Unique Identifier, reference to DHCP [DHCP]. 5. Miscellaneous The MN may send the DHCP request message with the TCoA to the DHCP server. The DHCP server shall assign this address to the MN as the NCoA. The TCoA will be translated into the NCoA as the MN receives the DHCP ack message from the DHCP server. The DHCP server may co- locate within the NAR, the above local address pool could be managed by the DHCP server. Moreover, the DHCP server may be indpendent physically. The local address pool may be a part of the whole address space. NAR shall take charge of the TCoA which has been assigned to the distinct MN is not allocated for other MNs. To achieve this point, more details should be researched. The PrRtAdv should contain the TBD option or flag to inform the MN on whether the NAR supports stateful address configuration. 6. Security Considerations This protocol does not introduce more security problems. More details could be researched further. 7. IANA Considerations IANA needs to take considerations on the assignment of DHCP option type. 8. Normative Reference [fmip] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", July 2005. [ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6", Dec. 1998. [DHCP] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6", July 2003. Xia & Qin Expires December 21, 2007 [Page 9] Internet-Draft Flexible Fast Handover for Mobile IPv6 June 2007 Authors' Addresses Bin Huawei Technologies. Nanjing, China Phone: Fax: Email: bin.xia@huawei.com URI: Xia Huawei Technologies. Email: Alice.Q@huawei.com Xia & Qin Expires December 21, 2007 [Page 10] Internet-Draft Flexible Fast Handover for Mobile IPv6 June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Xia & Qin Expires December 21, 2007 [Page 11]