Network Working Group F. Xia Internet-Draft B. Sarikaya Expires: August 21, 2007 Huawei USA February 17, 2007 Fast Handovers for Mobile IPv6 Operation on Point-to-Point Links draft-xia-mipshop-fmip-ptp-00 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 August 21, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Xia & Sarikaya Expires August 21, 2007 [Page 1] Internet-Draft FMIPv6 over Point-to-Point Links February 2007 Abstract FMIPv6 standard currently assumes that the mobile nodes are connected to the access routers using a shared link and does not define the operation over Point-to-Point links. In this document we define FMIPv6 operation over the Point-to-Point links. A PAR advertises PrRtAdv including one or more aggregate prefixes of a NAR to an MN; The MN formulates it's provisional NCoAs with the aggregate prefix(es); The MN initiates FMIPv6 procedure including the provisional NCoAs. Once detecting provisional NCoAs of the MN, the NAR assigns a unique prefix called the dedicated prefix to MN and the MN configures it's final NCoAs. Both reactive and predictive modes of FMIPv6 are explained. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 4. FMIPv6 Operation on Point-to-Point Links . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative references . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Xia & Sarikaya Expires August 21, 2007 [Page 2] Internet-Draft FMIPv6 over Point-to-Point Links February 2007 1. Introduction Fast handovers for Mobile IPv6 (FMIPv6) [RFC4068] aims at reducing the handover latency by reducing the time to configure a new CoA(NCoA) for a mobile node (MN). In FMIPv6, MN formulates a prospective NCoA when it is still present on the previous access router (PAR)'s link. However, FMIPv6 assumes that MN is on a shared link. [I-D.ietf-16ng-ipv6-link-model-analysis] provides different IPv6 link models that are suitable for 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. [I-D.ietf-16ng-ipv6-over-ipv6cs] specifies the addressing and operation of IPv6 over the IPv6 specific part of the packet convergence sublayer of IEEE Std 802.16e [802.16e], and Point-to- Point Link Model is recommended. Also, 3GPP and 3GPP2 have earlier adopted the Point-to-Point link model. It is impossible to formulate a prospective NCoA as per [RFC4068] when Point-to-Point model is adopted. MN configures its NCoA from the prefix shared by NAR breaks the Point-to-Point link model. In this document, we first explain the problems associated with FMIPv6 on Point-to-Point links followed by a detailed explanation of the modified FMIPv6 operation on Point-to-Point links. 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 [RFC2119]. The terminology in this document is based on the definitions in [RFC4068], in addition to the ones specified in this section. Point-to-Point Link Model: In this model, a set of MAC transport connections between an MN and an AR are treated as a single link. Each link is allocated one or more separate, unique prefixes by the AR. Aggregate Prefix: In Point-to-Point Link Model, AR should broadcast the prefixes (MNs route information) dynamically upstream, and this causes high routing protocol traffic ( OSPF, etc.). To solve the problem, route aggregation should be used. For example, each AR can be assigned a /48 prefix, while an MN's /64 prefix is derived from the /48 prefix extension. The main, higher-level prefix is called the Aggregate Prefix. An AR only broadcasts the Xia & Sarikaya Expires August 21, 2007 [Page 3] Internet-Draft FMIPv6 over Point-to-Point Links February 2007 aggregate prefix upstream. Dedicated Prefix: The prefix derived from the aggregate prefix and allocated for an MN is called a Dedicated Prefix. Provisional NCoA: NCoA obtained from the aggregate prefix. Modified NCoA: NCoA obtained from the dedicated prefix. 3. Problem Statement The following are operations as per [RFC4068]: o NCoA configuration. An MN sends a Router Solicitation for Proxy Advertisement (RtSolPr) to its access router to resolve one or more Access Point Identifiers to subnet-specific information. In response, the access router sends a Proxy Router Advertisement (PrRtAdv) message containing one or more [AP-ID, AR-Info] tuples. AR-Info contains an NAR's L2 and IP addresses, and the prefix valid on the interface to which the Access Point (identified by AP-ID) is attached. With the prefix provided in the PrRtAdv message, the MN formulates a prospective NCoA. In Point-to-Point link model, each MN has one or more dedicated prefixes, that is, different MNs have different prefixes. The prefixes could be allocated dynamically. When an MN attaches an AR, the AR should delegate one or more dedicated prefixes for it; when the MN detaches from the AR, the MN's prefixes are released, and can be reused by other MNs. The number of unique prefixes in this operation can be huge. In [RFC4068], the prefix in AR-Info is one of valid interfaces to which the Access Point (identified by AP-ID) is attached, and the prefix is not a dedicated prefix. An MN can't use the prefix in AR- info to formulate it's NCoA. A PAR can't get NCoA's prefix of an MN without complicated signaling exchange with NAR. 4. FMIPv6 Operation on Point-to-Point Links The simplest fix to the problem described in the previous section is as follows: NARs assign a unique prefix to each MN that could handover under this NAR. This prefix will be included in AR-Info. PAR sends this prefix in the PrRtAdv message. The disadvantages of the simplistic approach are that it makes prefix management complicated on NARs and that there are extra signaling exchanges between PAR and NAR. If MN does not handover then the prefix assigned should be reclaimed and assigned to another MN. There could potentially be large number of such prefixes in high mobility areas. Because of this we propose the following approach in Xia & Sarikaya Expires August 21, 2007 [Page 4] Internet-Draft FMIPv6 over Point-to-Point Links February 2007 which MN is assigned a dedicated prefix only if MN handovers to this NAR. The main idea of our solution is to include the aggregate prefix in the AR-Info. Then the MN can use the prefix to formulate NCoA. We call it provisional NCoA. Each aggregate prefix advertised by the candidate NARs MUST be unique. The following adaptation can be used in the predictive mode of FMIPv6: o An MN receives aggregate prefix in AR-Info of PrRtAdv, and formulates its provisional NCoA. Then, the MN sends FBU message to PAR with NCoA option, link layer information of the MN, and so on. The PAR sends this information to an NAR in HI message. o On receiving the HI, NAR processes the message as per [RFC4068] if the prefix of the NCoA is not an aggregate prefix of the NAR. Otherwise, the NAR allocates one or more dedicated prefixes for the MN based on it's link-layer address (MAC). NAR generates a new NCoA by replacing the provisional NCoA's prefix part with the dedicated prefix. The modified NCoA is then delivered to the MN through HAck and FBack message. The MN MUST use the modified NCoA. The following adaptation can be used in the reactive mode of FMIPv6: o An MN encapsulates FBU in FNA and sends them together to NAR. The source address of FNA is the provisional NCoA. If the prefix of the NCoA corresponding to the FNA message is not an aggregate prefix, the NAR processes the message as per [RFC4068]. Otherwise, the NAR assigns one or more prefixes for the MN based on Mobility Header Link-Layer Address (MH-LLA) option in the FNA. A modified NCoA is then formulated by replacing the provisional NCoA's prefix part. The NAR sends a Router Advertisement with the NAACK option in which it includes the modified NCoA. The MN then sends another FNA with modified NCoA as source IP address to NAR. The NAR processes the FNA as per [RFC4068]. 5. Security Considerations FMIPv6 operation on Point-to-Point links does not introduce any new security threats and the security provided by FMIPv6 applies completely. 6. IANA consideration None. Xia & Sarikaya Expires August 21, 2007 [Page 5] Internet-Draft FMIPv6 over Point-to-Point Links February 2007 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative references [802.16e] Institute of Electrical and Electronics Engineer, "Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE 802.16e/D12. [802.21] Institute of Electrical and Electronics Engineer, "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE P802.21/ D00.05. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [I-D.haddad-mipshop-optisend] Haddad, W., "Secure Neighbor Discovery (SEND) Optimization and Adaptation for Mobility: The OptiSEND Protocol", draft-haddad-mipshop-optisend-02 (work in progress), October 2006. [I-D.haddad-mipshop-fmipv6-auth] Haddad, W. and S. Krishnan, "Authenticating FMIPv6 Handovers", draft-haddad-mipshop-fmipv6-auth-02 (work in progress), September 2006. [I-D.ietf-mipshop-fh80216e] Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e Networks", draft-ietf-mipshop-fh80216e-01 (work in progress), January 2007. [I-D.ietf-16ng-ipv6-over-ipv6cs] Patil, B., "IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks", draft-ietf-16ng-ipv6-over-ipv6cs-07 (work in progress), January 2007. [I-D.ietf-16ng-ipv6-link-model-analysis] Xia & Sarikaya Expires August 21, 2007 [Page 6] Internet-Draft FMIPv6 over Point-to-Point Links February 2007 Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 based Networks", draft-ietf-16ng-ipv6-link-model-analysis-02 (work in progress), January 2007. Xia & Sarikaya Expires August 21, 2007 [Page 7] Internet-Draft FMIPv6 over Point-to-Point Links February 2007 Authors' Addresses Frank Xia Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Xia & Sarikaya Expires August 21, 2007 [Page 8] Internet-Draft FMIPv6 over Point-to-Point Links February 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 & Sarikaya Expires August 21, 2007 [Page 9]