Network Working Group F. Xia Internet-Draft B. Sarikaya Intended status: Informational Huawei USA Expires: September 5, 2009 March 4, 2009 Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links draft-xia-mipshop-fmip-ptp-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 September 5, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Xia & Sarikaya Expires September 5, 2009 [Page 1] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Xia & Sarikaya Expires September 5, 2009 [Page 2] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 Abstract The Mobile IPv6 Fast Handovers (FMIPv6) specification currently does not explicitly define prefix management over point-to-point links when a Mobile Node (MN) uses a prefix to formulate a new Care-of- Address (CoA). In this document a mechanism is developed for assigning unique prefixes to the MN by the Previous Access Router (PAR). The New Access Router (NAR) dynamically assigns a unique prefix called dedicated prefix to any MN that is performing a handover. Both reactive and predictive modes of FMIPv6 are explained. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Prefix Management on Point-to-Point Links . . . . . . . . . . 6 4.1. Predictive mode . . . . . . . . . . . . . . . . . . . . . 6 4.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 7 5. HI and Hack Extension . . . . . . . . . . . . . . . . . . . . 8 5.1. HI Extension . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. HAck Extension . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Dedicated Prefix Option . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative references . . . . . . . . . . . . . . . . . . 10 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Xia & Sarikaya Expires September 5, 2009 [Page 3] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 1. Introduction Mobile IPv6 Fast Handovers (FMIPv6) [I-D.ietf-mipshop-rfc5268bis] aims at reducing the handover latency by reducing the time to configure a new care-of address (NCoA) for a MN. In FMIPv6, the MN formulates a prospective NCoA when it is still present on the PAR's link. [RFC4968] 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. [RFC5121] 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 description of prefix management for 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 a procedure NAR can use to dynamically assign unique 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-rfc5268bis], in addition to the ones specified in this section. Point-to-Point Link Model: In this model, a set of MAC transport connections between a 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 [RFC4968] for detail. In this model, a host's only neighbor is its default router. Xia & Sarikaya Expires September 5, 2009 [Page 4] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 Dedicated Prefix: A unique prefix used by a MN in point-to-point link model. 3. Problem Statement The following are operations as per [I-D.ietf-mipshop-rfc5268bis]: o Movement detection. The protocol enables a 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, the 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. A MN sends a Router Solicitation for Proxy Advertisement (RtSolPr) to its access router to resolve one or more Access Point Identifiers (AP-ID) 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 a 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 a MN attaches to 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. NCoA formulation in point-to-point links requires a PAR to dynamically request a dedicated prefix from a NAR, and then advertise it to the MN through a Proxy Router Advertisement (PrRtAdv) message. [I-D.ietf-mipshop-rfc5268bis] does not specify such dependencies. 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. Xia & Sarikaya Expires September 5, 2009 [Page 5] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 4. Prefix Management on Point-to-Point Links The best solution 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 to MN. In the PrRtAdv message, A-bit and L-bit MUST be turned on. MN creates its NCoA based on the prefix received in PrRtAdv message. 4.1. Predictive mode 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-rfc5268bis], HI is assumed to be sent after the FBU for handover indication. Here, modified HI/Hack messages are used for prefix request/response. Details are described in Section 5. NAR MAY use DHCP prefix delegation (PD) to request/ release prefixes from a DHCP server. The DHCP messages are 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. The mechanisms for NAR to acquire the prefixes are outside the scope of this document. Lifetime in Dedicated Prefix Option Figure 1 is used to prevent prefix depletion because of erroneous movement in which the mobile node receives a dedicated prefix prior to a handover that it is moving to a new access point but it either moves to a different one or it aborts movement altogether. Not until timeout of the prefix does the NAR release it. Xia & Sarikaya Expires September 5, 2009 [Page 6] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 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 some wireless networks, the handover control may reside in the network even though the decision to undergo handover may be mutually agreed between the MN and the network. In such a case, the PAR can send an unsolicited PrRtAdv containing the link-layer address, IP address, and dedicated prefix of the mobile node when the network decides that a handover is imminent. In this network-initiated handover scenario, there isn't explicit RtSolPr to trigger PAR to request a prefix and implementation specific trigger MUST be used by PAR to send HI message for prefix request. 4.2. Reactive Mode In the reactive mode, there are two cases. A MN receives PrRtAdv message or otherwise. o The MN receives PrRtAdv message and formulates NCoA before attaching to the NAR. The MN and the NAR operate in line with the procedure defined in [I-D.ietf-mipshop-rfc5268bis]. Xia & Sarikaya Expires September 5, 2009 [Page 7] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 o The MN can't formulate NCoA before attaching to the NAR. IP connectivity should be established first. The MN can configure its IP address using stateless address configuration, or using stateful address configuration. In the former case, the NAR SHOULD send un-solicited RA to expedite MN's address configuration. Once NCoA formulation is finished, the MN operates according to [I-D.ietf-mipshop-rfc5268bis]. In both cases, MN formulates NCoA from the dedicated prefix. Since MN has already handed over to NAR this prefix is retained. 5. HI and Hack Extension 5.1. HI Extension The Handover Initiate (HI),defined in [I-D.ietf-mipshop-rfc5268bis], is a Mobility Header message sent by an Access Router (typically PAR) to another Access Router (typically NAR) to initiate the process of a MN's handover. In [I-D.ietf-mipshop-rfc5268bis], 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 the 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 a prefix according to it's discretion. 5.2. HAck Extension Handover Acknowledgment message defined in [I-D.ietf-mipshop-rfc5268bis] is a Mobility Header 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. Xia & Sarikaya Expires September 5, 2009 [Page 8] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 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 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. A MN uses it to formulate NCoA. 6. Security Considerations Prefix management for FMIPv6 operation on point-to-point links introduces two messages (HI/Hack) for prefix request and response. These messages are secured using FMIPv6 security mechanisms and hence do not introduce any new security threats and the security provided Xia & Sarikaya Expires September 5, 2009 [Page 9] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 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, Vijay Devarapalli, Rajeev Koodli, and Spencer Dawkins for valuable comments. 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-rfc5268bis] Koodli, R., "Mobile IPv6 Fast Handovers", draft-ietf-mipshop-rfc5268bis-00 (work in progress), February 2009. [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008. 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. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", Xia & Sarikaya Expires September 5, 2009 [Page 10] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 RFC 3314, September 2002. [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 Based Networks", RFC 4968, August 2007. Xia & Sarikaya Expires September 5, 2009 [Page 11] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 Appendix A. Change Log o v03 Dedicated Prefix Option made compatible with [I-D.ietf-mipshop-rfc5268bis]. Xia & Sarikaya Expires September 5, 2009 [Page 12] Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009 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 September 5, 2009 [Page 13]