Network Working Group F. Xia Internet-Draft B. Sarikaya Expires: January 6, 2008 Huawei USA July 5, 2007 Fast Handovers for Mobile IPv6 Operation on Point-to-Point Links draft-xia-mipshop-fmip-ptp-01 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 January 6, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Xia & Sarikaya Expires January 6, 2008 [Page 1] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 Abstract The FMIPv6 specification currently does not explicitly define the operation over Point-to-Point links. In this document we define FMIPv6 operation over the point-to-point links, especially we propose mechanism for assigning unique prefixes to the MN by the PAR. Three different solutions are proposed. A new access router dynamically assigns a unique prefix called dedicated prefix to any MN that is performing a handover. Alternatively, the previous access router sends an aggregate prefix of a new access router to MN for formulating NCoA, and only when handover takes place, the new access router assigns a dedicated prefix to MN and configures a NCoA for the MN. Lastly, MN is allowed to generate a special NCoA without any specific prefix information, and only when handover takes place, the new access router assigns a dedicated prefix to MN for NCoA formulation. Both reactive and predictive modes of FMIPv6 are explained. Xia & Sarikaya Expires January 6, 2008 [Page 2] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. FMIPv6 Operation on Point-to-Point Links . . . . . . . . . . . 6 4.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Applicability of Solutions . . . . . . . . . . . . . . . . 9 5. HI and Hack Extension . . . . . . . . . . . . . . . . . . . . 9 5.1. HI Extension . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. HAck Extension . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Dedicated Prefix Option . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative references . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Xia & Sarikaya Expires January 6, 2008 [Page 3] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 1. Introduction Fast handovers for Mobile IPv6 (FMIPv6) [I-D.ietf-mipshop-fmipv6-rfc4068bis] aims at reducing the handover latency by reducing the time to configure a new care-of address (CoA) for a mobile node (MN). In FMIPv6, MN formulates a prospective new CoA (NCoA) when it is still present on the previous access router (PAR)'s 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 based on the recommendations in [RFC3314]. 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. In Section 3 we describe why the point-to-point link address formation procedures are needed in FMIPv6, in Section 4 we define various procedures NAR can use to assign per-MN prefixes in point-to- point links and in Section 5 we define necessary messages/option for the operation in Section 4. 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 [I-D.ietf-mipshop-fmipv6-rfc4068bis], 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 a separate, unique prefix or a set of unique prefixes by the AR. Please refer to [I-D.ietf-16ng-ipv6-link-model-analysis] for detail. In this model, a host's only neighbor is its default router. Xia & Sarikaya Expires January 6, 2008 [Page 4] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 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 (IGMP, 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 aggregate prefix upstream. Dedicated Prefix: A unique prefix used by MN in Point-to-Point Link Model. Provisional NCoA: The prefix part of the NCoA is an aggregate prefix or a special prefix. Modified NCoA: The prefix part of the NCoA is a dedicated prefix. 3. Problem Statement The following are operations as per [I-D.ietf-mipshop-fmipv6-rfc4068bis]: o Movement detection. The protocol enables an MN to quickly detect that it has moved to a new subnet by providing the new access point and the associated subnet prefix information when the MN is still connected to its current subnet. For instance, an MN may discover available access points using link-layer specific mechanisms (i.e., a "scan" in WLAN) and then request subnet information corresponding to one or more of those discovered access points. 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, which an MN can use in readily detecting movement: when attachment to an access point with AP-ID takes place, the MN knows the corresponding new router's coordinates including its prefix, IP address, and L2 address. o NCoA configuration. AR-Info contains an access router'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 to an Xia & Sarikaya Expires January 6, 2008 [Page 5] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 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. NCoA formulation process in point-to-point links depends on the type of prefix offered in AR-Info. [I-D.ietf-mipshop-fmipv6-rfc4068bis] does not specify such dependencies. If a dedicated prefix is offered, then PAR SHOULD request the dedicated prefix from NAR and the prefix SHOULD be reclaimed if MN does not complete the handover. If an aggregate prefix is offered, then a modified NCoA SHOULD be formulated from the dedicated prefix. After NCoA is formulated from a dedicated prefix, other operations such as proxying NCoA with proxy neighbor cache at the NAR and duplicate address detection need to be specified. This is also missing in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. In short, FMIPv6 operation on point-to-point (p2p) links needs to be defined. We next define the operations related to NCoA formulation on point-to-point links. 4. FMIPv6 Operation on Point-to-Point Links Three different solutions are proposed. 4.1. Solution 1 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. In the PrRtAdv message, A-bit and L-bit MUST be turned on. New FMIPv6 message exchange is introduced for PAR to ask for MN's dedicated prefix as shown in Figure 1. In [I-D.ietf-mipshop-fmipv6-rfc4068bis], HI is assumed to be sent after the FBU for handover indication. Here, modified of HI/Hack messages are used for prefix request/response. Details are described in Section 5. The new AP-ID is included in RtSolPr for PAR to locate the corresponding NAR. NAR MAY use DHCP prefix delegation (PD) to request/ release prefixes from a DHCP server. NAR collocated with DHCP Client MAY use the signaling defined in [I-D.sarikaya-16ng-prefix-delegation] after Xia & Sarikaya Expires January 6, 2008 [Page 6] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 being triggered by the HI for prefix request. NAR MAY also use AAA prefix delegation (PD) to request/ release prefixes for this MN from an AAA server. NAR collocated with AAA Client MAY use the signaling defined in [I-D.sarikaya-16ng-prefix-delegation] after being triggered by the HI message for prefix request. MN PAR NAR DHCP/AAA Server | | | | |------RtSolPr------->| | | | | HI(Prefix Request) | | | |------------------------->|Prefix | | | |-Request->| | | |<-Reply---| | | HAck(Prefix Response) | | | |<-------------------------| | |<-----PrRtAdv--------| | | | | |No FBU | | | |Release | | | |Prefix | |------FBU----------->|--------HI--------------->| | | |<------HAck---------------| | | <--FBack---|--FBack---> | | disconnect forward | | | packets=====================>| | | | | | | | | | connect | | | | | | | |--------- UNA --------------------------------->| | |<=================================== deliver packets | | | | Figure 1: Prefix Signaling In Network-initiated Handover scenario, there isn't specific RtSolPr to trigger PAR to request a prefix. In this case, implementation specific trigger SHOULD be used by PAR to send HI for prefix request. 4.2. Solution 2 The main idea of this solution is to include an aggregate prefix in the AR-Info and the MN then uses this 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 predictive mode of FMIPv6: Xia & Sarikaya Expires January 6, 2008 [Page 7] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 o An MN receives aggregate prefix in AR-Info of PrRtAdv, and formulates its provisional NCoA according to [RFC2462], [RFC3041] or other mechanisms. Then, the MN sends FBU message to PAR with NCoA option, link layer information of MN, and so on. The PAR sends this information to an NAR in HI message. In order to determine the NAR's address for the HI message, the PAR can perform longest prefix match of NCoA (in FBU) with the prefix list of neighboring access routers. o HI message defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] is extended here. A Code value of 3 is defined Section 5.1. o On receiving the HI, NAR processes the message as per [I-D.ietf-mipshop-fmipv6-rfc4068bis] if the Code value is not 3. Otherwise, the NAR allocates one or more dedicated prefixes for the MN based on it's link-layer information contained in HI message. NAR generates a new NCoA by replacing the provisional NCoA's prefix part with the dedicated prefix. o The modified NCoA is then delivered to the MN in the NCoA field of HAck/FBack messages. MN MUST use the modified NCoA. The following adaptation can be used in the reactive mode of FMIPv6: o MN sends UNA to NAR. The source address of UNA is the provisional NCoA. If the prefix of the NCoA in the UNA message is not an aggregate prefix, the NAR processes the message as per [I-D.ietf-mipshop-fmipv6-rfc4068bis]. Otherwise, the NAR assigns one or more prefixes for the MN based on Link-Layer Address (LLA) option in the UNA. NAR MAY use DHCP/AAA protocol to request/ release prefixes for this MN from a DHCP/AAA server triggered by UNA using [I-D.sarikaya-16ng-prefix-delegation]. A modified NCoA is formulated by replacing the provisional NCoA's prefix part with the dedicated prefix. The NAR MUST send a Router Advertisement with the NAACK option in which it includes the modified NCoA to the source IP address present in UNA. The MN MUST use the modified NCoA. NAR MAY advertise more dedicated prefixes to MN in subsequent RAs. o MN sends the FBU to the PAR with source address set to the modified NCoA. 4.3. Solution 3 There are two main functions for PrRtAdv and RtSolPr exchange. One is fast movement detection, and the other is prefix acquisition for NCoA formulation [I-D.ietf-mipshop-fmipv6-rfc4068bis]. In this solution, RtSolPr is not necessary, while PrRtAdv is only used for fast movement detection. An unsolicited PrRtAdv is used to inform the MN about geographically adjacent ARs without the MN having to explicitly request that information. This can reduce the amount of wireless traffic required for the MN to obtain a neighborhood Xia & Sarikaya Expires January 6, 2008 [Page 8] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 topology map of links and ARs. When attachment to an access point with AP-ID takes place, the MN knows the corresponding new router's co-ordinates including its IP address and L2 address, and thus MN can decide to attach to the NAR or not. MN initiates fast handover procedure once movement detection occurs. At first, MN formulates a provisional NCoA without any information about it's new prefix in the coming handover, so it uses a special prefix which could be all-one or a random value to stuff the prefix part of the NCoA. The special prefix could also be the prefix MN receives in AR-Info [I-D.ietf-mipshop-fmipv6-rfc4068bis]. The interface identifier part of the NCoA is calculated according to [RFC2462], [RFC3041] or other mechanism. In the predictive mode, MN sends FBU with provisional NCoA from PAR's link. The new AP-ID is included in FBU for PAR to locate the corresponding NAR. PAR then sends HI to NAR. HI message defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] is extended here. A Code value of 3 is defined Section 5.1. On receiving the HI, NAR processes the message as per [I-D.ietf-mipshop-fmipv6-rfc4068bis] if the Code value is not 3. Otherwise, NAR allocates a dedicated prefix for MN, replaces prefix part of the provisional NCoA and sends HAck in response. In the reactive mode, MN first sends UNA to NAR. The source address of UNA is the provisional NCoA. NAR then allocates a dedicated prefix, replaces the special prefix of the provisional NCoA with the dedicated prefix, and sends a RA with an NAACK option in which the modified NCoA is included. The MN SHOULD use the modified NCoA. Subsequently, MN sends the FBU to the PAR with source address set to the modified NCoA. 4.4. Applicability of Solutions Comparing with solution 2 and solution 3, solution 1 has better compatibility with the specification defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis], even though there are two new messages exchanged between ARs. 5. HI and Hack Extension 5.1. HI Extension The Handover Initiate (HI)defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] is an ICMPv6 message sent by an Access Router (typically PAR) to another Access Router (typically Xia & Sarikaya Expires January 6, 2008 [Page 9] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 NAR) to initiate the process of a MN's handover. In this document, HI is extended with two new code values: o In [I-D.ietf-mipshop-fmipv6-rfc4068bis], the PAR uses a Code value of 0 when it processes an FBU with PCoA as source IP address, while uses a Code value of 1 when it processes an FBU whose source IP address is not PCoA. A new Code value of 2 is used for dedicated prefix request. Dedicated Prefix Option defined in Section 5.3 MAY be included. NAR allocates dedicated prefix based on the prefix preference in the option. If the option is not included, NAR allocates prefix according it's discretion. o A new code value of 3 is used by PAR to indicate NAR allocating a dedicated prefix for MN, replacing prefix part of the provisional NCoA to formulate a modified NCoA, and sending HAck in response in Solution 2 or Solution 3. 5.2. HAck Extension Handover Acknowledgment message defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] is a new ICMPv6 message that MUST be sent (typically by NAR to PAR) as a reply to the Handover Initiate message. In this document, HAck is extended to respond to a dedicated prefix request. o One new Code value is defined. Here, a Code value of 6 is used for dedicated prefix response. o Dedicated Prefix Option defined in Section 5.3 MUST be included for prefix delegation. 5.3. Dedicated Prefix Option This option is of the form shown in Figure 2. 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 | Length | Option-Code | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Xia & Sarikaya Expires January 6, 2008 [Page 10] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 Figure 2: Dedicated Prefix Option Type To be assigned by IANA Length The length of the option in units of 8 octets. Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. Option-Code 1 Dedicated Prefix Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent). A value of all one bits (0xffffffff) represents infinity. Prefix An IP address or a prefix of an IP address. MN uses it prefix to formulate NCoA 6. Security Considerations FMIPv6 operation on point-to-point links does not introduce any new security threats and the security provided by FMIPv6 applies completely. 7. IANA consideration This document extends existing HI/HAck messages, new Code values need to be assigned by IANA. The document defines one new Mobility Option which needs type assignment from the Mobility Options Type registry at http://www.iana.org/assignments/mobility-parameters: 1. Dedicated Prefix Option described in Section 5.3. 8. Acknowledgements The authors would like to thank Heejin Jang, Daniel Park and Rajeev Koodli for valuable comments. Xia & Sarikaya Expires January 6, 2008 [Page 11] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-mipshop-fmipv6-rfc4068bis] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fmipv6-rfc4068bis-01 (work in progress), March 2007. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. 9.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. [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-09 (work in progress), April 2007. [I-D.ietf-16ng-ipv6-link-model-analysis] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 based Networks", draft-ietf-16ng-ipv6-link-model-analysis-03 (work in progress), February 2007. [I-D.sarikaya-16ng-prefix-delegation] Sarikaya, B. and F. Xia, "Using DHCPv6 and AAA Server for Mobile Station Prefix Delegation", draft-sarikaya-16ng-prefix-delegation-01 (work in progress), March 2007. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. Xia & Sarikaya Expires January 6, 2008 [Page 12] Internet-Draft FMIPv6 over Point-to-Point Links July 2007 Authors' Addresses Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Xia & Sarikaya Expires January 6, 2008 [Page 13] Internet-Draft FMIPv6 over Point-to-Point Links July 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 January 6, 2008 [Page 14]